Что такое телевизионные поля ч.2

(c) Дмитрий Ходаков
http://www.dimsun.ru/

Компьютерные платы для ввода/вывода видео

Практически все известные мне платы нелинейного монтажа умеют захватывать и выводить видео с полями. Исключение составляет плата Miro Video DC1, но она вряд ли уже где используется, да и работала с 1/4 от нормального телевизионного разрешения с квадратным пикселем (384х288), так что всё нижеописанное её не касается. Так же не будем касаться различного вида ТВ-тюнеров с функциями капчура и прочих шедевральных девайсов стоимостью по 10$ и с настандартным форматом кадра.

Захват видеоматериала происходит либо в монтажной видеопрограмме через драйвер устройства ввода, либо с помощью утилит самой платы. Дальнейшая работа с материалом происходит на timeline видеоредактора и уже от настроек проекта зависит, будет ли содержать поля выходной клип или нет. Широкое распространение получил ввод информации через 1394 интерфейс (FireWire/iLink), но способ захвата/обработки не меняется и здесь.

Когда не существовало формата DV и плат работающих в нём (золотая эра нелинейного монтажа - середина 90-х), всё было достаточно просто. Подавляющее большинство плат того времени работали в формате сжатия изображения MJPEG и имели в качестве доминирующего поля именно первое. Яркие представители этого класса: Truevision Targa 1000/2000; Miro Video DC30; Matrox DigiSuite; DPS Perception. Тогда практически не существовало проблем – ролики со студии на студию передавались в большинстве случаев с первым полем и перегон принесённого материала в "свой формат" делался через Avid MCX Press или Adobe Premiere путём тупого пересчёта в свой кодек. Оппонентами таких видеоплат работающими со вторым полем были Fast AV Master, Miro Video DC20. Бывало нет нет, да и приносили ролик в их формате и тут начинались головняки. У незнающих.

Можно долго распространяться о том, какие возникали сложности при переносе видеоматериала с платы одной группы на другую. И дело может оказаться не только в ином кодеке, но и в иных разрешении, доминирующем поле, размере и кроппинге кадра. Очень часто простым переворотом полей в самой распространённой монтажной программе Adobe Premiere качественно проблему не решить. Нужно запускать тяжёлую артиллерию типа Adobe After Effects, чтобы правильно изменить поля, поменять разрешение кадра, обрезать кроппинг (какой идиот его ещё использует).

С приходом стандарта DV с его вторым полем стало одновременно и хуже и лучше. Хуже - потому как ещё обширен парк старых плат, работающих с первым полем и нет никаких предпосылок к тому, чтобы парк этот сколь более менее быстро умер. До сих пор живут много дорогих и просто отличных по характеристикам видеоплат (Truevision Targa, Matrox DigiSuite, DPS Perception и т.п.) работающих в формате MJPEG или Uncompress, предназначенных именно для профессионального применения и дающих намного более высокое качество и больше возможностей, чем у DV. Почему именно второе поле в качестве доминантного получило DV, я не знаю. Однако, как уже упоминалось выше, мне довелось слышать мнение, что это произошло с подачи Microsoft: американцы вполне логично сделали новый стандарт под себя и под свой формат NTSC. Но как бы то ни было, а расхлёбывать эту кашу приходится всему миру до сих пор.

А чем же стало лучше? Унификация! Сейчас (2008 г. - примечание) острота проблемы снимается: DV всё более проникает в низкобюджетные студии и становится стандартом de-facto, каким ещё лет 10 назад там был S-VHS. Фактически сейчас существует один универсальный кодек - Microsoft-DV; единый размер кадра; единый видеобитрейт; единые параметры звука. Другими словами передача материала с одной студии на другую превратилась в простейшее дело, не требующее времени на конвертацию и напряжения мозга видеомонтажёров.

Полукадры крупным планом

Итак, что же оно такое, эти полукадры-поля? Давайте рассмотрим в деталях.

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

Поднятая рука ребёнка имеет заметные полосы - это и есть телевизионные поля. Тогда почему они заметны только на руке и практически незаметны на остальном участке кадра (особенно чистым выглядит шкаф сзади). Ответ одновременно и прост и очень важен. Собственно он и есть ключ к пониманию сути.

Ребёнок быстро машет рукой. Пока луч кинескопа прорисовывал нечётные строки (у него на это уходит 1/50 секунды, помните?), рука успела чуть сдвинуться в пространстве и при рисовании второго полукадра её положение уже иное. Именно так видео засняла и разложила на поля видеовидеокамера, и точно так его и надо выводить на экран ТВ. А перемещения окружающих ребёнка предметов не было (разве что камера чуть тряслась), оттого и гребёнки на них практически нет. Но, такая картина наблюдается только на компьютерном мониторе, имеющем построчную развёртку, а стоит такое видео вывести на экран телевизора и мы не увидим никаких полос, перемещение объектов будет гладким, а сами объекты цельными.

Постараюсь тоже самое объяснить на примере анимированных картинок. Для простоты я взял всего 4 строки (по 2 строки на кажое поле) и всего 4 кадра. Итак, мы начинаем перемещать по экрану слева направо квадрат. Доминирующее поле в материале - первое.

 полукадры присутствуют

Та самая "гребёнка". Здесь видно, как квадрат разбивается на строки при перемещении, и такое происходит в масштабе всего телевизионного растра. За один кадр луч кинескопа делает по экрану два прохода и содержимое этих проходов РАЗНОЕ (вот он, ключевой момент - в отличие от прогрессивного сигнала!). Каждая следующая строка как бы дорисовывает движение, начатое в предыдущей строке.

