Перейти к содержимому


!!! Только у нас на форуме !!!
Спектакли от дяди Пчёлки

для просмотра необходима регистрация
Фотография

Поля, интерлейс, прогрессивная и чересстрочная развертка.


  • Please log in to reply
130 ответов в этой теме

#1 ALES74

ALES74
  • Участник
  • 841 Сообщений:

Отправлено 01 авг 2006 - 22:20

Поля, интерлейс, прогрессивная и чересстрочная развертка.

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

Прикрепленный файл  Interlace_01.gif   14,33К   1361 Количество загрузок:

Рис.1. Искажения границ

Не пугайтесь, с Вашей камерой, кабелями, картой и программой захвата, а так же софтовым плеером все в порядке. Так и должно быть! Вы столкнулись с интерлейсом (Interlace) - следствие чересстрочной развертки.

Так в чем же собственно дело? Рассмотрим принцип формирования обыкновенного телевизионного кадра. ТВ кадр состоит из 625 строк, 576 из которых являются видимыми (несущими информацию об изображении), а 49 – служебными. Строки выводятся (отображаются) на экран не последовательно (1-я, 2-я, 3-я и т.д.), как естественно было бы предположить, а через одну – в начале выводятся нечетные строки (1-я, 3-я, 5-я и т.д.), а затем четные (2-я, 4-я, 6-я и т.д.), или наоборот, что называется чересстрочной разверткой. Т.о. кадр делится на два полукадра состоящих из нечетных и четных строк. Каждый такой полукадр называется полем. Причем, поле, состоящее из нечетных строк, называется нечетным или верхним, а поле, состоящее из четных строк – четным или нижним (Рис.2). Очередность вывода полей может быть разной, для DV формата (следовательно, для всех miniDV видеокамер) первым полем является нижнее/четное.

Прикрепленный файл  Interlace_02.gif   7,52К   662 Количество загрузок:

Рис.2. Поля ТВ-кадра.


Т.е. телевизионное изображение обновляется не 25 раз в секунду (частота кадров), а 50 раз в секунду (здесь и далее имеется ввиду формат PAL).

Теперь мы подошли к самому главному. Видеокамеры, в отличие от кинокамер, снимающих на кинопленку, со скоростью 24 кадра в секунду, снимают 50 полей (полукадров) в секунду и кадр формируется путем сложения обоих полей. Т.е. каждую 1/50 секунды с матрицы видеокамеры считываются и записываются по переменно четные и нечетные строки. (Ради справедливости стоит заметить, что на сегодняшний день появились сравнительно недорогие видеокамеры, реализующие функцию прогрессивной съемки – фиксирующие полный кадр каждые 1/25 секунды.)

Но, рассмотрим процесс видеосъемки подробнее на примере уже знакомого колобка. Пусть колобок катится слева направо, видеокамера неподвижна. В первый момент времени видеокамера фиксирует на матрице изображение и считывает четные строки, формируя нижнее поле. Через 1/50 секунды видеокамера считывает нечетные строки, формируя верхнее поле. Сложим два поля – получим кадр (Рис.3).

Прикрепленный файл  Interlace_03.gif   8,83К   639 Количество загрузок:

Рис.3. Видеосъемка.


Вот оно! За 1/50 секунды колобок успел переместиться относительно положения зафиксированного в нижнем поле и верхнем поле оказался правее! Ну, как? Похожа картинка на то, что Вы видите на своем видео?

Для подтверждения теории рассмотрим фрагмент кадра реального видео - "Рука в прощальном жесте" (Рис.4).


Прикрепленный файл  Interlace_04.gif   22,41К   332 Количество загрузок:

Рис.4. Разложение по полям.


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

Итак, видеокамеры используют чересстрочный режим съемки – по полям, телевизоры выводят изображение по полям, и никаких искажений границ мы не замечаем. Вдобавок, получаем выигрыш в плавности движений – фиксация положения движущегося объекта каждые 1/50 секунды против 1/25 или в киносъемке – 1/24. И если Вы готовите свое видео для будущего просмотра на телевизоре (SVCD, DVD или видеокассета), вам надо беспокоиться лишь о правильном чередовании полей. Но в мониторах компьютеров используется прогрессивная (построчная) развертка - кадр отображается полностью, т.е. поля складываются и выводятся одновременно за один проход, вот тут мы и наблюдаем описанные выше искажения. Что же делать, если мы хотим создать фильм, предназначенный для просмотра на ПК? Выход есть! Но это отдельная тема, которую мы рассмотрим в следующий раз. (Ищите тему "Деинтерлейс".)



Деинтерлейс.

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

В прошлой теме мы выяснили, что причиной интерлейса является смещение изображения объекта в кадре за промежуток времени между его фиксацией в нижнем и верхнем поле. И время это, для видеокамер, равно 1/50 секунды.

Как же можно избавиться от этой противной "гребенки"?

У нас на выбор целых 4 методики устранения интерлейса (здесь мы рассматриваем только общедоступные программные методы, без уменьшения физического разрешения по вертикали):
1. Отбрасывание информации одного из полей и копирование в него информации из другого поля, т.е. дублирование одного из полей;
2. Смешивание цветов из обоих полей;
3. Отбрасывание информации одного из полей и интерполяция пикселей по окружающим его пикселям другого поля;
4. Компенсация движения между полями, т.е. расчет векторов смещения объектов в одном поле относительно другого и возврат их в нужное положение.

Рассмотрим уже знакомый фрагмент кадра:

Прикрепленный файл  Interlace_01.gif   14,33К   1361 Количество загрузок:

Рис.1.


Ниже приведена его часть, увеличенная в два раза, после обработки фильтрами деинтерлейса по каждой из методик (Рис.2).

Прикрепленный файл  DeInterlace_01.gif   51,46К   895 Количество загрузок:

Рис.2. Результаты работы фильтров деинтерлеса.



Рассмотрим подробнее каждую из методик:
  • Дублирование – самый простой и быстрый метод, однако на изображении явно заметны "ступеньки". Фактически данный метод вдвое уменьшает вертикальное разрешение изображения, отбрасывая одно поле - теряем ровно половину информации.
  • Смешение цветов – так же достаточно простой и быстрый метод, с одной стороны потери информации не происходит, но смазывает детали и образует отражения движущихся объектов (как на следующем фрагменте).

Прикрепленный файл  DeInterlace_01a.gif   4,5К   199 Количество загрузок:

  • Интерполяция – заметно проигрывает в производительности первым двум методам, однако, на первый взгляд, дает более симпатичный результат. Но, не будем забывать, что информация одного из полей интерполируется по информации из другого поля, детали, зафиксированные камерой в одном из полей потеряны. Фактически этот метод, как и первый, вдвое снижает эффективное разрешение изображения.
  • Компенсация движения – теоретически самый эффективный метод, поскольку должен предотвратить потерю информации из второго поля и сохранить лучшую детализацию по сравнению со всеми предыдущими методами. Хотя на практике этого практически не заметно, видимо, весьма сложно достаточно точно определить те самые вектора смещения изображения. Рассмотрим искусственно созданный пример с высокой вертикальной детализацией (Рис.3).

