Hard Боремся с чересстрочной развёрткой

Nubilius, просто поставь в VirtualDub'e фильтр "Video > Filters > Add > deinterlace" и настрой так:


С данным видео этого будет достаточно.
upd. Ой, извиняюсь, лучше так, а то частота кадров будет 50.


Но в этом случае не будет видно мерцания персонажа при попадании в него.

 

Ideagen, не позорься, ОК? Подучи принципы работы телевидения хотя бы.

Nubilius, ща докачается - гляну.

---------- Сообщение добавлено 28.02.2014 в 00:34 ---------- Предыдущее сообщение размещено 27.02.2014 в 23:40 ----------

Рассмотрел. Исходно было 320*240 и 50 кадр/cек, его можно восстановить. Ависинтом - вот так:

Код:

AVISource("fami_test.avi")
assumetff()
separatefields()
spline64resize( width()/2, height() )

- будет красивое плавное движение, а уменьшение размера заодно неплохо почистит картинку от шумов видеозахвата. (В одном месте - с 00:08.120 до 00:09.040 - на герое мерцает шляпа, это не глюк захвата, а глюк самой приставки.)
Если плавность не горит - можно смело делать 25 кадр/с: в конец скрипта добавить

Код:

selecteven()

Увеличивать размер картинки сверх 320*240 я б не стал - красивее не будет, а файл раздуется.
Широкие вертикальные сине-зелёные полосы - результат захвата с антенного или композитного (RCA) выхода. Если есть возможность, попробуй подключиться через S-Video, цветуха будет почище.

---------- Сообщение добавлено в 00:38 ---------- Предыдущее сообщение размещено в 00:34 ----------

Да, ещё одно. Если приставка позволяет гнать на видеовыход тестовую таблицу или просто мелкую сетку - этой фишкой можно воспользоваться чтобы точно угадать количество линий развёртки. Типовых значений в телевидении всего два - 480 и 576, но чем чёрт не шутит. :-

 

Рыжий Тигра, да вряд ли там будет что-то отличное от 480 или 576. Тип сигнала, PAL или NTSC, покажет программное обеспечение захвата. Если исходник 240 строк и на выходе 480 (NTSC) - это вообще идеальная ситуация, т.к. масштабирование происходит в этом случае с простым удвоением, то есть кратно без пересчёта, и можно смело сжимать вдвое без всяческих потерь, при этом даже сохранив каждый полукадр-240 как полный кадр, не уходя от частоты 59,94. Расчёска исчезнет сама, деинтерлейс не понадобится. В случае PAL уже сложнее, потому что масштабирование 240 строк на 288/576 не кратное. Хотя тоже можно так же попробовать.

---------- Сообщение добавлено в 03:05 ---------- Предыдущее сообщение размещено в 02:57 ----------

А, пропустил вот это:

Вполне вероятно, что при этой исходной частоте сигнал всё-таки PAL. Ведь растянуть 240 строк на 288 - это, наверное, меньший геморрой, чем подгонять 50 Гц под NTSC. Однако при обратном программном сжатии 288 в 240 результат качества может оказаться и нежеланным, поэтому лучше уж на компе оставить 288. Чтобы знать точно, нужно определить через тюнер тип сигнала.

 

Val07og,
Рыжий Тигра,
спасибо большое, вечером попробую обязательно.

А как удалось узнать разрешение и параметры исходника?

P.S. В конце своего пути видео всё-равно попадёт на ютуб, как часть видео с общим разрешением 1280х720, причем мне показалось, что ютуб всегда снижает частоту до 25 кадров, вне зависимости от того, с какой частотой и кодеком идёт заливаемое видео. По крайней мере, у всех скачанных с ютуба видео частота 25 кадров. Эх.

Это один из двух famiclon'ов, так что я не знаю, если у них бывают какие-то встроенные режимы тестирования - то я с удовольствием)

 

Сейчас несколько подряд посмотрел (скачанных) — есть и 23.97, и 25, и 29.97, и 30.

 

Забавно. Значит мне так везло.

Увы, там только RCA и антена. Тут запись с RCA.
Звук писал переходником с RCA на 3.5 miniJack, причем похоже недоткнул да и уровень сигнала надо было снизить.

 

По идее, должно быть вот так (каждое поле сохранено как отдельный кадр, частота 50к/с): https://dl.dropboxusercontent.com/u/28284862/222.avi (12 Мб). А что из этого сделает ютуб — ну в любом случае всё перепортит...

---------- Сообщение добавлено в 09:43 ---------- Предыдущее сообщение размещено в 09:41 ----------

Хотя в видимом кадре здесь как раз 240(480) строк.

 

