Качественное кодирование кодеком XViD
 

Спустя много лет решил обновить эту тему: новое время, новое ПО.
Теперь архив со статьями лежит здесь:
[Для просмотра данной ссылки нужно зарегистрироваться]
Вся многостраничная перепись, имхо, устарела, и её можно не читать.

Кто автор статьи? Источник?

Автор, разумеется, я. Всё написанное во всех этих статьях -- результат длительных исследований. Раньше свои статьи я размещал на cgtalk.ru, тот форум околел, и вот я переместился сюда.

Риспект, Жрец, что присоидинил все статьи в подвешенном архиве: читать из вордешника восто крат удобние.
Знаешь, я тоже забил на конвертацию, могу позволить себе хранить всё в исходниках, так что из подвешенных здесь в твоем архивве статей полезного для себя взял даж более, чем из конвертацеи в xvid.
Одно замечанье: ту статью где ты пишешь про переброс из flv в матрёшку былоб лучше подвесить к Тонкостям перекидывания в матрешку.

Знаешь, Рэмбо150, ты прав: статью "Конвертирование Flash Video (.flv) в avi и переброс из контейнера flv в mkv", пожалуй, было бы уместнее, выражаясь твоим языком, "подвесить" к теме о перекидывании в матрёшку. Но на этом форуме кнопка "Правка" активна для сообщения только некоторое время, и если я переделаю архив, то в теме уже будет недействительная ссылка. Так что оставлю, как есть, тем более что указание на статьтю про flv есть в первых абзацах этой темы.

Начну по порядку - ваше мнение относительно ac3filter_1_63b.exe, вы считаете что может быть проблема именно в фильтре? Да и вот еще : Когда я выставлял настройки для конвертации на свой фильтр - он не работал ... несколько раз проверил. Сегодня переустановлю на 1,63b я скачал его.
Теперь длинна дорожки - с этим делом я на "ТЫ" так как мое увлечение (хобби) подгоняю, синхронизирую зв. дорожки. У меня стоят две проги Sound Forge 6.0 и Adobe Audition 3.0.1 и я всегда после разборки - сборки DVD проверяю дорожки сравнивая с оригиналом.

Сворог, так мы не решим проблему: я всё-таки жрец, а не гадалка.
Напиши примерно так: звуковой файл с таким-то расширением, звук сжат ас3, медиаинфо показывает такую длину, другие проги (перечисление) -- например, такую же, открываю в голдвэйве -- получаю столько-то.
Также. Иногда есть смысл аудио файл перед открытием в Голдвэйве перебросить матрёшечником в mka -- это почти всегда лишает поток проблемности. Разумеется, чтобы mka открылся, должен стоять Хаали.
И можно присылать мне прямо на Нефезиду83 зараренный файл -- для этого я и выложил ящик для всех.

Жрец, а че у тебя в статье в том месте где про планары какие-то пляшущеи человечки? Все восприятие как-то портят К чему они?

Понимаешь, я изначально пишу статьи в Ворде, со всеми преимуществами такого писания, а потом просто копирую текст сюда. Я довольно долго ошивался на сиджитолке, и там несколько иная система устройства форума: там, если вставляешь из буфера обмена, то получается, как есть. Здесь же некоторые символы могут замениться, как ты выразился, пляшущими человечками. И я не сразу сообразил, что нужно включать опцию "Отключить смайлы". А когда сообразил, кнопка "Правка" стала уже не активна. В находящемся в архиве doc - файле этой статьи никаких "пляшущих человечков", естественно, нет.

Жрец Нефтиды, скажи, пожалуйста, влияет ли Польская матрица на качество (в лучшую или в худшую сторону)при кодировании XviD-ом на НИЗКИХ битрейтах ~1000kbps и МАЛОМ разрешении(480x320). Или может в этом случае лучше воспользоваться стандартной матрицей. Я понимаю что "качество всё...:57:", но просто сын попросил на Андроид клипов наделать, а в нём частота процессора 800Мгц, так что не потянет большое разрешение и большой битрейт.:31:

Дело в том, что польская матрица изначально заточена именно на кодирование с постоянным квантизёром не меньше 2 (для любого разрешения!), либо на кодирование с большим постоянным битрейтом, о чём сам Jawor чётко высказался. Но. Низкое разрешение -- оно само по себе уже не требует высоких битрейтов: 1000kbps для 480x320 -- это уже достаточно высоко. Я бы посоветовал так. Попробуй кодировать на требуемом тебе 480x320 именно с постоянным квантизёром = 2 на польской матрице. И если объём тебя устроит, то полькая матрица - это идеальное решение. Вообще постоянный квантизёр -- это всегда лучше постоянного битрейта, и в первом прикиде мне кажется, что средний битрейт именно таким и будет. Но вот если объём не устроит, или тебе нужно непременно на 1000 кбит/с -- трудно однозначно сказать, что лучше. Попробуй и польскую, и прилагаемые к иксвиду другие матрицы, сделай снимки в bmp с полученного ави, и посмотри, что лучше.

Жрец Нефтиды, ещё вопрос. Вот в этом примере всё понятно что яркость поднята на 1:

ColorMatrix(mode="Rec.709->Rec.601", clamp=0, opt=0)
ColorYUV(off_y=1)

А вот в других примерах без применения ColorMatrix нужно всегда применять фильтр "brightness/contrast" для поднятия яркости на 1 или нет?
Напимер в этих случаях:
ConvertToRGB24(matrix="rec709", interlaced=false)
RGBAdjust(1, 1, 1, 1, 1, 1, 1, 0, 1, 1, 1, 1)
или
ConvertToRGB24(matrix="rec709", interlaced=false)
Spline144Resize(720, 576, 0, 188, -0, -188)
RGBAdjust(1, 1, 1, 1, 1, 1, 1, 0, 1, 1, 1, 1)

Спрашиваю, потому что не силён в скриптах, но потихоньку читаю твои статьи и разбираюсь. ;)

Благодарю. :3 1: Я и думал что эта строка повышает яркость на 1, но для пущей верности решил переспросить. ;)

Необходим конвертор из AVI в AVI. Для конвертирования видео с камеры, которая снимает в расширении AVI видео кодек IBM Motion JPEG including Huffman Tables.
С этим кодеком не читает железный DVD плеер. Читает с кодеком XviD build 46
Подскажите, пожалуйста, прогу, что бы можно выбрать не только конвертируемый формат, расширение, но и кодеки XviD build 46 , XviD build 50 , а если еще будет сохранять размер (а значит и качество) то это вообще будет прекрасно.
P.S.
И еще произошла такая странная вещ, Конвертировал я прогой Format Factory версия 2.8
Там был кодек XviD build 46 (XviD 1.1.2 (UTC 2006-11-01)) , потом я установил Format Factory версия 3, там я обнаружил кодек XviD build 50 (XviD 1.2.1 (UTC 2008-12-04)). Снес эту версию и поставил старую 2.8, но все равно при конвертировании был кодек XviD build 50

Вначале разберёмся вот с каким архиважным вопросом. Частота кадров того ави, что ты мне выслал, по данным Медиаинфо составляет 28,051 кадров в секунду. Таких частот не бывает. Дело здесь вот в чём. Контейнер ави, по крайней мере в его изначальном виде, предназначен только для постоянной частоты кадров. В то же время другие контейнеры, такие, как mkv или mp4, прекрасно работают с переменной частотой кадров. Я очень подозреваю, что изначально всё-таки камера писала не в контейнер ави, а в какой-то другой, причём с переменной частотой кадров. А потом уже каким-то образом произошёл переброс в ави с усреднением частоты кадров, откуда и появилось это фантастическое значение 28,051. Ты разберись, и напиши, во что изначально камера пишет?

Вот данные из Медиаинфо
Video
Формат : M-JPEG
Идентификатор кодека : MJPG
Продолжительность : 23s 220ms
Битрейт : 6 802 Kbps
Ширина : 640 pixels
Высота : 480 pixels
Соотношение кадра : 4/3
Частота кадров : 28.036 fps
Разрешение : 24 bits
Тип развёртки : Progressive
Бит/(Пиксели*Кадры) : 0.790
Размер потока : 18.8 MiB (99%)



[Для просмотра данной ссылки нужно зарегистрироваться]
[Для просмотра данной ссылки нужно зарегистрироваться]

