Temporal Pixel Correlation: избыточность между кадрами

Автор: Николай СапуновОбновлено: август 202617 мин чтения
Содержание статьи +

TL;DR

Большинство пикселей в видео не меняются от одного кадра к следующему, и современный кодек берёт львиную долю своего сжатия именно из этого факта. Технически сходство между соседними кадрами называется временной избыточностью (temporal redundancy), и кодек её снимает, предсказывая каждый новый кадр из уже закодированных и передавая только небольшую остаточную разницу. По сравнению со сжатием каждого кадра по отдельности эта inter-frame prediction даёт ещё в три раза меньший битрейт, а часто и больше – именно поэтому двухчасовой фильм помещается на флешке, а не на жёстком диске. В статье разбираем, как измеряется временная избыточность, как motion estimation ищет совпадающий блок в предыдущем кадре, что такое I/P/B-кадры и GOP, и как каждое поколение кодеков от H.264 до AV1 и VVC оттачивало инструментарий.

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

Каждое продуктовое решение по видео – выбор кодека, интервал ключевых кадров, пресет энкодера, ширина битрейт-лестницы, выбор CDN, дизайн low-latency-плеера – стоит на одном физическом факте: бо́льшая часть информации видео живёт в изменениях между кадрами, а не в самих кадрах. Если вы понимаете временную избыточность, то умеете читать тикет от инженера и видеть, в motion estimation ли стоимость, в расстановке ключевых кадров или где-то ещё. Вы умеете спорить о том, стоит ли бюджет в 7 reference frames у AV1 затрат на CPU, и почему битрейт камеры на парковке падает почти до нуля, когда машина уезжает – в конкретных терминах, а не на словах. Эта статья – для фаундера, продакта, маркетинг-лида или операционного менеджера без предварительной экспертизы; в конце вы сможете объяснить коллеге, почему говорящая голова стоит дешевле футбольного матча, и куда именно деваются биты.

Почему один кадр похож на следующий

Ещё до запуска кодека любое видео полно повторений, которые видно невооружённым глазом. Поставьте на паузу любую спокойную сцену и шагните на один кадр вперёд. Стена за актёром – та же. Лампа – та же. Стул – тот же. Даже лицо актёра по большей части прежнее: моргнул один глаз, губы сдвинулись на несколько пикселей, остальное идентично пиксель в пиксель. Кодек, который запишет оба кадра целиком, сохранит стену, лампу, стул и 99% лица дважды. Эта переплата и есть то, что кодек выбрасывает.

Технический термин для сходства между соседними кадрами – временная избыточность (temporal redundancy), а операция, которая её снимает, называется inter-frame compression или временное сжатие. «Inter» по-латыни – «между»; кодек теперь смотрит между кадрами, а не внутри одного. Противоположная операция – снять повторения внутри одного кадра – называется intra-frame или пространственное сжатие, ей посвящена отдельная статья пространственная избыточность пикселей. Современные кодеки используют обе техники, и они дополняют друг друга: пространственное сжатие выжимает один кадр до минимально возможного размера в одиночку; временное затем замечает, что большая часть этого кадра вообще не должна была передаваться, потому что предыдущий кадр её уже принёс.

Полезная аналогия. Представьте, что каждый день вы шлёте другу фотографию своей книжной полки. В первый день вы отправляете фото целиком. Во второй вместо нового фото вы отправляете записку: «всё как вчера, только красная книга переехала на две полки ниже». В третий – ещё одну записку. Стоимость второго и третьего дней вместе – крошечная доля первого. Так и работает inter-frame compression. Полная фотография – это ключевой кадр (keyframe); записки – это предсказанные кадры.

Сколько это даёт? В типичном видео примерно 90% кадров не являются ключевыми в конфигурации H.264 или HEVC по умолчанию – они предсказаны от соседей. 1 Motion-compensated inter-frame coding даёт битрейт ниже примерно в 3 раза и более поверх чистого пространственного сжатия. 2 На статической картинке с камеры наблюдения экономия может быть в 20 раз и больше, потому что предсказанные кадры почти пустые. Этот один приём – причина, по которой фильм помещается на одном Blu-ray, а не на двадцати.

Рисунок 1. Соседние кадры – в основном одна и та же картинка. Кодеку нужно описать только небольшую изменившуюся область плюс движение объектов от одного кадра к следующему.

Как кодек реально использует это сходство