Прикрепленный файл  DeInterlace_02.gif   59,72К   713 Количество загрузок:

Рис.3.

Попытка фильтра, основанного на компенсации движения, сохранить детализацию (4) сильно похожа на шум и выглядит даже хуже чем результат интерполяции (3). При наличии в движении еще и вращательного момента, ситуация только усугубляется – появляются ложные детали. Вторая проблема – поля далеко не всегда дополняют друг друга. Такой простой пример – прыгающий матрос в тельняшке. Пусть в первый момент времени в первом поле были зафиксированы темные полосы тельняшки, какова вероятность того, что через 1/50 секунды во втором поле окажутся белые полосы? Думаю – 50/50. Т.е. запросто может оказаться, что и в первом и во втором поле будут зафиксированы темные полосы, и какой суперфильтр не применяй, а матрос будет не в полосатом тельнике, а в темной майке. Но все-таки, при малом движении существующие фильтры, применяющие компенсацию, показывают лучший результат.

Итак, мы пришли к тому, что практически любой способ деинтерлейса ведет к понижению эффективного вертикального разрешения вдвое. Не отчаивайтесь, не все так плохо. Здесь на сцену выступают так называемые area-based фильтры. До сих пор мы говорили о движущихся в пределах кадра изображениях, что же происходит с неподвижной частью кадра? Отличительной особенностью area-based фильтров является то, что они пытаются определить и подвергнуть обработке только движущиеся части изображения, в то время как неподвижная часть изображения остается не тронутой, т.е. сохраняется вся информация из обоих полей. А движущиеся изображения объектов и так немного смазаны. Вас это радует? Идем дальше…

Вернемся к рис.2, вы обратили внимание, что в результатах 2, 3 и 4 на некоторых участках изображения присутствуют горизонтальные полосы? А это как раз недостаток area-based фильтров. Дело в том, что фильтру необходимо по какому-то признаку определять является ли конкретный пиксель частью движущегося изображения и подлежит обработке или нет. А определяется это на основе сравнения соседних пикселей в разных полях, либо сравнением одного пикселя в разных кадрах, либо применяются оба метода вместе. Сравнение может проходить по цвету или по яркости. Т.о. должно существовать некоторое пороговое значение, если разница меньше – пиксель признается принадлежащим статичной части изображения и не подлежит обработке, если разница больше – пиксель принадлежит движущейся части изображения и подлежит обработке. Некоторые фильтры позволяют настраивать все эти параметры: производить сравнение в полях или кадрах, или и обоими способами, сравнивать по цветовой или яркостной составляющей, задавать пороговое значение. Чем больше величина порогового значения, тем меньше пикселей подвергаются обработке, чем меньше значение, тем больше размывается статичных элементов (Рис.4).

Прикрепленный файл  DeInterlace_03.gif   50,27К   601 Количество загрузок:

Рис.4.


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

И на последок выскажу еще несколько соображений.
Обращали ли вы внимание на то, что miniDV видеокамеры, имеющие (по проводимым тестам) горизонтальное разрешение чуть ли не более 600ТВЛ (что само по себе сомнительно, поскольку теоретический предел PAL кадра 720х576 – 540ТВЛ), в то же время, в вертикальном разрешении имеют показатели не многим более 400? Возможно, производители видеокамер намеренно занижают показатель вертикального разрешения, чтобы в изображении снизить искажения (изломы) тонких наклонных линий.

И второе, коли речь идет о деинтерлейсе, вероятно, что видео предназначается для просмотра на ПК, тогда есть смысл сразу привести его к нормальному соотношению сторон, исправив тем самым некоторую вытянутость изображения по вертикали. Ближайшее "правильное" разрешение (с учетом дальнейшего сжатия в MPEG) составляет 720х544, можно уменьшить и до 640х480, или, если фильм захвачен с VHS видеомагнитофона, и мы хотим уместить 1.5 часа на 1 CD – уменьшить до 512х384. Изменяя размер кадра, мы интерполируем все пиксели изображения, частично скрывая артефакты в виде горизонтальных полос.

Я нарочно не приводил здесь сравнения фильтров различных производителей, поскольку многое зависит от самого видео, да и у пользователей нет единого мнения на их счет, тем более ПО постоянно обновляется. Многие фильтры являются встроенными в пакеты обработки видео (Adobe Premier, Canopus ProCoder), в кодеки (DivX), некоторые поставляются отдельными подключаемыми модулями (QS Deinterlace, Alparysoft Deinterlace). Я ставил себе задачу помочь начинающим разобраться в применяемых методиках и выбрать наилучший для себя вариант.

p.s.: если у вас ничего путного не получается с деинтерлейсом вашего видео - остается эффект отражения, или, хуже того, в видео наблюдается жуткий строб, смотрите следующую тему "Проблемы чередования полей".



Проблемы чередования полей

Здесь я хотел рассмотреть проблемы, причиной которых становится чередование полей в видео. Это и не настоящая чересстрочность и бич многих монтажистов – строб.

Кто-то, прочтя первые две темы, может спросить: "А зачем это нужно? Сколько лет монтирую, и никогда не сталкивался ни с какими проблемами". И в самом деле, если вы сбрасываете на компьютер материал с цифровой камеры, монтируете и выводите готовый фильм на DVD (VSD, SVCD), который потом просматриваете на телевизоре, подключенном к аппаратному DVD-плееру, то вероятнее всего вы не столкнетесь с описываемыми здесь проблемами. Однако если вы готовите фильм к показу на компьютере или занимаетесь оцифровкой аналогового сигнала, вы просто обязаны разбираться особенностях прогрессивной и чересстрочной развертки.

Первая проблема это тривиальная ошибка (которую вы никогда не сделаете, зная особенности чересстрочной развертки) – изменение размеров кадра без предварительного диентерлейса, что приводит к тому, что я назвал не настоящей чересстрочностью. На рисунке 1 показан результат подобного преобразования.

Прикрепленный файл  Interlace_05.gif   58,52К   360 Количество загрузок:

Рис 1. Не настоящая чересстрочность


Фрагмент 1 – исходный кадр, фрагмент 2 – получен изменением размеров исходного кадра, на нем так же видна "гребенка", но она уже ре раскладывается по полям, информация из разных полей была смешана при изменении размеров. Если такое видео теперь подать на телевизор "гребенка" будет заметна и на нем. Применение фильтра деинтерлейса (фрагмент 3) так же не даст хороших результатов по той же причине смешивания полей. При более быстром движении в кадре картинка будет еще страшнее. Для сравнения в четвертом фрагменте приведен пример правильной последовательности действий: деинтерлейс а затем изменение размеров.