Более-менее прояснилось, хотя с такой нестандартной частотой встречаюсь впервые. В этом файле, как я понял, видео сжато по 709, поэтому разжимать напрямую встроенным MJPG декодером из Даба не годится. Включаем в ffdshow декодер MJPEG, и грузим в Даб через такой скрипт:
LoadPlugin("ColorMatrix.dll")
DirectShowSource("1.avi")
AssumeFPS(28.036)
ColorMatrix(mode="Rec.709->Rec.601", clamp=0, opt=0)
ColorYUV(off_y=1)

Извините за непонятливость
А можно подробнее "Включаем в ffdshow декодер MJPEG" "и грузим в Даб через такой скрипт"
Зачем ? и что в результате?
Мне не приходилось такое вытворять : 68:
А всего лишь навсего брал прогу, и простыми функциями конвертировал из одного в другое.

Уважаемый Жрец, откуда появилась такая уверенность, что DVD следует расжимать исключительно с применением цветового алгоритма "Rec. 709"?

Вот скриншоты мультсериала "Футурама", при риповании которого были применены оба алгоритма ("Rec. 601" и "Rec. 709", соотвественно):

[Для просмотра данной ссылки нужно зарегистрироваться]
[Для просмотра данной ссылки нужно зарегистрироваться]
Начиная с полнометражных фильмов, сериал стал выходить в "Full HD". Вот рип с WEB-DL 1080p фильма "Bender's Big Score" (при расжатии были применены алгоритмы "Rec. 709" и "Rec. 601", соотвественно):
[Для просмотра данной ссылки нужно зарегистрироваться]
[Для просмотра данной ссылки нужно зарегистрироваться]
Отметьте, насколько Зойдберг в DVDRip'е, где при расжатии исходника использовался протокол "Rec. 601" (первый скриншот в сообщении), цветом практически идентичен WEB-DLRip'у (исходник закодирован AVC), где цвет расжат по протоколу "Rec. 709" (третий скриншот в сообщении).

[Для просмотра данной ссылки нужно зарегистрироваться] "AviSynth" довольно чётко описывает эту ситуацию: если при расжатии использовался неверный протокол, то есть "Rec. 709" там, где нужно было "Rec. 601", то картинка будет казаться более насыщенной, а красный цвет будет иметь сдвиг в жёлтый. Соответственно, в DVDRip'е, созданном при использовании протокола "Rec. 709", заметно, что Зойдберг стал оранжевее (второй скриншот в моём сообщении). Кроме того, справочник предлагает считать за генеральное правило то, что для исходников в SD следует применять алгоритм 601, а для HD - 709.

Объясните, пожалуйста, где правда? Я отриповал весь сериал эпохи SD (DVD), используя алгоритм 709, и только сейчас, благодаря знакомому, обнаружил неясность с цветовой гаммой.

P.S.
Диски - системы NTSC. "MediaInfo" по ним даёт такую информацию:
"DGIndex" выдаёт это:

Ты совершенно верно сказал: если мы будем разжимать исходник, сделанный по 601, алгоритмом 709, то получим цветовой сдвиг: с очевидным не поспоришь. Вся проблема в том, чтобы правильно определить, по какому алгоритму сжат исходник. И вот тут могут быть нюансы.
Начну с h264/AVC. Вот известная программа x264.exe. Она точно гонит по 601. В этом легко убедиться: возьмём несжатый кусочек в несколько кадров в формате RGB, закодируем этой программой, потом разожмём и так и сяк, и увидим своими глазами. Причём x264.exe будет гнать по 601 независимо от разрешения, будь то даже Full HD. В то же время другие проги сжимают в h264 по 709 – тоже можно убедиться, загоняя в них RGB исходник.
Теперь MJPEG. Один фотоаппарат у меня кодировал в контейнер mov по 709: убедился лично, разжимая по 601 и по 709, и держа перед собой отснятый предмет. А вот другая камера в этот же самый контейнер mov с тем же самым MJPEG гнала по 601!
Теперь про Full HD, сжатое VC-1. Я одно время сомневался: по 601 или по 709? Однозначно надо по 709. Если будем по 601, получим неестественные цвета.
Ну а теперь к DVD. По крайней мере те DVD, которые мне встречались раньше, на мой взгляд были сделаны по 709. Прогоняя их через DGIndex, в его подокне тоже видел 709.
Медиаинфо – тоже не истина в последней инстанции. Лично убеждался.
Особенность моего подхода – что ты можешь самостоятельно переключать между 601 и 709, чего не позволяют все остальные конвертеры. Если считаешь, что исходник по 601 – так ещё и лучше, не нужно разжимать в RGB, прямо и подаёшь на XViD, только яркость на 1 поднимаешь. XViD – он-то точно всегда по 601 делает.
Ну а самое главное – я уже давно отошёл от конвертирования DVD: магазины ломятся от девятых болванок, и губить качество конвертированием – полное мракобесие. Просто перекинь в матрёшку, и вечно наслаждайся исходным качеством. Если ты сконвертируешь не по тому алгоритму, то потом уже ничего не сделаешь, а если у тебя есть исходный видео поток в матрёшке, то всегда сможешь переключить алгоритм в ffdshow. Вот конвертировать блюреи – это ещё куда ни шло, но в них, по моим наблюдениям, всегда 709.

