Via privata HLS-fluo elŝutiĝas por vi, ne por viaj spektantoj

Vi testas la paĝon sur via tekkomputilo, la ludilo ekfunkcias kaj la bileto fermiĝas. La spektanto ĉe la alia fino malfermas la saman paĝon kaj ricevas turniĝantan indikilon, kiu neniam solviĝas. La kutima klarigo estas, ke la VPN troviĝas sur la servilo, do la ludado devus funkcii — sed ĝuste la retumilo estas la komponento, kiu petas la ludliston, kaj ĝi havas sian propran retvojon. Paĝo enmetita sur servilon kun privata aliro ne pruntedonas tiun aliron al tiu, kiu ŝargas ĝin.

Temas pri ekzistanta ASP.NET-paĝo, kiu ludas HLS-fonton kiel http://10.5.5.9:8080/live/stream.m3u8, kiu estas ilustra privata adreso. Du aranĝoj funkcias; unu el ili probable ne estas tiu, kiun vi konstruis.

Mito: ŝargiĝanta paĝo pruvas la vojon de la aŭdvidaĵoj

La HTML de tiu paĝo venas de via retservilo, laŭ kiu ajn vojo via retservilo havas. La ludlisto kaj la segmentoj venas de la aŭdvida fonto, laŭ kiu ajn vojo la petanta komponento havas. Kiam la ludilo funkcias en la retumilo de la spektanto, temas pri du malsamaj klientoj, du malsamaj fontadresoj kaj ofte du malsamaj fiaskodomajnoj. Vidi la unuan sukcesi diras nenion pri la dua.

Kion via testo vere pruvis, estas pli mallarĝa ol ĝi aspektis: via maŝino povas atingi la publikan paĝon kaj la privatan aŭdvida gastiganto samtempe. La maŝino de la spektanto neniam estis parto de la eksperimento.

Kion la ludlisto postulas poste

RFC 8216 apartigas aŭdvidajn ludlistojn, kiuj listigas segmentojn, de ĉefaj ludlistoj, kiuj listigas aliajn ludlistojn, kaj solvas relativajn URI-ojn rilate al la URI de la ludlisto, kiu enhavas ilin. Ĝuste tiun regulon homoj preterlasas. Sukcese elŝuti unu dosieron .m3u8 ne estas ludtesto, ĉar la dosiero, kiun vi elŝutis, estas indekso, ne la aŭdvidaĵoj.

Sekvu la ĉenon tiel, kiel faras la ludilo: malfermu la elektitan ludliston, poste petu la rimedojn, kiujn ĝi nomas, poste sekvu ajnan alidirektadon. Ludlisto liverita tra atingebla retservilo ankoraŭ povas direkti la spektanton al neatingebla privata adreso. Same, movi relativan ludliston al alia URL ŝanĝas la bazon, rilate al kiu ĝiaj eroj solviĝas, kaj tial reverkado de la unua videbla URL kaj halti tie kutime produktas ludliston, kiu aspektas valida sed ne povas ludi.

Rekta spektado: la spektanto bezonas la vojon

Se la spektantoj devas atingi la aŭdvidan gastiganton rekte, iliaj aparatoj bezonas la aprobitan VPN-on aŭ alian privatan vojon, DNS-on, kiu solvas la nomojn, kiujn vi efektive uzis, permeson atingi tiujn celojn kaj ajnan aŭtentikigon, kiun la aŭdvida servo postulas. Kontrolu ĉiun el ili sur la aparato de la spektanto, ne sur la servilo. Retumilo sur telefono kun instalita sed nekonektita VPN-profilo estas ofta kaj tute ripetebla fiasko.

Tiu aranĝo tenas la fonton privata kaj puŝas la alirpostulon al la publiko. Ĝi estas politika decido same kiel teknika, do konfirmu, ke ĉiu celata spektanto rajtas teni tiun vojon antaŭ ol desegni ĉirkaŭ ĝi.

Liverado de la servila flanko: unu kontrolita enirpunkto

La alternativo estas rajtigita aŭdvida fasado, kiu elprenas la fonton laŭ sia privata vojo kaj republikigas nur la spektantajn rimedojn. Tenu la ludliston, la segmentojn kaj eblajn ŝlosilrimedojn kongruaj kun tiu sola enirpunkto, alie la ludilo elprenos reverkatan ludliston tra la fasado kaj la segmentojn rekte de adreso, kiun la spektanto ne povas atingi.

Limigu la fonton kaj la permesitajn vojojn en tiu fasado. Arbitra URL provizita de la uzanto transformas utilan prokurilon en senliman elprenanton de via interna reto, kio estas multe pli malbona problemo ol fluo, kiu ne ludos. Metu la fonton kaj la vojprefikson en permesilon anstataŭ validigi la ĉenon post la fakto.

Por ekzistanta HLS-fonto, unue kontrolu ĉu kontrolita plusendo sufiĉas; VPN en la mezo ne implicas, ke transkodado necesas. Poste validigu la efektivan kombinaĵon de retumilo kaj kodigilo, ĉar atingebla respondo kaj subtenata formato estas apartaj kondiĉoj. Konservu la TLS, aŭtentikigon kaj retumilsekurecajn postulojn de la fonto sendifektaj — enmetita ludilo ne estas escepto de ili.

Testu la ĉenon, ne la URL-on

Plenumu la kontrolojn el la komponento, kiu efektive faros ĉiun peton, kaj traktu ĉiun paŝon kiel sian propran rezulton:

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

Poste ripetu ĝin en la propra retumilo de la spektanto kun la celata fluo, ne kun testa ŝablono de via skribotablo. Ŝargado de la paĝo, ŝargado de la ludlisto, elpreno de segmento kaj malsukceso de rajtigo estas kvar apartaj rezultoj, kaj vi volas vidi ĉiujn kvar antaŭ ol nomi ĝin riparita. Ne instalun malnovan retumilan kromaĵon ĉar malnova ekzemplo tiel ludis unu fluon; la mankanta peco kutime estas la vojo de la spektanto aŭ la nesubskribita URL de la segmento.

Post kiam la aranĝo estas intenca, skribu ĝin en unu linio: kiu elprenas la aŭdvidaĵojn, laŭ kiu vojo kaj kion la spektanto rajtas postuli. Tiu frazo solvas la plej multajn estontajn disputojn pri por kiu la fluo vere destinatas.