Современный inter-frame энкодер снимает временную избыточность в три этапа. Этап один – разбиение на блоки, такой же, как при intra-coding: кадр режется на маленькие квадраты, чтобы каждый можно было обработать отдельно. Этап два – motion estimation: для каждого блока текущего кадра энкодер ищет в недавно декодированном reference-кадре блок, который выглядит наиболее похоже, и записывает, где совпадение было найдено (короткий вектор) плюс маленькую ошибку «пиксель к пикселю». Этап три – трансформация и квантование этого остатка – операция та же, что и в конце пространственного кодирования.

Каждый этап разбирается в собственной статье – inter-frame coding и motion estimation, блочное предсказание (CTU/superblock), transform coding, квантование. Задача этой статьи – сделать этап два понятным настолько, чтобы вы видели, что делает кодек каждый раз, когда прогресс-бар FFmpeg перемещается на один тик.

Этап 1 – Разбиение на блоки (как в intra)

Каждый современный кодек режет кадр на сетку квадратных блоков ещё до всего остального. H.264 называет их макроблоками (macroblocks) по 16×16 пикселей (с дроблением вплоть до 4×4 для тонкой работы). H.265 / HEVC ввёл Coding Tree Unit (CTU) до 64×64 пикселей. AV1 использует superblocks до 128×128, а H.266 / VVC сохраняет 128×128 CTU. 3 Бо́льшие блоки помогают, когда большая область кадра движется как одно целое – например, при панораме стадиона, когда вся толпа смещается влево на одинаковую величину. Меньшие блоки помогают на границах движущихся объектов, где половина блока принадлежит идущему человеку, а другая половина – стене.

Этап 2 – Motion estimation (главный механизм)

Для каждого блока текущего кадра энкодер задаёт один вопрос: есть ли где-то в предыдущем кадре блок, который выглядит почти так же? Если да, описать координаты этого совпадения гораздо дешевле, чем описать сам блок с нуля. Энкодер передаёт декодеру два маленьких числа – насколько сдвинуться по горизонтали и по вертикали – и короткий остаток. Эти два числа вместе называются motion vector. Техника описания блока через ссылку на похожий блок где-то ещё называется motion compensation.

Как энкодер находит совпадение? Он делает block search: ставит текущий блок в разные кандидатные позиции в reference-кадре и измеряет, насколько каждый кандидат похож, обычно метрикой Sum of Absolute Differences (SAD) – суммой модулей разности пикселей двух блоков. 4 Позиция с минимальным SAD побеждает. Полный «exhaustive» перебор всех пикселей внутри радиуса поиска для HD или 4K слишком медленный, поэтому реальные энкодеры используют умные шаблоны поиска, проверяющие лишь несколько десятков позиций на блок. Доминируют три шаблона:

  • Diamond search – старт из центра, проверяем четырёх соседей на расстоянии 1 пиксель (вверх, вниз, влево, вправо). Двигаемся к тому, что лучше, повторяем. Останавливаемся, когда центр уже не побеждается. Быстро и достаточно хорошо для медленного контента.
  • Hexagonal search – та же идея, но шаблон – шесть точек на радиусе 2. Дефолт в x264 и x265 на быстрых пресетах; в x264 радиус ограничен 4–16 пикселями. 5
  • Uneven Multi-Hexagon (UMH) – многоэтапный шаблон с неравномерным охватом; дефолт x265 на высоких пресетах, со значениями search range 16, 32 и 48 на трёх уровнях иерархического motion estimation. 6 Медленнее, чем hex, но находит лучшие совпадения на HD-кадре с быстрым движением.

Именно эти шаблоны – причина, по которой ручка preset так сильно влияет. ultrafast пропускает почти весь поиск; placebo делает почти exhaustive в широком радиусе. Тот же источник на том же битрейте на slow будет выглядеть заметно лучше, чем на ultrafast, потому что motion estimation отработал больше, нашёл правильный блок-совпадение, а не просто какой-то.

Маленькая деталь с большим эффектом: блок-совпадение не обязан попадать на целочисленную пиксельную сетку. Современные кодеки разрешают motion vector с sub-pixel точностью – H.264 и HEVC до 1/4 пикселя по luma (яркостный канал) и 1/8 по chroma (цветовые каналы). AV1 пушит до 1/8 пикселя по luma. 7 Кодек интерполирует синтетическое «промежуточное» положение из reference-пикселей вокруг. Это важно: реальное движение в мире почти никогда не кратно целому пикселю – лицо, сместившееся на 1,3 пикселя влево, гораздо лучше описывается дробным вектором, чем ближайшим целым.

