GOP-структура: I, P, B-кадры, open/closed GOP

TL;DR

GOP (Group of Pictures, «группа изображений») – это отрезок видеопотока, начинающийся с ключевого кадра (keyframe) и заканчивающийся непосредственно перед следующим keyframe. Это наименьший фрагмент видео, который можно декодировать независимо. Внутри GOP кодер чередует три типа кадров: I-кадры (полные изображения), P-кадры (предсказанные на основе предыдущих кадров) и B-кадры (предсказанные по данным как прошлых, так и будущих кадров), располагая их так, чтобы после небольшой перестановки декодер мог воспроизвести последовательность. Две основные структурные настройки – длина GOP (расстояние между keyframe) и его «открытость» (могут ли B-кадры ссылаться за пределы GOP): ошибка в любой из них нарушает возможность перемотки (seek), переключение битрейтов в ABR или приводит к сбоям в обоих случаях. Эта статья даёт рабочую ментальную модель, которую в 2026 году используют инженеры HLS, DASH, WebRTC и вещания, а также цифры, подтверждающие каждое решение, и одностраничный чит-лист.

Зачем это нужно

Длина GOP – единственная настройка, которая одновременно влияет на размер видеофайлов, скорость перемотки у зрителя, чистоту переключения битрейтов в HLS-плеере и задержку лайв-стрима от камеры до экрана. Слишком длинный GOP – и перемещение по видео тормозит; слишком короткий – и битрейт растёт на 20–40% при том же визуальном качестве. Выбор между open и closed GOP – следующее важное решение, которое чётко разделяет архивные мастер-файлы и стриминг для конечного пользователя. Основатель, прочитавший эту статью, сможет на встрече по инфраструктуре уверенно обсуждать правильные параметры; операционный руководитель – за пять секунд заметить расхождение в энкодерной лестнице у поставщика.

Что такое GOP и зачем он нужен

Group of Pictures, почти всегда сокращаемое до GOP, – это последовательность кадров, начинающаяся с ключевого кадра (keyframe) и заканчивающаяся непосредственно перед следующим keyframe. Ключевой кадр – это точка входа: кадр, который декодер может восстановить, не имея доступа к предыдущим. Все остальные кадры в GOP зависят от keyframe (или от цепочки кадров, ведущей к нему).

Это похоже на главы в книге: вы можете открыть книгу с любой главы и читать дальше, не читая предыдущие, но не сможете понять предложение из середины третьей главы без контекста. Keyframe – это первое предложение главы; последующие кадры – это предложения, которые на нём строятся; следующий keyframe – первое предложение следующей главы.

Эта конструкция «глав и страниц» существует из-за особенностей математики сжатия, описанных в предыдущих статьях о внутрикадровом кодировании и межкадровом кодировании. Межкадровое кодирование – описание кадра как небольшой коррекции более раннего кадра – примерно в 30 раз эффективнее, чем внутрикадровое кодирование того же содержимого. Но за эту эффективность приходится платить: P-кадр сам по себе бесполезен. Чтобы восстановить его, нужно проиграть все кадры, начиная с ближайшего keyframe.

GOP-структура – это компромисс между двумя факторами. Длинные GOP дают кодеру больше inter-кадров и снижают битрейт. Короткие GOP обеспечивают декодеру больше точек входа и ускоряют перемотку, переключение каналов и адаптивный стриминг. Любой видеопоток, который вы когда-либо смотрели, выбирает определённую точку на этой шкале.

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

Три типа кадров и как они складываются в GOP

Полные названия – Intra-coded, Predicted, Bi-predictive – были закреплены в MPEG-1 в 1993 году и с тех пор не менялись. Поведение при сжатии тоже почти не изменилось: современные кодеки добавили новые приёмы к каждому типу, но буквы остались прежними.

I-кадр – это полная картинка. Он сжимается только за счёт информации, содержащейся в нём самом, по той же логике, что и JPEG. I-кадр можно декодировать независимо. Каждый GOP начинается с него. Типичный I-кадр 1080p в H.264 занимает 80–250 килобит.

P-кадр – это кадр, который копирует большую часть содержимого из предыдущего кадра в порядке отображения и затем вносит изменения в отличающиеся участки. Буква P означает Predicted (предсказанный). Кодер описывает каждый блок с помощью motion vector – указателя на похожий участок в предыдущем кадре – и небольшого residual. P-кадр при той же нагрузке обычно занимает 30–60% объёма I-кадра.

