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