Váš súkromný HLS stream sa načítava pre vás, nie pre vašich divákov

Testujete stránku na notebooku, prehrávač sa spustí a tiket sa zatvorí. Divák na druhej strane otvorí rovnakú stránku a dostane indikátor, ktorý sa nikdy nedorieši. Zvyčajné vysvetlenie je, že VPN je na serveri, takže prehrávanie by malo fungovať — ale práve prehliadač je komponent, ktorý si vyžaduje zoznam skladieb, a má vlastnú sieťovú cestu. Stránka vložená na serveri s privátnym prístupom tento prístup nepožičiava tomu, kto ju načíta.

Ide o existujúcu stránku ASP.NET, ktorá prehráva zdroj HLS, napríklad http://10.5.5.9:8080/live/stream.m3u8, čo je ilustratívna privátna adresa. Fungujú dve usporiadania; jedno z nich pravdepodobne nie je to, ktoré ste postavili.

Mýtus: načítaná stránka dokazuje cestu k médiám

HTML tej stránky prichádza z vášho webového servera, po akejkoľvek trase váš webový server má. Zoznam skladieb a segmenty prichádzajú z mediálneho zdroja, po akejkoľvek trase má komponent, ktorý posiela požiadavku. Keď prehrávač beží v prehliadači diváka, sú to dvaja rôzni klienti, dve rôzne zdrojové adresy a často dve rôzne domény zlyhania. To, že prvý uspeje, nehovorí o druhom nič.

Čo váš test skutočne dokázal, je užšie, než to vyzeralo: váš stroj dosiahne súčasne verejnú stránku aj privátny mediálny hostiteľ. Stroj diváka nikdy nebol súčasťou experimentu.

Čo si zoznam skladieb vyžiada ďalej

RFC 8216 oddeľuje mediálne zoznamy skladieb, ktoré vypočítavajú segmenty, od hlavných zoznamov, ktoré vypočítavajú iné zoznamy, a rieši relatívne URI voči URI zoznamu, ktorý ich obsahuje. Práve toto pravidlo ľudia preskakujú. Úspešné stiahnutie jedného súboru .m3u8 nie je test prehrávania, pretože stiahnutý súbor je index, nie médiá.

Sledujte reťaz tak, ako to robí prehrávač: otvorte zvolený zoznam, potom si vyžiadajte zdroje, ktoré pomenúva, a potom nasledujte akékoľvek presmerovanie. Zoznam poskytovaný cez dostupný webový server môže diváka stále nasmerovať na nedostupnú privátnu adresu. Rovnako presun relatívneho zoznamu na inú URL mení základ, voči ktorému sa jeho položky riešia, a preto prepísanie prvej viditeľnej URL a zastavenie na tom mieste zvyčajne vytvorí zoznam, ktorý vyzerá platne, ale nedá sa prehrať.

Priame sledovanie: divák potrebuje cestu

Ak majú diváci dosiahnuť mediálneho hostiteľa priamo, ich zariadenia potrebujú schválenú VPN alebo inú privátnu cestu, DNS, ktoré rieši mená, ktoré ste skutočne použili, povolenie dosiahnuť tieto destinácie a akúkoľvek autentifikáciu, ktorú mediálna služba vyžaduje. Overujte každú položku na zariadení diváka, nie na serveri. Prehliadač v telefóne s nainštalovaným, ale nepripojeným profilom VPN je častá a úplne reprodukovateľná porucha.

Toto usporiadanie udržiava zdroj v súkromí a presúva požiadavku na prístup na publikum. Je to politické rozhodnutie rovnako ako technické, preto pred návrhom potvrďte, že každý zamýšľaný divák smie mať túto cestu.

Doručenie zo servera: jeden riadený vstupný bod

Alternatívou je autorizovaný mediálny frontend, ktorý zdroj stiahne po svojej privátnej ceste a znova publikuje len prostriedky určené divákovi. Udržujte zoznam, segmenty a akékoľvek kľúčové prostriedky v súlade s týmto jediným vstupným bodom, inak prehrávač stiahne prepísaný zoznam cez frontend a segmenty priamo z adresy, na ktorú divák nedosiahne.

Obmedzte zdroj a povolené cesty v tomto frontende. Ľubovoľná URL zadaná používateľom mení užitočný proxy na neobmedzený sťahovač vašej internej siete, čo je oveľa horší problém než stream, ktorý sa neprehrá. Dajte zdroj a prefix cesty na zoznam povolených, namiesto toho, aby ste reťazec overovali dodatočne.

Pri existujúcom zdroji HLS najprv overte, či stačí riadené preposielanie; VPN v strede neznamená, že je potrebné prekódovanie. Potom overte skutočnú kombináciu prehliadača a kodeku, pretože dostupná odpoveď a podporovaný formát sú dve oddelené podmienky. Zachovajte TLS, autentifikáciu a bezpečnostné požiadavky prehliadača zdroja nedotknuté — vložený prehrávač z nich nie je vyňatý.

Testujte reťaz, nie URL

Spúšťajte kontroly z komponentu, ktorý naozaj odošle každú požiadavku, a každý krok berte ako jeho vlastný výsledok:

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

Potom to zopakujte v prehliadači samotného diváka s plánovaným streamom, nie s testovacím vzorom zo svojho stola. Načítanie stránky, načítanie zoznamu, získanie segmentu a zlyhanie autorizácie sú štyri odlišné výsledky a chcete mať videné všetky štyri, kým to vyhlásite za opravené. Neinštalujte zastaraný doplnok prehliadača len preto, že starý príklad takto prehral jeden stream; chýbajúci diel je zvyčajne cesta diváka alebo nepodpísaná URL segmentu.

Keď je usporiadanie zámerné, zapíšte ho jedným riadkom: kto sťahuje médiá, po akej ceste a čo smie divák žiadať. Tá veta vyrieši väčšinu budúcich sporov o to, pre koho je stream vlastne určený.