B-кадр – это кадр, который может использовать данные как из предыдущего, так и из последующего кадра, усредняя их. Буква B означает bi-predictive (двунаправленный прогноз). B-кадры обеспечивают наилучшее сжатие среди трёх типов: обычно занимают 15–30% объёма I-кадра. При этом они требуют наибольшей задержки: кодер не может сформировать B-кадр, пока не увидит будущий опорный кадр, а декодер не может его отобразить, пока не расшифрует этот будущий кадр.

Рабочий GOP объединяет три типа кадров в повторяющийся узор. Классический вариант – IBBPBBPBBPBB…: один ключевой кадр (I), затем P-кадр каждые три позиции с двумя B-кадрами между каждым P. Иерархические B-пирамиды, описанные ниже, заменяют этот простой шаблон более умной структурой, но принцип остаётся тем же: I-кадр открывает GOP, P-кадры указывают вперёд, а B-кадры заполняют промежутки.

Конкретный пример закрепляет цифры. Возьмём 2-секундный сегмент 1080p24 – 48 кадров при 24 кадрах в секунду – закодированный современным пресетом x265 с закрытой группой кадров (closed GOP) длиной 48 и узором IBBPBBPBBPBB…. В этом сегменте – 1 I-кадр, 15 P-кадров и 32 B-кадра.

I-кадр:    1 × 200 кбит = 200 кбит
P-кадры:  15 × 100 кбит = 1500 кбит
B-кадры:  32 ×  50 кбит = 1600 кбит
итого за 2-секундный сегмент:  3300 кбит
средний битрейт:              1650 кбит/с ≈ 1.65 Мбит/с

А теперь проигрывайте тот же сегмент без B-кадров – так работает лайв-кодер с низкой задержкой. Каждая позиция B превращается в P-кадр.

I-кадр:    1 × 200 кбит = 200 кбит
P-кадры:  47 × 100 кбит = 4700 кбит
итого за 2-секундный сегмент:  4900 кбит
средний битрейт:              2450 кбит/с ≈ 2.45 Мбит/с

Отключение B-кадров требует на 48% больше битрейта при неизменном визуальном качестве. Это постоянная плата за low-latency-стриминг в реальном времени и главная причина, по которой WebRTC-пайплайну нужно больше битов, чем HLS при одинаковом разрешении.

Порядок кадров: чем display order отличается от decode order

Кадры B-узорного GOP на диске хранятся не в том порядке, в котором вы их видите. Они расположены в последовательности, удобной для декодера, и это – совсем не то же самое. Разделение между display order (порядок отображения) и decode order (порядок декодирования) – главная причина большинства первых недопониманий, связанных с B-кадрами.

Возьмём GOP, начинающийся с I B B P …. В порядке отображения – то есть в том, в котором кадры выводятся на экран – последовательность выглядит так: I(0) B(1) B(2) P(3). Однако второй B-кадр, находящийся на позиции 2, требует P-кадра с позиции 3 в качестве одного из опорных кадров. Декодер не может обработать B(2) до того, как будет декодирован P(3), поэтому кодер меняет порядок. В порядке декодирования те же четыре кадра хранятся как I(0) P(3) B(1) B(2).

Декодер читает кадры в порядке декодирования, помещает их в небольшой буфер переупорядочивания и выдаёт в порядке отображения в нужный момент. Буфер переупорядочивания добавляет одну кадрную задержку на каждый уровень переупорядочивания – поэтому поток с N B-кадрами между P-кадрами требует до N кадров буферизации в декодере.

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

Эта перестановка обязательна для B-кадров – она структурная. Два практических следствия для продуктовых команд: во-первых, каждый B-кадр добавляет один кадр сквозной латентности – это около 42 мс при 24 кадрах в секунду и 17 мс при 60 кадрах в секунду; во-вторых, плееры, транскодеры и пакеры обязаны учитывать метаданные picture timing в битстриме, чтобы отображать кадры в правильное реальное время. Распространённая ошибка: быстрый пайплайн FFmpeg теряет данные picture order, плеер отображает B-кадры в момент декодирования, и возникает заметный джиттер.

Иерархические B-кадры: узор B-пирамиды

GOP с одним B-кадром между каждой парой P-кадров – это лишь малая часть всего design space. Современные кодеки работают на несколько уровней глубже. Иерархическая B-структура, часто называемая B-пирамидой, позволяет B-кадрам ссылаться на другие B-кадры, формируя несколько временных слоёв внутри одного GOP.

