Testirate stranicu na prijenosniku, player se pokrene i tiket se zatvori. Gledatelj na drugoj strani otvori istu stranicu i dobije spinner koji se nikada ne razriješi. Uobičajeno objašnjenje je da je VPN na poslužitelju, pa bi reprodukcija trebala raditi — ali preglednik je komponenta koja traži popis za reprodukciju i ima vlastitu mrežnu putanju. Stranica ugrađena na poslužitelj s privatnim pristupom ne posuđuje taj pristup onome tko je učita.

Riječ je o postojećoj ASP.NET stranici koja reproducira HLS izvor poput http://10.5.5.9:8080/live/stream.m3u8, što je ilustrativna privatna adresa. Rade dva rasporeda; jedan od njih vjerojatno nije onaj koji ste izgradili.

Mit: učitana stranica dokazuje medijsku putanju

HTML te stranice dolazi s vašeg web poslužitelja, kojim god putem vaš web poslužitelj raspolaže. Popis za reprodukciju i segmenti dolaze s medijskog izvora, kojim god putem raspolaže komponenta koja šalje zahtjev. Kada player radi u pregledniku gledatelja, to su dva različita klijenta, dvije različite izvorne adrese i često dvije različite domene kvara. To što prvi uspije ne govori ništa o drugom.

Ono što je vaš test zapravo dokazao uže je nego što je izgledalo: vaše računalo može istovremeno doći do javne stranice i do privatnog medijskog hosta. Računalo gledatelja nikada nije bilo dio eksperimenta.

Što popis za reprodukciju traži dalje

RFC 8216 razdvaja medijske popise za reprodukciju, koji navode segmente, od glavnih popisa za reprodukciju, koji navode druge popise, i razrješava relativne URI-je prema URI-ju popisa koji ih sadrži. To pravilo je dio koji ljudi preskaču. Uspješno dohvaćanje jedne .m3u8 datoteke nije test reprodukcije, jer je dohvaćena datoteka indeks, a ne medij.

Pratite lanac onako kako to čini player: otvorite odabrani popis, zatim zatražite resurse koje navodi, zatim slijedite svako preusmjeravanje. Popis poslužen preko dostupnog web poslužitelja ipak može usmjeriti gledatelja na nedostupnu privatnu adresu. Jednako tako, premještanje relativnog popisa na drugi URL mijenja osnovu prema kojoj se razrješavaju njegovi unosi, i zato prepisivanje prvog vidljivog URL-a i zaustavljanje na tome obično daje popis koji izgleda ispravno, ali se ne može reproducirati.

Izravno gledanje: gledatelju treba putanja

Ako gledatelji trebaju izravno dosegnuti medijskog hosta, njihovi uređaji trebaju odobreni VPN ili drugu privatnu putanju, DNS koji razrješava imena koja ste stvarno koristili, dopuštenje za dosezanje tih odredišta i bilo koju autentikaciju koju medijska usluga zahtijeva. Provjerite svaku stavku na uređaju gledatelja, a ne na poslužitelju. Preglednik na telefonu s instaliranim ali nepovezanim VPN profilom čest je i potpuno ponovljiv kvar.

Ovaj raspored čuva izvor privatnim i prebacuje zahtjev za pristupom na publiku. To je politička odluka koliko i tehnička, pa potvrdite da svaki predviđeni gledatelj smije držati tu putanju prije nego što dizajnirate oko nje.

Isporuka sa strane poslužitelja: jedna kontrolirana ulazna točka

Alternativa je ovlašteni medijski frontend koji dohvaća izvor preko svoje privatne putanje i ponovno objavljuje samo resurse okrenute gledatelju. Držite popis, segmente i sve ključne resurse usklađene s tom jednom ulaznom točkom, inače će player dohvatiti prepisani popis preko frontenda, a segmente izravno s adrese do koje gledatelj ne može doći.

Ograničite izvor i dopuštene putanje na tom frontendu. Proizvoljni URL koji dostavi korisnik pretvara koristan proxy u neograničeni dohvaćač vaše interne mreže, što je mnogo gori problem od toka koji se neće reproducirati. Stavite izvor i prefiks putanje na bijelu listu umjesto da niz provjeravate naknadno.

Za postojeći HLS izvor prvo provjerite je li kontrolirano prosljeđivanje dovoljno; VPN u sredini ne znači da je potrebno transkodiranje. Zatim provjerite stvarnu kombinaciju preglednika i kodeka, jer su dostupan odgovor i podržani format odvojeni uvjeti. Sačuvajte TLS, autentikaciju i sigurnosne zahtjeve preglednika netaknutima — ugrađeni player nije izuzet od njih.

Testirajte lanac, a ne URL

Izvodite provjere iz komponente koja će stvarno slati svaki zahtjev i tretirajte svaki korak kao zaseban rezultat:

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

Zatim to ponovite u gledateljevu vlastitom pregledniku s predviđenim tokom, a ne s testnim uzorkom sa svog stola. Učitavanje stranice, učitavanje popisa, dohvaćanje segmenta i neuspjeh autorizacije četiri su različita ishoda, i želite vidjeti sva četiri prije nego što to proglasite popravljenim. Ne instalirajte zastarjeli dodatak preglednika zato što je stari primjer tako reproducirao jedan tok; dio koji nedostaje obično je gledateljeva putanja ili nepotpisani URL segmenta.

Kada raspored postane namjeran, zapišite ga u jednom redu: tko dohvaća medij, kojom putanjom i što gledatelj smije tražiti. Ta rečenica rješava većinu budućih rasprava o tome za koga je tok stvarno namijenjen.

Povezani članci