Сразу предупреждаю - «букфф много», это попытка рассказать о причинах появления «вертикального блюра» или строба, принципах работы Вегаса в статье "Определение реального Field First видеофрагмента" (чтож там на самом деле внутри то происходит?), терминах «приведение к единому первоидущему» и т.д. и т.п.
Так что, если кому то это интересно, то читайте эти «много букфф»…
Конечно, хотелось бы со скринами, причём анимированными, схематически объясняющее описанное (давно собирался их сделать), но… руки так и не дошли. Попробую без них.
На написание этого меня «толкнул» один пост на соседнем форме, его мы разберём позже в этом же посте, когда «переварим» первую часть информации. Там я отвечать не стал, долго это и муторно, а вот здесь попробую рассказать, рассказать для того, чтобы форумчане proVegas-a могли в дальнейшем избежать подобных ошибок и ляпов при работе с интерлейсным видео...

Оговорюсь сразу, что «сфотографированный» момент времени буду называть «кадриком», а НЕ «кадром».
Также буду объяснять не совсем точно технически, но понятно для осознания процесса относительно работы именно(!) в Sony Vegas, так что – не придирайтесь к словам, иначе в следующий раз дам абсолютно грамотное технически, но абсолютно непонятное неподготовленному читателю объяснение…

Итак, поехали… Поехали с самых азов…

Интерлейсная видеокамера снимает 50(!) кадриков в секунду. Именно 50, а не 25, как многие думают.
Уже потом (не важно где - в камере, на плёнке, в программе) из этих кадриков формируются интерлейсные кадры, которые состоят из 2(!) кадриков, или, как их называют – полей, которые идут через строчку. То есть, в интерлейсном кадре присутствуют два(!) различных по времени изображения действа, 2 кадрика, один из которых занимает чётные строки пикселей, а другой – нечётные. Кадрик, который занимает 1,3,5 и т.д. нечётные строки называют верхним полем (Upper Field), а кадрик, который занимает 2,4,6 и т.д. чётные строки – нижним полем (Lower Field).
Итак, в одном интерлейсном кадре находится 2 поля (кадрика) с изображением 2 разных по времени (1/50 сек) действа. Это отчётливо можно увидеть в Вегасе в окне Preview в режиме «Best Full», это как раз то, что многие называют гребёнкой, а по сути – это всего лишь два разных кадрика, два разных «сфотографированных» момента времени…
Но если в интерлейсном кадре два разных момента времени (2 кадрика), то программа должна знать, какой кадрик изображает предыдущий момент действа, а какой – последующий, что произошло раньше, а что позже. Вот для этого введено определение – FieldFirst. Оно рассказывает программе, какой кадрик из этих двух должен показываться раньше, а какой позже, какое поле выводится (показывается) первым, а какое – вторым.
Поэтому, если говорить о DV-видеокамере, которая снимает с «нижним полем» (LowerFieldFirst), то тогда последовательность кадриков (12345678) в раскладке на интерлейсные кадры будет выглядеть так:

1L2U-3L4U-5L6U-7L8U
-1i-- -2i-- -3i-- -4i--

То-есть, 1 кадрик будет помещён в нижнее (L) поле первого (1i) интерлейсного кадра, 2 кадрик – в верхнее (U) поле первого интерлейсного кадра,
3 кадрик будет помещён в нижнее поле второго (2i) интерлейсного кадра, 4 кадрик – в верхнее поле второго интерлейсного кадра,
5 кадрик будет помещён в нижнее поле третьего (3i) интерлейсного кадра, 6 кадрик – в верхнее поле третьего интерлейсного кадра и т.д.

У HDV камеры будет (по аналогии) наоборот, так как HDV камера – UpperFieldFirst: 1U2L-3U4L-5U6L-7U8L

Итак, указав программе, что это видео (или вообще весь проект) LowerFieldFirst, вы тем самым ей говорите, что сначала она должна показать всё то, что находится на нижнем поле, то есть то изображение, которое занимает чётные строки пикселей (2,4,6, и т.д.), а уже после него (спустя 1/50 секунды) уже показать верхнее поле - то изображение, что занимает нечётные строки (1,3,5, и т.д.) интерлейсного кадра.