Рисунок 2. Motion estimation. Для каждого блока текущего кадра энкодер ищет в reference-кадре ближайшее совпадение и передаёт его координаты (motion vector) плюс небольшой остаток. Остаток – то, что motion estimation не смог предсказать.

Этап 3 – Трансформация и квантование остатка (как в intra)

То, что осталось после предсказания «пиксель к пикселю», называется остатком (residual). Если предсказание было удачным – стена, плавная панорама, лицо, едва двинувшееся – residual в основном нули. Если предсказание было неудачным – резкий новый объект, склейка сцен, брызги воды – остаток всё ещё несёт большую часть энергии исходного блока. В любом случае кодек передаёт residual в ту же DCT-и-квантование цепочку, что и в конце intra-кодирования, описанную в статьях transform coding и квантование.

Квантование – единственный этап всего пайплайна, где информация реально выбрасывается. Всё до него – разбиение на блоки, предсказание, трансформация – обратимо. Агрессивность квантования, контролируемая одной ручкой под названием QP, и есть причина, по которой более высокий CRF даёт меньший файл: больше коэффициентов residual округляется до нуля.

I, P и B-кадры – действующие лица

Когда inter-frame prediction уже работает, нужно решить для каждого кадра: кодировать ли его с нуля, или опереться на соседа? Современные кодеки используют три типа кадров, а смесь между ними и есть GOP-структура (Group of Pictures).

  • I-кадр (Intra-coded) – кодируется полностью самостоятельно, только пространственным сжатием. Тяжёлый по битам, но декодер может стартовать с любого I-кадра, не нуждаясь в предыдущих. Используется как ключевой кадр для перемотки и восстановления. Типичная доля в битрейтном бюджете: 30–50%, при том что I-кадры составляют 1–2% всех кадров на длинном GOP. 8
  • P-кадр (Predicted) – кодируется как motion vectors плюс residual, ссылается назад на один предыдущий I- или P-кадр. Типичная стоимость в битах: 10–25% от I-кадра при том же качестве. 9
  • B-кадр (Bi-directional) – может ссылаться и назад, и вперёд, на будущие кадры. Типичная стоимость: 25–50% от P-кадра при том же качестве. B-кадры дают самый высокий коэффициент сжатия, потому что у них два reference-кадра для предсказания.

Короткий пример. Распространённая H.264-конфигурация для стриминга – IBBPBBPBBPBBPBB: один I-кадр, затем повторяющийся узор из двух B-кадров между каждой парой P. Двенадцать из пятнадцати кадров – предсказаны; только первый несёт полное изображение. Если I-кадр весит 1,0 МБ, P-кадры по 0,15 МБ каждый, а B-кадры – по 0,05 МБ, весь GOP весит примерно 1,0 + 4×0,15 + 10×0,05 = 2,1 МБ. Тот же контент в режиме all-I весил бы 15 × 1,0 = 15 МБ. Коэффициент сжатия, выигранный чисто за счёт временного кодирования, – около .

Это и есть число, которое стоит запомнить. Пространственное сжатие обычно уводит 1080p видео из 600 Мбит/с сырых данных вниз до примерно 30 Мбит/с в all-I-режиме; временное затем берёт эти 30 Мбит/с и доводит их до 5–8 Мбит/с при том же качестве. Временной слой зарабатывает примерно три четверти всего сжатия, которое вы видите на экране.

Рисунок 3. Типичный 15-кадровый GOP. I-кадр в позиции 0 – якорь группы; P-кадры опираются на предыдущий P/I; B-кадры – на оба направления. Высота столбиков показывает, как резко падает битовая стоимость предсказанных кадров.

Hierarchical B-frames – GOP получает дерево

Простой линейный узор выше оставляет деньги на столе. HEVC и все кодеки после него используют hierarchical B-frames (или «B-pyramid»), где некоторые B-кадры сами становятся reference-кадрами для других B. Зависимости образуют дерево, а не цепочку. HEVC в конфигурации Random Access использует 5 temporal layers в этой иерархии. 10 Выигрыш – примерно 15–20% поверх плоского GOP при той же средней оценке качества, потому что энкодер может тратить больше бит на немногие B-кадры у корня (от которых зависит много потомков) и меньше – на листья.

