Trick Play, Seek и DVR: Незаметные Тяжёлые Задачи

TL;DR

Три функции стриминга, которым никто не аплодирует, но которые сразу замечают, когда они ломаются – скраббинг, переход к таймкоду и пауза в прямом эфире, чтобы пересмотреть гол – также являются тремя функциями, которые тихо, но сильно увеличивают расходы на хранение, нагружают CPU origin-сервера и ставят плеер в неловкое положение при сбоях. Trick play (превью-миниатюры под скраббером, а также ускоренная перемотка вперёд и назад), seek (прыжок плеера на любую точку таймлайна) и DVR (возможность отмотать прямой эфир в прошлое) – каждая требует компромиссов на уровне энкодера, упаковщика, манифеста, CDN и плеера. Сложные части в 2026 году те же, что и в 2010-м: закодированное видео состоит из кадров, которые невозможно декодировать изолированно, а HTTP-кэши изначально не проектировались для зрителей, которые прыгают назад во времени. Эта статья объясняет структурные причины сложности каждой функции, механизмы HLS и DASH на уровне манифеста, а также практические решения, определяющие, будет ли ваше DVR-окно длиться две минуты или двое суток.

Почему это важно

Три функции из заголовка – те, что инженеры-менеджеры недооценивают на этапе планирования, а продакт-менеджеры потом обвиняют в сбоях на запуске. 90-минутный фильм, до нужного момента в котором можно добраться за восемь секунд, теряет зрителей; 24-часовой прямой эфир, который нельзя перемотать дальше последней рекламной паузы, теряет подписчиков; скраббер без миниатюр выглядит как приложение из 2008 года. Ни один из этих сбоев не возникает в первоначальном плане «доставить HLS на телефоны» – они проявляются за две недели до релиза, когда команда плеера обнаруживает, что энкодер никогда не создавал I-frame playlist, а строка «storage» в бюджете следующего квартала должна вырасти втрое. Эта статья даёт нетехническим лидерам достаточно понимания механики, чтобы принимать решения заранее, и предлагает инженерным руководителям чек-лист тегов манифеста, флагов энкодера и правил кэша CDN, которые тихо определяют, заработают ли функции на запуске или сломаются.

Почему эти три функции так сложны

Чтобы понять, почему скраббинг, перемотка и функции DVR структурно сложнее, чем просто воспроизведение потока вперёд, нужен один важный контекстный факт: не каждый закодированный кадр можно декодировать независимо. Энкодер сжимает видео, сохраняя большинство кадров в виде разниц относительно соседних – только небольшая часть кадров, называемых I-кадрами (от «intra-coded frames», внутрикадровое кодирование), содержит достаточно информации для самостоятельного декодирования. Всё остальное – P-кадры (предсказанные на основе более ранних кадров) и B-кадры (предсказанные по обоим направлениям) – зависит от соседних кадров.

Полезная аналогия: представьте комикс, где каждая пятая страница – полный рисунок, а все остальные – просто список изменений по сравнению с предыдущей: «добавьте шляпу, сдвиньте дерево на пять сантиметров влево, поменяйте цвет неба». Вы можете начать читать с любого полного рисунка, но не с середины – изменения теряют смысл без контекста полного изображения, к которому они относятся. Декодеры работают так же. Чтобы начать воспроизведение с произвольной точки, декодер должен вернуться к ближайшему I-кадр и последовательно обработать все зависимые кадры до нужного таймкода.

Этот единственный факт – корневая причина всех проблем в статье. Seek сложен, потому что плеер не может просто перейти к байту X – ему сначала нужно найти правильный I-кадр. Trick play сложен, потому что перемотка со скоростью 8× потребовала бы декодирования 240 кадров в секунду обычного видео, что большинство телефонов не потянут – поэтому для trick play используется альтернативный поток, содержащий только I-кадры. DVR сложен, потому что манифест, хранилище и кэш CDN должны хранить информацию о прошлом, а HTTP-кэши никогда не были дружелюбны к URL, которые обновляются каждые две секунды.

Хорошая новость в том, что каждый современный протокол стриминга – HLS, MPEG-DASH, CMAF – отточен до такой степени, что все три функции работают без сбоев. Плохая новость в том, что они работают только при условии, что энкодер, упаковщик, манифест и плеер настроены согласованно. Пропустите один из этапов – и функция незаметно деградирует.