Что будет, если на таймлайн присутствуют различные эвенты (разный FieldFirst) или эвенты, отличные от настроек проекта?
Посмотрите на эти последовательности:
LowerFieldFirst (LFF ) видео- 1L2U-3L4U-5L6U-7L8U
UpperFieldFirst (UFF) видео - 1U2L-3U4L-5U6L-7U8L
Например, настройка проекта у нас LowerFieldFirst. Что будет происходить? Следуя принципам LFF, программа первым будет брать (показывать) нижнее поле, потом верхнее. Еще раз посмотрим на вторую последовательность –
UpperFieldFirst (UFF) видео - 1U2L-3U4L-5U6L-7U8L
Программа первым возьмёт 2 кадрик (так как он на нижнем поле), а затем 1 кадрик! Потом возьмёт 4 кадрик, затем 3 и так далее! Последовательность показа кадриков будет такая: 21-43-65-87 вместо положенной 12-34-56-78!!!!
Это и есть строб или «два шага вперёд - один назад»!

Вот, чтоб этого не было, в Вегасе (и в других программах) существует так называемый «Полевой контроль». Именно он и отвечает за «привод к единому первоидущему», то есть делает все эвенты с одинаковым FieldFirst, значение которого берётся из настроек проекта.
То есть, если настройки проекта LFF и «полевой контроль» включён, то и все эвенты на таймлайн должны быть LFF, а если попадаются UFF, Вегас сделает из них LFF.
Что делает Вегас, приводя видео «к единому первоидущему»? Как он делает из LFF -> UFF и наоборот? Об этом чуть позже.

Сейчас просто попробуем суммировать некоторую информацию.
Проект LFF. Видео на таймлайн LFF, интерлейсный кадр которого состоит:
из изображения первого кадрика, расположенного на 2,4,6,8,…574,576 строке пикселей (на нижнем поле)
и изображения второго кадрика, находящемся на верхнем поле – на 1,3,5,7,…573,575 строке пикселей.
Так как проект LFF, Вегас будет всегда сначала читать нижнее поле, потом верхнее.

Представьте это себе мысленно, ещё лучше – зарисуйте схематически.

А теперь, подумайте сами, что произойдёт, если вы сдвинете изображение на один пиксель вверх или вниз?

????

Чётные строки станут нечётными и наоборот!!! Если сдвигаете на пиксель вверх, то всё, что было на строках 2,4,6,…574,576 станет располагаться на строках 1,3,5,…573,575 – то есть изображение (кадрик) верхнего поля переместится на нижнее поле и наоборот!
И значит, если раньше у этого интерлейсного кадра был LowerFieldFirst (первый кадрик на нижнем поле), то станет UpperFieldFirst (первый кадрик на верхнем поле). Мы поменяем FieldFirst данного видеоэвента!

Теперь вернёмся к вопросу
«Что делает Вегас, приводя видео «к единому первоидущему»? Как он делает из LFF -> UFF и наоборот?»
Так же – сдвигает на пиксель вверх? Или на пиксель вниз? И не так, и не так. Вегас сдвигает кадрик (поле) на пиксель и вверх, и вниз..
Получается «двоящееся» изображение – «вертикальный блюр» . Например, если мы имеем ряд точек толщиной в один пиксель на 5 строке (верхнем поле), то, после использования этого алгоритма Вегаса этот ряд точек будет присутствовать и на строке 4, и на строке 6.
Почему так? Зачем? Не проще ли просто сдвинуть на пиксель верх или вниз? Забегая вперёд, скажу – нет, не проще. Многие «действительно-гуру» сломали зубы при доказательстве правдивости именно этого алгоритма, объяснение есть, но чтобы читатель понял его объяснение, мне придётся выложить тонну рисованных анимированных роликов, схематично и наглядно показывающих, что только такой автоматизированный алгоритм имеет право на существование. Мы этого делать не будем. Ну, пока точно не будем. Просто возьмем за аксиому:

При включённом «полевом контроле» , чтобы привести «к единому первоидущему» полю «разношёрстны»е эвенты, Вегас сдвигает видеоэвент на пиксель вверх и на пиксель вниз. Поэтому мы и видим «вертикальный блюр» на данном эвенте, эвенте, FieldFirst которого отличается от FieldFirst проекта.
А, соответственно, при ОТключенном «полевом контроле» мы видим строб, строб перепутанных полей - «два шага вперёд - один назад».

А что значит «При включённом “полевом контроле”»? Где он включается?
Вот тут – «Deinterlace metod» в настройках проекта. «None» - отключен, «Blend fields» и «interpolate fields» - включён.
Я немного подробнее писал об этом в этом посте.


================================================== =