Колориметрия ДВД
 

Всем привет! Во-первых хочу поблагодарить Жреца Нефтиды за массу полезных и доходчивых статей по обработке аудио и видео. Спасибо!
Читаю форум уже 2 года, но проблема, поднятая Antique87, заставила зарегистрироваться, поскольку тема рипования "Футурамы" из по-моему единственного в сети комплекта американских 16хDVD9 мне близка.
Возьму на себя смелость пояснить за Antique87 некоторые проблемы этого издания.
Зачем делать рип? Диски сделаны с переменной частотой кадров по самому похабному из всех возможных варианту 4 (Деинтерлейс, удаление зернистости и шума). Скрипт для этого случая + деинтерлейс по номерам кадров даёт самый лучший, но не идеальный результат, поскольку, как выяснилось, от некоторых кадров осталось только одно поле, а некоторые поля и вовсе имеют цветные тени предыдущего или последующего кадров. Предложенный метод просмотра через МРС НС такого видео с задачей не справляется (У меня, может быть я что-то прочитал невнимательно), остаются рваные края движущихся объектов, картинка периодически дёргается в вертикальном направлении. В итоге рип смотрится гораздо приятнее, чем оригинал, за исключением некоторого изменения цветовой гаммы.
Полнометражные фильмы выходили как на БД, так и на ДВД. Antique87 имеет в виду, что цвета ДВД, разжатого алгоритмом 601, полностью соответствуют цветам Вэб Дл или БДремукса, разжатых алгоритмом 709. Отсюда напрашивается вывод, что не все поголовно ДВД кодированы с использованием матрицы 709, а только те, где этот параметр не задан явно или задан как REC709. Те же ДВД, где Медиаинфо пишет BT.601 NTSC, а DGIndex определяет "Colorimetry: SMPTE 170M" или "BT.470-2" (попадались мне и такие) кодированы с использованием матрицы 601 и декодировать их тоже нужно по алгоритму 601.
Такие же данные Медиаинфо и ДГИндекса мне встречались на ДВД фильма "Бездна" [Для просмотра данной ссылки нужно зарегистрироваться] , но там, как и в мультфильме, невозможно проверить правильность выбора алгоритма декодирования "на глаз", поскольку действие происходит в основном под водой или при слабом освещении.
Вот цитата из руководства к ColorMatrix v2.5 от Тритикал:

Цитата:

Когда преобразование из RGB в YUV и наоборот, есть несколько наборов коэффициентов, которые могут быть использованы. Наиболее распространенными являются Rec.709, FCC, Rec.601 (aka SMPTE 170М или МСЭ-R BT.470-2)и SMPTE 240 М

И хотя он, Тритикал, пишет, что MPEG-2 потоки в основном закодированы ВТ709, но бывают и исключения. (в оригинале была табличка)
Видимо, здесь как раз такой случай. Поэтому, уважаемый Жрец, прошу прояснить этот вопрос и если сказанное выше подтвердится, внести изменения в Вашу статью, дабы не вводить в заблуждение рабов качества.

Колориметрия ДВД
 