Представьте 16-кадровый GOP. В плоской структуре B-кадры вставляются между P-кадрами на одном уровне: I B B B B B B B B B B B B B B P. Pyramid-структура организует те же 16 кадров в виде дерева. Кадр 8 – это B-кадр на вершине пирамиды, ссылающийся на I-кадр и следующий P-кадр. Кадры 4 и 12 – B-кадры среднего уровня, ссылающиеся на кадры 0, 8 и 16. Кадры 2, 6, 10, 14 – B-кадры нижнего уровня, и так далее. Каждый уровень использует ссылки с более высокого уровня, поэтому глубина зависимостей логарифмическая, а не линейная.

Выигрыш в сжатии ощутим: иерархическое B-пирамидальное кодирование даёт HEVC и AV1 на 10–15% лучшее сжатие на типичном контенте по сравнению с плоской B-структурой той же длины. Платой за это становится буферизация на стороне декодера – самый глубокий B-кадр зависит от опорных кадров, находящихся на расстоянии GOP_length/2. Для VOD это не проблема, а для лайв-стриминга – серьёзное ограничение, поэтому в LL-HLS-потоках пирамиду либо делают неглубокой, либо отключают полностью.

Чтобы полноценно использовать B-пирамиду, длину GOP задают степенью двойки – 16, 32 или 64 кадра. И HEVC, и AV1 рассчитаны на такой формат. По умолчанию AV1 использует 4-кадровый mini-GOP с тремя временными слоями; его система референсов ALTREF и GOLDEN по сути представляет собой пирамиду, построенную из неотображаемых отфильтрованных кадров – об этом мы подробнее поговорим в разделе про AV1 ниже.

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

IDR, CRA и разница между I-кадром и keyframe

Частый источник ошибок – предположение, что «I-кадр» и «keyframe» – одно и то же. Это не так. Каждый keyframe – это I-кадр, но не каждый I-кадр является keyframe.

IDR-кадр – Instantaneous Decoder Refresh – это I-кадр, который одновременно очищает буфер ссылок декодера. После IDR-кадра ни один последующий кадр не может ссылаться на кадры, предшествующие ему. IDR-кадры – настоящие точки случайного доступа: плеер может начать воспроизведение с любого IDR-кадра и корректно декодировать видео далее. В HLS, DASH и CMAF каждый видеосегмент начинается с IDR-кадра – это требование спецификации.

Не-IDR I-кадр – это полностью интра-кодированная картинка, однако последующие кадры всё ещё могут ссылаться на кадры, предшествующие ему. Детектор смены сцены, вставляющий I-кадр для сжатия в начале нового кадра, не вставляет автоматически IDR – это зависит от настроек кодера.

HEVC добавляет третью категорию: Clean Random Access (CRA). CRA похож на IDR – начальные кадры можно декодировать, начиная с него, – но его последующие leading pictures могут ссылаться на кадры, предшествующие CRA, что делает границу более чёткой при склейке потоков. AV1 идёт иным путём: порядок отображения совпадает с порядком кодирования, поэтому концепция GOP становится ближе к «golden frame group» в VP9, а различие между keyframe и I-кадром заменяется сигналами в битстриме KEY_FRAME и INTRA_ONLY_FRAME.

Практические последствия для HLS- и DASH-пайплайнов: во-первых, граница каждого сегмента должна быть IDR-кадром, а не обычным I-кадром – иначе плеер не сможет перейти к этому сегменту с помощью seek; во-вторых, используйте фиксированную длину GOP, чтобы кодер не вставлял ключевые кадры при смене сцены в произвольных местах разных рендеров вашей лестницы; в-третьих, не путайте счётчик ключевых кадров плеера (он считает только IDR) со счётчиком I-кадров кодера (он учитывает оба типа).

Open vs Closed GOP

GOP закрыт, если ни один кадр внутри него не ссылается на кадры за его пределами. Граница между двумя закрытыми GOP – это жёсткий разрез: можно остановить декодирование в конце одного GOP, очистить все ссылки и начать с нуля на следующем IDR без потерь.

GOP открыт, если B-кадр в начале GOP может ссылаться на последний P-кадр предыдущего GOP. Логика чисто компрессионная: этот P-кадр часто оказывается значительно лучшим опорным кадром для первых одного–двух B-кадров нового GOP, чем собственный I-кадр этого GOP. Возможность кросс-граничной ссылки позволяет сэкономить биты.

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

Open GOP обычно экономит 1–3% битрейта при том же VMAF. Это правильный выбор по умолчанию для архивных мастеров и единичных VOD-файлов, в которые вы никогда не возвращаетесь с помощью seek.