Нажмите, чтобы увеличить

Seek: Анатомия прыжка на таймкод

Когда зритель перемещает скраббер с 12-й минуты на 47-ю, плеер выполняет цепочку шагов, которые большинству людей кажутся мгновенными. На самом деле это происходит примерно так.

Плеер читает свой манифест – HLS multi-variant playlist или DASH MPD – и находит сегмент, чей временной диапазон включает 47-ю минуту. Манифест может перечислять сегменты либо явно, по URL и длительности (HLS media playlist; DASH SegmentList), либо неявно – через шаблон, генерирующий URL сегмента на основе его номера и смещения start-number (DASH SegmentTemplate; наиболее распространённый подход). В любом случае плеер вычисляет номер сегмента по таймкоду: при длительности сегмента 4 секунды 47-я минута (2820 секунд) попадает в сегмент 706 (2820 ÷ 4 = 705, округлено вверх).

Плеер отправляет HTTP-запрос на сегмент 706. Сегмент – это короткий фрагмент файла в формате fragmented-MP4, обычно продолжительностью 2–6 секунд, который плеер может декодировать независимо от других сегментов. Именно это свойство делает возможным HTTP-стриминг: каждый сегмент самодостаточен, начинается с I-кадра и заканчивается там, где начинается следующий.

Внутри сегмента 706 плеер всё ещё должен найти нужный кадр. Сегмент 706 охватывает 4 секунды реального времени, но зритель хочет увидеть 47-ю минуту, что соответствует примерно 1,7 секунде в этом сегменте. Декодер начинает с открывающего I-кадра сегмента, последовательно декодирует P- и B-кадры до кадра 51 (при частоте 30 кадров в секунду 1,7 с ≈ 51 кадр) и только после этого выводит изображение на экран.

Гранулярность seek потока определяется как длительность сегмента в секундах, делённая на интервал между ключевыми кадрами внутри сегмента. В HLS и DASH традиционно размещают ровно один I-кадр в начале каждого сегмента, поэтому гранулярность seek совпадает с длительностью сегмента – примерно 2–6 секунд. Чтобы обеспечить точность поиска с шагом менее секунды, энкодер должен вставлять дополнительные I-кадры внутрь сегментов, что увеличивает битрейт на 10–30%. Большинство платформ работают с гранулярностью 2–4 секунды и строят пользовательский интерфейс с учётом этого – скраббер перемещает воспроизведение на начало сегмента, содержащего запрошенный таймкод, и зритель воспринимает это как мгновенный переход.

Распространённая ошибка – несогласованные границы сегментов между rendition-ами. Если поток 1080p обрезает новый сегмент каждые 4 секунды на границах кадров N, N+120, N+240, а поток 480p – на N+10, N+130, N+250, плеер не может корректно переключить rendition при seek. Каждая ступенька битрейтной лесенки должна использовать одни и те же границы сегментов, определяемые одинаковым интервалом closed-GOP ключевых кадров. Упаковщик обеспечивает это при нарезке выходного потока энкодера, но сам энкодер должен сначала генерировать I-кадры в правильном ритме. Классический сбой – per-title энкодер, который оптимизирует размещение ключевых кадров под конкретный контент и в итоге даёт несогласованные границы GOP между rendition-ами: плеер переключает rendition, номера сегментов перестают совпадать, и следующий seek оказывается не на той секунде.

Trick Play: Fast Forward Без Перегрузки Декодера

Trick play – это набор действий, которые зритель ожидает от «пульта»: перемотка вперёд со скоростью 2×, 4×, 8×, миниатюры под ползунком, превью-кадр при наведении курсора – и всё то же самое в обратном направлении. Ничего из этого нельзя реализовать, просто ускоряя воспроизведение основного потока. На скорости 8× поток с частотой 30 кадров в секунду потребовал бы подачи в декодер 240 кадров в секунду – это выходит за пределы возможностей мобильных декодеров и быстро разряжает батарею. На любой скорости миниатюры скраббера появляются на каждом пикселе, над которым проходит пользователь, то есть плееру нужно иметь загруженными сотни превью-кадров впереди текущей позиции – гораздо больше, чем может обеспечить ритм сегментов основного потока.

