Ang pribado mong HLS stream ay naglo-load para sa iyo, hindi para sa iyong mga manonood

Sinusubukan mo ang pahina sa laptop, nagsisimula ang player, at nagsasara ang ticket. Binuksan ng manonood sa kabilang dulo ang parehong pahina at nakakuha ng umiikot na indikasyon na hindi natatapos. Ang karaniwang paliwanag ay nasa server ang VPN, kaya dapat gumana ang pag-playback — pero ang browser ang bahaging humihingi ng playlist, at may sarili itong landas sa network. Ang pahinang naka-embed sa isang server na may pribadong access ay hindi nagpapahiram ng access na iyon sa sinumang naglo-load nito.

Ito ay tungkol sa isang umiiral na pahina ng ASP.NET na nagpapatugtog ng HLS source tulad ng http://10.5.5.9:8080/live/stream.m3u8, na isang halimbawang pribadong address. May dalawang kaayusan na gumagana; ang isa sa kanila ay malamang hindi ang ginawa mo.

Mito: ang pahinang naglo-load ay nagpapatunay ng landas ng media

Ang HTML ng pahinang iyon ay galing sa iyong web server, sa anumang ruta na mayroon ang iyong web server. Ang playlist at ang mga segment ay galing sa pinagmulan ng media, sa anumang ruta na mayroon ang bahaging humihingi. Kapag tumatakbo ang player sa browser ng manonood, dalawang magkaibang kliyente iyon, dalawang magkaibang source address at kadalasan dalawang magkaibang domain ng pagkabigo. Ang makita ang una na nagtagumpay ay walang sinasabi tungkol sa pangalawa.

Ang tunay na pinatunayan ng iyong pagsubok ay mas makitid kaysa sa tila: kayang abutin ng iyong makina ang pampublikong pahina at ang pribadong media host nang sabay. Ang makina ng manonood ay hindi kailanman naging bahagi ng eksperimento.

Ano ang hinihingi ng playlist susunod

RFC 8216 ay naghihiwalay ng mga media playlist, na naglilista ng mga segment, mula sa mga master playlist, na naglilista ng iba pang playlist, at nilulutas ang mga relatibong URI laban sa URI ng playlist na naglalaman sa kanila. Iyon ang tuntuning nilalaktawan ng mga tao. Ang matagumpay na pagkuha ng isang .m3u8 file ay hindi pagsubok sa pag-playback, dahil ang file na nakuha mo ay index, hindi ang media.

Sundin ang chain tulad ng ginagawa ng player: buksan ang napiling playlist, pagkatapos ay hingin ang mga resource na pinapangalanan nito, pagkatapos ay sundan ang anumang redirect. Ang playlist na inihahatid sa pamamagitan ng naaabot na web server ay maaari pa ring magturo sa manonood sa isang pribadong address na hindi maabot. Gayundin, ang paglipat ng relatibong playlist sa ibang URL ay nagbabago ng base kung saan nilulutas ang mga entry nito, at iyon ang dahilan kung bakit ang muling pagsulat ng unang nakikitang URL at pagtigil doon ay kadalasang gumagawa ng playlist na mukhang wasto pero hindi ma-play.

Direktang panonood: kailangan ng manonood ang landas

Kung ang mga manonood ay dapat direktang makarating sa media host, kailangan ng kanilang mga device ang aprubadong VPN o ibang pribadong landas, DNS na naglulutas ng mga pangalang aktwal mong ginamit, pahintulot na maabot ang mga destinasyong iyon, at anumang authentication na hinihingi ng serbisyo ng media. Suriin ang bawat isa sa device ng manonood at hindi sa server. Ang browser sa teleponong may naka-install na VPN profile pero hindi konektado ay karaniwan at ganap na maaaring ulitin na pagkabigo.

Ang kaayusang ito ay nagpapanatiling pribado ang pinagmulan at itinutulak ang pangangailangan ng access sa audience. Desisyon ito sa patakaran gayundin sa teknikal, kaya tiyakin na ang bawat nilalayong manonood ay pinapayagang magkaroon ng landas na iyon bago ka magdisenyo sa paligid nito.

Paghahatid mula sa server: isang kontroladong entry point

Ang alternatibo ay isang awtorisadong media frontend na kumukuha ng pinagmulan sa sarili nitong pribadong landas at muling naglalathala lamang ng mga resource na nakaharap sa manonood. Panatilihing pare-pareho ang playlist, ang mga segment at anumang key resource sa isang entry point na iyon, kung hindi ay kukunin ng player ang muling isinulat na playlist sa frontend at ang mga segment nang direkta mula sa address na hindi maabot ng manonood.

Limitahan ang pinagmulan at ang mga pinapayagang landas sa frontend na iyon. Ang arbitraryong URL na ibinigay ng user ay ginagawang walang limitasyong kumuha ng iyong internal network ang isang kapaki-pakinabang na proxy, na mas malaking problema kaysa sa stream na hindi mag-play. Ilagay ang pinagmulan at ang prefix ng landas sa allowlist sa halip na i-validate ang string pagkatapos ng pangyayari.

Para sa umiiral na HLS source, suriin muna kung sapat na ang kontroladong pagpapasa; ang VPN sa gitna ay hindi nangangahulugang kailangan ang transcoding. Pagkatapos ay i-validate ang aktwal na kombinasyon ng browser at codec, dahil ang naaabot na tugon at ang sinusuportahang format ay dalawang magkaibang kondisyon. Panatilihing buo ang TLS, authentication at mga pangangailangan sa seguridad ng browser ng pinagmulan — ang naka-embed na player ay hindi eksepsiyon sa mga ito.

Subukan ang chain, hindi ang URL

Patakbuhin ang mga pagsusuri mula sa bahaging tunay na gagawa ng bawat kahilingan, at ituring ang bawat hakbang bilang sarili nitong resulta:

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

Pagkatapos ay ulitin ito sa sariling browser ng manonood gamit ang nilalayong stream, hindi gamit ang test pattern mula sa iyong mesa. Ang pag-load ng pahina, pag-load ng playlist, pagkuha ng segment at pagkabigo sa awtorisasyon ay apat na magkakaibang resulta, at gusto mong maobserbahan ang lahat ng apat bago mo sabihing naayos na. Huwag mag-install ng lumang browser plugin dahil isang lumang halimbawa ay nag-play ng isang stream sa ganoong paraan; ang kulang na piraso ay kadalasan ang landas ng manonood o ang hindi pinirmahang URL ng segment.

Kapag ang kaayusan ay sinadya na, isulat ito sa isang linya: sino ang kumukuha ng media, sa anong landas, at ano ang pinapayagang hingin ng manonood. Ang pangungusap na iyon ay nagtatapos sa karamihan ng hinaharap na pagtatalo tungkol sa para kanino talaga ang stream.