Прогрессивная и чересстрочная развёртка: что нужно знать на самом деле

TL;DR

Есть два способа «нарисовать» каждый кадр видео – современный и устаревший. Современный способ, прогрессивная развёртка, рисует весь кадр за один проход: каждую строку, сверху вниз, все одновременно. Устаревший способ, чересстрочная развёртка (interlaced), разбивает каждый кадр на две половины – сначала нечётные строки, затем чётные через долю секунды – и был придуман в 1930-х, чтобы вместить движение в узкую полосу аналогового вещания. Всё в современном вебе, каждый Netflix-стрим, каждый Zoom-звонок, каждый современный ТВ использует прогрессивную развёртку. Но вы по-прежнему будете получать interlaced-материал из старых архивов, спутниковых фидов и некоторых legacy-камер, и если ваш пайплайн не конвертирует его правильно, в выпуске будут видны характерные «зубцы» на всём, что движется – артефакт combing. Эта статья объясняет, как работает каждая развёртка, почему они выглядят по-разному и как именно исправлять interlaced-источники до того, как они дойдут до энкодера.

Зачем это знать

Если вы делаете продукт, в который попадает видео из внешних источников – telemedicine-системы со старого медоборудования, видеонаблюдение со старых IP-камер, образовательные платформы, переиспользующие архивный контент, broadcast-платформы, принимающие спутниковые сигналы – вы будете получать interlaced-материал независимо от того, просили вы об этом или нет. Если ваша команда обрабатывает этот материал как современное прогрессивное видео, на каждом движущемся объекте в итоговом стриме будут видны «зубцы» – артефакт combing, – и ваш кодек будет тратить биты на этот дефект вместо реальной картинки. Combing делает профессиональный контент сломанным, и как только он запечён в закодированный файл, убрать его уже невозможно.

Исправление известное и дешёвое, но должно происходить на правильной стадии пайплайна, и нужно знать, что искать. К концу этой статьи вы будете понимать, когда применять исправление и какой из доступных инструментов подходит вашей ситуации.

Проблема 1930-х, породившая чересстрочную развёртку

Чтобы понять, зачем существует interlaced, нужно вспомнить, как выглядело телевидение в 1930-х. Инженеры в Великобритании, США и Германии впервые в истории передавали движущиеся картинки в эфир и упёрлись в жёсткий компромисс. Им требовались картинки достаточно детальные, чтобы быть полезными (много горизонтальных строк), достаточно частые, чтобы движение выглядело плавным (высокая частота обновления), и при этом помещающиеся в узкую радиополосу. Технологии того времени не могли выдать всё это одновременно.

Конкретный компромисс в числах. Высокая частота – около 50 или 60 картинок в секунду – была необходима, потому что всё, что медленнее, заметно мерцало на электронно-лучевых трубках того времени: экран ощутимо тускнел между кадрами, и зритель это видел. Но доступная радиополоса несла только примерно вдвое меньше деталей. Инженерам пришлось выбирать: либо без мерцания и с низкой детализацией, либо детально, но с мерцанием. Ни то ни другое не годилось.

Британская инженерная команда придумала элегантный обходной путь в 1936 году для 405-строчной системы BBC. 1 Вместо отправки каждой полной картинки целиком они разбили её на две половины. Первая половина содержала только строки с нечётными номерами (1, 3, 5, 7…). Вторая – только с чётными (2, 4, 6, 8…). Каждая половина, называемая полем (field), могла быть передана в половинной полосе, поэтому инженеры передавали два поля за то же время, за которое раньше передавался один полный кадр. Телевизор зрителя визуально сшивал их так быстро, что мозг видел одну детальную картинку, обновляющуюся 50 раз в секунду, хотя каждое отдельное полу-изображение приходило только 25 «полнокадровых эквивалентов» в секунду.

Трюк работал благодаря двум особенностям зрения. Люминофор на экране CRT продолжал светиться крошечный миг после удара электронного луча, что смягчало переход между полями. И ваш глаз достаточно медленный, чтобы две переплетающиеся полу-картинки, нарисованные через 1/50 секунды, выглядели одной целой. Чересстрочная развёртка по сути стала первым видеотрюком сжатия – двукратной экономией полосы в обмен на визуальную ловкость рук. 2

Каждый крупный аналоговый broadcast-стандарт унаследовал эту идею: NTSC в Америке использовал 525 чересстрочных строк на 60 Гц, PAL в Европе – 625 строк на 50 Гц, SECAM во Франции – близкие цифры. 3 Следующие 60 лет именно так передавалось почти всё телевидение в мире.

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

Прогрессивная развёртка и почему она победила

Прогрессивная развёртка – современная альтернатива. Она рисует каждую строку каждого кадра по порядку, сверху вниз, за один проход в один момент времени. Каждый кадр – один полный, целостный снимок. Название происходит от того, что строки идут подряд (прогрессируют) сверху вниз, а не прыгают между нечётными и чётными.

