Ваш приватний 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 сегмента.

Коли схема обрана свідомо, запишіть її одним рядком: хто отримує медіа, яким шляхом і що глядачеві дозволено запитувати. Це речення розв'язує більшість майбутніх суперечок про те, для кого насправді цей потік.