Вашиот приватен HLS тек се вчитува за вас, а не за вашите гледачи

Ја тестирате страницата на преносниот сметач, плеерот се стартува и тикетот се затвора. Гледачот од другата страна ја отвора истата страница и добива индикатор што се врти и никогаш не завршува. Вообичаеното објаснување е дека VPN-от е на серверот, па репродукцијата треба да работи — но токму браузерот е компонентата што ја бара плејлистата, и тој има своја мрежна патека. Страница вградена на сервер со приватен пристап не го позајмува тој пристап на тој што ја вчитува.

Станува збор за постоечка ASP.NET страница што репродуцира HLS извор како http://10.5.5.9:8080/live/stream.m3u8, што е илустративна приватна адреса. Функционираат два распореди; едниот од нив веројатно не е оној што сте го изградиле.

Мит: вчитана страница го докажува медиумскиот пат

HTML-от на таа страница доаѓа од вашиот веб-сервер, по која и да е рута што ја има вашиот веб-сервер. Плејлистата и сегментите доаѓаат од медиумскиот извор, по која и да е рута што ја има компонентата што го испраќа барањето. Кога плеерот работи во браузерот на гледачот, тоа се два различни клиенти, две различни изворни адреси и често две различни домени на откажување. Успехот на првиот не кажува ништо за вториот.

Она што вашиот тест всушност го докажа е потесно отколку што изгледаше: вашата машина стигнува и до јавната страница и до приватниот медиумски домаќин во исто време. Машината на гледачот никогаш не беше дел од експериментот.

Што бара плејлистата потоа

RFC 8216 ги одвојува медиумските плејлисти, кои наведуваат сегменти, од мастер плејлистите, кои наведуваат други плејлисти, и ги решава релативните URI во однос на URI-то на плејлистата што ги содржи. Токму тоа правило луѓето го прескокнуваат. Успешно преземање на една .m3u8 датотека не е тест за репродукција, бидејќи преземената датотека е индекс, а не медиумот.

Следете го синџирот како што прави плеерот: отворете ја избраната плејлиста, потоа побарајте ги ресурсите што ги наведува, потоа следете го секое пренасочување. Плејлиста послужена преку достапен веб-сервер сепак може да го упати гледачот на недостапна приватна адреса. Исто така, преместувањето на релативна плејлиста на друг URL ја менува основата во однос на која се решаваат нејзините записи, и затоа препишувањето на првиот видлив URL и запирањето таму обично дава плејлиста што изгледа валидна, но не може да се репродуцира.

Директно гледање: на гледачот му треба патеката

Ако гледачите треба директно да стигнат до медиумскиот домаќин, нивните уреди имаат потреба од одобрениот VPN или друга приватна патека, DNS што ги решава имињата што навистина сте ги користеле, дозвола да ги достигнат тие дестинации и каква и да е автентикација што ја бара медиумската услуга. Проверете го секое од нив на уредот на гледачот, а не на серверот. Браузер на телефон со инсталиран, но не поврзан VPN профил е чест и целосно репродуктивен отказ.

Овој распоред го чува изворот приватен и го префрла барањето за пристап врз публиката. Тоа е политичка одлука исто колку и техничка, затоа потврдете дека на секој предвиден гледач му е дозволено да ја држи таа патека пред да проектирате околу неа.

Испорака од серверот: една контролирана влезна точка

Алтернативата е авторизиран медиумски фронтенд што го презема изворот по својата приватна патека и ги објавува повторно само ресурсите свртени кон гледачот. Држете ја плејлистата, сегментите и сите клучни ресурси во согласност со таа единствена влезна точка, инаку плеерот ќе ја преземе препишаната плејлиста преку фронтендот, а сегментите директно од адреса што гледачот не може да ја достигне.

Ограничете го изворот и дозволените патеки во тој фронтенд. Произволен URL даден од корисникот го претвора корисниот прокси во неограничен преземач на вашата внатрешна мрежа, што е многу полош проблем од тек што нема да се репродуцира. Ставете ги изворот и префиксот на патеката на список на дозволени, наместо да ја валидирате низата отпосле.

За постоечки HLS извор, прво проверете дали контролираното препраќање е доволно; VPN во средината не значи дека е потребно транскодирање. Потоа валидирајте ја вистинската комбинација на браузер и кодек, бидејќи достапниот одговор и поддржаниот формат се два одделни услови. Зачувајте ги TLS, автентикацијата и барањата за безбедност на браузерот на изворот непроменети — вградениот плеер не е исклучок од нив.

Тестирајте го синџирот, не URL-то

Изведувајте ги проверките од компонентата што навистина ќе го испрати секое барање и третирајте го секој чекор како свој резултат:

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

Потоа повторете го тоа во браузерот на самиот гледач со предвидениот тек, а не со тест-шаблон од вашето биро. Вчитувањето на страницата, вчитувањето на плејлистата, преземањето на сегментот и откажувањето на авторизацијата се четири различни исходи, и сакате да ги видите сите четири пред да го наречете поправено. Не инсталирајте застарен додаток за браузер затоа што стар пример така репродуцирал еден тек; делот што недостасува обично е патеката на гледачот или непотпишаниот URL на сегментот.

Кога распоредот е намерен, запишете го во еден ред: кој ги презема медиумите, по која патека и што смее гледачот да побара. Таа реченица ги решава повеќето идни расправии за тоа за кого е навистина текот.