Справедливости ради следует заметить, что существуют фильтры, выполняющие масштабирование не всего кадра целиком, а по полям, т.е. масштабируется каждое поле в отдельности. Так в VirtualDub фильтр Resize умеет делать масштабирование по полям, для чего нужно в настройках фильтра выбрать опцию «Interlaced». Так же, работая с чересстрочным видео, поступают и монтажные программы при манипуляциях приводящих к изменению размеров видео: картинка в картинке, различные 3D переходы и т.п. В других случаях необходимость изменения размеров чересстрочного видео вообще представляется мне весьма сомнительной т.к. при показе на телевизоре в системе PAL изображение должно быть разложено на 576 видимых строк, по 288 в каждом поле. В других случаях видео следует в начале преобразовать в прогрессивное, т.е. выполнить деинтерлейс.

Если вышеописанная проблема встречается достаточно редко, то следующая, судя по появлению вопросов на различных форумах, встречается достаточно часто. И имя ее - Строб – дерганое, прерывистое движение. Вообще строб может возникать из-за пропущенных при захвате кадров и из-за недостаточной производительности компьютера или конфликтов устройств и т.п. Но есть еще одна причина, сразу не заметная ни при монтаже, ни при просмотре на компьютере, но проявляющая себя во всей красе, когда мы, переполненные чувством гордости, устраиваем первый просмотр готового, записанного на DVD, фильма, усадив перед телевизором все семейство, а еще хуже – заказчика.

Итак, захват аналогового сигнала. Вспомним, что видео представляет собой последовательность полукадров – полей. На рисунке 2 представлено разложенное по полям видео катящегося колобка. В каждом кадре присутствуют два поля "Н" – нижнее и "В" – верхнее. На рисунке 2а можно видеть последовательный показ всех 12 полей.

Прикрепленный файл  Colob_f01.gif   7,53К   484 Количество загрузок:

Рис 2.

Прикрепленный файл  Colob_01.gif   14,88К   128 Количество загрузок:

Рис 2а.


Так вот, дело в том, что при захвате, показанный выше порядок полей может поменяться. Две причины могут повлиять на это: во первых – нет гарантии, что захват начнется с нижнего поля, может и с верхнего; а во вторых – одни карты располагают в памяти сначала нижнее поле, а потом верхнее, в то время как другие наоборот. И тогда, из оригинальной последовательности (Н1В1-Н2В2-Н3В3…) можем получить 4 варианта:

1. Н1В1-Н2В2-Н3В3… - без изменений
2. В1Н1-В2Н2-В3Н3…
3. В1Н2-В2Н3-В3Н4…
4. Н2В1-Н3В2-Н4В3…

А после, при просмотре, например 2-го варианта, увидим следующую картину (рис. 3, 3а).


Прикрепленный файл  Colob_f02.gif   7,53К   197 Количество загрузок:

Рис 3.

Прикрепленный файл  Colob_02.gif   14,88К   96 Количество загрузок:

Рис 3а.

Здорово? А вы заметили, что кадры по прежнему состоят из тех же полей, что и в оригинальном видео? Следовательно, при монтаже и просмотре на компьютере, где используется прогрессивная развертка, и кадр отображается целиком за один проход, никакой разницы мы не увидим. "Гребенка на месте, ну и ладно, все равно на телевизоре ее не будет!" Ее и в самом деле на телевизоре не будет, но все движение будет жутко "стробить" (рис. 3а).

Что делать? Для начала необходимо определить каков же порядок полей в исходном видео. Самый простой и надежный способ записать фрагмент на DVD-RW и прогнать на DVD-плеере, если строб есть – непорядок с полями. Если есть карта захвата аналогового сигнала, которые, как правило, умеют и выводить видео, раскладывая его по полям, тогда можно вывести на телевизор через нее (однако, надо точно знать, как работает с полями ваша карта). Я лично использую фильтр Deshaker для VirtualDub. Сам фильтр предназначен для стабилизации изображения, но он при работе раскладывает кадр на два поля и показывает вектора смещения блоков, направления векторов в разных полях должны совпадать, если вектора направлены в разные стороны, значит, выбрана не правильная очередность полей.

Вторым этапом следует решить: исправлять очередность полей или оставить как есть. В самом деле, многие монтажные программы позволяют явно указать очередность полей, да и DVD-плееру все равно – они умеют выводить как нижнее, так и верхнее поле первым. В самом деле, MPEG2 содержит два значения с информацией о полях: первое значение указывает реальную очередность полей, а второе – в каком порядке плееру их выводить. Т.е. мы можем управлять очередностью вывода полей. Я все же предпочитаю приводить все видео «правильному» виду – нижнее поле первое. Это позволяет в дальнейшем не беспокоиться, что в один проект попадут фрагменты видео с разным чередованием полей, а так же не ломать голову о том какие поля выставлять при подготовке видео к записи на DVD. Studio9 от Pinnacle вообще не позволяет указать очередность полей. И что же, если у вас в проекте используется видео в котором верхнее поле – первое, то при использовании переходов, Studio9 просчитает их, сделав первым нижнее поле. Т.о. строб вам обеспечен или на всем видео или на переходах.

Как изменить очередность полей? Я использую для этих целей все тот же VirtualDub и его встроенный фильтр – «field swap». Если же поля не просто поменяны местами (как в вариантах 1 и 2), а еще присутствует смещение полей (варианты 3 и 4), можно воспользоваться фильтром «QS Deinterlace». Этот фильтр позволяет, отключив выполнение деинтерлейса, воспользоваться его расширенными возможностями по работе с полями (менять поля до сдвига, сдвигать поля, менять поля после сдвига).

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

Сообщение отредактировано ALES74: 26 июн 2007 - 11:46

  • 2

#2 Relogan

Relogan
  • Участник
  • 124 Сообщений:

Отправлено 13 авг 2006 - 14:44

Studio9 от Pinnacle вообще не позволяет указать очередность полей. И что же, если у вас в проекте используется видео в котором верхнее поле – первое, то при использовании переходов, Studio9 просчитает их, сделав первым нижнее поле. Т.о. строб вам обеспечен или на всем видео или на переходах.

Позвольте Вам возразить, если мы производим импорт материала в Studio с первым верхним полем, то при выводе этого материала Studio просто перевернет поля и первое верхнее первоначального видео станет первым нижнем в просчитанном видео. Поэтому строба не будет, если при кодировании в MPEG 2 в параметрах источника будет стоять превое поле-нижнее.
  • 0

#3 hukutocuk

hukutocuk
  • Участниk
  • 3 Сообщений:

Отправлено 03 мар 2007 - 03:48

господа, а не ответите на такой вопрос:
имею камеру мини диви, при захвате видео на компутер в *.avi (используется приложение для захвата сони вегас 7) и при просмотре этого файла в любом компутерном плеере , во первых плавно движется картинка во вторых если на динамичном моменте нажать на паузу будет чёткий стоп кадр, как фото, НИКАКОЙ ГРЕБЁНКИ . Далее при кодировке в MPEG2 (используется тот же сони вегас) появляется эта гребёнка, и картинка как будто становится медленнее чтоли, теряется плавность.
а в вашей статье сказано, что черезстрочная развертка уже в камере заложена, если можно так выразиться, так почему же её (гребёнки) нету в файле *.avi ???
Спасибо.
и ещё возможно вопрос не по теме, но влияет ли как нибудь на черезстрочность i-frame и b-frame и какие значения для них лучьше выставлять?
  • 0