Но из какого такого места, в таком случае, DGIndex достал тот самый SMPTE 170M, для которого многими источниками, в том числе и Тритикалом напрямую указывается ВТ601? Да, отчасти согласен, бракодел с 20 Век Фокс подложил очень много всевозможных какашек, мог и не ту цифирь в метаданных поставить, но если считать, что всё сделано точно и в соответствии со стандартом, достаточно ли показаний DGIndex'а? Или для 100% уверенности должны быть указаны ещё какие-то параметры?
Не знаю, что делать с рабами, но свободных египтян всё же стоит уведомить о возможности наличия на NTSC DVD MPEG-2 потока, который нужно декодировать по алгоритму 601, вне зависимости от того, будут ли они просто смотреть это видео в МРС НС, риповать или просто снимать качественные скрины для нужд своего сайта, на то они и свободные:ad:
(Да, разобрался с просмотром в МРС НС, перенастроил, всё пошло, но полосатые рты всё равно местами остались)

Ну а болванки, это уже прошлый век. Все 96ГБ тех исходников и еще очень много чего уже 3 года лежат на 2ТБ винте, а недавно был прикуплен ещё и 1ТБ портативный HDD, на который скопировано всё самое ценное.

Приветствую!а можете записать и выложить на ютубе видео руководство по правильной конвертации mts через Virtual Dub (или через другие правильные проги/форматы/кодеки).Прочитал руководство и мозг сломал себе,хоть я и немного продвинутый так сказать) Так что просим-просим) Спасибо!

Я ждал этого вопроса. В служебной зоне vob-ов есть место, куда вписывается информация, по какому протоколу сжат поток в планарный формат YV12. Вот из этого-то места DGIndex и другие программы считывают инфу о протоколе. Причём данная информация – это просто небольшой кусочек текста, никак не связанный с самим потоком, и более нигде не дублирующийся. Следовательно, если информация о 601 или 709 вписана в vob неверно, то никаким логическим или математическим путём ты не вычислишь, правда ли это. Только просмотром, на глаз. Это подобно тому, как если бы ты при конвертировании увеличил, скажем, красноту изображения, и приложил к avi текстовый файл, что ничего такого ты не делал. Никаких следов такого вредительства в самой структуре файлов не останется, только на глаз и увидишь. "Или для 100% уверенности должны быть указаны ещё какие-то параметры?" – а никаких других параметров в vob-е просто нет.
"всё же стоит уведомить" – ну тогда уведомляю. Иногда, на счастье очень редко, MPEG-2 поток может быть сжат по протоколу 601, причём вероятность такого безобразия для NTSC во много раз больше, чем для ПАЛа. Инфа, которую выдаёт DGIndex, не всегда гарантированно точно даёт протокол, а другой инфы просто нет. Так что остаётся на глаз.
"полосатые рты всё равно местами остались" – для мультов с их чёткими изображениями при наличии переменной частоты кадров в NTSC можно порекомендовать постоянно включённый пятиточечник из ffdshow. Описано в "Качественный просмотр фильмов с остаточной интерлейсностью".
"Ну а болванки, это уже прошлый век" – ой не скажи. Вот тут одна из моих тёток несколько лет назад купила внешний винт с объёмом, фантастичным даже для нашего времени, и всё тудыть скинула. А у неё кошка была, сбросила кошка винт со стула, и он сказал "хрясть" вместе со всей инфой, восстановить не удалось. Поплакала-поплакала тётка и уехала с горя в Канаду…

Для jbancrew. Не, видеоруководства я никогда не делал, даже не очень представляю, как они делаются. Да вроде всё подробно расписал.

Спасибо за ответы! Наконец всё понятно.
Теперь каждый свободный египтянин, увидев подозрительные буковки в окошечке или логфайле ДГИндекса насторожится, включит мозг и зоркий глаз, а не будет, подобно рабу, совать куда не попадя REC709 при виде VOB'a :ab:

jbancrew
Зачем видеоруководство? Открываешь статью, устанавливаешь все проги и плагины, которые рекомендует Жрец, настраиваешь (расписано всё до галочки в каждом окошке, куда уж подробнее?) Создаёшь какой-нибудь простенький скрипт, копируя строки прямо из текста, чтобы попробовать и понять как это работает. Когда чуть освоишься, ищи свой случай и вперёд! Я именно так и поступил 2 года назад, не имея ни малейшего представления об Ависинт, да и сейчас не стесняюсь подглядывать :ab:

Добрый вечер Жрец! Прогресс идет вперед, о конвертировании уже забываем, даже как то скучновато стало - открыл в MPC HC любое видео и смотри , никаких проблем.
Но вместе с тем возникают новае специфические вопросы.
Скажи пожалуйста, что есть плохо и хорошего в таком улучшайзере как приведение к 60 fps для большей плавности. Я посмотрел кусок Аватара на комп. мониторе в 23.9fps, 23.9 --60 fps и оригинал 60 fps - в принципе никакой разницы нет. Может на большом ЖК ТВ это будет работать?

Спасибо!Прогрессив камеру нет желания и надобности пока покупать,поэтому вопрос по ЭТОЙ камере и видео,которое оно снимает) Моя цель классическая: отснятый материал соединить в один фильм,без большой потери кач-ва;уменьшить размер процентов на 27-45 и всё это для последующего просмотра на компьютере.
Как я понял мне смысла всё это с xvidom делать нет)Так как размер будет такой же или больше и из плюсов будет только склейка в один фильм)
Тогда можешь посоветовать другой контейнер или кодек для моего исходника и моих целей,плиз)
И если исходник будет такого плана,что изменится?))

Формат : BDAV
Формат/Информация : Blu-ray Video
Размер файла : 57,6 Мбайт
Продолжительность : 21 с.
Режим общего битрейта : Переменный
Общий поток : 22,1 Мбит/сек
Максимальный общий битрейт : 24,0 Мбит/сек

Видео
Идентификатор : 4113 (0x1011)
Идентификатор меню : 1 (0x1)
Формат : AVC
Формат/Информация : Advanced Video Codec
Профиль формата : [email protected]
Параметр CABAC формата : Да
Параметр ReFrames формата : 2 кадра
Параметр GOP формата : M=2, N=13
Идентификатор кодека : 27
Продолжительность : 21 с.
Вид битрейта : Переменный
Битрейт : 20,9 Мбит/сек
Максимальный битрейт : 22,0 Мбит/сек
Ширина : 1920 пикселей
Высота : 1080 пикселей
Соотношение сторон : 16:9
Частота кадров : 25,000 кадров/сек
Цветовое пространство : YUV
Субдискретизация насыщенности : 4:2:0
Битовая глубина : 8 бит
Тип развёртки : Чересстрочная
Порядок развёртки : Верхнее поле первое
Бит/(Пиксели*Кадры) : 0.404
Размер потока : 53,0 Мбайт (92%)

аудио такое же
Спасибо!!!

Всё же в случае jbancrew, можно выполнить некоторый приблизительный монтаж без конвертации и потери качества. Ведь, как правило, в любительской съёмке достаточно моментов, которые совершенно не нужны потомкам, например вид земли под ногами, когда забыл выключить камеру.
Сначала открываем свой видеофайл в проигрывателе и при просмотре (лучше покадровом) записываем времена начала и окончания нужного куска. Ещё удобнее открыть видео в ВиртуалДабе, предварительно прогнав через DGAVCIndex. Потом открываем этот же видеофайл "Матрёшечником", на вкладке "Глобальные" ставим птицу "Включить разбиение" и точку "...после таймкодов". Например, у нас видео 5мин12сек, где нужно отрезать первые 24 секунды и последние 12. В строке "...после таймкодов" пишем 00:00:24,00:05:00 (где формат времени ЧЧ:ММ:СС) или 24s,300s (формат времени секунды). Запускаем процесс и получаем на выходе 3 файла с длительностью примерно 24с (от 0 до 24с), 4м36с (от 24с до 5минут) и 12 (от 5мин до 5мин12сек). Почему примерно? Потому, что видео нарезается без пережатия по ключевым кадрам, поэтому понадобится методом научного тыка немного изменить границы нарезки, чтобы в каждый файл попало именно то, что нужно. Ненужные файлы удаляем, а из нужных клеим свой фильм. Что будет со звуком - не знаю, возможен рассинхрон при большом количестве отдельных кусков.

А будет ли с текущей версией XViD ошибкой позволить "VirtualDub" самому производить конверсию RGB24 в планарный формат перед подачей в кодер? Я имею ввиду скрипт, где цвет до "Даба" был расжат в RGB24, потому что нужно было произвести обрезку и масштабирование.

Ошибкой, в принципе, не будет. Но мои тонкие исследования на различных сценах показали, что если уж была необходимость разжать до RGB, то лучше этот самый RGB подать на XViD, как он есть, чтобы XViD, а не Даб, преобразовал его в YV12.

Очень важная информация.
Во всех своих писаниях я рекомендовал поднимать яркость на 1 при конвертировании в avi XViD. Откуда я это взял? Полученный avi XViD я просто открывал в Виртуал Дабе, делал снимок кадра в формате bmp, и сравнивал со снимком bmp из исходника. Получалось, что поднимать на 1 надо.
Но ведь смотреть мы будем не Дабом, а Плеером!
Так вот я попробовал сделать снимок полученного конвертированием avi XViD-а Плеером Хоумсинема. Получилось, что для полного соответствия по яркости оригиналу яркость при конвертировании поднимать на 1 не нужно! Почему такой простой опыт столь долго не приходил мне в голову – это уже тема отдельного жреческого разбирательства. Также. Если полученный avi XViD открыть в Дабе не напрямую, а через скрипт DirectShowSource или AviSource, то, для полного соответствия яркости, поднимать яркость на 1 при конвертировании тоже не нужно. Конечно, разность яркостей в 1 заметна только на неярких кадрах и то лишь чуть-чуть, но качество, как известно, всё.
Столько лет лежат здесь мои статьи, и никто не отругал меня за данный недосмотр. А вот конкретно за это нужно было.
Таким образом, если кто-то ещё занимается конвертированием с пережатием, то изо всех моих скриптов просто выбрасываем строки RGBAdjust(1, 1, 1, 1, 1, 1, 1, 0, 1, 1, 1, 1) и ColorYUV(off_y=1)

Как убрать ступенчатость в круглых объектах?
Видео в vob-файле:
интерлейсное, NTSC, 29.97, судя по статье "Деинтерлейсинг..." случай № 5-1, т.е. деинтерлейсим как в случае № 2 скриптом:

TDeint(type=2, hints=false, full=true, sharp=true, slow=2, mthreshL=5, mthreshC=5)

На выходе получается такое безобразие:
[Для просмотра данной ссылки нужно зарегистрироваться]

В то же время, при просмотре исходного vob-a в MPC-HC все очень даже прилично:
[Для просмотра данной ссылки нужно зарегистрироваться]

Что нужно добавить в скрипт, чтобы получилось как на второй картинке?

Хороший вопрос. "при просмотре исходного vob-a в MPC-HC все очень даже прилично:" -- ты под этим подразумеваешь, что декодирование производится внутренним декодером из MPC-HC? При таком подходе Плеер используем алгоритм "blend", то есть попросту подразмазывает.
Вначале попробуй ядиф от Физика. Вот так:
LoadPlugin("DGDecode.dll")
Load_Stdcall_plugin("yadif.dll")
MPEG2Source("1.d2v")
yadif()
ConvertToRGB32(matrix="rec709", interlaced=false)

Я между этими "картинками" не вижу большой разницы,
всё относительно

"От оно че!" Да, совершенно верно, видео встроенными фильтрами воспроизведено. Физический фильтр ненамного улучшил картинку. Но, как я уже понимаю, много тут уже не сделать?

Возможно и так... Но когда смотришь в движении, разница в глаза бросается и вопрос сам собою рождается, а нельзя ли сделать лучше.

Какое движение? у вас статичные снимки,
я так и не понял, что вы хотите расказать?

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

Тогда нужно показать реальную (видео) картинку,
скриншоты ни о чём

Понял, тогда так. Ролик на выходе после кодирования:


Тот же участок при проигрывании в MPC-HC:


P.S. Как оформлять ссылки на Ютуб? Код [YOUTUBE ][/YOUTUBE ] не
срабатывает.

Залей куда-нибудь небольшой кусок ни во что не преобразованного исходника, мне уже интересно стало.