Closed GOP обязателен в любом современном workflow с адаптивным битрейтом. И спецификация HLS от Apple, и руководства по совместимости DASH-IF требуют использования closed GOP, выровненных по всем уровням лестницы. Причина – структурная: при переключении плеера с 720p на 1080p это происходит на границе сегмента. Если сегмент 1080p начинается с open GOP, чьи первые B-кадры ссылаются на P-кадр, который плеер ещё не получил, он на пару кадров декодирует мусор и отображает видимые артефакты.

Правило для продакшена однозначно: закрытый GOP, фиксированная длина, выравнивание по всем рендерингам. Экономия 1–3% при использовании open GOP – только для меззантина и архива, но не для доставки.

Длина GOP: самая гибкая настройка стриминга

Длина GOP – расстояние от одного keyframe до следующего, измеряемое в кадрах или секундах, – это настройка, которую чаще всего изменяет operations-инженер. Правильное значение зависит от того, что вы оптимизируете.

В VOD-стриминге выгоднее использовать длинный GOP. Каждый I-кадр стоит дорого; чем дальше они расположены друг от друга, тем ниже средний битрейт на пиксель. Ограничения накладывают требования к перемотке, переключению битрейтов и выравниванию сегментов. Типичный мастер-стрим YouTube или Netflix использует GOP длительностью 2 секунды: 24 кадра в секунду × 2 с = 48 кадров.

В лайв-стриминге длина GOP задаёт нижнюю границу латентности. Плеер не может начать воспроизведение, пока не получит полный сегмент, а сегмент не может завершиться раньше следующего keyframe. GOP 2 с означает минимум 2 секунды сегментной латентности поверх сетевой задержки и буфера. LL-HLS потоки с GOP 1 с и CMAF-частями 200–400 мс достигают латентности glass-to-glass в 3 секунды; full-segment HLS с GOP 6 с в продакшене работает с латентностью 15–25 секунд.

В WebRTC длина GOP определяется стабильностью сети, а не возможностью поиска (seek). WebRTC использует обратную связь по RTP (PLI, FIR, NACK), чтобы по требованию запрашивать ключевые кадры, когда один из участников теряет синхронизацию. Поэтому кодер обычно работает с очень длинным GOP – иногда один ключевой кадр в минуту – и вставляет его только по запросу. Результат – экономия битрейта за счёт полного отсутствия случайного доступа, что допустимо, поскольку WebRTC-потоки не сегментируются для адаптивной доставки.

В вещании длина GOP определяется стандартом: ATSC требует IDR-кадры каждые 0,5–1 с; DVB ориентируется на интервал 0,5–2 с; маркеры SCTE-35 должны располагаться на границах IDR-кадров для вставки рекламы.

Эмпирически частые настройки в продакшене на 2026 год:

Практическое правило для стриминга: выбирайте длину GOP так, чтобы она делилась на длину сегмента, количество аудио-сэмплов на сегмент и частоту кадров. Несоответствие заставляет кодер вставлять лишние IDR-кадры на границах сегментов, что незаметно повышает битрейт.

Частая ошибка: GOP не согласованы с лестницей битрейтов

Самая дорогая ошибка в HLS и DASH – это несогласованные GOP по рендерам. Если 720p- и 1080p-стримы вставляют ключевой кадр в слегка разное время – например, из-за разных детекторов смены сцены, – сегменты перестают совпадать. Плеер может воспроизводить любой из стримов по отдельности, но при переключении между ними на границе сегмента он либо пропускает, либо повторяет кадр, и ABR-переключение становится заметно рывковым.

Лечение – заставить использовать фиксированный одинаковый GOP во всех рендерах. В x264 это --keyint 48 --min-keyint 48 --no-scenecut. В x265 – --keyint 48 --min-keyint 48 --no-scenecut --no-open-gop. В FFmpeg с libx264 эквивалент – -g 48 -keyint_min 48 -sc_threshold 0. Те же значения на каждом рендере.

Вторая, родственная ошибка – смешение open и closed GOP по рендишенам, обычно из-за того, что один рендишен был пересжат с дефолтными настройками, в то время как остальные использовали явные ABR-параметры. Периодически проверяйте лестницу битрейтов: HLS-чит-лист в PDF ниже содержит точные FFmpeg-флаги для самых распространённых workflow.