#4 black

black
  • Участник
  • 1 057 Сообщений:

Отправлено 03 мар 2007 - 04:34

а в вашей статье сказано, что черезстрочная развертка уже в камере заложена, если можно так выразиться, так почему же её (гребёнки) нету в файле *.avi ???


Каким плеером смотришь?

Большенство плееров по умолчанию деинтерлейзят картинку и гребенки ты не увидешь.

Воспользуйся верчал дабом или экспортируй одн кадр из монтажки посмотри его в графическом редакторе... вот тут все и увидишь.
  • 0

#5 Serg Falkon

Serg Falkon
  • Модераторы
  • 1 533 Сообщений:

Отправлено 03 мар 2007 - 07:35

появляется эта гребёнка, и картинка как будто становится медленнее чтоли, теряется плавность
Угу. Когда DV с камеры смотрел - как отмечено, деинтерлейс плеером делался . Причем, деинтерлейс ВОВ - преобразование в 50 к/с. Отсюда и отсутствие гребенки и бОльшая плавность. Во втором случае - оба поля кадра одновременно выводились - отсюда и гребенка и потеря плавности, т.к. 25 к/с.
Правда, можно и для MPEG2 деинтерлейс аналогичный при просмотре делать. Зависит от плеера.

но влияет ли как нибудь на черезстрочность i-frame и b-frame и какие значения для них лучьше выставлять
Не понял - что на что (не) влияет и какие значения имеются в виду?
  • 0

#6 Dick

Dick
  • Участник
  • 10 055 Сообщений:

Отправлено 03 мар 2007 - 08:59

А поблагодарить аффтара темы ( и полезной статьи) забыли?!

Спасиб, ALES74 !!!

Многим будет оч. полезно.
  • 0

#7 hukutocuk

hukutocuk
  • Участниk
  • 3 Сообщений:

Отправлено 03 мар 2007 - 13:37

но влияет ли как нибудь на черезстрочность i-frame и b-frame и какие значения для них лучьше выставлять
Не понял - что на что (не) влияет и какие значения имеются в виду?


просто в вегасе есть настройки для mpeg2 и там можновыставить значения i-frame и b-frame, только вот никак не пойму для чего это и что от этого лучьше, а что хуже.

всем спасибо за ответы, впринципе я все понял. единственное что не понял, почему в таком случае файл захваченый с диви камеры (*.avi) c частотой кадров 25к/с и при просмотре на монтажных столах разных програм тоже написано 25к/с без гребёнки, а mpeg2 всё в гребёнке, но видимо это уже не так важно, так как от неё никуда не дется, всёравно пишу для тв.

ещё раз всем спасибо.

:009:
  • 0

#8 swersh

swersh
  • Участник
  • 295 Сообщений:

Отправлено 03 мар 2007 - 22:48

Черезстрочное видео 25 кадров в секунду содержит 50 "полей=полукадров" в секунду. Что непонятно?
А гребенка- это проблема плохого компьютерного проигрывателя, который не умеет грамотно преобразовать черезстрочное видео в прогрессивную развертку коипьютерного монитора. Хорошие проигрыватели (Power DVD например) делают это великолепно: они, как уже было сказано выше, преобразуют каждый полукадр в полный кадр и, таким образом, выводят видео уже не 25 кадров в секунду (50 полукадров в секунду), а 50 полных кадров в секунду.
  • 0

#9 Serg Falkon

Serg Falkon
  • Модераторы
  • 1 533 Сообщений:

Отправлено 03 мар 2007 - 23:15

можновыставить значения i-frame и b-frame
Это, насколько я понимаю (сам в Вегасе не работал, но принципы едины), задается макс. интервал между I-кадрами (размер GOP'а) и число подряд идущих В-кадров . На "гребенку" не влияет :)
А насчет наличия/отсутствия гребенки при просмотре DV-avi и MPEG2 - swersh уже написал. Используйте при просмотре MPEG2 (DVD) на компе плеер (PowerDVD, WinDVD, Elecard, Media Player Classic, например), что умеет деинтерлейс типа ВОВ (преобразование 50 полей-полукадров в 50 полноразмерных кадров) - и будет все ОК.
  • 0

#10 hukutocuk

hukutocuk
  • Участниk
  • 3 Сообщений:

Отправлено 03 мар 2007 - 23:19

:) ок, всем спасибо!
  • 0

#11 Андрей К.

Андрей К.
  • Участник
  • 3 289 Сообщений:

Отправлено 04 мар 2007 - 00:25

Спасибо аФФтору :) , многое знал, но так разжевать тоже нужно умение.
  • 0

#12 ALES74

ALES74
  • Участник
  • 841 Сообщений:

Отправлено 04 мар 2007 - 15:29

Привет!
Вопервых спасибо всем за лесные отзывы, это всегда приятно :)

Теперь по теме:

почему в таком случае файл захваченый с диви камеры (*.avi) c частотой кадров 25к/с и при просмотре на монтажных столах разных програм тоже написано 25к/с без гребёнки

Если я правильно понял, автор вопроса работает в Vegas. В Vegas в окне просмотра имеется возможность отображения как полноразмерного кадра, так и половины. По умолчанию, чтобы не занимать большую часть экрана отображается половинный размер кадра. Подозреваю что в этом случае информация об изображении берется из одного поля, соотвественно никакого интерлейса нет. Если выбрать отображение полного кадра в наилучшем качестве (и, как уже писалось выше, сохранить и рассмотреть кадр), "гребенка" будет присутствовать.
Удачи!

И еще один момент: Когда я только разбирался с чересстрочным видео и писал эту статейку, то тоже пытался найти способы определения порядка полей, которые и предложил. Стоит признать их не самыми удачными. В одной из тем по обсуждению полей один из форумчан (кажется Игорь Полежаев, извините если ошибаюсь) предложил простой способ определения порядка полей прямо в монтажке, которым я сейчас и пользуюсь. Для этого надо просто сделать замедление видео ровно в два раза (установить скорость равную 0,5). Если порядок полей источника выбран не верно замедленное видео будет стробить.
Все гениальное просто. Расчет сделан на то, что при замедлении в два раза каждый кадр замедленного видео получается из одного поля. Если прядок полей нарушен, т.е. нарушены фазы движения, та же ерунда будет теперь присутствовать в замедленном видео! И не надо ничего рендерить и пользоваться другими программами и фильтрами - тут же в монтажке в окне просмотра оцениваем правильность установки порядка полей.
Огромное спасибо автору идеи!

Сообщение отредактировано ALES74: 04 мар 2007 - 15:29

  • 0

#13 Андрей К.