Теперь прочитайте ещё раз статью статью "Определение реального Field First видеофрагмента".
Разберём её принцип, основываясь на всём вышеизложенном.

I. Мы хотим увидеть, правильно ли у нас интерпретирован видеоэвент, действительно ли в его свойствах стоит правильный (реальный) FieldFirst или нет? Что мы делаем, что советует нам статья? Переключаем в режим 50p, в этом режиме «полевой контроль» ВЫключен (так как прогрессивный проект не нуждается в полевом контроле), а интерлейсный кадр раскладывается на 2 кадра – 50i ->50p! Каждое поле мы видим как отдельный кадр!
Но видео у нас на таймлайне интерлейсное, и оно как то интерпретировано – или LFF, или UFF. Вот как оно интерпретировано, так Вегас его и разложит на кадры.
Вспомним то, что я писал выше:

Что будет, если на таймлайн присутствуют различные эвенты (разный FieldFirst) или эвенты, отличные от настроек проекта?
Посмотрите на эти последовательности:
LowerFieldFirst (LFF ) видео- 1L2U-3L4U-5L6U-7L8U
UpperFieldFirst (UFF) видео - 1U2L-3U4L-5U6L-7U8L
Например, настройка проекта у нас LowerFieldFirst. Что будет происходить? Следуя принципам LFF, программа первым будет брать (показывать) нижнее поле, потом верхнее. Еще раз посмотрим на вторую последовательность –
UpperFieldFirst (UFF) видео - 1U2L-3U4L-5U6L-7U8L
Программа первым возьмёт 2 кадрик (так как он на нижнем поле), а затем 1 кадрик! Потом возьмёт 4 кадрик, затем 3 и так далее! Последовательность показа кадриков будет такая: 21-43-65-87 вместо положенной 12-34-56-78!!!!
Это и есть строб или «два шага вперёд - один назад»!

Вот так же и в этом случае, правильно интерпретированное видео Вегас разложит как 12-34-56-78, а "НЕ правильное" как 21-43-65-87! Разложит полукадры (поля) по кадрам и даст нам это увидеть!

II. Мы вычислили, какое видео у нас реально с отличным от настроек проекта FieldFirst. Как ведёт себя Вегас? Допустим, у нас проект LFF. Он видит на таймлайне эвент с UFF. Он применяет к нему алгоритм «приведения к единому первоидущему», «двоит» изображение, мы видим вертикальный блюр. Что мы делаем? Сдвигаем на пиксель вверх (PanCrop или Track Motion), тем самым меняем ему FieldFirst (я это писал выше) –

…Чётные строки станут нечётными и наоборот!!! Если сдвигаете на пиксель вверх, то всё, что было на строках 2,4,6,…574,576 станет располагаться на строках 1,3,5,…573,575 – то есть изображение (кадрик) верхнего поля переместится на нижнее поле и наоборот!
И значит, если раньше у этого интерлейсного кадра был LowerFieldFirst (первый кадрик на нижнем поле), то станет UpperFieldFirst (первый кадрик на верхнем поле). Мы поменяем FieldFirst данного видеоэвента!

Вегас видит, что всё стало нормально, всё на своих местах, НЕТ необходимости применять алгоритм «приведения к единому первоидущему», поэтому то и не будет вертикального блюра в этом случае, в случае, когда МЫ САМИ приведём все к «единому первоидущему», просто и без вертикального блюра!


================================================== =

Вот теперь мы и дошли до того «поста на соседнем форуме», который и подтолкнул меня написать этот статью-пост.
Привожу этот пост дословно:

К сожалению, старые глюки Вегаса, с которыми безуспешно бился еще с 5-й версии, перекочевали и в последнюю, 8-ю.
Так он не может поменять порядок полей на правильный при работе с DV файлами после применения эффекта Reverse или переворота кадра на 180 градусов (в свойствах файла).
Правда, если перевернуть картинку при помощи Event Pan/Crop правильный порядок полей сохраняется, но изображение немного двоится (смешиваются поля).
Итак, после реверса или переворота, когда рендеришь в DV Вегас почему-то пытается сделать TFF, и результирующий файл дергается. Если применить два этих эффекта одновременно, то результат в порядке. Но мне эти эффекты нужны по отдельности.
Раньше боролся с путаницей в полях с помощью ависинта, но на новом ноуте он не установлен...
Помогите!
Надо срочно проект сдавать, а там много кадров с перевернутой камерой. Деинтерлейс не предлагать.
Как решить эти баги в Вегасе? Почему он не сдвигает поля между кадрами при реверсе и перевороте?

