Потребность в последовательном подходе с малой задержкой к "потоковой" доставке сегментов или фрагментов видео на основе HTTP обсуждалась более десяти лет. Еще в 2011 году, с ратификацией Dynamic Adaptive Streaming через HTTP (сокращенно DASH) Группой экспертов по кинематографии, появилось несколько красных флажков, предупреждающих о потенциальном «загоне себя в угол отсрочки доставки» с помощью 6 - 30-секундных задержек, связанных с доставкой по протоколу HTTP. Эти предупреждения поднимались на многих отраслевых мероприятиях.

Десять лет спустя, похоже, эти опасения были услышаны. Начиная с 2019 года Apple, которая была частью ратификации MPEG DASH, но не реализовала какие-либо части международного стандарта, вместо этого полагаясь на свой подход MPEG-2 Transport Stream (m2ts), прежде чем перейти на байтовую адресацию фрагментированных MP4 ( fMP4) - заговорили о возможности версии с низкой задержкой его спецификации доставки HTTP Live Streaming (HLS).

Apple была не первой, кто обсуждал подход с низкой задержкой к доставке HTTP, и было сделано несколько попыток с использованием DASH и общего медиаформата (CMAF). Но поскольку это Apple, которая доминирует в доставке на основе HTTP с HLS, многие в отрасли ждали, что скажет по этой теме Роджер Пантос / Roger Pantos из Apple.

У Пантоса уже более десяти лет существует спецификация Internet Engineering Task Force (IETF) по HLS в виде проекта. Первая спецификация HLS, датированная 1 мая 2009 года, была разработана им и с тех пор ласково называлась «спецификацией Пантоса» как сокращение для рекомендаций HLS и передовых практик по доставке потоков HLS на Apple, Android и других телевизионных приставках.

Однако в 2019 году Пантос увидел, как другие подходы к доставке HTTP на основе сегментов начали решать проблему низкой задержки, и приступил к переопределению HLS в версии с низкой задержкой. Он сделал это на презентации на Всемирной конференции разработчиков Apple (WWDC 2019), где представил концепцию HLS с малой задержкой и изложил требования для последовательной доставки с почти одной третью типичной задержки, которой был известен HLS. И эти рекомендации были изложены на сайте разработчиков Apple как для начальной, так и для «почти окончательной» версии HLS с малой задержкой (LL-HLS).

Промышленность поспешила дать отзывы - как положительные, так и, в большей степени, отрицательные - о первоначальной спецификации Pantos LL-HLS. Таким образом, последняя версия спецификации Пантоса от апреля 2020 года несколько резко отличается от предыдущих презентаций Пантоса на WWDC 2019.

Одно большое изменение заключается в том, что новая спецификация предназначена для полной замены всех спецификаций HLS без малой задержки. Фактически, Пантос отмечает в выпуске от апреля 2020 года, что «этот документ отменяет RFC 8216».

Еще одно большое изменение - новейшая спецификация Пантоса отменяет требование, чтобы все HTTP-серверы, используемые для доставки LL-HLS, использовали HTTP / 2 PUSH.

Это приводит нас к текущему состоянию на сентябрь 2020 года. Хотя версия спецификации Пантоса от апреля 2020 года по-прежнему рекомендует HTTP / 2 PUSH, она переместила рекомендацию в Приложение B. Вместо него есть явное обязательное расширение «подсказки», названное соответствующим образом EXT-X-PRELOAD-HINT.

Питер-Ян Спилманс из THEOplayer объяснил этот сдвиг и то, как он на самом деле полезен для устранения дополнительного двустороннего обмена между серверами и конечными пользователями, но также отметил, что спецификации Apple всегда могут быть изменены.

«Вместо использования HTTP / 2 push Apple добавляет новый тег под названием # EXT-X-PRELOAD-HINT», - пишет Спилманс. «С этим тегом сервер, публикующий поток HLS с низкой задержкой, должен объявить наиболее вероятное местоположение следующих мультимедийных данных, которые станут доступны. Это позволяет клиенту плеера выполнить запрос, позволяя данным поступать, как только становится доступной следующая часть сегмента. Затем этот процесс можно повторить, что позволяет убрать дополнительное время приема-передачи при загрузке новых мультимедийных данных (что было основной причиной использования HTTP / 2 push)».

По материалам Streamingmedia