Vaš privatni HLS strim se učitava za vas, a ne za vaše gledaoce

Testirate stranicu na prenosnom računaru, plejer se pokrene i tiket se zatvori. Gledalac na drugoj strani otvori istu stranicu i dobije spinner koji se nikada ne razreši. Uobičajeno objašnjenje je da je VPN na serveru, pa bi reprodukcija trebalo da radi — ali pregledač je komponenta koja traži plejlistu i ima sopstvenu mrežnu putanju. Stranica ugrađena na server sa privatnim pristupom ne pozajmljuje taj pristup onome ko je učita.

Reč je o postojećoj ASP.NET stranici koja reprodukuje HLS izvor kao što je http://10.5.5.9:8080/live/stream.m3u8, što je ilustrativna privatna adresa. Rade dva rasporeda; jedan od njih verovatno nije onaj koji ste napravili.

Mit: učitana stranica dokazuje medijsku putanju

HTML te stranice dolazi sa vašeg veb servera, kojim god putem vaš veb server raspolaže. Plejlista i segmenti dolaze sa medijskog izvora, kojim god putem raspolaže komponenta koja šalje zahtev. Kada plejer radi u pregledaču gledaoca, to su dva različita klijenta, dve različite izvorne adrese i često dva različita domena kvara. To što prvi uspe ne govori ništa o drugom.

Ono što je vaš test zapravo dokazao uže je nego što je izgledalo: vaša mašina može istovremeno da dođe do javne stranice i do privatnog medijskog hosta. Mašina gledaoca nikada nije bila deo eksperimenta.

Šta plejlista traži dalje

RFC 8216 razdvaja medijske plejliste, koje navode segmente, od glavnih plejlisti, koje navode druge plejliste, i razrešava relativne URI-je prema URI-ju plejliste koja ih sadrži. To pravilo je deo koji ljudi preskaču. Uspešno dohvatanje jednog .m3u8 fajla nije test reprodukcije, jer je dohvaćeni fajl indeks, a ne medij.

Pratite lanac onako kako to čini plejer: otvorite izabranu plejlistu, zatim zatražite resurse koje ona navodi, zatim pratite svako preusmeravanje. Plejlista poslužena preko dostupnog veb servera i dalje može da usmeri gledaoca na nedostupnu privatnu adresu. Isto tako, premeštanje relativne plejliste na drugi URL menja osnovu prema kojoj se razrešavaju njeni unosi, i zato prepisivanje prvog vidljivog URL-a i zaustavljanje na tome obično daje plejlistu koja izgleda ispravno, ali ne može da se reprodukuje.

Direktno gledanje: gledaocu treba putanja

Ako gledaoci treba direktno da dosegnu medijski host, njihovi uređaji trebaju odobreni VPN ili drugu privatnu putanju, DNS koji razrešava imena koja ste stvarno koristili, dozvolu da dosegnu te destinacije i bilo koju autentikaciju koju medijska usluga zahteva. Proverite svaku stavku na uređaju gledaoca, a ne na serveru. Pregledač na telefonu sa instaliranim ali nepovezanim VPN profilom je čest i potpuno ponovljiv kvar.

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

Isporuka sa strane servera: jedna kontrolisana ulazna tačka

Alternativa je ovlašćeni medijski frontend koji dohvata izvor preko svoje privatne putanje i ponovo objavljuje samo resurse okrenute gledaocu. Držite plejlistu, segmente i sve ključne resurse usklađene sa tom jednom ulaznom tačkom, inače će plejer dohvatiti prepisanu plejlistu preko frontenda, a segmente direktno sa adrese do koje gledalac ne može da dođe.

Ograničite izvor i dozvoljene putanje na tom frontendu. Proizvoljni URL koji korisnik dostavi pretvara koristan proksi u neograničeni dohvatač vaše interne mreže, što je mnogo gori problem od strima koji se neće reprodukovati. Stavite izvor i prefiks putanje na belu listu umesto da niz proveravate naknadno.

Za postojeći HLS izvor prvo proverite da li je kontrolisano prosleđivanje dovoljno; VPN u sredini ne znači da je potrebno transkodiranje. Zatim proverite stvarnu kombinaciju pregledača i kodeka, jer su dostupan odgovor i podržani format odvojeni uslovi. Sačuvajte TLS, autentikaciju i sigurnosne zahteve pregledača netaknutima — ugrađeni plejer nije izuzet od njih.

Testirajte lanac, a ne URL

Izvodite provere iz komponente koja će stvarno slati svaki zahtev 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 gledaočevom sopstvenom pregledaču sa predviđenim strimom, a ne sa testnim uzorkom sa svog stola. Učitavanje stranice, učitavanje plejliste, dohvatanje segmenta i neuspeh autorizacije su četiri različita ishoda, i želite da vidite sva četiri pre nego što to proglasite popravljenim. Ne instalirajte zastareli dodatak pregledača zato što je stari primer tako reprodukovao jedan strim; deo koji nedostaje obično je gledaočeva putanja ili nepotpisani URL segmenta.

Kada raspored postane nameran, zapišite ga u jednom redu: ko dohvata medij, kojom putanjom i šta gledalac sme da traži. Ta rečenica rešava većinu budućih rasprava o tome za koga je strim stvarno namenjen.