Андрей К.
  • Участник
  • 3 289 Сообщений:

Отправлено 07 мар 2007 - 01:50

А кто объяснит про спортивные режимы съёмки ? Скажем я на камере ставлю выдержку 1/50 или 1/120 или там ещё многопредустановок. Вот в режиме 1/120 время экспозиции в 2 с небольшим раза меньше но 25 кадров в секунду никто не отменял. Получается что камера будет снимать через паузу, так?
Как фотографу, про диафрагму и выдержку мне известно и понятно всё, а как это лепится к камере ????
  • 0

#14 ALES74

ALES74
  • Участник
  • 841 Сообщений:

Отправлено 08 мар 2007 - 13:37

Привет, Андрей! А что тебя смущает в том, что камера снимает "через паузу"? Если чувствительность позволяет, такой режим дает возможность получить в пределах одного поля менее смазанные движущиеся объекты.
  • 0

#15 Климов

Климов
  • Участник
  • 8 Сообщений:

Отправлено 17 май 2007 - 17:08

А какой прогой можно изменить индикатор очерёдности полей в файле AVI, не меняя очерёдность этих полей физически?
  • 0

#16 Eugene7

Eugene7
  • Участник
  • 467 Сообщений:

Отправлено 18 май 2007 - 18:44

для AVI - никак! каждая программа при импорте интерпретирует порядок полей
чтобы определить правильно ли вы интерпретировали поля - есть один верный способ:
1. выбираем фрагмент видео, где есть характерное движение
2. замедляем в 2 раза
3. если движение дерганное (то вперед, то назад) - то нужно поменять порядок полей
если все плавно - значит все ок

Что касается уже готового Mpeg-2 файла, то в нем явно указан порядок полей
его можно исправить без перекодирование видео с помощью утилиты ReStream
  • 0

#17 пётр

пётр
  • Участник
  • 2 088 Сообщений:

Отправлено 20 май 2007 - 08:43

Спасибо! очь позновательно!!!
Но вот такой ламерский вопросик....ежели камера позволяет снимать в прогрессиве...ЭТО хорошо или нет??? ведь как правило...процентов 94% из 100 конечный результат будет DVD...правда многие плеера имеют ПрогрессивСкан....НО опять же ...прогрессив кажут только ЖК и плазма-панели...Вот и вопрос...что и как снимать , что и на чём смотреть?....Опятьже, если я делаю монтаж с материалом в прогрессиве...добавляю какое-либо видео в интерлейссе....что и как правельно будет делать....????
  • 0

#18 Климов

Климов
  • Участник
  • 8 Сообщений:

Отправлено 21 май 2007 - 13:48

для AVI - никак! каждая программа при импорте интерпретирует порядок полей..
...Что касается уже готового Mpeg-2 файла, то в нем явно указан порядок полей
его можно исправить без перекодирование видео с помощью утилиты ReStream


Кажется стало прояснятся.
Т.е.:
1. Если я кодирую Канопусом, и он мне показывает, что захваченные с DV камеры файлы имеют разный порядок полей, то это баг Канопуса.
2. Если уже в процессе кодирования в MPEG-2 прошляпил, то править РеСтримом.

Всплывает вопрос: Если в AVI файле не указывается полрядок полей, то он и не может сторобить, ведь DVD проигрыватель должен сам распознвать какое поле пускать первым? Тогда непонятно для чего меняют порядок полей в Virtal Dub-ом в файлах AVI?
  • 0

#19 Зос

Зос
  • Модераторы
  • 4 180 Сообщений:

Отправлено 21 май 2007 - 14:07

1. Нет это баг кривых рук.
порядок полей в Virtal Dub-ом в файлах AVI - Допустим, Ты захватывал в Студии (тип2), монтируешь в АР (тип1 по умолчанию) . Или захват в Улиде (тип 1) , монтаж в Студии (тип2). Чтобы получилось нормально - надо привести к общему знаменателю.
  • 0

#20 Климов

Климов
  • Участник
  • 8 Сообщений:

Отправлено 21 май 2007 - 17:56

1. Нет это баг кривых рук.
порядок полей в Virtal Dub-ом в файлах AVI - Допустим, Ты захватывал в Студии (тип2), монтируешь в АР (тип1 по умолчанию) . Или захват в Улиде (тип 1) , монтаж в Студии (тип2). Чтобы получилось нормально - надо привести к общему знаменателю.


Задача была, ничего не редактируя перегнать чужую кассету с DV на DVD, дабы народ посмотрел турпоход. Захватывал Сценалайзером по сценам (уж три года опыта. Свои записи я потом в АП редактирую и храню в DV и смотрю на компе.) Далее Канопусом все сцены пакетно перегнал, ничего не проверяя в DVD-PAL. А на DVD-LAB (опыт тоже есть. С HD рекордера играюсь).

Глянул: две сцены стробят. Оказалось, что при открытии этих сцен в Канопусе, он определяет их как с вехним полем. Я, конечно, "силком" Канопусу указал, что сцены с нижнем полем и строб ушёл. И возник вопрос: Откуда Канопус берёт информацию, что поле верхнее. Как мне сказали, что в AVI файле нет информации. Если криво захватил, то почему 40 сцен захватились нормально, а две нет.

Думал косина в камере. Я на всякий слчай второй раз всю ленту захватил на другой DV камере. Результат - тот же. Со своей ленты проверил 5% тоже Канопус распознаёт как с верхним полем. Черт меня раздери. Если все знают, что DV формат с нижнем полем, то какого чёрта Канопус часть сцен считает нижними?

Рад бы свои руки выпрямить, да никак не могу понять где-ж править!
  • 0

#21 Зос

Зос
  • Модераторы
  • 4 180 Сообщений:

Отправлено 21 май 2007 - 18:08

Я думаю, что в Сценалайзере что-то где-то сбилось.
Сейчас точно сказать не могу (и завтра тоже), но наверное в Канопусе установки по умолчанию. Попробуй в Сценалайзере захватить два куска с разными настройками полей (он это позволяет) и подсунуть их Канопусу без захода в АР. Потом расскажешь :)
  • 0

#22 Serg Falkon

Serg Falkon
  • Модераторы
  • 1 533 Сообщений:

Отправлено 21 май 2007 - 19:01

Откуда Канопус берёт информацию, что поле верхнее
Ниоткуда. В принципе, для DV-avi он обычно всегда нижнее первым ставит. Даже если они были программно зажаты с реально верхним первым.
Если все файлы были с одинаковыми параметрами, а он на 2-х другой порядок указал - IMHO, глючок какой-то.
  • 0

#23 black

black
  • Участник
  • 1 057 Сообщений:

Отправлено 21 май 2007 - 19:04

вот я сталкивался с тем, что тупо захваченные премьером файлы, он(ProCoder) в 50% случаев интерпретирует как с верхним полем, а в остальных случаях правильно.
просчитанные же премьером или АЕ файлы всегда интерпретирует правильно.
  • 0

#24 Климов