первый способ верней, для сохранения всех катров, так как входил сигнал с частотой 50.
можно и второй вариант, но только если нужно видео с урезанной частотой до 25.

У меня высшее образование в сфере телевидения, но дело не в этом, а в итоговом решении, к которому приводят имеющиеся знания. К чему мне расписывать все формулы и разжовывать все дасконально, если можно указать на конечный результат.
Да, способов много, но как я понял, дело в реал-тайме. И скажи, где я не прав. Я предложил варианты для сохранения частоты 25, можно пойти и путём удвоения чатоты, так сохранятся все кадры, и более "гладким" будет видео, но не думаю, что это надо. Видео полюбому надо маштабировать в обратной последовательности, можно добавить кропинг, чтобы получить в итоге 320*240. Удаление четных или нечетных строк приведёт к частоте 25. Маштабирование своим алгоритмом само уничтожит то или другое, по "оптическому предпочтению", так сказать, хотя это не совсем верный взгляд на вещи. Действуешь либо так, либо эдак, результат один - видео с частотой 25 кадров. Но если удалять четные или нечетные строки, картинка останится в том же размере 720*576. Действовать нужно по предпочтениям.
Способов куча, но принцип один, или сохраняешь частоту 25, тогда надо избавлятся от четных или нечетных строк, или переводишь в принимаемую, то бишь 50, тогда нужно разделять четные и нечетные строки в отдельные последовательно-идущие кадры, как предложил Val07og в начале.

Если есть возможность переключить режим ТВ на NTSC, то будет ещё лучше, не появятся черные бордеры, будет только гребенка (и той можно лешиться, если захватывать видео с частотой 59,94к/с, только при переводе в 29,97, один фиг идалятся либо четные, либо нечетные кадры, аналогично как и строки). Останется только отмаштабировать видео с 640*480 до 320*240 без фильтра интерполяции.

 

Во-во-во. Я это как раз и проделал.

Увы, это не NTSC - кадров в секунду честных 25. Но строк не 576, но при 480 строках картинка выглядит вроде бы гармонично... В общем, пока навскидку трудно сказать.