Структурное решение – вторичный поток только из I-кадров. Энкодер генерирует рядом с основным потоком альтернативный поток, содержащий исключительно I-кадры основного контента, упакованные на значительно меньшем битрейте, поскольку между ними отсутствуют P- и B-кадры. Манифест HLS объявляет этот поток тегом EXT-X-I-FRAME-STREAM-INF – отличающимся от обычного EXT-X-STREAM-INF, используемого для объявления воспроизводимых rendition’ов. Внутри плейлиста I-кадров каждый «сегмент» представляет собой один I-кадр, помеченный EXT-X-I-FRAMES-ONLY в начале медиа-плейлиста для сигнализации нестандартной структуры. DASH решает ту же задачу с помощью AdaptationSet с атрибутом @codecs либо путём указания того же потока I-кадров как low-битрейтового представления с пометкой trick-режим в MPD.

Когда зритель запускает перемотку вперёд, плеер переключается с основного потока на поток I-кадров, определяет, какие из них нужно отобразить при выбранной скорости (каждый второй при 4×, каждый четвёртый при 8× и так далее) и передаёт эти кадры в декодер с нормальной частотой воспроизведения. Декодеру не приходится обрабатывать более 30 кадров в секунду – независимо от скорости трюк-воспроизведения; только источник перемещается по временной шкале. Обратное воспроизведение работает по тому же принципу, но в обратную сторону – плеер декодирует I-кадры от поздних к ранним и отображает их в обратном порядке.

Миниатюры под скраббером – это упрощённая, меньшая версия того же трюка. Стандартное решение – I-кадрная миниатюрная дорожка: отдельный поток низкого разрешения – обычно 160×90 пикселей, один кадр каждые 2 секунды – публикуется как последовательность изображений в формате JPEG или WebP, объединённых в спрайт-лист для эффективного получения по HTTP. HLS передаёт их через тег EXT-X-IMAGE-STREAM-INF (добавленный в черновик RFC 8216bis и поддержанный основными упаковщиками с 2021 года). DASH использует для этого кодек image/jpeg в AdaptationSet, как определено в руководстве DASH-IF по миниатюрам. В обоих случаях плеер загружает миниатюрную дорожку параллельно с основным воспроизведением, индексирует её по таймкодам и отображает нужную плитку при наведении курсора на скраббер.

Самый частый баг миниатюр – рассогласование ритма: трек миниатюр закодирован с интервалом 10 секунд, а манифест указывает 2 секунды, из-за чего превью при скраббинге не совпадают с тем, что воспроизводится после отпускания скраббера. Доверяй манифесту, но перед релизом обязательно проверяй фактический ритм миниатюр на соответствие указанному в манифесте.

Нажмите, чтобы увеличить

DVR: Пауза в прямом эфире

DVR – сокращение от «digital video recorder», но в стриминге так называют любую возможность перемотки в прямом эфире. Это функция, которая позволяет зрителю поставить на паузу баскетбольный матч, взять напиток, вернуться через десять минут и продолжить просмотр с того же места. Она же даёт возможность отмотать на тридцать секунд назад, чтобы пересмотреть гол. Хорошая реализация такой функции отличает отполированный стриминговый сервис от любительского.

Структурная проблема в том, что прямой эфир по определению – это скользящее окно недавних сегментов. Энкодер генерирует новый сегмент каждые 2–6 секунд. Упаковщик обновляет манифест, добавляя новый сегмент и (в большинстве конфигураций для прямых трансляций) удаляя самый старый. Если манифест всегда содержит только пять последних сегментов, зритель может перемотать назад на десять-двадцать секунд – более старые сегменты уже недоступны. Такое поведение является стандартным для «live»-плейлиста HLS без тега EXT-X-ENDLIST: плеер периодически опрашивает манифест на предмет обновлений, и возможность перемотки ограничена тем, какие сегменты сейчас в нём перечислены.

DVR расширяет это окно. Вместо удаления сегментов после их сдвига за live edge упаковщик сохраняет их, и манифест продолжает их перечислять – иногда на час, иногда на сутки, а иногда – на всю продолжительность трансляции. В HLS DVR-окно выражается неявно – теми сегментами, которые всё ещё перечислены в media playlist. В DASH оно задаётся явно с помощью атрибута MPD@timeShiftBufferDepth, который указывает в секундах продолжительность доступного для перемотки прошлого: PT1H – для DVR-окна в один час, PT4H – для четырёх часов. ISO/IEC 23009-1:2022, раздел 5.3.1.2, определяет timeShiftBufferDepth как длительность time-shift буфера, гарантированно доступного от live edge назад.