Третья ошибка: указание длины GOP в секундах без проверки, что частота кадров постоянна. У VFR-источников GOP может иметь сильно различающийся байтовый вес, даже если временные интервалы «постоянны». Сначала следует привести исходник к CFR, а затем задавать длину GOP.

Codec-специфические отличия, которые стоит знать

Концептуальный GOP одинаков во всех современных кодеках, но детали реализации у них различаются.

H.264 / AVC. Поддержка до 16 опорных кадров. B-пирамиды включены по умолчанию через b-pyramid normal в x264. IDR- и не-IDR I-кадры чётко разделены. SPS/PPS NAL-юниты, размещённые в начале каждого IDR-кадра, позволяют декодерам начинать воспроизведение mid-stream.

H.265 / HEVC. Та же базовая модель, что и у H.264, но с добавлением CRA-кадров, позволяющих использовать leading-кадры, которые декодируются независимо, и trailing leading pictures, ссылающиеся на них через CRA. GOP-структуры HEVC обычно включают 4 или 8 уровней иерархических B-кадров; low-delay-режим SVT-HEVC по умолчанию применяет 4-кадровый mini-GOP.

VP9. Концепция «golden frame group» – это долгопериодический референсный кадр, отличный от непосредственно предыдущего, – ведёт себя как гибкая структура GOP без строгой семантики случайного доступа.

AV1. Порядок отображения совпадает с порядком кодирования; в AV1 групповая структура кадров (GOP) формируется на основе управления референсными кадрами, а не с помощью буфера переупорядочивания. Два типа неотображаемых референсов – ALTREF (вперёд, с временной фильтрацией) и ALTREF2 (вперёд, с более коротким горизонтом) – вместе с GOLDEN, LAST, LAST2, LAST3 и BWDREF обеспечивают кодеру доступ к семи референсным кадрам. В режиме высокой задержки (high-delay) кодека libaom-av1 используется группа кадров golden frame из 16 кадров со встроенной трёхслойной пирамидой.

H.266 / VVC. Наследует от HEVC семейство типов кадров IDR/CRS/BLA, а также вводит новый тип – Gradual Decoding Refresh (GDR), – позволяющий декодеру постепенно восстанавливаться после сбоя или при подключении к потоку за заданное число кадров, не дожидаясь следующего IDR. GDR особенно важен для low-latency спутниковых каналов и contribution-линков.

Где здесь Фора Софт

Настройка GOP – одна из тех вещей, с которыми мы работаем на каждом проекте. В наших WebRTC- и видеоконференцпроектах мы используем feedback-управляемые ключевые кадры и очень длинные GOP, чтобы минимизировать использование пропускной способности в unicast-соединениях между пирами. В OTT- и интернет-ТВ-проектах мы применяем закрытые фиксированные GOP, выровненные по всем разрешениям, потому что рассогласование – тихий убийца качества ABR. В системах видеонаблюдения мы используем длинные статичные сцены, увеличивая GOP до 20 секунд и более, и вставляем event-управляемые IDR-кадры на основе метаданных детектора движения. Наши проекты в сфере e-learning и телемедицины находятся посередине: достаточно точек случайного доступа для быстрой перемотки и достаточная длина GOP для экономии CDN. Чит-лист ниже суммирует производственные пресеты, которые мы чаще всего поставляем клиентам.

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

• GOP – это последовательность кадров между двумя ключевыми кадрами; наименьший фрагмент видео, который можно декодировать независимо.
• I-кадры – полные изображения; P-кадры строятся на основе предыдущих кадров; B-кадры используют информацию как из прошлого, так и из будущего и сжимаются эффективнее всего.
• Порядок отображения и порядок декодирования различаются; B-кадры заставляют кодер переставлять кадры и увеличивают задержку.
• Иерархическое B-пирамидальное кодирование даёт прирост сжатия на 10–15% в длинных GOP, позволяя B-кадрам ссылаться друг на друга.
• Только IDR-кадры являются настоящими точками случайного доступа; обычный I-кадр не подходит для границы сегмента HLS.
• Закрытый GOP (closed GOP) обязателен для ABR-стриминга; открытый GOP (open GOP) экономит 1–3% битрейта, но только для архивных мастер-файлов.
• Правило продакшена: фиксированный закрытый GOP, длина которого кратна длительности сегмента и кратна частоте кадров, одинаковая для всех рендеров.

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

• Block-based prediction: MB, CTU, SB и superblocks
• Rate control: CBR, VBR, CRF, ABR, capped CRF
• Стриминг-протоколы: 8 главных в 2026