Начну с того, что то, что автор поста назвал «старые глюки Вегаса», на самом деле – его собственное дилетантское незнание принципов работы программы. Но не будем о его познаниях, разберём его пост.
Во первых, из его поста чётко видно, что «полевой контроль» у него отключен, в свойствах проекта «deinterlace method» стоит <None>. Это ясно из этой фразы:

Итак, после реверса или переворота, когда рендеришь в DV Вегас почему-то пытается сделать TFF, и результирующий файл дергается.

Если бы «полевой контроль» был включён, у него бы всегда был просто вертикальный блюр, такой, как здесь:

Правда, если перевернуть картинку при помощи Event Pan/Crop правильный порядок полей сохраняется, но изображение немного двоится (смешиваются поля).

Дело в том, что при применении Event Pan/Crop вступают в силу другие алгоритмы «разбора по полям», но об этом мы пока не будем говорить…
Но вопрос остается – почему при повороте на 180 градусов и при реверсе появляется вертикальный блюр? Мы знаем, что это следы работы алгоритма по «приведению к единому первоидущему», следовательно, что, у этих эвентов меняется FieldFirst?!? ДА. Меняется. А Вегас просто правит, приводит всё к единому первоидущему и всё.
Почему меняется FieldFirst?
Да элементарно. Рассмотрим случай поворота на 180 градусов. Поворачиваем кадр. 1 строка пикселей становится 576, а 576 –> 1. Чётная становится нечётной и наоборот! LowerField меняется на Upper и наоборот, идёт смена FieldFirst!
Второй случай, случай реверса. Вспомним последовательность: LowerFieldFirst (LFF ) видео- 1L2U-3L4U-5L6U-7L8U
Видно, что первым должно идти нижнее поле. Прочитаем наоборот (сделаем реверс): 8U7L-6U5L-4U3L-2U1L. Теперь, чтобы сохранить правильную последовательность полукадров (полей), сначала надо читать из интерлейсного кадра верхнее поле, а потом нижнее!! И здесь идёт смена FieldFirst!

Вегас это знает, поэтому и применяет в этих случаях алгоритм «приведения к единому первоидущему», блюрит материал…
Но мы знаем, как самим, ручками можно поменять FieldFirst! Сдвиг на пискель вверх или вниз!!

Поэтому, надо просто запомнить – при применении поворота на 180 градусов (или зеркального отражения по горизонтали) и при реверсе у видеоевента меняется FieldFirst. Сдвиньте на пиксель вниз или вверх (PanCrop или Track Motion) и не будет никакого вертикального блюра!
Только надо учитывать одно, что каждый из этих эффектов меняет FieldFirst на противоположный. Поэтому, если мы сначала применим реверс (сменим LFF на UFF), а потом повернём на 180 градусов (снова поменяем UFF на LFF), то видеоэвент сохранит свой начальный FieldFirst. Именно поэтому при применении этих двух эффектов вместе у автора поста всё было в порядке:

…Если применить два этих эффекта одновременно, то результат в порядке. Но мне эти эффекты нужны по отдельности.

Ну вот, наверное, и всё. Рассказал, как мог… Буду рад, если эта информация окажется действительно кому то полезной, поможет ещё более разобраться в алгоритме работы Вегас (а также AfterEffect и прочих программ, использующих этот алгоритм «приведения к единому первоидущему»).
Наступит время, и вы в конце концов полностью поймёте принцип работы программы, «кубик-рубика понимания окончательно сложится» и вы сможете жонглировать многими скрытыми возможностями программы Sony Vegas как настоящий Профи, имея возможность делать то, что не доступно во многих хвалённых едиках, премьерах и других известных программах…

Внимание!

в VegasPro, начиная с версии 9.0b, при монтаже интерлейсного материала исчезла необходимость в сдвиге видеофрагментов на одну строку. Теперь Vegas делает это самостоятельно!

.

просто 5!
отлично, доступно и , надеюсь для всех, понятно.

До недавного времени было понятно и мне, но случилась как-то такая проблемма:
в проекте (PAL DV Widescreen, Lower FF, "Deinterlace metod" -> "Blend fields") использовался материалл 4-х видов:

1. PAL DV Widescreen (720x576, 50i, Lower Field First)
2. HDV-1800i (50i, Upper Field First)
3. DVCPRO 50 (720x576, 50i, Upper Field First)
4. DVCPRO HD 720p (1280x720, 50p)