Климов
  • Участник
  • 8 Сообщений:

Отправлено 21 май 2007 - 19:08

Сценалайзер не позволяет захватить два куска с разными настройками полей! Единственное что там имеется, так тап файлов для захвата. Например: Canopus compatible DV-files - применяется при захвате для последующей работы с платами видеомонтажа от Canopus. Но все эти установки всего лишь генерируют разные композиции видео и звуковых файлов для разных редакторов, не меняя по своей сути структуру самих файлов.

Всё что нашёл в руководстве по ScenalyzerLive 4.0:

ScLive recognizes the following attributes for each clip:
...
Interlaced - Indicates if the video is interlaced or progressive-scan (=movie-mode)
...


Т.е. он только может определить черезстрочная развёрта или прогрессивная и вывести это на индикатор около клипа. Это я проверил. Включил индикатор и он сказал, что всё сцены Interlaced

Вот что мне сказал эксперт на другом форуме:

DVD-плеер ничего не определяет. Он просто выводит у avi-файла какое-либо поле первым и все. Так например, мой BBK964 умеет выводить divX. Но он всегда выводит первым нижне поле. Соответственно, если дать ему divX с первым верхним полем , то будет строб, т.к. никакого флага, дающего плееру подсказку, нет и плеер тупо будеет выводить нижнее поле первым. Существуют, говорят, и совсем старые DVD-плеера, которые в mpeg2 всегда первым выводят верхнее поле, не обращая внимания на флаг.
Иными словами, любой плеер всегда отличит верхнее поле от нижнего, но он не может проанализировать кадр и отличить в каком поле зафиксировано событие произошедшее раньше по времени. В mpeg2 существует флаг, который объясняет плееру, какое поле надо выводить первым, а вот в avi такого флага нет.
Некоторые проги, например TMPGEnc, могут проанализировать видеоряд в avi-файле и самостоятельно определить, какое там поле идет первым, но они иногда ошибаются, поэтому лучше это сделать самому визуально, хотя бы с помощью приведенного мной ранее ависинтовского скрипта. Но если вы собираетесь кодировать свой avi в mpeg2, то можно опеределить все без скриптов и не забивать себе голову. Поскольку кодируем в прокодере, то достаточно изготовить несколько (точне 4 штуки) mpeg2-файлов с различными комбинациями Source и Target, вывести их потом с помощью DVD-плеера на телевизор и визуально определить правильные комбинации.


И ещё:

Любая прога или плеер рассматривая что avi, что mpeg2 прекрасно определят, где верхнее поле, а где нижнее. Но в avi-файле, в отличие от mpeg-2, нет подсказки в виде флага, какое поле надо выводить первым.
Допустим, вы имеете mpeg2 файл и хотите еще раз перекодироватть его в Прокодере. ProCoder увидит флаг и скорей-всего выставит в Source поле, соответствующее этому флагу.
А вот когда вы даете Пркодеру на вход avi-файл, то ProCoder начинает что-то там анализировать, но качества этого анализа таково, что можно считать, что он выставит в Source значение "от балды". Вот здесь и надо поработатьть ручками, поменяв, если нужно, параметры в Source. (Кстати для dv, помнится, ProCoder без всякого анализа в Source всегда ставит "нижнее".)

И последнее, допустим у вас есть некий avi-файл с первым верхним полем, т.е. событие А, зафиксированное в верхнем поле первого кадра произошло раньше, чем событие Б, зафиксированное в нижнем поле этого кадра. Задача - сделать avi-файл с первым нижним полем. Большинство прог, которые сделают это корректно, полагаю, поступят следующим образом: обрежут в кадре верхнюю строку и продублируют нижнюю. В этом случае поле, которое было нижним - станет верхним и наооборот. Разумеется, без перекодировки такая операция невозможна. Но можно поступить иначе, и это тоже будет правильно - не заниматься обрезанием строк, а просто отбросить первое нижнее поле и сформировать новые кадры, т.е. в первый новый кадр войдет верхнее поле первого кадра (старого) и нижнее поле второго (старого) кадра. Таким образом, в новом кадре событие в верхнем поле происходит раньше, чем в нижнем. Такая процедура тоже требует перекодировки.
Многие проги (ProCoder, TmpgEnc), если им на вход подавать dv, полагают, что в нем первое нижнее поле, поскольку таков стандарт для dv. Но далеко не все dv-файлы таковы. Например, если вы будете делать захват на тюнере и кодировать в на лету в dv, то получится dv-файл c первым верхним полем. Если вы имеете какой-нибудь avi-файл с первым верхним полем (пусть это будет huffyuv) и перекодируете в dv, допустим в VirtualDub'е, то тоже получите dv-файл с первым верхним полем. Но, разумеется, никакой метки, индикатора или флага в файле, что верхнее поле первое, там не будет.

  • 0

#25 Serg Falkon

Serg Falkon
  • Модераторы
  • 1 533 Сообщений:

Отправлено 21 май 2007 - 22:35

лучше это сделать самому визуально, хотя бы с помощью приведенного мной ранее ависинтовского скрипта
то достаточно изготовить несколько (точне 4 штуки) mpeg2-файлов с различными комбинациями Source и Target, вывести их потом с помощью DVD-плеера на телевизор и визуально определить правильные комбинации
Так оно, конечно, надежнее, но явно не быстрее и проще, чем с помощью тех же скриптов AVYSynth'а. Ими определяю порядок полей исходника (в сомнительных случаях), а в выходном MPEG2 всегда TFF ставлю.
  • 0

#26 Ludens

Ludens
  • Участник
  • 213 Сообщений:

Отправлено 10 июн 2007 - 19:24

А вот такой наивный вопрос.
А какова частота кадров после деинтелейса? До деинтерлейса мы имеем 50 РАЗНЫХ кадров в секунду. А после? 25? Или 50?
  • 0

#27 Dick

Dick
  • Участник
  • 10 055 Сообщений:

Отправлено 11 июн 2007 - 10:44

М.б. будет кому полезно

http://ru.wikipedia.org/wiki/%D0%9A%D0%B0%...%BE%D1%82%D0%B0

PS
В первом посте темы не является ли ошибкой:
"И второе, коли речь идет о деинтерлейсе, вероятно, что видео предназначается для просмотра на ПК, тогда есть смысл сразу привести его к нормальному соотношению сторон, исправив тем самым некоторую вытянутость изображения по вертикали. Ближайшее "правильное" разрешение (с учетом дальнейшего сжатия в MPEG) составляет 720х544..."

М.б. 720х540 ? Ведь соотношение д.б. 4:3

640х480, 560х420, 512х384.... тут все верно - 4:3

И м.б. добавить не только "(с учетом дальнейшего сжатия в MPEG)", но и DviX ?

PPS
Статья ALES74 оч. и оч. полезная! Прочитал взахлеб.

Сообщение отредактировано Dick: 11 июн 2007 - 11:14

  • 0

#28 Erny

Erny
  • Участник
  • 1 089 Сообщений:

Отправлено 11 июн 2007 - 12:11

720х540 - это и есть 4х3 :)

PS а я из DV PAL 720х576 для просмотра на компе делаю ави 768х576 квадратный пиксель(чтоб лица вытяутые не были) и деинтерлейс само-собой.
  • 0

#29 Dick

Dick
  • Участник
  • 10 055 Сообщений:

Отправлено 11 июн 2007 - 12:30

Читай внимательней!!!

Я ж и пишу, что в статье вместо 720х544 "М.б. 720х540 ? Ведь соотношение д.б. 4:3"

Скорей всего ALES74 просто опечатался (а никто не заметил) :)

Сообщение отредактировано Dick: 11 июн 2007 - 15:30

  • 0

#30 ALES74

ALES74
  • Участник
  • 841 Сообщений:

Отправлено 11 июн 2007 - 16:25

Привет! Спасибо за отзывы и горячее обсуждение.
Касательно 720х544 - ошибки нет. Да действительно 720/4*3=540, т.е. должно быть 720х540. Однако в моем тексте есть оговорка:"(с учетом дальнейшего сжатия в MPEG)", и здесь я имелл виду кратность размеров кадра размеру макроблока 16х16, на которые разбивается изображение при кодировании, тогда ближайший "правильный" размер 544. В принципе условие не обязательное.
  • 0

#31 Erny

Erny
  • Участник
  • 1 089 Сообщений:

Отправлено 11 июн 2007 - 16:34

Ага :) значит 768х576 правильней будет?
  • 0

#32 Dick

Dick
  • Участник
  • 10 055 Сообщений:

Отправлено 13 июн 2007 - 02:45

Привет! Спасибо за отзывы и горячее обсуждение.
Касательно 720х544 - ошибки нет. Да действительно 720/4*3=540, т.е. должно быть 720х540. Однако в моем тексте есть оговорка:"(с учетом дальнейшего сжатия в MPEG)", и здесь я имелл виду кратность размеров кадра размеру макроблока 16х16, на которые разбивается изображение при кодировании, тогда ближайший "правильный" размер 544. В принципе условие не обязательное.


1. а тогда 640х480, 560х420, 512х384.... ( это все 4:3) тоже надо подвергнуть коррекции, учитывая кратность размеров кадра размеру макроблока 16х16?

2. И еще я предложил добавить "(с учетом дальнейшего сжатия в MPEG)" и DviX ! ... если "видео предназначается для просмотра на ПК", если " есть смысл сразу привести его к нормальному соотношению сторон"
  • 0

#33 Eugene7

Eugene7
  • Участник
  • 467 Сообщений:

Отправлено 13 июн 2007 - 14:37

Привет! Спасибо за отзывы и горячее обсуждение.
Касательно 720х544 - ошибки нет. Да действительно 720/4*3=540, т.е. должно быть 720х540. Однако в моем тексте есть оговорка:"(с учетом дальнейшего сжатия в MPEG)", и здесь я имелл виду кратность размеров кадра размеру макроблока 16х16, на которые разбивается изображение при кодировании, тогда ближайший "правильный" размер 544. В принципе условие не обязательное.


Здрастье! Для сжатия в Mpeg-2 720x544??? Это вы где такие цифры взяли, в специфиции DVD такие чудеса пишут?? :)

Не надо никого вводить в заблуждение
1. Стандарт PAL о которм здесь идет речь имеет размер кадра 720x576
2. Разделите 576 на 16 и получите целое значение. С макроблоками 16x16 проблем нет.
3. Что касается DivX то обрезайте кадр как хотите, но не забывайте что есть PIXEL ASPECT RATIO, поэтому не знаю как можно было получить 720 / 540 = 4x3
  • 0

#34 Erny

Erny
  • Участник
  • 1 089 Сообщений:

Отправлено 13 июн 2007 - 15:20

Речь не про второй MPEG, про второй стандарт все знают :)
Кстати в стандартных пресетах DivX оказывается на самом деле так и стоит - 720х544 как один из стандартных размеров.
  • 0

#35 black

black
  • Участник
  • 1 057 Сообщений:

Отправлено 13 июн 2007 - 15:43

вообще очень странно, потому как глупо скалировать по строкам, когда можно просто привести к 768x576 и картинка будет более качественно, потому что видео очень не любит, когда колличество строк меняется. вот пример. взл черные строки в один пиксел и картинку размером в 720х576, левую я привел к 768х576, а правую к 720х540(544) и получил размытие гораздо белоее заметное на втором варианте:

Изображение

это и понятно, что бы сделать меньше строк, комп должен их перемешать, от этого получаем, что какие-то строки образовались путем смешивания соседних, от сюда и потери в четкости.
  • 0

#36 Erny

Erny
  • Участник
  • 1 089 Сообщений:

Отправлено 13 июн 2007 - 22:04

Или скалировать, например, 768x576 до 384х288 (ровно в 2 раза, и тогда потерь четкости меньше будет) или оставлять размер таким как есть(пересчитанным в квадратный пискель)
Правильно?
  • 0

#37 black

black
  • Участник
  • 1 057 Сообщений:

Отправлено 13 июн 2007 - 22:24

Совершенно верно, любое не кратное скалирование убивает качество, так что либо оставлять исходный размер, либо уменьшать кратно, например в два раза.
  • 0

#38 Dick

Dick
  • Участник
  • 10 055 Сообщений:

Отправлено 13 июн 2007 - 22:46

Или скалировать, например, 768x576 до 384х288 (ровно в 2 раза, и тогда потерь четкости меньше будет) или оставлять размер таким как есть(пересчитанным в квадратный пискель)
Правильно?


А зачем может потребоваться уменьшать с 768x576 до 384х288, если выяснилось, что вес не зависит от размера и останется примерно прежним ?

А мысль насчет 768x576 оч. интересная. Что-то нигде таких рекомендаций не встречал.
  • 0

#39 RANET

RANET
  • Участник
  • 1 784 Сообщений:

Отправлено 13 июн 2007 - 23:23

А зачем может потребоваться уменьшать с 768x576 до 384х288, если выяснилось, что вес не зависит от размера и останется примерно прежним ?

В принципе - зависит. Возьмём к примеру DVD ... "50 в 1м" :).
Кроме того ... есть ограничения по разрешению. Это может быть и Интернет, и мобильный телефон и даже DVD плеер. К примеру, если DivX будет с разрешением 768x576, то DVD плеер воспроизведёт только звук т.к. выше 720х576 он воспроизводить не способен ... :)
  • 0

#40 Dick

Dick
  • Участник
  • 10 055 Сообщений:

Отправлено 13 июн 2007 - 23:56

"примеру, если DivX будет с разрешением 768x576, то DVD плеер воспроизведёт только звук т.к. выше 720х576 он воспроизводить не способен ... "

Оп-па, вот это важная ИНФА, тогда чтобы картинка игралась и на РС и через плеер на ТВ, получается лучше всего юзать (768x576 разделить на два) 384х288 ?