Чтобы B-pyramid работала, размер GOP должен быть степенью двойки – типично 16 или 32. Побочный эффект: энкодер обязан переупорядочивать кадры. B-кадр в позиции отображения 4 может зависеть от I-кадра в позиции 0 и от P-кадра в позиции 16, поэтому позицию 16 нужно закодировать раньше позиции 4, хотя показана она позже. Эта перестановка не видна плееру, но именно она – причина, по которой HEVC-энкодеры по умолчанию вводят больше задержки, чем H.264.

Куда уходят биты на типичных I, P и B-кадрах

Раскладка между intra-coding (внутри одного кадра) и inter-coding (между кадрами) зависит от контента. Числа ниже типичны для сцены 1080p 24 fps, закодированной x265 на CRF 22 – это примерно качество, на которое целятся стриминговые сервисы:

Источник экономииПримерная доля сжатия
Пространственное предсказание (intra) внутри I-кадров25–35%
Motion compensation между кадрами (главный герой этой статьи)50–70%
Energy compaction трансформации + квантование10–20%
Энтропийное кодирование (CABAC, arithmetic)5–10%

Доли меняются под контент. Интервью говорящей головы легче поддаётся временному кодированию – голова движется медленно, фон статичен – поэтому временное забирает ближе к 80% бюджета. Футбольный матч сложнее – игроки бегут, камера панорамирует, толпа мерцает – поэтому временное падает до 50%, а intra должен покрыть остальное. Машина per-title encoding у Netflix существует именно для того, чтобы измерять этот раскладку и подстраивать энкодер-лестницу под смесь пространственной и временной сложности каждого тайтла; опубликованный результат – около 20% экономии трафика в среднем, до 30% с per-scene tuning. 11

Как каждое поколение кодеков улучшало временное предсказание

Каждое поколение кодеков добавляло новые motion-инструменты. Главные улучшения:

  • H.264 / AVC (2003) – до 16 reference-кадров, 1/4-pel sub-pixel precision, motion-partitions от 16×16 до 4×4. 12
  • H.265 / HEVC (2013) – те же 16 references, та же 1/4-pel, но motion-partitions до 64×64. Введены AMVP (Advanced Motion Vector Prediction) и Merge mode, которые позволяют одному блоку унаследовать motion vector от соседа без дополнительных бит. Hierarchical B-pyramid в reference-конфигурации. 13
  • AV1 (2018) – до 7 reference-кадров, 1/8-pel sub-pixel precision, superblocks до 128×128. Добавлены OBMC (Overlapped Block Motion Compensation, смешивает предсказания от соседних блоков, чтобы сгладить швы на границах), warped motion (per-block аффинное преобразование – повернуть и растянуть reference-блок, а не только сдвинуть), global motion (одно аффинное преобразование на весь кадр – идеально для панорам и зумов), и более богатая compound prediction, смешивающая два reference-кадра. 14
  • H.266 / VVC (2020) – до 1/8-pel luma, 128×128 CTU, и affine motion model на 4 или 6 параметров с sub-block precision, так что один блок может описать поворот, зум и сдвиг, а не только перенос. Добавлены SbTMVP (sub-block temporal motion vector prediction), BDOF (Bi-Directional Optical Flow) и DMVR (Decoder-side Motion Vector Refinement). 15

Каждый шаг по лестнице кодеков покупает примерно 30–50% более низкий битрейт при том же качестве, и существенная часть этого улучшения – именно в motion-слое, а не в трансформе или энтропии. Камера, панорамирующая стадион, – канонический случай, где global-motion-инструмент AV1 окупается: H.264 вынужден слать тысячи почти одинаковых motion vectors для блоков, которые все движутся вместе; AV1 шлёт одно аффинное преобразование на весь кадр.

Рисунок 4. Motion-инструментарий растёт с каждым поколением кодеков. Каждый новый инструмент целит в класс движений, который предыдущий кодек описывал плохо.

Частая ошибка: укорачивать GOP ради live-стриминга

Самая дорогая ошибка, которую мы видим у команд на реальных проектах – слишком короткий GOP в попытке сделать low-latency-стриминг. Короткий GOP – скажем, один I-кадр в секунду – действительно помогает join-у, перемотке и восстановлению, но стоит много трафика: I-кадры продолжают прилетать, и каждый – самый тяжёлый кадр в потоке. Дефолт для live – один I-кадр на 2 секунды (-g 48 на 24 fps) – разумный баланс. Срезать это до одного на полсекунды легко добавляет 20–35% к общему битрейту при том же качестве, а join-time после настройки CMAF или LL-HLS почти не улучшается. Правильный ответ почти всегда – «оставьте GOP в покое, чините latency в сегментере и плеере», а не «укоротите GOP». Подробный разбор протокольной механики – в LL-HLS vs WebRTC vs CMAF-LL: low-latency.

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