И вот на выходе столкнусля со стробом

Причем строб проявлялся (ИНОГДА!!!) не только на эвентах DVCPRO 50 (это еще можно как-то объяснить, все-таки UFF), но и на прогрессивном DVCPRO HD 50p, и на HDV (хотя эти два исходника везде даунсемплились до PAL DV Wide). Иногда строб проскакивал и на DV-исходниках. Заметил так же, что в этом проекте Вегас не всегда правильно определял свойства исходников, т.е. показывал не те поля, что в реальном файле, приходилось менять.
В тот раз я это дело поборол. Как потом оказалось - сам кое что недоглядел. Но, как говорится, осадок остался.

После прочтения данной статьи у меня (ну такой вот я дотошный) возник такой вопрос:
допустим, имеется проект pal dv LFF.
имеются два pal dv исходника, но с разными полями
если я поставлю в свойствах проекта "Deinterlace metod" -> "None", подниму один из эвентов (uff) в pan/crop на один пиксел и в дальнейшем буду контролировать это дело при вращении или реверсе, то, если я правильно понял, строба быть не должно.
Надо-ли в таком случае мне насильно менять в свойствах UFF-эвента порядок полей на LFF?

Сообщение от andrewl

если я поставлю в свойствах проекта "Deinterlace metod" -> "None"

то при изменении размера кадра (из HDV -> SD), панкроп и некоторых других манипуляциях в результате (на экране ТВ) получите нечто такое:



и всего делов

Сообщение от GS1966

то при изменении размера кадра (из HDV -> SD), панкроп и некоторых других манипуляциях в результате получите нечто такое:

С этим полностью согласен, сталкивался и прекрасно понимаю - что и откуда здесь берется. Но в "условии задачи" стояло:

Сообщение от andrewl

допустим, имеется проект pal dv LFF.
имеются два pal dv исходника, но с разными полями

т.е. никакого ресемпла не происходит (если, конечно, не наворачивать эффектов в pan/crop)
главный вопрос остается:

Сообщение от andrewl

Надо-ли в таком случае мне насильно менять в свойствах UFF-эвента порядок полей на LFF?

и, в общем-то созрел еще один:
стоит-ли вообще заморачиваться с подвиганием на пиксел эвента "неправильными полями" в том случае, если "Deinterlace metod" -> "Blend fields"?

Блин, как-то все заморочено написалось... Попробую еще добавить объяснений к чему я все это веду.
Насколько понял из статьи, при включении контроля полей в Вегасе, он сам все делает автоматом, на выходе получаем правильную картинку, но там, где ему приходится "поправлять поля" действует алгоритм вертикального блюра. Мой вопрос сводился к тому, что можно-ли этого (блюра) избежать, если отключить контроль и подвинуть эвент на пиксел вверх (или вниз). Естественно, речь идет об одинаковых по размеру кадра исходниках, один из которых имеет UFF. Ну и понятно, что при работе с таким проектом дальнейшие манипуляции с pan/crop недопускаются, как и други эффекты, "двигающие" картинку. Т.е. в идеале - простейший монтаж с fade и cut.

andrewl, знаю, что BIGNik сейчас пишет вам подробный ответ, но отвечу кратко - в пропертях фрагмента (ов) ничего насильно менять не нужно, оставляйте все как есть. Просто сдвинули на пиксель вверх файл с верхним полем (или дорожку, если таких эвентов много).

Сообщение от andrewl

стоит-ли вообще заморачиваться с подвиганием на пиксел эвента "неправильными полями" в том случае, если "Deinterlace metod" -> "Blend fields"?

Хоть бленд, хоть интерполяция - неважно. Сдвинули на пиксель, и забыли о "мыле"

To: andrewl

Сообщение от andrewl

…хотя эти два исходника везде даунсемплились до PAL DV Wide.

andrewl, а что это за термин - "даунсемплились"?
Может, "даунскалились"? От слов "Down" (вниз) и "Scale" (масштаб)?
Огромная просьба - если пользуете проф.сленг, пожалуйста(!), употребляйте его точно, а то новички начитаются, потом начнут вопросы с его применением задавать - так ничего понятно не будет, что они имеют ввиду!
Но это так, просто просьба, а теперь по существу.

Andrewl, отвечаю по порядку, насколько это возможно…

================================================== ==

Сообщение от andrewl

