Din privata HLS-ström laddas för dig, inte för dina tittare

Du testar sidan på laptop, spelaren startar och ärendet stängs. Tittaren i andra änden öppnar samma sida och får en snurra som aldrig löses upp. Den vanliga förklaringen är att VPN:en ligger på servern, så uppspelningen borde fungera — men just webbläsaren är komponenten som begär spellistan, och den har sin egen nätverksväg. En sida inbäddad på en server med privat åtkomst lånar inte ut den åtkomsten till den som laddar sidan.

Det handlar om en befintlig ASP.NET-sida som spelar upp en HLS-källa som http://10.5.5.9:8080/live/stream.m3u8, vilket är en illustrativ privat adress. Två uppställningar fungerar; en av dem är förmodligen inte den du byggde.

Myt: en sida som laddas bevisar medievägen

HTML:en för den sidan kommer från din webbserver, över vilken väg din webbserver nu har. Spellistan och segmenten kommer från mediekällan, över vilken väg den begärande komponenten nu har. När spelaren körs i tittarens webbläsare är det två olika klienter, två olika källadresser och ofta två olika feldomäner. Att den första lyckas säger ingenting om den andra.

Det ditt test faktiskt bevisade är snävare än det såg ut: din maskin når både den offentliga sidan och den privata medievärden samtidigt. Tittarens maskin var aldrig en del av experimentet.

Vad spellistan begär härnäst

RFC 8216 skiljer mediespellistor, som listar segment, från huvudspellistor, som listar andra spellistor, och löser relativa URI:er mot URI:n för den spellista som innehåller dem. Just den regeln hoppar folk över. Att en .m3u8-fil hämtas framgångsrikt är inget uppspelningstest, eftersom filen du hämtade är ett index, inte mediet.

Följ kedjan som spelaren gör: öppna den valda spellistan, begär sedan de resurser den namnger och följ sedan eventuella omdirigeringar. En spellista som serveras via en nåbar webbserver kan fortfarande skicka tittaren till en onåbar privat adress. På samma sätt ändrar flytten av en relativ spellista till en annan URL den bas som dess poster löses mot, och därför ger omskrivningen av den första synliga URL:en och att stanna där oftast en spellista som ser giltig ut men inte kan spelas upp.

Direkt visning: tittaren behöver vägen

Om tittarna ska nå medievärden direkt behöver deras enheter den godkända VPN:en eller en annan privat väg, DNS som löser de namn du faktiskt använde, tillstånd att nå dessa destinationer och all autentisering som medietjänsten kräver. Kontrollera var och en på tittarens enhet i stället för på servern. En webbläsare på en telefon med VPN-profilen installerad men inte ansluten är ett vanligt och helt reproducerbart fel.

Den här uppställningen håller källan privat och knuffar över åtkomstkravet på publiken. Det är ett policybeslut lika mycket som ett tekniskt, så bekräfta att varje avsedd tittare får ha den vägen innan du designar runt den.

Leverans från servern: en kontrollerad ingångspunkt

Alternativet är en auktoriserad mediefrontend som hämtar källan över sin privata väg och publicerar bara de resurser som tittaren möter. Håll spellistan, segmenten och eventuella nyckelresurser konsekventa med den enda ingångspunkten, annars hämtar spelaren en omskriven spellista via frontend och segmenten direkt från en adress som tittaren inte kan nå.

Begränsa källan och de tillåtna vägarna i den frontenden. En godtycklig URL som användaren anger gör en användbar proxy till en obegränsad hämtare av ditt interna nätverk, vilket är ett mycket värre problem än en ström som inte spelas upp. Sätt källan och vägprefixet på en tillåten lista i stället för att validera strängen i efterhand.

För en befintlig HLS-källa, kontrollera först om kontrollerad vidarebefordran räcker; en VPN i mitten betyder inte att transkodning krävs. Validera sedan den faktiska kombinationen av webbläsare och codec, eftersom ett nåbart svar och ett stödt format är två separata villkor. Håll källans TLS, autentisering och webbläsarsäkerhetskrav intakta — en inbäddad spelare är inget undantag från dem.

Testa kedjan, inte URL:en

Kör kontrollerna från komponenten som faktiskt kommer att skicka varje begäran och behandla varje steg som sitt 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

Upprepa det sedan i tittarens egen webbläsare med den avsedda strömmen, inte med ett testmönster från ditt skrivbord. Sidladdning, laddning av spellistan, hämtning av segmentet och ett auktoriseringsfel är fyra olika utfall, och du vill ha alla fyra observerade innan du kallar det åtgärdat. Installera inte ett föråldrat webbläsartillägg för att ett gammalt exempel spelade en ström så; den saknade biten är oftast tittarens väg eller segmentets osignerade URL.

När uppställningen är medveten, skriv ner den på en rad: vem hämtar mediet, över vilken väg och vad tittaren får begära. Den meningen avgör de flesta framtida diskussioner om vem strömmen egentligen är till för.