Хм. Ты не в курсе. Видеосигнал передаётся последовательно по строкам. Сжать/растянуть по горизонтали - просто: хоть при передаче гнать на выход содержимое ячеек памяти чуть быстрее/медленнее, хоть при захвате "раскладывать" принятое по ячейкам чуть быстрее/медленнее.
А вот с количеством строк - капец. :-( Единственное, что могут хоть приставка, хоть тюнер, - это или выбрасывать каждую N-ю строку, если нужно меньше чем есть, или удваивать каждую N-ю, если нужно больше. Надо пробовать и мерять. :-(

Просто рассмотрел захват покадрово при увеличении. На статичных кадрах видно, что каждый пиксел игровой картинки занимает 2*2 пиксела захваченного видео, отсюда размеры. На равномерных пробежках хорошо заметно (после assumetff() и
separatefields(), что (a) картинка не прыгает вверх-вниз, т.е. разрешение по вертикали удвоено; (b) фон движется плавно, cдвоенных кадров нет, т.е. разрешение "по времени" тоже натуральное.

Тем более - надо по максимуму вытянуть сейчас, при захвате.

Я по приставкам не спец. :-(
Нужна мелкая сетка. Если нет теста - годится любой мелкоячеистый фон из любой игры, заставки, чего угодно. Если на телевизоре фон выглядит равномерным, а на захваченном видео сквозь сетку проглядывают более "гладкие" удвоенные (или слипшиеся из-за выброшенной между ними) строки (ну, словно из ткани нитку выдернули) - значит, разрешение по вертикали при захвате угадано неверно.

Ага. А внутрь корпуса заглянуть можешь? Рядом с выходом RCA на плате вполне может быть гнездо (или контактные площадки) раздельно яркости, цвета, синхронизации и прочего; опытный телемастер вполне может впаяться туда и сделать S-Video.

---------- Сообщение добавлено в 11:26 ---------- Предыдущее сообщение размещено в 10:51 ----------

Позволь усомниться...

Во-первых: "черезстрочная развертка" в телевидении - это примерно как "композитор Бах!" в музыке. :-( А "гребёнка" - уже как "композитор Бабах!". :-((((((
Далее, ты почему-то старательно избегаешь слова "поле" или хотя бы "полукадр". Не криминал, но для "высшего образования в сфере телевидения" странно не намекнуть собеседнику, что телесигнал передаётся полями, а не целыми кадрами, - будет куда понятнее, чем объяснять про чётные и нечётные строки.

Да и для любого вуза: "не уж толь", "в двое" "в большенстве DVD-декодерах", "оригенальный", "маштабировать", "лешиться", "дасконально" - сразу видно, сколько книг человек за время учёбы прочитал. В т.ч., ясен перец, и по заявляемой специальности. :-(

Например, тут:

- на самом деле NTSC видео всегда 29.97 кадр/с, а то, что ты назвал, это 24-кадровое кино, закрученное в NTSC-видео (это называется "telecine").
Как делается обратная операция ("inverse telecine", или IVTC) - ты тоже не знаешь. :-(
Прочие ляпы можно не разбирать? :-

---------- Сообщение добавлено в 12:04 ---------- Предыдущее сообщение размещено в 11:26 ----------

Кстати, обнаружил интересную штуку.
На длинной пробежке (на захвате это кадры 166 тире 209) заметно, что шаг "гребёнки" нестабильный: на примерно каждом пятом кадре (170, 175, ... 195, 197, 202, 207) он вдвое меньше, чем на остальных.
Получается, что приставка генерирует где-то 90 полей в секунду, затем каждое 9-е поле удваивается, а из получившихся 100 полей выводится каждое второе. Т.о., собственно генератор картинки в NTSC- и PAL-версиях приставки идентичен, а отличаются они только дообработкой последовательности полей; в NTSC-устройстве должно, соответственно, выводиться просто каждое третье поле.
Скорее всего, я тут "открыл америку", но раньше я этого не знал и нигде в литературе не встречал. Дарю - вдруг на что-то пригодится.

---------- Сообщение добавлено в 12:23 ---------- Предыдущее сообщение размещено в 12:04 ----------

За звук я вчера провтыкал посмотреть. Да, перепор конкрэээтный - на глаз этак децибел на 20; если дружишь с паяльником - лучше сделай делитель из пары резюков, скажем, 1 и 10 кОм и подавай звук через него. Или, если приставка позволяет регулировать громкость, подбери уровень на ней.
А 96 кГц дискретизации - откровенное пижонство. :-) В оригинале было вряд ли больше 11.

А тут ХЗ: ТВ редко использует стереосигнал, так что, похоже, в левом канале просто мусор.

 

Рыжий Тигра, нет, я в курсе. Ты меня недопонял, я совсем не имел в виду горизонтальное разрешение. Строго говоря, в аналоговых источниках сигнала каждая строка уже как бы и не дискретна, и её можно раскладывать по горизонтали на пиксели как душе угодно. Другое дело, что разрешающая способность волны конечна, поэтому обычно считается, что предел для строки - 720 пикселей по горизонтали. По этому принципу построена и запись MPEG2 в системе PAL на DVD-видео, 720х576.

А всё, что я отмечал ПЕРЕД этим, касалось исключительно взаимоотношения дискретных строк и, следовательно, вертикального разрешения, а не горизонтального.

 

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

 

Попробовал вариант, предложенный Val07og (плюс сразу же сжимая в h264 с помощью x264vfw) - вроде получается нормально (42 МБ, без звука). Я так понимаю, Рыжий Тигра, предлагаешь по смыслу аналогичное?

https://mega.co.nz/#!gU01RA4I!DixK5lwBPT27i1AeCUFQNDSXSxgC6yNx_gmISDWQRPI
http://yadi.sk/d/mXg7RJX6Ji2Ye

Проблема следующая: если захватывать изначально "без потерь" (пробовал Huffyuv с разными настройками) - у меня похоже слишком слабый комп (хард?) для такого испытания, появляются местами "рывки" в видео, если записывать более минуты. Хотя можно попробовать кодек, который шел с DosBox, если его можно подрубить к VirtualDub - тот без потерь даже на не самой мощной мышинке записывал без проблем.

 

На медленный винт как раз не похоже - тогда рывки были бы раз по 10 на минуте.
Проверь (a) нагрузку на проц: если заметно больше половины - пробуй другой кодек (я, например, предпочитаю ArithYUV); (b) не крутится ли у тебя в это время что-ньдь лазящее к винту (антивирус, ослик, торрент, м.б. сосед по сетке что-ньдь с твоего винта тырит); (ц) должно хватать ОЗУ, чтобы система не лазила поминутно в своп; (d) если разделов несколько - складируй захваченное на самый внешний, там и скорость побольше, и головкам в случае чего летать за свопом или там системными библиотеками будет не так далеко и надолго...
И, ясен перец, весьма не помешает дефрагментация свободного пространства.

Э... я не в курсе, мне тоже может пригодиться. Что за кодек, как зовут, где можно скачать?

---------- Сообщение добавлено в 17:15 ---------- Предыдущее сообщение размещено в 17:05 ----------

Плохая идея: AVI с H.264 по жизни не дружит. Скачал, в плеере наблюдаю мельтешение цветных пятен (декодер - ffdshow), в виртуалдабе просто чёрный экран... :-(

 

Рыжий Тигра, вообще вариант, попробую другой кодек. На фоне вроде никакой активности нет (антивиръ отключаю перед захватом, как и сеть, так что сосед тоже исключается), но процессор при кодировании видео напрягается сильно, точнее не скажу, причем вне зависимости от кодека (Intel Core 2 Duo E4500, пробовал x264vfw и Huffyuv), в своп тоже не должно падать поидее, памяти 2 Гб (DDR2). Винт в NTFS, там вроде нет резона дефрагментацию насильно делать...

Насчет h264 и черного экрана/мельтешения - хм. Я в систему кодеков и декодеров отдельно сейчас не ставлю, устанавливают только плеер MPC-HC. И не последняя причина, почему я кодирую именно в него: черт знает почему, но в видеоредакторе именно в этом формате файлы (и этим уровнем сжатия) обрабатываются быстрее всего. Т.е., когда в редакторе я нарезаю файлики, минимальный тормоза на передвижении и построении превью именно на нём. Забавный такой факт...

Глянул файлы, захваченный DosBox'ом - кодек зовётся ZMBV (Zip Motion-Block Video), в папке Tools самого DosBox лежат DLL'ки zmbv.dll и zmbv64.dll, а так же inf-файлики. Попробовал установить - в списке VirtualDub появился. Позже посмотрю, как там с эффективностью и тормозами. С удивлением кстати обнаружил, что запись видео в DosBox идёт в 70 FPS в файле о_О Вот это поворот!

 

Есть-есть. NTFS хорошо балансирует дерево каталогов, но самостоятельно обеспечить перетаскивание крупных кусков данных с места на место она не в силах.

Всё равно проверь. Вплоть до полного запрета свопа на предмет "свалится - не свалится".

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

(мрачно) И максимальные искажения при перепаковке. :-(

Ага, сенькс, гляну. Заодно обновлю dosbox, у меня достаточно древний 0.74.

Кстати, ещё один источник напрягов - то, что картинка всё-таки сильно интерлейсная. Обычно при кодировании считаются различия с соседними строками, а они немаленькие. Ищи в настройках кодеков галочку "чересстрочное видео", это тонкий намёк как раз на кодирование полей по отдельности, а не всего кадра гамузом.

 

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

 

Да вроде норм. Глянь ради интереса видяши мои на ютубе, там (ну кроме последнего, 13го выпуска, да, там я косяк дверной) вроде никаких явных артефактов не видно. Я уровень сжатия низким держу. Может скорость обработки ещё от контейнера зависит, но тем не менее.

Большое спасибо за кучу советов, всё попробую и проверю в воскресенье.

---------- Сообщение добавлено в 22:51 ---------- Предыдущее сообщение размещено в 22:47 ----------

Кстати, на тему MJPG. Я игрушки современные и рабочий стол захватываю с помощью Bandicam. Так вот, разница между кодированием в MPEG-1 и Motion JPEG визуально заметна. Второй больше идёт квадратами и что-то не то с оттенками цветов о_О Я не знаю как точнее описать, надо будет тоже захватить и выложить демку. Ну разница в размерах была эпичная.

 

Nubilius, странно, на 2 ГГц HuffYUV даже с "best" сжатием спокойно тянет 25 к/с 720x576.
Кстати, версия кодека какая - если 2.2.0, то его кто-то уже после автора допиливал, попробуй Посмотреть вложение HuffYUV_v2.1.1.rar - может, лучше будет работать.

И ещё покрути настройки буферизации для записи ("Capture" > "Disk I/O..." > размер и количество буферов) - если диск медленный, может помочь.

 

Потерьный. :-( Раз MJPG, два MJPG... после пятой перепаковки уже со всех мультперсонажей надо сбривать "волосатые" артефакты. :-(((((

:-))))))))))))
(продышавшись) Небось и монитор "циферный", жидкокристаллуевый? :-)))))

Да не должно, сколько там того контейнера - два-три сложения на кадр... :-

http://avisynth.org.ru/docs/english/externalfilters/colormatrix.htm ?

 

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

Плюс опытным путём проверил одну теорию) В общем, если хочется сохранить идеальное качество, то для видеоредактора VideoPad подойдёт такой вариант:

1) пережимаем видео в h264 (lossless оригиналы не удаляем!)
2) монтируем всё как надо
3) сносим к чертям h264-файлы и открываем проект. Редактор на старте завопит "куды всё поделалось?!" - подаём на вход уже оригинальные файлы и производим финальный рендер. Лишнее промежуточное звено устранено. Правда разницы на глаз я всё-равно не вижу. Мда.