…Надо-ли в таком случае мне насильно менять в свойствах UFF-эвента порядок полей на LFF?

НЕТ!!

1. ВСЕГДА ПРАВИЛЬНО(!) ИНТЕРПРЕТИРУЙТЕ СВОЕ ВИДЕО!

Именно для этого и написана статья "Определение реального Field First видеофрагмента", написана для того, чтобы Вы могли сами проверить, правильно ли Вегас интерпретировал поля в исходниках (в свойствах эвента).
Что значит «интерпретировал»? Скопирую частично свой пост с другого форума, поможет понять:

Tо, что Вы видите, открыв пропертис футажа – LowerFieldFirst или UpperFieldFirst, это то, как сам Вегас ИНТЕРПРЕТИРУЕТ (а не определяет!!!) данный футаж, говоря Вам, что, мол, я с ним буду работать как с видео с нижним/верхним полем. ВЫ ДОЛЖНЫ ЕГО ПОПРАВИТЬ, ЕСЛИ ОН ОШИБСЯ!
Повторю ещё раз - НИКАКИЕ монтажки НЕ ОПРЕДЕЛЯЮТ, В КАКОМ ВИДЕО КАКОЕ ПЕРВОИДУЩЕЕ - ВЕРХНЕЕ ИЛИ НИЖНЕЕ ПОЛЕ, они интерпретируют так или так.

Отвлечённый пример. Вы пришли домой с девушкой. Можете сказать родителям, что это мол моя невеста. Или - эта продажная женщина, через час уйдёт. Скажем, "интерпретируете" девушку родителям. Вот как скажете, так и будут к ней родители относится и так с ней обращаться. А так как родители очень хотят Вас женить, они ВСЕХ приходящих молодых девушек "интерпретируют" как невест. И если это не так, ВЫ им САМИ говорите - нет, это не невеста, эта коллега по работе, сестра друга и т.д. т.п.

Также и Вегас, если он ошибся, поправьте его, скажете ему, какой это футаж (lower, Upper, Progressive), как скажете, так он с ним работать и будет...
А что бы сказать ему правильно, нужно определить РЕАЛЬНЫЙ FieldFirst, для этого и была написана статья.

Что будет, если Вы неправильно интерпретируете своё видео?!?
Допустим, у Вам реально UFF. Вегас его интерпретировал как LFF, а Вы его не поправили. Проект у вас LFF. Что видит Вегас? Проект LFF, видео на таймлайн LFF, всё в порядке, делать ничего не надо («приведение к единому первоидущему»), всё замечательно и… Вы получаете СТРОБ! Вегас будет думать про видео, что оно LFF, первым из кадра будет вынимать нижнее поле, а реально видео UFF, первый кадрик там в верхнем поле! Вот и будет строб: 21-43-65-87

Поэтому – ещё раз – всегда правильно интерпретируйте футаж. И мой первый пост в этой теме написан с учётом того, что ВСЁ ВИДЕО на таймлайне ПРАВИЛЬНО интерпретировано!

================================================== ==

Сообщение от andrewl

…если я поставлю в свойствах проекта "Deinterlace metod" -> "None"

2. НИКОГДА НЕ ОТКЛЮЧАЙТЕ «ПОЛЕВОЙ КОНТРОЛЬ» (Deinterlace metod=None), ЕСЛИ РАБОТАЕТЕ С ИНТЕРЛЕЙСНЫМ ВИДЕО!!!

Ничего Вам его отключение не даст.
Если полевой контроль включен, в случае присутствия на таймлайн различных (правильно интерпретированных) футажей – с разным разрешением, с разным FieldFirst, то, если Вы сами не будете ручками приводить всё к единому первоидущему, максимум что у Вас будет не так – это вертикальный блюр. Плохо, но не смертельно.
Если же полевой контроль будет отключен – это и строб перепутанных полей, это и гиганская гребёнка при скалировании материала (её можно увидеть постом выше, в посте GS1966). Он Вам всё правильно написал про последствия.
Попробую рассказать и привести опять же цитату из своего поста (кстати, ссылку я давал на него выше, в первом посте):

Сообщение от BIGNik

Всем известна опция <Deinterlace method> в окне <Project Properties>.
Сколько сказано про неё, аж жуть. Кто то советует ставить одно, кто то другое... В справке (и в сплывающей подсказке) ясно написано, что используется для рендера эффектов и дэинтерлейса. И всё! Нормальный человек, не собирающийся дэинтерлейсить и накладывать эффекты в монтируемый фильм, запросто поставит <None>. И крандец его материалу, если он собирается делать скалинг (Scale) материала, например из 1440x1080 в 720x576!
В этом незаметном переключателе кроется глобальная настройка для работы с видео, то есть, как Вега будет понимать и работать с материалом.

