Din private HLS-stream indlæses for dig, ikke for dine seere

Du tester siden på din bærbare computer, afspilleren starter, og sagen lukkes. Seeren i den anden ende åbner den samme side og får en spinner, der aldrig falder til ro. Den sædvanlige forklaring er, at VPN’en ligger på serveren, så afspilning burde virke — men det er browseren, der beder om afspilningslisten, og den har sin egen netværksvej. En side, der er indlejret på en server med privat adgang, udlåner ikke den adgang til den, der indlæser den.

Det handler om en eksisterende ASP.NET-side, der afspiller en HLS-kilde som http://10.5.5.9:8080/live/stream.m3u8, som er en illustrativ privat adresse. To opsætninger virker; en af dem er sandsynligvis ikke den, du har bygget.

Myte: en indlæst side beviser mediebanen

HTML’en til den side kommer fra din webserver, ad hvilken som helst rute din webserver har. Afspilningslisten og segmenterne kommer fra medieoprindelsen, ad hvilken som helst rute den anmodende komponent har. Når afspilleren kører i seerens browser, er det to forskellige klienter, to forskellige kildeadresser og ofte to forskellige fejldomæner. At se den første lykkes siger intet om den anden.

Hvad din test faktisk beviste, er snævrere, end det så ud: din maskine kan nå den offentlige side og den private medievært samtidig. Seerens maskine var aldrig en del af eksperimentet.

Hvad afspilningslisten beder om næste gang

RFC 8216 adskiller medieafspilningslister, der lister segmenter, fra masterafspilningslister, der lister andre lister, og opløser relative URI’er mod URI’en for den liste, der indeholder dem. Den regel er den del, folk springer over. At hente én .m3u8-fil med succes er ikke en afspilningstest, for den fil, du hentede, er et indeks, ikke mediet.

Følg kæden, som afspilleren gør det: åbn den valgte liste, bed derefter om de ressourcer, den navngiver, og følg derefter enhver omdirigering. En liste, der leveres gennem en tilgængelig webserver, kan stadig pege seeren mod en utilgængelig privat adresse. På samme måde ændrer flytningen af en relativ liste til en anden URL den base, dens poster opløses imod, og derfor giver omskrivningen af den første synlige URL og stop der normalt en liste, der ser gyldig ud, men ikke kan afspille.

Direkte visning: seeren har brug for banen

Hvis seerne skal nå medieværten direkte, har deres enheder brug for den godkendte VPN eller en anden privat rute, DNS der opløser de navne, du faktisk brugte, tilladelse til at nå de destinationer og den autentificering, medietjenesten kræver. Kontroller hver af dem på seerens enhed i stedet for på serveren. En browser på en telefon med VPN-profilen installeret men ikke forbundet er en hyppig og fuldstændig reproducerbar fejl.

Denne opsætning holder kilden privat og skubber adgangskravet over på publikum. Det er en politisk beslutning lige så meget som en teknisk, så bekræft, at hver tilsigtet seer har lov til at holde den bane, før du designer omkring den.

Levering fra serveren: ét kontrolleret indgangspunkt

Alternativet er en autoriseret mediefrontend, der henter kilden over sin private bane og genudgiver kun de ressourcer, seeren møder. Hold afspilningslisten, segmenterne og eventuelle nøgleressourcer i overensstemmelse med det ene indgangspunkt, ellers henter afspilleren en omskrevet liste gennem frontenden og segmenterne direkte fra en adresse, seeren ikke kan nå.

Begræns kilden og de tilladte baner i den frontend. En vilkårlig URL fra brugeren gør en nyttig proxy til en ubegrænset henter af dit interne netværk, hvilket er et langt værre problem end en stream, der ikke vil afspille. Sæt kilden og banepræfikset på en tilladelsesliste i stedet for at validere strengen bagefter.

For en eksisterende HLS-kilde, kontroller først, om kontrolleret videresendelse er nok; en VPN i midten betyder ikke, at transkodning er påkrævet. Validér derefter den faktiske kombination af browser og codec, for et tilgængeligt svar og et understøttet format er to separate betingelser. Hold oprindelsens TLS, autentificering og browsersikkerhedskrav intakte — en indlejret afspiller er ikke en undtagelse fra dem.

Test kæden, ikke URL’en

Kør kontrollerne fra den komponent, der rent faktisk sender hver anmodning, og behandl hvert trin som sit eget resultat:

curl -s http://10.5.5.9:8080/live/stream.m3u8
curl -s -o /dev/null -w '%{http_code}\n' http://10.5.5.9:8080/live/segment-000123.ts

Gentag det derefter i seerens egen browser med den tilsigtede stream, ikke et testmønster fra dit skrivebord. Sideindlæsning, indlæsning af listen, hentning af segmentet og en autorisationsfejl er fire forskellige udfald, og du vil have alle fire observeret, før du kalder det løst. Installer ikke et forældet browserplugin, fordi et gammelt eksempel afspillede én stream sådan; den manglende brik er normalt seerens bane eller segmentets usignerede URL.

Når opsætningen er bevidst, skriv den ned på én linje: hvem henter mediet, ad hvilken bane, og hvad seeren må anmode om. Den sætning afgør de fleste fremtidige diskussioner om, hvem streamen egentlig er for.