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

Оригинал (7z, 3.40->6.03)
https://mega.co.nz/#!EQt21Z4Q!hBQi0KRpuonS61P04uYaTLZ7Qp9w-MXvfaEi3AizTU4
https://mega.co.nz/#!AA0gHYbR!WJzOvoFgewOYIlUqnMsvlg8hmYsIQz2_HPpjzUf7pvY
640x480
https://mega.co.nz/#!oE0zmKTa!QZb-Xls5-yTgPD_oxXxGtsOoh3jnOgskzkIqdIAK39M
320x240
https://mega.co.nz/#!QVckWLgT!z1wAUObVRCm4TLaHcTUdCpGMKg3BKBlRA8ekgPvaMiM
Для скачивания рекомендую использовать MiPony.

Уточняю, что у обработанных вариантов кодек x264 - H264/AVC encoder. В более подходящем не уверен.

 

Не представляю как это сделать через RCA-кабель. И, если честно, не очень понимаю, что мне нужно сделать.

 

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

 

СТОП!!! Таки наоборот - сначала правильно расставить флаги чересстрочности и полей, а потом уже в YV12. Это преобразование чувствительно к фактической чересстрочности и порядку чередования полей захваченного материала, чересстрочному сжатию в кодере и флагу "чересстрочный" на самом видео. Угробленный цвет уже хрен чем восстановишь.
В идеале - всю обработку делать в YUY2 и только в конце превращать в YV12.

 

Рыжий Тигра, не, видео там "Field Based" по определению - иначе бы чересстрочность удалять не нужно было.

Поэтому AssumeFrameBased() до ConvertToYV12() ставить не надо, по-моему.
Но ты прав, чересстрочность действительно нужно учитывать при преобразовании цвета:

 

По факту - да. И если б источником была непосредственно видеохваталка, то да. А в .avi'ке всё на совести декодера, который вызывается avisource()'м.

А вот тут я плаваю - какие фильтры берут характеристики потока из его атрибутов, а какие из параметров, в упор не помню, надо каждый раз смотреть доку.

А вот это уже совсем зря - цвет размазывается по вертикали уже не на пару соседних строк, а через одну, зрелище довольно мерзкое и источник цветного муара. :-(
Тем более что yadifmod() вроде бы кушает и YUY2 тоже.

 

Рыжий Тигра, вот точно, доки мне нужно было почитать, всё-таки AssumeFrameBased() и правда до ConvertToYV12() надо ставить.
Похоже, "field-based" - это не просто чересстрочный, а если кадр разделён на 2 отдельных полукадра (с половинной высотой).

Поэтому для конвертирования цвета они рекомендуют

преобразовывать именно полный кадр:

Итого, получается:

Или даже лучше (точно, yadifmod поддерживает и YV12, и YUY2):

(Interlaced=true - на случай, если исходное видео в YV12).

 

Хм. А это не одно и то же?
Или имеешь в виду - каждое поле отдельным кадром (вдвое меньшей высоты и вдвое чаще)? Тогда таки наоборот: полный кадр может быть хоть frame-based (прогрессивный), хоть field-based (чересстрочный), а если видео разбито на поля (после separatefields() - то только frame-based.

Кошмар. :-( Больше похоже на "отлитую из бронзы" ошибку в фильтрах преобразования цвета, чем на нормальную работу.
Надо пробовать. Например, слепить видеоряд из тёмно-серого фона с передвигающейся по нему светлой ярко окрашенной полосой и, гоняя разные преобразования, ловить - при каких комбинациях цветные зубчики будут наименее заметны и не вырождаться в цветную гребёнку. Я когда-то такое проделывал - реставрировал какое-то угробленное кривым чередованием кино с DVD.
И повторюсь - по-хорошему преобразование в YV12 понадобится только в самом конце перед кодированием готового продукта (и то если кодер сам не умеет это делать; XviD, например, умеет) или если позарез горит использовать фильтр, не понимающий YUY2.
PS. Ага, порылся в доке на ависинт и пробежался по forum.doom9.org и дошло: отдельный параметр у converttoXXX() - для борьбы с криворукими кодировщиками. :-(

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

Тююю, а это на кой??? Если исходник вообще в RGB, то надёжнее будет его выбросить и захватить по новой в YUY2, чем гадать о степени криворукости разработчика хваталки и ейного драйвера...

Тогда лучше вообще не трогать, а так в YV12 и работать.

 

Хм, логично.

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

Не, field-based - это именно прогрессивное видео из полукадров.
Вот здесь описана разница между полнокадровым и полукадровым потоком:

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

SeparateFields на самом деле разделяет на полукадры, а AssumeFieldBased - просто начинает считать его полукадровым.

 

Ё, точно, это я глюканул. :-( Только что проверил - таки да, ты прав, а я попутал field/frame-based с прогрессивным/чересстрочным. Впредь буду внимательнее. :-

 

Offtop

Рыжий Тигра, ты-то хоть попутал, а для меня это вообще открытием было.

 

Скриншоты из нового видео. Ссылка на само видео будет позже.

 

Видео:
https://mega.co.nz/#!QdE3CRKR!nZPz63Hv7tAUR4iuORJKTn8r0QwmMOf1wRp7ELObI9g
https://mega.co.nz/#!xF1mDBRT!ITNnRgaL9CpzYm_UwFOOwRncUNO4SzyHiZ0M6-LYcZs

 

За прошедшее время не было выявлено оптимальное решение:
- как понял, несовпадение строк решается использованием фильтра field delay перед захватом. Попытка использования других фильтров к результатам не приводит - либо картинка получается хуже, либо такое же, как и до фильтров.
- фильтры для улучшения резкости, убирания развертки и dot crawl не были выявлены. По резкости ничего выявить не удалось (уточнение - чтобы это стало примерно этим); убирание развертки дает либо Yadiff(правда, на мой взгляд, иногда косячит), либо использовать bob doubler (с опцией alternate fields) и делать ресайз после записи; с dot crawl не ясно в полной мере так как вариантов много

http://forum.videohelp.com/threads/354097-Help-with-Dot-Crawl-or-whatever-this-is
http://forum.videohelp.com/threads/342027-Hideous-dot-crawl
http://forum.doom9.org/showthread.php?t=105639
http://www.digitalfaq.com/forum/video-restore/5738-restoring-dot-crawl.html
http://home.earthlink.net/~tacosalad/video/dotcrawl.html
http://www.aquilinestudios.org/avsfilters/dotcrawl.html
http://avisynth.nl/index.php/Category:Rainbow_&_Dot_Crawl_Removal
http://www.doom9.org/index.html?/capture/chroma_artefacts.html

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

 

Не уловил - что значит "перед".
Я хватал подряд не фильтруя, потом avisymth'ом резал по соскокам полей и одни оставлял как есть, а другие сдвигал на одно поле.

Ого! Это в сыром захвате такое или это уже сглаживалка нагадила? Если в захвате - пробуй другой видеокабель: потерянная инфа о деталях картинки не восстанавливается. :-(

 

Рыжий Тигра, скриншоты из Wind Waker - не мои. Ориентируйся на мои из DK64, так как у N64 нет S-Video, в отличие от GameCube - только композит.

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

В смысле до начала захвата.

 

Без толку. Тюнеры не умеют надёжно определять первое поле, проще потом обработать уже захваченное и только там где надо.