Вегас может работать двумя способами:

1. как с интерлейсным материалом, когда вега все преобразования (эффекты, скалинг и т.п.) делает для каждого полукадра в отдельности(!), и складывая их (вынимая из них нужные поля) только для показа на превью монитора и ещё для пару др. вещей. Назвать этот алгоритм можно как угодно – реинтерлейс, «полевой» контроль и т.д.

2. Как с прогрессивным материалом, то есть работать с кадром целиком, не разбивая его на полукадры, а применяя эффекты, масштабирование ко всему кадру.
Что получится, если вега в этом режиме будет скалировать (масштабировать) интерлейсный кадр, кадр, где через строчку разная по времени информация, два разных кадра?!?? Да перемешается вся информация чётных и нечётных строк, винегрет получится и т.д.

Поэтому программерам Веги надо спросить пользователя – как работать с любым(!) материалом в проекте? Обращать внимание, что и как кладут на таймлайн и учитывать это или отключить контроль полей (пукнт1), их всё равно не будет в исходных материалах? Если нет, давай отключим, Вега работать станет быстрей и т.д. и т.п.

И они задали вопрос – Deintrlace metod. Учитывать поля или нет. При эффектах. И масштабировании. МАСШТАБИРОВАНИЕ ОНИ ОТНЕСЛИ К ЭФФЕКТАМ!!!
А вот если вдруг понадобится просто(!) дэинтерлейсить, вот тогда и пригодится ответ пользователя, каким методом, blend или interpolate.

Поэтому, это вопрос на самом деле выглядит так:

Deinterlace method:
--------------------

None (НЕ учитывать поля, НЕ включать полевой контроль, НЕ применять реинтерлейс при масштабировании, эффектах и дэинтерлейсе)

Blend (УЧИТЫВАТЬ полевую структуру материала, применять реинтерлейс при масштабировании, эффектах, если делать дэинтерлейс, то по методу Blend)

Interpolate (УЧИТЫВАТЬ полевую структуру материала, применять реинтерлейс при масштабировании, эффектах, если делать дэинтерлейс, то по методу Interpolate).

================================================== ==

Поэтому, касательно Вашей задачи:

Сообщение от andrewl

…После прочтения данной статьи у меня (ну такой вот я дотошный) возник такой вопрос:
допустим, имеется проект pal dv LFF.
имеются два pal dv исходника, но с разными полями
если я поставлю в свойствах проекта "Deinterlace metod" -> "None", подниму один из эвентов (uff) в pan/crop на один пиксел и в дальнейшем буду контролировать это дело при вращении или реверсе, то, если я правильно понял, строба быть не должно.
Надо-ли в таком случае мне насильно менять в свойствах UFF-эвента порядок полей на LFF?

НЕ надо ни отключать «полевой контроль» ("Deinterlace metod"-> "None"), ни насильно менять в свойствах UFF-эвента порядок полей на LFF. Ничего этого НЕ НАДО.

Ваша задача:

Сообщение от andrewl

имеется проект pal dv LFF.
имеются два pal dv исходника, но с разными полями

Всё до жути элементарно – ответ опять же в статье "Определение реального Field First видеофрагмента"!
Проверяете, правильно ли Вегас интерпретировал поля и потом приводите сами всё к единому первоидущему, так, как написано в статье – или по отдельности каждый футаж с отличным от свойств проекта FieldFirst (через Pan/Crop), или всю дорожку (через Track Motion) с футажами/эвентами, отличным от свойств проекта FieldFirst.
И ВСЁ !
Потом, если Вы применяете поворот или реверс, просто учитывайте это, меняйте FieldFirst на противоположный, делайте так, как описано в первом посте этой темы...

Ну, вот, наверное, пока всё, что касается работы с pal dv.
А то, что Вы в своём винегрете

Сообщение от andrewl

1. PAL DV Widescreen (720x576, 50i, Lower Field First)
2. HDV-1800i (50i, Upper Field First)
3. DVCPRO 50 (720x576, 50i, Upper Field First)
4. DVCPRO HD 720p (1280x720, 50p)