Имплементационная работа ведётся в трёх местах. Упаковщик должен продолжать генерировать новые сегменты, не удаляя старые. Origin должен сохранять старые сегменты доступными – обычно на том же хранилище, что и live-сегменты, а иногда – на отдельном медленном tier’е для часовых архивов. CDN должен эффективно кэшировать их: DVR-сегменты – отличные кандидаты для CDN, потому что, как только они отстают от live edge на несколько минут, их содержимое больше не меняется. Длинный TTL (1 час, 6 часов, 1 день) на edge-нодах CDN означает, что большинство повторных запросов на DVR-воспроизведение обслуживаются из кэша.

Компромисс – это хранилище. 1080p-канал с композитным битрейтом 5 Мбит/с потребляет 2,25 ГБ в час. На шести уровнях ресайзинга это составляет 13,5 ГБ на канал в час. DVR-буфер на 4 часа требует 54 ГБ хранилища на канал, а на 24 часа – 324 ГБ. Платформе с 200 живыми каналами и 24-часовым DVR-буфером потребуется около 65 ТБ постоянно доступного хранилища с низкой задержкой только для DVR – это пятизначная ежемесячная статья расходов на хранилище у практически любого облачного провайдера.

Решение на уровне упаковщика – будет ли DVR-окно rolling (старые сегменты удаляются по мере поступления новых – простейший паттерн) или catch-up (каждый сегмент с начала трансляции сохраняется до её завершения, после чего архивируется в VOD-актив). Rolling DVR применяют новостные каналы и спортивные вещатели в обычном режиме. Catch-up DVR используют подписочные сервисы, когда ценность трансляции выходит за рамки live-эфирного момента – например, матч Премьер-Лиги должен оставаться доступным для просмотра хотя бы 24 часа после финального свистка, а в идеале – неделю.

Решение на уровне плеера – какой интерфейс показывать. Кнопка «отмотать на 30 секунд» – самый безопасный и универсальный элемент управления: она работает независимо от длины DVR-окна и от того, началась ли трансляция 10 минут или 4 часа назад. Скраббер, отображающий полное DVR-окно, мощнее, но сложнее: зрители часто перетаскивают его за границу прямого эфира, получают сообщение «Live» и думают, что что-то сломалось. Конвенция 2026 года – показывать таймлайн, заканчивающийся на «Live» с чёткой меткой, со скраббером, который можно перемещать влево к любому сегменту в DVR-окне и автоматически возвращаться к прямому эфиру при приближении к правому краю.

Где HTTP-Кэширование Перестаёт Помогать

Trick play и seek совместимы с HTTP-кэшированием. Сегменты и плейлисты I-кадров становятся статичными после публикации – CDN может кэшировать их с длительным TTL, и большинство запросов попадают на «тёплый» edge. Основная сложность – манифест, который в live-потоках обновляется каждые несколько секунд: большинство CDN устанавливают короткий TTL (1–3 секунды) на манифест и длинный TTL (часы или дни) на сегменты. LL-HLS добавляет дополнительную сложность, отдавая частичные сегменты, которые объединяются в финальный сегмент спустя несколько секунд, однако разделение TTL между манифестом и сегментами сохраняется.

DVR seek – там, где логика кэширования усложняется. Зритель, перемотавший назад на 47-ю минуту 4-часовой трансляции, вызывает cache miss для выбранного rendition’а на сегменте, соответствующем этой минуте. Если сегмент последний раз запрашивался час назад и уже устарел в edge-кэше, запрос направляется через origin shield к origin. Первый зритель, выполняющий seek на «холодный» сегмент, несёт задержку полного прохода до origin; последующие зрители выигрывают за счёт прогрева кэша.

Митигация – origin shield tier – представляет собой небольшой набор промежуточных узлов (mid-tier edges) между листовыми edge-узлами и origin, настроенных с более длительными TTL и с явным сохранением DVR-сегментов. Shield перехватывает большую часть промахов кэша DVR и не пропускает их к origin; origin видит лишь небольшую долю промахов, которые не удалось обработать даже shield’у. (Полную архитектуру см. в Origin Shielding and Tiered Caching.)

