El vostre flux HLS privat es carrega per a vosaltres, no per als espectadors

Proveu la pàgina a l’ordinador portàtil, el reproductor arrenca i el tiquet es tanca. L’espectador de l’altre costat obre la mateixa pàgina i obté un indicador de càrrega que no s’acaba mai. L’explicació habitual és que la VPN és al servidor, així que la reproducció hauria de funcionar — però és el navegador el component que demana la llista de reproducció, i té la seva pròpia ruta de xarxa. Una pàgina incrustada en un servidor amb accés privat no presta aquest accés a qui la carrega.

Això tracta d’una pàgina ASP.NET existent que reprodueix una font HLS com ara http://10.5.5.9:8080/live/stream.m3u8, que és una adreça privada il·lustrativa. Funcionen dos arranjaments; un d’ells probablement no és el que heu construït.

Mite: una pàgina que carrega demostra la ruta dels mitjans

L’HTML d’aquesta pàgina ve del vostre servidor web, per la ruta que tingui el vostre servidor web. La llista de reproducció i els segments venen de l’origen dels mitjans, per la ruta que tingui el component que fa la petició. Quan el reproductor s’executa al navegador de l’espectador, són dos clients diferents, dues adreces d’origen diferents i sovint dos dominis de fallada diferents. Veure que el primer té èxit no diu res sobre el segon.

El que la vostra prova va demostrar de fet és més estret del que semblava: la vostra màquina pot arribar alhora a la pàgina pública i a l’amfitrió privat dels mitjans. La màquina de l’espectador mai no va formar part de l’experiment.

Què demana la llista de reproducció a continuació

RFC 8216 separa les llistes de reproducció de mitjans, que enumeren segments, de les llistes mestre, que enumeren altres llistes, i resol els URI relatius respecte de l’URI de la llista que els conté. Aquesta regla és la part que la gent s’salta. Descarregar amb èxit un fitxer .m3u8 no és una prova de reproducció, perquè el fitxer que heu baixat és un índex, no el mitjà.

Seguiu la cadena tal com ho fa el reproductor: obriu la llista seleccionada, després demaneu els recursos que anomena i després seguiu qualsevol redirecció. Una llista servida a través d’un servidor web accessible encara pot enviar l’espectador a una adreça privada inaccessible. Igualment, moure una llista relativa a un altre URL canvia la base respecte de la qual es resolen les seves entrades, i per això reescriure el primer URL visible i aturar-se aquí sol produir una llista que sembla vàlida però no pot reproduir-se.

Visualització directa: l’espectador necessita la ruta

Si els espectadors han d’arribar directament a l’amfitrió dels mitjans, els seus dispositius necessiten la VPN aprovada o una altra ruta privada, un DNS que resolgui els noms que heu fet servir realment, permís per arribar a aquestes destinacions i qualsevol autenticació que requereixi el servei de mitjans. Comproveu cada element al dispositiu de l’espectador, no al servidor. Un navegador en un telèfon amb el perfil de VPN instal·lat però no connectat és una fallada freqüent i completament reproduïble.

Aquest arranjament manté l’origen privat i trasllada el requisit d’accés al públic. És una decisió de política tant com tècnica, així que confirmeu que cada espectador previst té permís per tenir aquesta ruta abans de dissenyar-hi al voltant.

Lliurament des del servidor: un punt d’entrada controlat

L’alternativa és un frontal de mitjans autoritzat que obté l’origen per la seva ruta privada i republica només els recursos que veu l’espectador. Manteniu la llista, els segments i qualsevol recurs de clau coherents amb aquest punt d’entrada únic, o el reproductor baixarà una llista reescrita a través del frontal i els segments directament d’una adreça a què l’espectador no pot arribar.

Restringiu l’origen i les rutes permeses en aquest frontal. Un URL arbitrari proporcionat per l’usuari converteix un proxy útil en un buscador sense restriccions de la vostra xarxa interna, que és un problema molt pitjor que un flux que no es reprodueix. Poseu l’origen i el prefix de ruta a la llista de permesos en lloc de validar la cadena després dels fets.

Per a una font HLS existent, comproveu primer si el reenviament controlat és suficient; una VPN al mig no implica que calgui transcodificar. Després valideu la combinació real de navegador i còdec, perquè una resposta accessible i un format compatible són condicions separades. Manteniu intactes el TLS, l’autenticació i els requisits de seguretat del navegador de l’origen — un reproductor incrustat no n’és una exempció.

Proveu la cadena, no l’URL

Executeu les comprovacions des del component que farà realment cada petició i tracteu cada pas com el seu propi 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

Després repetiu-ho al navegador del mateix espectador amb el flux previst, no amb un patró de prova de la vostra taula. La càrrega de la pàgina, la càrrega de la llista, l’obtenció del segment i una fallada d’autorització són quatre resultats diferents, i voleu haver observat els quatre abans de donar-ho per arreglat. No instal·leu un connector de navegador antic perquè un exemple vell va reproduir així un flux; la peça que falta sol ser la ruta de l’espectador o l’URL del segment sense signar.

Un cop l’arranjament sigui deliberat, escriviu-lo en una línia: qui obté els mitjans, per quina ruta i què té permès de demanar l’espectador. Aquesta frase resol la majoria de discussions futures sobre per a qui és realment el flux.