Zure HLS korronte pribatua zuretzat kargatzen da, ez zure ikusleentzat

Orria zure eramangarrian probatzen duzu, erreproduzigailua abiarazten da eta tiketa ixten da. Beste aldeko ikusleak orri bera irekitzen du eta inoiz amaitzen ez den karga-adierazlea jasotzen du. Ohiko azalpena VPN-a zerbitzarian dagoela da, beraz erreprodukzioak funtzionatu beharko lukeela — baina nabigatzailea da erreprodukzio-zerrenda eskatzen duen osagaia, eta bere sare-bidea du. Sarbide pribatua duen zerbitzari batean txertatutako orriak ez dio sarbide hori uzten hura kargatzen duenari.

Hau HLS iturri bat erreproduzitzen duen ASP.NET orri bati buruzkoa da, hala nola http://10.5.5.9:8080/live/stream.m3u8, hau da, helbide pribatu ilustratzailea. Bi antolaketa funtzionatzen dute; horietako bat ziurrenik ez da zuk eraiki zenuena.

Mitoa: kargatzen den orri batek medioen bidea frogatzen du

Orri horren HTMLa zure web zerbitzaritik dator, zure web zerbitzariak duen bideari jarraituz. Erreprodukzio-zerrenda eta segmentuak medioen iturritik datoz, eskaera egiten duen osagaiak duen bideari jarraituz. Erreproduzigailua ikuslearen nabigatzailean exekutatzen denean, bi bezero desberdin dira, bi iturburu-helbide desberdin eta sarritan bi huts-eremu desberdin. Lehenengoak arrakasta izatea ikustek ez du ezer esaten bigarrenari buruz.

Zure probak benetan frogatu zuena uste baino estuagoa da: zure makinak orri publikora eta medioen ostalari pribatura aldi berean irits daiteke. Ikuslearen makina ez zen inoiz esperimentuaren parte izan.

Zer eskatzen duen erreprodukzio-zerrendak ondoren

RFC 8216 arauak medioen erreprodukzio-zerrendak, segmentuak zerrendatzen dituztenak, maisu-zerrendetatik bereizten ditu, azken horiek beste zerrenda batzuk zerrendatzen dituztelarik, eta URI erlatiboak zerrenda horiek dituen zerrendaren URIaren arabera ebazten ditu. Arau hori da jendeak saltatzen duen zatia. .m3u8 fitxategi bat behar bezala lortzea ez da erreprodukzio proba bat, lortu duzun fitxategia indize bat delako, ez medioak.

Jarraitu kateari erreproduzigailuak egiten duen bezala: ireki hautatutako zerrenda, gero eskatu izendatzen dituen baliabideak, gero jarraitu edozein birbideratze. Web zerbitzari irisgarri baten bidez zerbitzatutako zerrendak ikuslea iristezina den helbide pribatu batera bidal dezake oraindik. Era berean, zerrenda erlatiboa beste URL batera mugitzeak bere sarrerak ebazteko oinarria aldatzen du, eta horregatik lehen URL ikusgaiaren berridazketak eta han gelditzeak baliozko itxura duen baina erreproduzi ezin den zerrenda sortzen du normalean.

Zuzeneko ikuskapena: ikusleak bidea behar du

Ikusleek medioen ostalarira zuzenean iritsi behar badute, beren gailuek onartutako VPN-a edo beste bide pribatu bat behar dute, benetan erabili zenituen izenak ebazten dituen DNS bat, helmuga horietara iristeko baimena eta medioen zerbitzuak eskatzen duen autentifikazioa. Egiaztatu bakoitza ikuslearen gailuan, ez zerbitzarian. VPN profila instalatuta baina konektatu gabe duen telefono bateko nabigatzailea huts egite arrunta eta guztiz errepikagarria da.

Antolaketa honek iturria pribatu gordetzen du eta sarbide-baldintza publikoari eramaten dio. Politika-erabakia da, tekniko adina, beraz berretsi aurreikusitako ikusle bakoitzak bide hori izateko baimena duela haren inguruan diseinatu aurretik.

Zerbitzaritik entregatzea: sarrera-puntu kontrolatu bakarra

Alternatiba medioen frontend baimendu bat da, iturria bere bide pribatuaren bidez lortzen duena eta ikusleak ikusten dituen baliabideak soilik birargitaratzen dituena. Mantendu zerrenda, segmentuak eta balizko gako-baliabideak sarrera-puntu bakarreko horrekin bat, bestela erreproduzigailuak zerrenda berridatzia frontendetik eta segmentuak zuzenean ikuslea irits ezin den helbide batetik ekarriko ditu.

Mugatu iturria eta baimendutako bideak frontend horretan. Erabiltzaileak emandako URL arbitrario batek proxy erabilgarri bat zure barne-sarearen lortzaile mugagabe bihurtzen du, eta hori erreproduzitzen ez den korronte bat baino askoz arazo okerragoa da. Jarri iturria eta bide-aurrizkia baimenduen zerrendan, katea geroago baliozkotu beharrean.

Lehendik dagoen HLS iturri baterako, egiaztatu lehenik birbidalketa kontrolatua nahikoa ote den; erdian VPN bat egoteak ez du esan nahi transkodetzea beharrezkoa denik. Gero baliozkotu benetako nabigatzaile eta kodek konbinazioa, erantzun irisgarria eta formatu onartua baldintza bereiziak direlako. Mantendu iturriaren TLS, autentifikazio eta nabigatzailearen segurtasun baldintzak osorik — txertatutako erreproduzigailua ez da horietatik salbuesten.

Probatu katea, ez URLa

Exekutatu egiaztapenak eskaera bakoitza benetan egingo duen osagaitik, eta tratatu urrats bakoitza bere emaitzatzat:

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

Gero errepikatu ikuslearen beraren nabigatzailean aurreikusitako korrontearekin, ez zure mahaiko proba-eredu batekin. Orriaren karga, zerrendaren karga, segmentuaren lortzea eta baimen-hutsegitea lau emaitza desberdin dira, eta laurak ikusi nahi dituzu konpondutzat jo aurretik. Ez instalatu zaharkitutako nabigatzaile-plugin bat adibide zahar batek horrela erreproduzitu zuelako korronte bat; falta den pieza ikuslearen bidea edo sinatu gabeko segmentuaren URLa izan ohi da.

Antolaketa deliberatua denean, idatzi lerro bakarrean: nork lortzen ditu medioak, zein bidetik eta zer duen ikusleak esateko baimena. Esaldi horrek konpontzen ditu etorkizuneko eztabaida gehienak korrontea benetan norentzat den jakiteko.