Вторая митигация – дисциплина cache key. Удивительно, сколько багов в DVR возникает из-за того, что в ключ кэша CDN попадают query-параметры, которые плеер добавляет для аналитики или идентификации сессии. Если seg_00706.m4s?session=abc и seg_00706.m4s?session=xyz кэшируются отдельно, эффективный hit rate CDN становится нулевым. Убирайте из cache key параметры, идентифицирующие сессию, либо используйте signed-URL с долгоживущим ключом кэша. (См. Cache Keys for Streaming.)

Live-to-Video-on-Demand: Финальная форма DVR

Самая чистая реализация дальнего DVR – это вовсе не DVR, а live-to-VOD конвейер. Когда прямая трансляция заканчивается (или иногда продолжается), упаковщик закрывает манифест тегом EXT-X-ENDLIST (HLS) или меняет тип MPD с dynamic на static (DASH), и контент становится обычным VOD-материалом. С этого момента применяются все стандартные VOD-оптимизации – предварительно упакованные или JIT-оригинальные потоки, очень длинные TTL в CDN, дешёвое хранение в object-сторе. Стоимость хранения DVR-окна перестаёт зависеть от live-хранилища и переходит на archive-уровень.

Большинство спортивных и новостных платформ работают в гибридном режиме: rolling DVR на 4–6 часов во время прямой трансляции, после чего контент автоматически переходит в VOD-актив, доступный в каталоге на несколько дней или даже лет. Плееру не нужно отправлять команды – он сам опрашивает манифест, обнаруживает появление тега EXT-X-ENDLIST (или изменение типа DASH MPD) и переключает внутреннее состояние с «live» на «on demand». Зритель при этом ничего не замечает.

Подвох – переходное окно: несколько минут, в течение которых и live-сигнал, и VOD-актив ссылаются на одни и те же сегменты. Если live-упаковщик продолжает записывать, пока VOD-упаковщик начинает публикацию, манифест может временно содержать больше сегментов, чем есть в хранилище, или включать URL сегмента, который переименовывается на лету. Решение – контракт координации live-to-VOD: live-упаковщик публикует финальный манифест с ENDLIST, VOD-упаковщик либо копирует live-сегменты в VOD origin, либо перенаправляет URL через правило редиректа, а live-origin продолжает обслуживать старые URL с 301-перенаправлением на новые как минимум в течение срока действия кэша (cache TTL).

Рабочий пример: спортивный DVR с функцией trick play

Пройдём арифметику end-to-end для типового деплоя: стриминговый сервис, транслирующий 50 спортивных каналов в прямом эфире с 4-часовым rolling DVR, миниатюрами под скраббером и возможностью воспроизведения со скоростью 8× в режиме catch-up.

Лесенка энкодера – стандартная шестиступенчатая: 240p, 360p, 480p, 720p, 1080p, 4K. Композитный битрейт при максимальном качестве составляет около 9 Мбит/с. Добавьте вторичный поток с I-кадром только на 600 кбит/с и трек миниатюр 160×90 на 50 кбит/с. Каждый канал занимает в хранилище примерно 9,65 Мбит/с.

9,65 Mbps × 3600 с = 34 740 Mb/час = 4,34 GB/channel-hour
× 4 часа DVR-окна         = 17,37 GB на канал
× 50 каналов               = 868 GB live DVR-хранилища постоянно

При тарифах AWS S3 Standard (~$0,023 за ГБ в месяц) это хранилище обходится примерно в $20 в месяц – мелочь. Реальная стоимость – в всегда активном уровне хранения с низкой задержкой (always-on object-store latency tier): большинство платформ размещают DVR на решениях типа EBS-обработки исходного хранилища, чтобы задержка при доступе к DVR оставалась ниже 200 мс. Это обходится примерно в 5 раз дороже, чем S3 Standard. Итого строка хранилища DVR для такой платформы – около $100 в месяц, что всё ещё мало по сравнению с CDN.

CDN-сторона несёт реальные расходы. При средней нагрузке в 50 000 зрителей по 50 каналам и среднем битрейте 5 Мбит/с объём live-трафика составляет 250 Гбит/с. За месяц это около 80 Пб при стандартных тарифах доставки – или примерно 400 000 долларов в месяц по типовым ценам CDN для крупных клиентов. Использование DVR добавляет к этому около 5–8%, в основном за счёт зрителей, просматривающих записи через несколько минут после эфира – такие сегменты ещё остаются «тёплыми» на большинстве edge-узлов, поэтому дополнительные затраты минимальны.

