Термин
Blocking playlist reload
Server-side ожидание LL-HLS: плеер запрашивает следующую версию плейлиста через параметры запроса `_HLS_msn=` и `_HLS_part=`; сервер удерживает ответ, пока эта версия не станет доступна.
Классические HLS-плееры опрашивают медиаплейлист каждые target-duration в надежде обнаружить новые сегменты. Такой опрос либо расходует пропускную способность (если происходит слишком часто), либо увеличивает задержку (если слишком редкий). Блокировка перезагрузки плейлиста устраняет необходимость в опросе: плеер указывает `_HLS_msn=N` (следующий номер медиапоследовательности, который он ожидает) и, при необходимости, `_HLS_part=K` (номер partial), а сервер удерживает HTTP-ответ открытым до тех пор, пока плейлист не достигнет указанной версии, после чего отправляет его.
С точки зрения плеера это выглядит как long polling. С точки зрения разработчика – это требует настоящей инженерной работы: origin должен поддерживать долгоживущие запросы, точно будить только тех клиентов, которые ожидают обновления, а CDN edge – прозрачно проксировать долгоживущие ответы. HLS-спецификация Apple описывает точную семантику – включая лимит таймаута (3 × target duration), требование корректно отправлять `If-Modified-Since` и взаимодействие с rendition reports.
Блокировка перезагрузки плейлиста в связке с `EXT-X-PART` и `EXT-X-PRELOAD-HINT` обеспечивает полный выигрыш по задержке в LL-HLS. Без блокирующей перезагрузки плеер всё равно узнаёт о новых частях с задержкой, равной одному round-trip времени опроса. А с ней обнаружение становится мгновенным – обновление плейлиста приходит ровно в момент готовности частей. В продакшен-пайплайнах LL-HLS используются все три механизма одновременно.
Считаете параметры для своего продукта?
Поможем собрать энкодер-леддер и посчитать стоимость доставки – до старта разработки.