Я бился головой о стену, пытаясь правильно кэшировать живые видеопотоки DASH и HLS с помощью обратного прокси-сервера HTTPS, кэширующего NGINX.
В настоящее время я думаю, что моя основная проблема может заключаться в том, что NGINX proxy_cache_valid директива, по-видимому, относится к тому моменту, когда файл попал в кеш. Я думаю, что мне нужно, чтобы срок хранения кеша был относительно Last-Modified поле заголовка. NGINX предоставляет доступ к этому через sub_filter_last_modified on и $upstream_http_last_modified, но я еще не нашел, как установить «Last-Modified + 10 секунд» в качестве времени истечения срока действия кеша.
proxy_cache_valid на «Последнее изменение + 10 секунд»?Другой возможный подход, который я нашел, заключается в том, что серверная часть предоставляет X-Accel-Expires поле заголовка с @ (ссылка: http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_cache_valid).
Является X-Accel-Expires «самый правильный» способ для NGINX кэшировать медиаконтент в реальном времени?
Есть ли другие, более эффективные способы расследования?
Заранее спасибо. (Это мой третий кусок этого яблока, мои предыдущие вопросы были слишком расплывчатыми и невежественными, чтобы получить полезные ответы.)
Некоторые предпосылки / обзор / контекст для тех, кто не знаком с потоковой передачей видео в реальном времени по HTTP:
Видеопоток начинается с транспортного потока (TS) MPEG, предоставляемого цифровым ТВ-тюнером (ATSC @ 1080i), который подается на транскодер MPEG (ffmpeg с аппаратной поддержкой), который в реальном времени генерирует 3 разрешения (720p, 480p, 360p. ) в CBR (постоянная скорость передачи данных), которые затем передаются в упаковщик (например, GPAC или Shaka), который генерирует динамические мультимедийные файлы (манифесты / списки воспроизведения + аудио + видео) для потоковой передачи с адаптацией к полосе пропускания (например, затухание Wi-Fi вызывает разрешение для уменьшения, которое будет автоматически увеличиваться при улучшении пропускной способности).
Новые наборы файлов создаются каждые 2-10 секунд («время сегмента»), в зависимости от того, как настроен упаковщик; в настоящее время мы используем 10-секундные сегменты, чтобы минимизировать количество передач, хотя мы надеемся в конечном итоге перейти на 2 секунды, чтобы минимизировать задержку. Все эти файлы обслуживаются NGINX через простую страницу со списком доступных прямых трансляций.
Чтобы дать вам представление о масштабе, один вход 1080i генерирует 3 потока CBR, каждый из которых упаковывается как DASH и HLS, для 6 выходных потоков, созданных из каждого входного потока. Всего упаковщик выводит 10 файлов каждые 10 секунд для каждого входа 1080i. С 24 входами 1080i (не редкость во многих городах) это 240 новых файлов каждые 10 секунд или 86 400 новых файлов каждый час. Кэш рассчитан на 1 минуту истории или 1440 файлов мультимедиа (<1 ГБ).
Файлы видео и аудио сегментов (которые содержат данные MPEG) создаются с уникальными именами, поэтому выпустить их LRU из полного кеша не проблема. Но манифесты DASH и списки воспроизведения HLS представляют собой форматированные текстовые файлы, которые перезаписываются каждый раз (для отображения новых файлов аудио и видео сегментов), поэтому манифесты / списки воспроизведения должны быть заменены при обновлении.
Тюнер-транкодер-упаковщик отлично справляется со своей задачей, но это не лучший веб-сервер для десятка клиентов, в первую очередь из-за накладных расходов на HTTPS. Обратный прокси-сервер HTTPS с внешним кэшированием необходим для минимизации этой нагрузки, его задача - выглядеть как единый клиент, независимо от количества реальных пользователей видео. Однако пользователи видео не должны знать, что кэширующий обратный прокси присутствует, поэтому всегда правильное кеширование жизненно важно.
В настоящее время я вижу, что видео из кеша иногда зависает, хотя оно отлично воспроизводится непосредственно с видеосервера. HLS раньше, чем DASH, но оба зависнут через 1-8 часов.
И видеосервер, и кэширующий обратный прокси-сервер запускают NGINX для использования (настройки / оптимизации) объединенного набора функций.
Лучший рабочий пример, который я нашел для обратного прокси-сервера HTTPS с кэшированием NGINX для серверов потокового мультимедиа, был отсюда: https://docs.peer5.com/guides/use-nginx-as-wowza-cache/
Это потребовало лишь незначительных изменений для моей конкретной среды.