Trick play добавляет одноразовую стоимость кодирования (I-кадры потока кодируются при примерно 5% битрейта основного, так что назовём прирост вычислительной нагрузки на кодирование около 5%) и небольшую дополнительную нагрузку на CDN во время сессий перемотки. Миниатюры скраббера добавляют, возможно, 0,5% к нагрузке энкодера и 0,1% к исходящему трафику CDN.

Вывод: функции – не то, куда уходят деньги. Деньги уходят на CDN egress, доставляющий основные потоки. Функции стоят инженерного внимания, а не капитала.

Где Фора Софт подходит

Мы разрабатываем стриминговые платформы для OTT, спорта, e-learning, телемедицины и видеонаблюдения, и такие функции, как trick play, seek и DVR, – это вызовы, с которыми мы сталкиваемся почти в каждом проекте. В спортивной трансляции мы предоставляем 4-часовой rolling DVR с миниатюрами скраббера и 8× catch-up как базовый функционал; в e-learning – возможность поиска по уроку с маркерами глав в манифесте и оффлайн-скачивание трека миниатюр I-кадров для скраббинга при низкой пропускной способности; в телемедицине – запись сессий с DVR и frame-accurate seek для детального клинического анализа. Паттерны использования различаются в зависимости от сферы, но механика на уровне манифеста – EXT-X-I-FRAMES-ONLY, EXT-X-IMAGE-STREAM-INF, DASH timeShiftBufferDepth, image adaptation sets – остаётся одинаковой во всех случаях, как и типичные сбои: несоответствие GOP, дрейф cache key и недостаточный размер окна DVR, которые часто выявляются только на следующий день после релиза.

Распространённые ошибки (быстрая справка)

Ниже приведён список паттернов сбоев, которые возникают почти в каждом проекте. Используйте его как чек-лист перед запуском.

• Границы GOP не согласованы между rendition-ами – каждая ступенька лесенки должна закрывать GOP на одном и том же моменте времени, иначе при переключении rendition ломается seek.
• I-frame playlist не сгенерирован – энкодер создаёт I-кадры в правильном ритме, но упаковщик не выставляет EXT-X-I-FRAMES-ONLY и EXT-X-I-FRAME-STREAM-INF, из-за чего плеер не может выполнять fast forward.
• Thumbnail track закодирован с ритмом, отличным от заявленного в манифесте – превью под скраббером дрейфуют относительно реального контента.
• TTL live-манифеста слишком большой – зрители видят устаревший «live edge», потому что CDN отдаёт манифест с 60-секундным сроком жизни.
• DVR-окно указано в секундах, но хранилище удерживает данные в сегментах – 1-часовое DVR-окно с 4-секундными сегментами требует хранения 900 сегментов на rendition, и реальное ограничение – лимит количества сегментов на упаковщике, а не временной интервал из манифеста.
• Cache key включает session ID – из-за этого каждый DVR-повтор идёт на origin, так как ни один cache key не совпадает с другим.
• Переход live-to-VOD без EXT-X-ENDLIST – плееры в режиме «live» продолжают опрашивать манифест и пропускают весь VOD-актив.

Нажмите, чтобы увеличить

Ключевые выводы

• Разрешение поиска (seek) соответствует длительности сегмента; субсекундный поиск требует дополнительных I-кадров и увеличивает битрейт на 10–30%.
• Для трюковой проигрывания (trick play) используется отдельный поток, содержащий только I-кадры – без него невозможно перемотка вперёд на любой скорости.
• DVR – это скользящее окно сохранённых сегментов прямого эфира; в HLS оно реализуется неявно через содержимое плейлиста, в DASH – явно через timeShiftBufferDepth.
• Хранение DVR-данных обходится недорого, а задержка при промахе кэша – дорого; используйте уровень защиты origin shield и исключайте session ID из ключа кэша.
• Наиболее чистое и эффективное решение для долгосрочного хранения – переход с live на VOD, а не бесконечное хранение прямого эфира.

Что читать дальше

• HLS Подробный разбор: m3u8, сегменты, мультивариантные плейлисты
• MPEG-4 DASH Подробный разбор: MPD, периоды, адаптационные наборы, представления
• Just-in-Time Packaging против предварительно упакованного источника