строб видели, так несколько причин могло быть - и не правильная интерпретация, и то, и сё...
Главное - что в таком разношёрстном наборе футажей Вы смогли самостоятельно разобраться и найти причину Вашей ошибки! Значит, разберётесь и поймете всё остальное, и то, что я написал, и ещё многое другое!

P.S.

Сообщение от andrewl

..Мой вопрос сводился к тому, что можно-ли этого (блюра) избежать, если отключить контроль и подвинуть эвент на пиксел вверх (или вниз). Естественно, речь идет об одинаковых по размеру кадра исходниках, один из которых имеет UFF. Ну и понятно, что при работе с таким проектом дальнейшие манипуляции с pan/crop недопускаются, как и други эффекты, "двигающие" картинку. Т.е. в идеале - простейший монтаж с fade и cut.

В принципе, ответ есть выше, но ещё раз повторю:
Блюра избежать можно, просто сдвинув на пиксель вверх! НЕ НАДО при этом отключать "полевой контроль"!

Огромное спасибо за столь развернутый и разжеваный ответ. Вот теперь все понятно

Прочитал с большим интересом, спасибо. Позвольте спросить уважаемых знатоков:
1. Актуальна ли информация об интерпретации невесты для Вегаса Про 8с? Неужели он до сих пор не понимает, какой формат видеофайла ему подсунули? Ведь есть же соответствующий софт. Я сам пользуюсь бесплатной и очень удобной прогой Mediainfo, она показывает полную информацию и по видео (в т.ч. тип развертки и порядок чередования), и по аудиопотоку.
2. Ситуация: камера дает 1080i50 Pal, в проекте используются еще и фотки, да еще и футажи SD Pal и NTSC Не пинайте, чем богаты, тем и рады. Разрешение проекта ставлю 1920*1080, не хочется понижать. С помощью опции кодирования Pan&Crop от черных полей в футажах другого разрешения избавился. Строба нет. А как избавится от интерлейсной гребенки? Если смотреть достаточно близко к экрану - очень заметно для движущихся частей кадра. А если используется для фоток переход - сдвиг, вообще жуть... Что делать?

Сообщение от Lpavel

Актуальна ли информация об интерпретации невесты

Интерпретация невесты так же актуальна, как и интерпретация жениха. Причем в любом софте (какой вопрос, такой и ответ).

Если серьезно - что такое флажок поля. Флажок поля - это всего лишь команда для декодера, как обрабатывать видеосигнал, в какой последовательности. Начинать вывод с верхнего поля, или с нижнего. До SP2 не было единства, что же считать первым полем, а что вторым (верхнее или нижнее), и производители софта тулили по своему разумению, кто во что горазд (благо, вариантов то всего два). Но отголоски того хаоса аукаются и сегодня - можно найти файл (или создать самостоятельно, при желании), где медиаинфо покажет верхнее поле первым, а фактически у файла поле нижнее.
Поэтому и нужно проверять инородные файлы в Вегасе - правильно ли прописан в них заголовок, или нет.

Ага, спасибо.
А с гребенкой что делать? Бороться? Смириться? Использовать софтовый плейер с функцией деинтерлейса?

Большое спасибо за подробный ответ.
С другой стороны, сейчас стирается грань между тв и мониторами.
У меня тв Full HD 1080р, связан с компом по HDMI, в панели управления NVidia можно выставить формат выводного сигнала, разрешение и частоту развертки. Я экспериментировал с типом выходного сигнала, но пока не получилось добиться хорошего качества. ТВ был специально куплен с прицелом на просмотр высококачественного видео. Как-то для тестирования смотрел на нем фильм в формате 1080р, всё было идеально, на лице персонажа каждая морщинка была видна...

Lpavel, а добавленный скрин - это что ?
В полях слишком большая разница в движении

Это переход от одной фотке к другой в интерлейсном режиме. Для интереса перекодировал этот кусок Канопусом в прогрессивную развертку, стало всё нормально. Но этот метод нельзя назвать универсальным: попробовал перекодировать кусок видео от камеры из 1080i тоже в прогрессивную развертку, гребёнка пропала, но стал мерцать цвет

Сообщение от Lpavel

Это переход от одной фотке к другой в интерлейсном режиме.

Длительность перехода увеличить - зачем так быстро? Или вообще, встык
С такой скоростью вряд-ли что-то справится

Это был стандартный переход длительностью 1с... Да, придется использовать эффект типа размывания, растворения, там в глаза не бросается. Просто это самый яркий эффект грЁбанки