Вокруг трюков с полосой больше не надо строить дизайн по трём причинам, ставшим истиной в 1990-х и 2000-х.

Во-первых, изменились экраны. Плоские LCD- и OLED-дисплеи в вашем телефоне, ноутбуке и ТВ больше не имеют электронного луча, сканирующего люминофор – у них сетка отдельных пикселей, которые обновляются вместе. Рисовать сначала нечётные строки, потом чётные, на современный экран даже физически не ложится. Современные экраны просто обновляют целые кадры.

Во-вторых, сжатие стало достаточно умным. Видеокодеки – программные алгоритмы, которые ужимают видео, чтобы оно поместилось в стриминговый битрейт – спроектированы под предположение, что каждый кадр – это один целостный снимок. Они ищут паттерны внутри кадра и между кадрами, и математика, на которой они работают, ломается на interlaced-данных, где две половины кадра показывают разные вещи. Скармливание interlaced-материала современному кодеку H.264, H.265 или AV1 тратит биты и даёт худший результат. 4

В-третьих, интернету неважна аналоговая полоса. Протоколы доставки видео в вебе – HLS, MPEG-DASH, WebRTC, CMAF – все спроектированы под прогрессивные кадры с первого дня. Просто нет чистого пути для interlaced-сигнала дойти до зрителя через современный стриминговый пайплайн без преобразования.

В итоге: 720p, 1080p, 4K UHD, 8K – все прогрессивные по спецификации. Буква «p» в «1080p» означает progressive. (Буква «i» в «1080i», которая ещё встречается в некоторых broadcast-фидах, означает interlaced.) Для любого продукта, который вы запускаете в 2026 году, относитесь к interlaced как к устаревшему входному формату, который может прийти извне, но никогда не производите его сами.

Артефакт combing – и почему он так разрушителен

Здесь абстрактная идея «два поля на кадр» превращается в конкретную визуальную проблему.

Представьте, что вы снимаете футбольный мяч, летящий через кадр. С чересстрочной развёрткой камера захватывает нечётные строки картинки в один момент, а чётные – через 1/50 секунды. За эту 1/50 секунды мяч сместился на несколько сантиметров. Поэтому нечётные строки видят мяч в одном положении, а чётные – чуть правее. Если телевизор корректно сшивает их визуально, вы не замечаете – глаз и CRT сливают их в плавное движение.

Но что произойдёт, если взять эти interlaced-данные и попытаться отобразить их как прогрессивные – например, записать оба поля в одну картинку и показать её на плоском экране? Две половины больше не сливаются. Нечётные строки показывают мяч в первой позиции, чётные – во второй. Везде, где у мяча есть край, видна горизонтальная пилообразная картина – знаменитый артефакт combing. 5

Пилообразный рисунок похож на зубцы расчёски, отсюда и название. Статичные части кадра (трава, штанги ворот) не показывают combing, потому что между двумя полями ничего не двигалось; нечётные и чётные строки идеально совпадают. Combing появляется только на движущихся краях.

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

А теперь разрушительная часть. Combing – это не проблема отображения, которая исчезнет, когда экран зрителя «разберётся». Артефакт запечён в данных в момент, когда два поля начали трактоваться как один кадр. Если скормить такой combing-кадр современному кодеку, кодек видит эти горизонтальные зубцы как реальные детали и старательно их сжимает. Биты тратятся на кодирование шума. Motion estimation – часть кодека, которая определяет, как каждый кадр связан со следующим, – путается из-за всего этого высокочастотного горизонтального шума. Итоговый поток получается больше и хуже, чем заслуживает источник.

Поэтому каждый ответственный пайплайн преобразует interlaced-источники в прогрессивные до кодирования, а не после. Когда combing-кадр уже закодирован, combing навсегда остаётся в файле.

Деинтерлейсинг – делайте раз, делайте правильно

Процесс преобразования называется deinterlacing. Он берёт двухполевой interlaced-источник и выдаёт серию полных прогрессивных кадров, которые понимает современный мир. Существуют четыре семейства алгоритмов деинтерлейсинга, в порядке от «дешёвых и плохих» до «дорогих и хороших».

Для подавляющего большинства задач правильный ответ – motion-adaptive категория, конкретно фильтр BWDIF.

BWDIF (Bob Weaver Deinterlacing Filter) – улучшение более старого фильтра YADIF (Yet Another DeInterlacing Filter, изначально написанного для опенсорсного видеоплеера MPlayer инженером Михаэлем Нидермайером). 6 Оба фильтра работают, проверяя каждый пиксель: если пиксель в области, которая не двигалась между нечётным и чётным полем, они выполняют «weave» – доверяют обоим полям и комбинируют их напрямую. Если пиксель в области с движением, они выполняют «bob» – отбрасывают конфликтующее поле и синтезируют заместительную строку, глядя на соседние статичные пиксели. Разница между YADIF и BWDIF в том, насколько агрессивно каждый смотрит в будущие кадры для принятия лучших решений: BWDIF одновременно изучает прошлые, текущие и будущие кадры и лучше справляется с быстрым движением. 7 Оба фильтра поставляются «из коробки» в популярном опенсорсном видеоинструменте FFmpeg.