Мы делаем видеопродукты с 2005 года – видеоконференцсвязь, OTT, e-learning, surveillance, телемедицина, AR/VR – и тюнинг motion estimation один из самых частых рычагов, к которому мы тянемся, когда у клиента не сходится битрейт или latency. На surveillance-проектах экономия от временной избыточности огромна по умолчанию, потому что сцена статична бо́льшую часть суток, и правильный ответ обычно – длинный GOP с выключенными B-кадрами для быстрого random access; на live e-learning стриме GOP должен вставать рядом с сегментером, чтобы motion estimation отрабатывал свою работу, не делая «зайти на лекцию» медленным. Мы не продаём лицензии кодеков и не продаём железо – мы вшиваем кодеки в остальной продукт, где трейд-оффы становятся видны.

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

  • Большая часть информации видео – в изменениях между кадрами, а не в самих кадрах.
  • Inter-frame prediction зарабатывает 50–70% всего сжатия в типичном стриминговом контенте; пространственное – остальное.
  • Motion vector говорит декодеру, где в reference-кадре искать совпадающий блок; оставшаяся ошибка – это residual.
  • I, P, B кадры обменивают независимость на сжатие: I-кадр для seek, P/B кадры в 5–20 раз дешевле.
  • Каждое поколение кодеков добавляет инструменты – AMVP, Merge, OBMC, warped, global, affine – и каждый покупает несколько процентов.
  • Укорачивание GOP не лечит latency: оно поднимает битрейт и почти не помогает join-у, когда сегментеры настроены.

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

Источники

  1. FastPix. "Understanding Video Inter-Frame Compression Techniques." Дата обращения 2026-05-16. https://www.fastpix.io/blog/understanding-video-inter-frame-compression
  2. ScienceDirect Topics. "Temporal Compression – Overview." Дата обращения 2026-05-16. https://www.sciencedirect.com/topics/computer-science/temporal-compression
  3. Wikipedia. "Inter frame." Дата обращения 2026-05-16. https://en.wikipedia.org/wiki/Inter_frame
  4. Lumenci. "How Video Codecs Work." Дата обращения 2026-05-16. https://lumenci.com/blogs/how-video-codecs-works/
  5. x264 encoder guide, FFmpeg.party. Дата обращения 2026-05-16. https://ffmpeg.party/guides/x264/
  6. x265 Documentation, "Command Line Options." Дата обращения 2026-05-16. https://x265.readthedocs.io/en/master/cli.html
  7. Chen, Y. et al. "A Technical Overview of AV1", arXiv:2008.06091. Дата обращения 2026-05-16. https://arxiv.org/abs/2008.06091
  8. OTTVerse. "I, P, and B-Frames – Differences and Use Cases Made Easy." Дата обращения 2026-05-16. https://ottverse.com/i-p-b-frames-idr-keyframes-differences-usecases/
  9. Elecard / Video Compression Guru. "Group of pictures and its structure." Дата обращения 2026-05-16. https://videocompressionguru.medium.com/group-of-pictures-and-its-structure-8d9c4ea20852
  10. arXiv 2406.16544. "Hierarchical B-frame Video Coding for Long Group of Pictures." Дата обращения 2026-05-16. https://arxiv.org/html/2406.16544v1
  11. Netflix Technology Blog. "Per-Title Encode Optimization." Дата обращения 2026-05-16. https://netflixtechblog.com/per-title-encode-optimization-7e99442b62a2
  12. ITU-T Recommendation H.264. https://www.itu.int/rec/T-REC-H.264
  13. HEVC Inter-Picture Prediction notes. https://harrycharan.gitlab.io/pdfs/2014_hevc_alg.pdf
  14. Chen, Y. et al. "An Overview of Core Coding Tools in the AV1 Video Codec." https://www.jmvalin.ca/papers/AV1_tools.pdf
  15. OTTVerse. "Affine Motion Compensated Prediction in VVC." https://ottverse.com/affine-motion-estimation-compensation-in-vvc/

Строите такую систему?

Подберём параметры кодирования под ваш контент и посчитаем стоимость доставки до старта разработки.