В итоге человек видит на экране не скачкообразное перемещение квадрата 25 раз в секунду заметными прыжками, а... (как бы это выразиться.....) видит более сглаженное..."перетекающее" движение состоящее из 50 фаз, что воспринимается как плавное движение. Вот такой вот чистой воды обман зрения.

полукадры отсутствуют

А сейчас рассмотрим вариант без полей. По этой анимации видно, что квадрат перемещается за те же самые временные интервалы целиком и дискретно: был тут, а теперь уже в другом месте - скачками. И никаких вам переходных фаз, никакого разбиения на строки. И переместившись на новое место он тупо там стоит 1/25 секунды. А вот при чересстрочной прорисовке он стоял бы неподвижно "в одной позе" всего 1/50 секунды. Именно по этим причинам, видя на экране телевизора динамичную картинку без полей мы говорим: "Изображение чего-то стробит". И если такое движение ни коим образом не стилизовать под кино размывая движущиеся объекты или смешивая соседние кадры (blending), то зритель увидит неприятный строб.

Только что сказанное наглядно демонстрирует фотосессия квадрата быстродвигающегося слева направо по экрана телевизора, сделанная с большой выдержкой. Хорошо видна дискретность перемещения квадрата по экрану.

На фото слева движение состоит из мелких перемещений - сначала за 1/50 секунды рисуется одно поле, а потом за тоже время - второе. Квадрат за это время уже успевает сместиться вправо.

На правом фото за тоже время квадрат делает лишь один большой скачёк длительностью в 1/25 секунды, а вторые 1/25 секунды он тупо стоит. Отсюда возникает заметный глазу строб.

Работа с видео и компьютерной графикой

Не существует каких-то особенных различий в использовании обоих этих типов данных в качестве исходников. Зато есть различия в природе их появления.

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

ВАЖНО!
Необходимо отслеживать наличие полей во время работы над видеороликом на всех этапах его производства. Все исходники для сборки клипа должны содержать поля. Зачастую можно услышать: "Я вот заготовку в 3DSMax отсчитал без полей, зато в After Effects при рендере поля включил". Бред. Достаточно хоть один раз в цепочке потерять поля и больше вы их ничем полноценно не восстановите. Зарубите это себе на носу!
Кстати, необходимость этого постоянного контроля является наверное самым распространённым фактором нежелания работы с полями: некоторым товарищам просто лениво с ними возиться. Согласен с ними, ведь гораздо приятнее полазить по порносайтам, покурить и попить кофе.

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

Есть ещё нюансы по настройке некоторого софта на рендер. Например первые версии трёхмерного редактора Maya не умели работать с полкадрами вообще. И зачастую, чтобы отрендерить в 3D редакторе графику с полями, включить банальное "Used fields" в рендер-сеттингах может оказаться недостаточным. Например 3DSMax ещё требует их правильной настройки в Preference Settings/Rendering/Field Order – тут надо выбрать Odd или Even

Сложности, проблемы и глюки

Работа с полями постоянно сталкивает композера со многими трудностями. Это и неправильная интерпретация доминирующего поля программами, и проблемы несовместимости с некоторыми плугинами/фильтрами, и, например увеличенное почти в 2 раза время рендера в After Effects и т.д. Это та плата, которую приходится платить за качественную гладкую картинку в конце работы.

Однако практически все эти проблемы решаемы. Но чтобы их решить, надо подойти к проблеме логически. У меня аська с занудным постоянством выкидавает сообщения типа: "Я отрендерил в 3DSMax с полями, потом с полями-же обработал в After Effects, накидал фоток и видео, потом пережал в MPEG2 программой TMPGEnc, потом заавторил в Ulead DVD-Factory и у меня на DVD-плеере что-то стробит". Порою так и хочется спросить у таких деятелей отчего они ещё больше не усложнили техпроцесс и каким таким экстрасенсорным методом я должен найти глюк среди этого нагромождения пережатий/кодирований/рекомпрессов.

Начать расследовать любой баг стоит с максимально укорачивания цепочки и упрощения проекта. Никаких эффектов, никаких плугинов, никаких трансформаций и деформаций, никаких кодеков и компрессий: взяли исходный материал, кинули на таймлайн любимого видеоредактора и вывели изображение на телевизор. Если нет платы видеовывода для прямого контроля, то используйте любую простейшую "однокнопочную" программу для кодирования и записи в DVD-video. Если проблема осталась - разбирайтесь с исходником. Если проблем нет, то начинайте добавлять по 1-2 "наворота" с обязательным последующим контролем, подключайте программу композитинга. От простого к сложному - только так вы сможете "найти больной зуб".

Особое внимание стоит так же уделить идентификации глюка - что именно глючит? Если глючит только какой-то отдельный элемент, введённый в программу извне (например секвенция из 3D программы), то здесь налицо либо её неправильный просчёт при выводе из 3D-редактора или неправильная её интерпретация в программе композитинга/монтажа.

Ниже перечислены типичные грабли для новичков и методы их решения.
Отсчитали вы из 3D-редактора графику в секвенцию, загрузили её в композер, обработали, накидали титров, эффектов и т.д. А тестовый рендер дал на телемониторе гребёнку. Лажа? Несомненно… и вы просто в панике. Чтобы убрать баг, нужно разобраться откуда он вылез. Вариантов обычно три, перечисляю: