Дёргается пережатое видео
Mar. 8th, 2014 06:13 pm![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
kray-zemli.livejournal.com posting in ![[community profile]](https://www.dreamwidth.org/img/silk/identity/community.png){kind=small}
useful_faqСофт: винда 2003 (комп Athlon 64 4400+), VirtualDub 1.10.4 Rus, Media player classic 1.7.3.45, K-Lite codec pack mega (новый, только сегодня скачал).
Исходник получен оцифровкой с VHS через canopus advc-110 при помоши того же VirtualDub, он чересстрочный. Исходник плеером играется удовлетворительно, плеер сам делает деинтерлейс.
Потом при помощи того же дуба видео было пережато кодеком x264. Использовался ключ --interlaced, чтобы видео осталось чересстрочным.
Получившееся видео дёргается, идёт как бы рывками (не так, как если быстродействия не хватает). Как на компе, так и на цифровом телевизоре (говорят, нынче у них внутри linux и весь тот же самый красноглазый софт, так что не удивительно). Однако, при покадровом просмотре тем же MPC на компе никаких чудес не выявляется, но совершенно точно изображение не такое как в динамике (например, при покадровом просмотре чёрное поле сверху стабильного размера, а при проигрывании оно пульсирует).
Пережимал примерно так:
Кто виноват и что делать?
Вторая проблема с самой оцифровкой. Почему-то предварительный просмотр virtualdub подтормаживает (периодически изображение замирает), а счётчик кадров показывает 26-32 кадров вместо положенных 25. Почему так и что делать? Тут, подозреваю, дело может касаться нехватки ресурсов, но проц вроде бы всё же недозагружен. И в режиме теста захвата ничего не замирает, хотя кадров всё равно 26.5. И вообще, какие установки захвата дуба (в частности, синхронизации звука и изображения) оптимальны при захвате DV (полученное из VHS) через firewire?
UPD: Первая проблема решилась добавлением ключа --bff. Причина оказалась в том, что все нормальные люди и программы привыкли, что в составном кадре первым по времени идёт верхнее поле, а при захвате с DV первым оказывается нижнее. Хотя, возможно, где-то для порядку следует ещё что-то в настройках поменять, чтобы при использовании фильтров проблема е вылезла снова. Вторая проблема пока не закрыта.
Исходник получен оцифровкой с VHS через canopus advc-110 при помоши того же VirtualDub, он чересстрочный. Исходник плеером играется удовлетворительно, плеер сам делает деинтерлейс.
Потом при помощи того же дуба видео было пережато кодеком x264. Использовался ключ --interlaced, чтобы видео осталось чересстрочным.
Получившееся видео дёргается, идёт как бы рывками (не так, как если быстродействия не хватает). Как на компе, так и на цифровом телевизоре (говорят, нынче у них внутри linux и весь тот же самый красноглазый софт, так что не удивительно). Однако, при покадровом просмотре тем же MPC на компе никаких чудес не выявляется, но совершенно точно изображение не такое как в динамике (например, при покадровом просмотре чёрное поле сверху стабильного размера, а при проигрывании оно пульсирует).
Пережимал примерно так:
Кто виноват и что делать?
Вторая проблема с самой оцифровкой. Почему-то предварительный просмотр virtualdub подтормаживает (периодически изображение замирает), а счётчик кадров показывает 26-32 кадров вместо положенных 25. Почему так и что делать? Тут, подозреваю, дело может касаться нехватки ресурсов, но проц вроде бы всё же недозагружен. И в режиме теста захвата ничего не замирает, хотя кадров всё равно 26.5. И вообще, какие установки захвата дуба (в частности, синхронизации звука и изображения) оптимальны при захвате DV (полученное из VHS) через firewire?
UPD: Первая проблема решилась добавлением ключа --bff. Причина оказалась в том, что все нормальные люди и программы привыкли, что в составном кадре первым по времени идёт верхнее поле, а при захвате с DV первым оказывается нижнее. Хотя, возможно, где-то для порядку следует ещё что-то в настройках поменять, чтобы при использовании фильтров проблема е вылезла снова. Вторая проблема пока не закрыта.
no subject
Date: 2014-03-08 11:59 am (UTC)no subject
Date: 2014-03-08 12:04 pm (UTC)Может например поля интерлейса инвертировались, в некоторых кодеках есть выбор какой их полей сначала.
2. Помнится во всяком продвинутом софте (в частности в BeholderTV) есть 3 варианта захвата синхросигналов для VCR…
no subject
Date: 2014-03-09 03:40 am (UTC)no subject
Date: 2014-03-10 08:44 am (UTC)no subject
Date: 2014-03-10 09:34 am (UTC)no subject
Date: 2014-03-10 09:56 am (UTC)Короче, цифре слава! Скорей бы уже....
а счётчик кадров показывает 26-32 кадров
Date: 2014-03-08 02:26 pm (UTC)Есть уверенность, что VHS-кассета была PAL?
Первичный захват производился в uncompressed rgb avi?
no subject
Date: 2014-03-09 03:37 am (UTC)no subject
Date: 2014-03-09 04:45 am (UTC)Да, это DV
А в каком формате сохранялся? какой формат получившегося исходного файла? каким кодеком пользовались?
Что пишет про исходный файл прога MediaInfo ?
И как вариант - если исходный файл проигрывается плеером нормально, то попробовать пережимать не h.264, а в DivX - как получится?
no subject
Date: 2014-03-08 04:18 pm (UTC)http://en.wikipedia.org/wiki/Telecine
сталкивался с таким на вхс. Исправить тяжело)
По поводу "дергается" - если это похоже на как-бы двоение движущихся предметов - я тоже за то, что перепутаны местами полукадры
---------------------
К сожалению, занимался этим 8 лет назад, многое забыл. Как я вижу, видео не очень хорошего качества, у меня получался нормальный просмотр только в мпег2 (если пленка была замята). При пережатии в мпег 4 уезжала синхронизация аудио и видео. Спрашивал тут, но никто ничего не ответил. Удалось найти только краткое упоминание типа "мпег2 содержит в себе мощные возможности борьбы с выпадением кадров", в чем заключается - не могу сказать, увы, не докапался. В виртуал дабе врде настройка была что-то типа - "повторять предыдущий кадр в случае дропа". Вот, боюсь, что нестабильная частота кадров может быть из-за плохого качества видео - какие-нибудь срывы кадровой синхронизации и т.п. (когда приходит шум, "похожий" на синхроимпульс)
---------------------
а не пробовали писать видео с удвоенной частотой кадров?:) Помнится, эффект был тот же самый вроде, а всяких несостыковок с этим интерлейсом меньше.
no subject
Date: 2014-03-09 03:38 am (UTC)no subject
Date: 2014-03-10 06:43 am (UTC)Давайте так, я вам выложу немного теории и моих догадок на основе полузабытого опыта, думаю, вам это сможет помочь проанализировать проблему и понять, что происходит. Прошу прощения, если отнял время, и вы это знаете.
Фактически, телевизионный сигнал состоит из полей (полукадров), которые следуют с частотой 50 штук в секунду, чередуются "верхние" и "нижние" (second, lower, even, bottom) поля (четные-нечетные строки). Поля снимаются в РАЗНЫЕ моменты времени, поэтому, если в одном кадре собрать четные и нечетные строки, то будет видна "гребенка" на изображении (http://upload.wikimedia.org/wikipedia/ru/1/11/%D0%98%D0%BD%D1%82%D0%B5%D1%80%D0%BB%D0%B5%D0%B9%D1%81%D0%B8%D0%BD%D0%B3.jpg) - нужно включать деинтерлейсинг при просмотре на компе. Деинтерлейс может делаться при помощи 1) выкидывании одного поля и растягивания изображения по вертикали (потеря частоты кадров и "условной четкости" изображения, визуально для меня сильно заметно), 2) оба поля растягиваются по вертикали, и накладываются друг на друга - мне не понравилось, потому что на кадре получается двоящееся изображение движущихся объектов, как-то мутно и подергивается.3) интеллектуальные методы, когда в кадре на неподвижных изображениях обработки не происходит (высокая четкость, присутствуют строк из обоих полей), а на движущихся частях происходит интеллектуальная обработка. Этот метод плох тем, что появлялась неестественность в изображении.
Когда вы просматриваете покадрово интерлейс-изображение в виртуалдабе, у вас складываются поля в один кадр (с гребенкой). Вы не видите ничего странного. Однако, когда выводите на телек, и у вас перепутаны местами строки в изображении (то есть, фактически перепутаны поля), может получиться вместо плавного движения, движение вида - "сильно вперед - чуть назад - сильно вперед - чуть назад".
Когда вы захватываете видео с плохого оригинала, при достаточно сильном замятии может происходить выпадение полей (это ж аналоговый сигнал, тайминги все делаются синхроимпульсами, стабильность скорости движения ленты невысока, а помеха может быть принята за синхроимпульс), то есть может получиться, что сперва идет правильная последовательность полей, а после помехи на месте четного, например, поля, оказывается нечетное.
no subject
Date: 2014-03-10 06:43 am (UTC)no subject
Date: 2014-03-10 07:30 am (UTC)Понятно, что если на плёнке попадается последовательность из большого количества запоротых кадров, то такая схема может давать сбой. Но хочется и на ёлку, и жопу не ободрать.
Соответственно, а что изменится если я поставлю первые две галочки? Можно ли сделать так, чтобы вставки/удаления кадров происходили только в особо тяжёлых случаях, а в норме всё работало как я хочу?
Что будет, если поставить галочку "do not sync"? Я ведь цифрую DV поток, а там, по идее, аудио и видео синхронно должны передаваться в лббом случае?
no subject
Date: 2014-03-10 08:17 am (UTC)По аналоговой части продолжу. В телеках стоят генераторы вертикальной и горизонтальной развертки. Стабильность телесигнала по эфиру очень высока. Генераторы синхронизируются по синхроимпульсам (они не кварцевые). Для простоты буду рассматривать только вертикальную развертку, кадры и цифры условные, с потолка (ибо все умные книги уже на даче). При приеме с эфира генераторы настрены так, чтоб не переводить луч в кинескопе на новый кадр, если частота кадров получается 49,9 кадров (полей) в секунду, и по любому перевести на новый кадр, если частота кадров получилась более 50,1 кадров (полей) в секунду. Когда включается видеовход, этот диапазон расширяется, например до 48-52 полей в секунду, чтобы скомпенсировать неравномерность движения пленки, но, я думаю, стабильность движения достаточно высока. Что мы получаем? Что в случае пропадания синхроимпульсов, частоста кадров, без первых двух чекбоксов, скорее всего будет около 48 кадров в секунду (потому что генератор будет синхронизироваться по шуму, и срабатывать по первому похожему импульсу). Однако, так как скорость движения ленты на мой взгляд все же высока, можно было бы поставить синхронизацию по _генератору_ видеозахватчика (по кварцу), а не по аналоговым синхроимпульсам (то есть, включить чекбоксы).
Resync mode - это уже раздел с более тонкой синхронизацией по продолжительности аудио-видео, по их длине. И если начисто дропнулось несколько кадров, хотя они там должны быть, будет слишком сильное рассинхронизирование. Именно это, на мой взгляд, часто происходит при пререкодировании из мпег2 в мпег4, почему - не знаю. Смотришь мпег2 - все ок, кодируешь в мпег4- звук уехал.
Далее. Мне, честно говоря, совсем непонятна концепция интерлейсд видео. В телесигнале поля-полукадры идут последовательно, и выводятся на ЭЛТ последовательно, с частотой 50 полей в секунду )
no subject
Date: 2014-03-10 08:27 am (UTC)Проверьте, может, так будет попроще с кодированием (все равно просмотр либо на компе, либо на LCD телевизоре, который по-любому моргает с частотой 50 кадров). Зато от гребенки избавитесь. Обратно собрать такие видео в интерлейсд, если приспичит, тоже можно.
no subject
Date: 2014-03-10 08:36 am (UTC)>Поэтому, следует сделать так, чтобы захватчик брал по очереди все пришедшие кадры, с какой бы частотой они не поступали
Дело в том, что синхроимпульсы в видаках пишутся на пленку )) Когда пленка замята - высока вероятность, что синхроимпульсы с видака вообще не выдаются. Как косвенное подтверждение - если есть вывод какой-нибудь OSD-инфы, стоит только отключить вывод синего фона при пропадании сигнала, геометрия символов искажается (только вот вообще не помню, это я опыты с видаком проводил, или при установке ДУ в советский телек. Извините. Слишком много пыли на моем опыте)
no subject
Date: 2014-03-08 06:10 pm (UTC)no subject
Date: 2014-03-09 03:47 am (UTC)Установки синхронизации я взял такие:
no subject
Date: 2014-03-09 04:33 am (UTC)Или вы сразу пытались получить, при захвате, avi со звуком с кассеты?
no subject
Date: 2014-03-10 07:32 am (UTC)no subject
Date: 2014-03-10 06:45 am (UTC)no subject
Date: 2014-03-10 06:49 am (UTC)да, точно.
Это вот как раз про обработку мест, где из-за замятия пленки нет изображения, захватчик пытается удержать частоту кадров в заданных границах по времени, а не по приходу якобы синхроимпулса (ложного, их-за шумов)
no subject
Date: 2014-03-10 08:30 am (UTC)no subject
Date: 2014-03-10 09:22 am (UTC)да, точно.
Это вот как раз про обработку мест, где из-за замятия пленки нет изображения, захватчик пытается удержать частоту кадров в заданных границах по времени, а не по приходу якобы синхроимпулса (ложного, их-за шумов)