При этом 384х288 разрешении картинка будет лучше при сжатии в DviX, чем при 720х540 (если исходник DV(avi) 720х576) ???
Получается так?
  • 0

#41 RANET

RANET
  • Участник
  • 1 784 Сообщений:

Отправлено 14 июн 2007 - 00:13

Если исходник DV ... то лучше всего юзать MPEG2 ... :)
Сергей, всё относительно ... ты уточни, что в итоге тебя больше интересует - размер (вес) или качество?
  • 0

#42 Dick

Dick
  • Участник
  • 10 055 Сообщений:

Отправлено 14 июн 2007 - 00:35

КАЧЕСТВО, но в DviX, ради экономии места, в последующем просмотр будет только на РС (совсем изредка на ТВ).
(такая задача)

Т.е. задача - получить максимальное качество DviX из DV(avi)
МПЕГи - если взять файл того же небольшого веса что и dvix - проигрывают в качестве при деинтерлейсе. ИМХО
DviX оч.хорошо делает деинтерлейс, т.к. создавался под РС

И повторю вопрос:
"При сжатии из DV(avi 720х576) в DviX при 384х288 картинка будет лучше чем, чем при 720х540, т.к. 288 кратно 576 ???
Получается так?

Сообщение отредактировано Dick: 14 июн 2007 - 00:43

  • 0

#43 black

black
  • Участник
  • 1 057 Сообщений:

Отправлено 14 июн 2007 - 05:55

"При сжатии из DV(avi 720х576) в DviX при 384х288 картинка будет лучше чем, чем при 720х540, т.к. 288 кратно 576 ???

нет картинка не будет лучьше, потому что ты ее в 4 раза убил :)

речь о том, что в выборе между 720х540 и 768х576 во втором варианте картинка будет лучьше, потому что мы не трогали строки (а это важно)
про то что плеер откажется играть 768х576 слышу впервые, по этому не могу прокомментировать, но вообзе странно.

да, если кодек умеет прописывать пиксел-аспект, то оставляй 720х576 pixel=1:1.067, и тогда у тебя будет максимальное качество.
  • 0

#44 Dick

Dick
  • Участник
  • 10 055 Сообщений:

Отправлено 14 июн 2007 - 10:11

1. "потому что ты ее в 4 раза убил"
Так и полагал... Только м.б. в 2 раза (в 4 раза уменьшается площадь и вес, а вертик. и гориз. детализация соответствует линейным размерам)..... ну да ладно....

2. "в выборе между 720х540 и 768х576"
А ни в DviX 6.6.1, ни в Dr.DviX, ни в VD никак не поставишь больше 720 !!!

3. "если кодек умеет прописывать пиксел-аспект, то оставляй 720х576 pixel=1:1.067"
Тогда на многих софтовых плеерах (даже на родном софт.плеере Dvix) по бокам черные шторки, поэтому юзаю в установках DviX 720х540, проблем со шторками тогда нет

4. Если в самом конверторе DviX 6.6.1 включить замочек (сцепить гориз и вертик разрешение), то он выдает 720х528
А это что за разрешение?
  • 0

#45 Erny

Erny
  • Участник
  • 1 089 Сообщений:

Отправлено 14 июн 2007 - 14:50

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

По 2. вопросу - очень даже поставишь, просто надо в Sertification Profile c default(Home Theater) изменить на High Definition Profile, тогда открываются все настройки.
По 4. - фиг его знает, это он считает, что 720х576 квадратный пиксел, а так как соотношение сторон в таком разе не 4х3, то он просто приводит это соотношение по большей стороне. Но у тебя ведь пиксел не квадратный. Надо ставить самому как положено.
  • 0

#46 Dick

Dick
  • Участник
  • 10 055 Сообщений:

Отправлено 14 июн 2007 - 18:17

Согласен во всем! Спасиб.

Просьба модераторам, т.к. многие в полемике почерпнули все необходимое, почистить столь полезную тему.
  • 0

#47 Dick

Dick
  • Участник
  • 10 055 Сообщений:

Отправлено 16 июн 2007 - 10:18

Климов "А вот когда вы даете Пркодеру на вход avi-файл, то ProCoder начинает что-то там анализировать, но качества этого анализа таково, что можно считать, что он выставит в Source значение (верхнее, нижнее поле) "от балды..."

Не от балды. В конечных настройках СРС2 предлагается выбор - строчка interlacing - нужно установить, что треба, верхнее или нижнее... это если, например, пишете DVD
Если создаете одиночный файл MPEG2, то в этой же строчке предлагается еще и "non-interlaced" для деинтерлейсинга.

А нет ли проги, кот. указывала какое поле в видео-файле первое ?

Сообщение отредактировано Dick: 16 июн 2007 - 18:15

  • 0

#48 Erny

Erny
  • Участник
  • 1 089 Сообщений:

Отправлено 16 июн 2007 - 20:25

Я в Виртуал дабе смотрю: меню Video - Frame Rate - Change To - ставишь 5 кадров, после этого твой файл будет проигрываться в 5 раз медленнее. А в меню Options - Preview Fild Mode ставишь поочередно А(верхнее) или В(нижнее) и смотришь где стробит. Безошибочный вариант.
А другой народ смотрит в монтажке - замедляет кажись в 2 раза, но я этим не пользуюсь, пусть кто это делает сам расскажет.

PS Это был ответ на вопрос "А нет ли проги, кот. указывала какое поле в видео-файле первое ?"

Сообщение отредактировано Erny: 16 июн 2007 - 23:55

  • 0

#49 Serg Falkon

Serg Falkon
  • Модераторы
  • 1 533 Сообщений:

Отправлено 16 июн 2007 - 20:38

Dick
предлагается еще и "non-interlaced" для деинтерлейсинга
Оно не для этого предлагается. Т.е., поставив non-interlaced у тебя автоматом видео не будет деинтерлейситься. А ставить это надо, если реально прогрессивная картинка кодируется , т.е. оба поля кадра соответствуют одному моменту времени. И кодировщик будет кодировать кадр целиком - так качественней выходит, чем по полям (именно для прогрессивного источника).
  • 0

#50 Dick

Dick
  • Участник
  • 10 055 Сообщений:

Отправлено 16 июн 2007 - 23:54

Я исхожу из личного опыта, если просто сжимаю в СРС2 из DV в MPEG2 - сильная грЁбанка при просмотре на РС (а мне надо именно на нем!).
Если ставлю в Визарде non-interlaced - грЁбанка на мониторе пропадает. Значит это - деинтерлейс (или как его еще там). ИИИМХО. :beer:



2 Erny
Эх, какие все сложные пути определения первого поля.
А хотелось бы прогу, вроде видеоинспектора, вызываешь туда видеофайл - он тебе и показывает Lower или Upper

Сообщение отредактировано Dick: 17 июн 2007 - 00:37

  • 0




0 человек читают эту тему

0 пользователей, 0 гостей, 0 скрытых пользователей

Rambler's Top100