Вот реальная команда – та, что мы запускаем в продакшене Фора Софт для 1080i-источника, приходящего по broadcast SRT:

# Деинтерлейсинг 1080i-источника до 1080p25 через BWDIF, перекодирование в H.264.
ffmpeg -i in.ts -vf "bwdif=mode=send_frame:parity=tff" \
       -c:v libx264 -preset slow -crf 18 -c:a copy out.mp4

Загадочная часть – bwdif=mode=send_frame:parity=tff. mode=send_frame говорит фильтру выдавать один прогрессивный кадр на каждые два interlaced-поля – сохраняя ту же частоту, что у источника (1080i25 → 1080p25). Альтернатива – mode=send_field, который выдаёт прогрессивный кадр на каждое одно поле, удваивая частоту (1080i25 → 1080p50) и сохраняя максимально плавное движение. Используйте send_field для быстро-движущегося контента типа спорта; send_frame – для всего остального.

parity=tff говорит фильтру, какое поле каждого кадра «верхнее» – нечётное или чётное. «TFF» означает «top field first», «BFF» – «bottom field first». Interlaced-источники в природе разные; одни шлют TFF, другие BFF, и неправильная parity даёт дрожащий выход, который выглядит так, будто время сломано. Это раздражающе сложно дебажить, если не знать причину.

Всегда проверяйте parity до пакетной обработки. Инструмент – ffprobe (бесплатно, ставится вместе с FFmpeg), который читает метаданные файла, или фильтр idet внутри FFmpeg, который анализирует реальные пиксельные данные, а не доверяет флагу в метаданных. Прогоните 5-секундный сэмпл источника через idet и посмотрите результат, прежде чем запускать четырёхчасовой батч.

Частая ошибка: деинтерлейсить дважды или не деинтерлейсить вообще

Два режима провала повторяются в продакшен-аудитах раз за разом. Оба легко допустить и сложно потом локализовать.

Ошибка 1: двойной деинтерлейсинг. Устройство захвата деинтерлейсит на входе (потому что прошивка вендора делает это автоматически). Позднее в пайплайне шаг транскодинга деинтерлейсит ещё раз (потому что оператора не предупредили). Двойная конвертация даёт мягкий, размазанный, слегка дрожащий выход, который ощущается «не так», но привязать к одной стадии трудно. Выберите одно место в пайплайне, где деинтерлейсите, делайте это аккуратно, и чётко маркируйте результат как прогрессивный в метаданных, чтобы никто дальше не пытался деинтерлейсить ещё раз.

Ошибка 2: деинтерлейсинг не происходит. Кто-то заливает «1080i25» в пайплайн, который считает, что всё прогрессивное. Энкодер обрабатывает данные как прогрессивные – и запекает combing в каждый движущийся кадр выходного файла. Зритель видит зубцы на всём, что движется, а файл уже навсегда сломан; только перекодирование с чистого источника может это исправить.

Исправление в обоих случаях: один чётко маркированный шаг деинтерлейсинга в ingest-пайплайне, сразу после того, как источник входит в систему. Метить выход как «progressive – already deinterlaced». Все следующие стадии доверяют этой метке и не обрабатывают повторно.

Чем мы занимаемся в Фора Софт

Мы работаем с interlaced-источниками почти каждую неделю. Telemedicine-системы часто получают 1080i-фиды через SRT из старого больничного оборудования. Архивы видеонаблюдения уходят в NTSC- и PAL-эры, когда камеры были изначально interlaced. Broadcast-партнёры иногда передают фиды в 1080i25, которые надо приземлить в публичный веб как 1080p25 или 1080p50. Исправление всегда – небольшой аккуратный кусочек pipeline glue: шаг detect-parity, который прогоняет idet по сэмплу, фильтр деинтерлейсинга, подобранный под тип контента, и чистый прогрессивный выход, который примут все downstream-кодеки и плееры. Принципы из этой статьи – те, что мы применяем каждый раз.

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

• Чересстрочная развёртка разбивает каждый кадр на две полу-картинки (поля), захваченные через 1/50 или 1/60 секунды. Это трюк 1930-х по экономии полосы.
• Прогрессивная развёртка рисует каждый кадр за один проход. Единственный формат, под который спроектированы современный веб, дисплеи и кодеки.
• «Combing» – видимые горизонтальные зубцы на движущихся объектах – появляется, когда interlaced-данные показываются как прогрессивные.
• Всегда деинтерлейсьте до кодирования, ровно один раз, motion-adaptive фильтром типа BWDIF.
• Проверяйте порядок полей (TFF vs BFF) через ffprobe или фильтр idet до запуска батча. Неправильная parity = дрожащий выход.

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

• Что такое цифровое видео: от аналогового сигнала к битам
• Сэмплирование и теорема Найквиста применительно к видео
• Frame rate, judder и motion blur