Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток DIY доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 156
“оцифровывать его с высокой частотой простым ЦАП” - дальше читать не стал.
Стоило дочитать хотя бы до того места, где упоминается вполне доступный ЦАП:
Карта видеозахвата формата PCIe 1x на основе чипа Conexant CX2388x, как на картинке ниже. Такую карточку можно найти по запросу «карта видеозахвата 640x480» на Ozon или Aliexpress. Стоить она будет около 1700 рублей.
ЦАП не оцифровывает. Оцифровывает АЦП.
Кто-то уже нашёл за 1700 руб - поделитесь пожалуйста? За 1700 удалось встретить только на чипе Conexant fusion 878a с мостом PCIe-PCI, а она плохо подходит для оцифровки из-за неотключаемого смещения уровня под уровень чёрного и выключения АЦП во время обратного хода развёртки.
Ну ошибся человек с терминологией. С кем не бывает? Ставить теперь крест на этой великолепной статье?
А у вас всё хорошо с цветом без использования amplifyer? Кстати, кварц 40МГц даёт лучшую картину по искажениям (если не изменяет память)
UPD: а зачем вы используете флаги nld и ire0_adjust?
Без промежуточного усилителя отношение сигнала к шуму на кассете со звонком около 36дБ, а это вроде бы неплохо. Но это отношение может зависеть от магнитофона, поэтому что у разных магнитофонов разная амплитуда сигнала на тестовом контакте. Возможно, вам не повезло.
Вы пробовали 40МГц? Я попробовал заменить кварц, но у меня почему-то не завелось, и я вернул все, как было. Как я понимаю, 40МГц нужно скорее для S-VHS, а для обычного VHS хватит и стандартной частоты.
Я не использую флаг nld, потому что он пока что экспериментальный. А флаг ire0_adjust использую, потому что его настоятельно советуют разработчики. И действительно цвета становятся более приятными. В вики VHS-Decode пишут
Automatically adjust the black level on a per-field basis, using the back porch level. Unlike
--clampthis is done after time base correction. Therefore it can fix the per-field variations caused by the slight carrier shift of VHS-HQ and S-VHS. (more info)
сначала меня смутили слова про VHS-HQ и S-VHS, но потом мне обьяснили, что этот аргумент полезен для всех форматов. Обещали исправить формулировку в вики
Спасибо за ответ. У меня заработал буквально первый попавшийся китайский кварц :) Если хотите, могу скинуть ссылку на лот.
Суть предварительного усилителя не в том, чтобы увеличить отношение С/Ш (это вторично), а согласовать импедансы. Не знаю как у вас, но в моём случае видаку не очень приятно работать в нагрузку 75Ом, которую внезапно прицепили на выход, поэтому на выходе присутствуют ромбовидные артефакты... Я сперва думал что это проникновение цвета в канал яркости (но откуда ему взяться при декодировании?), потом оказалось что это типовая проблема, которая решается только установкой полноценного преда и подбором нагрузки на его стороне
В вики чётко не прописано, но с этими картами категорически не стоит использовать любые частоты дискретизации кроме частоты тактирования. Это связано с появлением отражений (aliasing)...
Для ускорения можно было сделать даунсэмплинг через SOX к 18MSps и "убрать" один бит, т.к. отношение С/Ш позволяет.
С 0ire у меня были опасения что будут видны мгновенные изменения в цветах поля. Надо будет попробовать самому... nld у вас был на скрине с графиком скорости, поэтому я про него и написал)
Наверное пока что мне не нужен другой кварц. Для целей оцифровки семейных кассет стандартной частоты хватает.
Я не сталкивался с артефактами, поэтому не могу ничего сказать о вашей ситуации. Возможно, в вашем случае действительно не обойтись без усилителя. Видел на алиэкспресс варианты, которые могут подойти.
Для ускорения можно было сделать даунсэмплинг....
Это предложение, как можно ускорить работу Decode? Уменьшить частоту дискретизации до 18МГц, а затем запустить decode с аргументом --no_resample ? Вы пробовали так делать? Это дает прирост скорости? И есть ли при этом заметная потеря качества?
... nld у вас был на скрине...
Это не мой скрин :) Под ним написано, что картинка взята из сети. Если конкретно, то это замеры одного из участников чата VHS-Decode в Discord
Вы немного не поняли части про ускорение: вы всегда захватываете с частотой дискретизации Х1 от тактирующей, а потом делаете даунсэмплинг. 40 МГц лучше не потому что полоса выше, а потому что АЦП имеет меньшие искажения (по сравнению со стоковыми 28 МГц)...
Уменьшить частоту дискретизации до 18МГц, а затем запустить decode с аргументом
--no_resample? Вы пробовали так делать? Это дает прирост скорости? И есть ли при этом заметная потеря качества?
Я думал вы читали вики 0_0. Можно даже отбросить 1 бит, т.к. 7 бит дают ДД в 42дБ, что покрывает почти все записи с VHS... Если вы цифровали архив, можно было даже использовать use_saved_levels т.к. источник записи одинаковый. Я догонял скорость на R7 3700X почти до 8fps на малом отрезке
Видел на алиэкспресс варианты, которые могут подойти.
Я на днях закажу у Гарри платы clockgen и собранный amplifyer, а то что на али, не позволит настроить сопротивление на входе...
Это не мой скрин :) Под ним написано, что картинка взята из сети
Лисичка не читатель
Вообще странно что в статье не показана работа с ld-analyse, а ведь в него необходимо залезать для правильной настройки вывода
После того, как у меня не завелся кварц на 40МГц, я не особо копал в сторону нестандартных частот. Также я не храню сырые данные, поэтому пропустил разделы про сжатие файлов. Не подумал, это может быть полезно для ускорения декодирования.
Я понимаю, что вы имеете в виду. Семплирование с частотой X1, ресемплинг из файла в файл с понижением частоты дискретизации, отбрасывание одного бита, деродирова6ние с no_resample. При этом процесс декодирования укоряется где-то в 1.5-2 раза? И видимой потери качества нет, верно?
Я на днях закажу у Гарри платы clockgen и собранный amplifyer, а то что на али, не позволит настроить сопротивление на входе...
Ох, вы находитесь в России? Если да, то можно скооперироваться с вами и заказать два усилителя?
Кстати недавно видел описание как работают РЭБ для Дронов - они сигнал модулируют частотой 32768 и это сводит с ума электронику.
Если рандомно соединять проводом два устройства 220 вольт, то кого-нибудь может убить током и оцифровка будет идти уже без вас...
не знаю за что минусуют, замечание вполне уместное, думать нужно про такие вещи. Но с конкретно видеомагнитофонами это не опасно, у них обычно корпус не заземлён и гальваническая развязка качественная.
Вас долбануло, когда вы USB-принтер к компу подключали?
Магнитофон штатно подключается к аудио-системе, которая тоже ест 220 В от соседней розетки. И к телевизору той эпохи, в котором на кинескоп вообще 25000 В подаётся. И если это всё нечаянно не заливать смузи пивом, оно нормально работает и током не шарахает.
Я 43 года занимаюсь электроникой и сжег уже достаточно техники (компьютеры, принтеры, телевизоры и пр.). Вы путаете внешние интерфейсы, которые конечно имеют гальваническую развязку и пр. защитные механизмы и припаиные сопли (даже через конденсатор за 3 рубля) ВНУТРЬ устройства, на который у вас нет достоверной информации об особенностях работы или питания. 85% что оно сгорит, может быть даже не сегодня. Надеяться что вы сделаете лучше чем это сделали в Panasonice как бы совсем наивно. Кстати магнитных головок в видеомагнитофоне как минимум 4. К какой там автор хотел подпаяться?
Я, конечно, извиняюсь за резкость. Но защиту интерфейсов бытовых устройств не стоит переоценивать. Чаще всего на штатных входах/выходах защиты нет никакой, кроме встроенных в любой усилитель паразитных диодов. Гальвано-развязка трансформатором от сети есть, и на том спасибо)))
Наверное, стоило бы добавить последовательный резистор 75 Ом, чтобы согласовать с кабелем и АЦП, и заодно помочь этим самым диодам в борьбе за выживание. Но для разового мероприятия это лишнее.
Кстати магнитных головок в видеомагнитофоне как минимум 4. К какой там автор хотел подпаяться?
Тут пишут, что к двум видео-головам после преампа и коммутатора. Сигнал со звуковой головы пишут на звуковую карту. А синхро-голова, оказывается, только самому магнитофону нужна, а при обработке - нет.
Извините, но ЧТО ВЫ НЕСЁТЕ?!!
"RF" это же ни разу не с "видео головки"! Это же "Radio Frequency"! Это самые что ни на есть "обычный" видеосигнал! Вы его спокойно можете найти на разъёме ЛЮБОГО (совершенного любого) видеомагнитофона! Это уже сигнал с головки, сто раз обработанный и преобразованный к какому-то стандарту! Иногда через двойное преобразование (смотря, что у вас за магнитофон и кто и как писал). С потерей информации, между прочим. Его же (этот бедный видео-сигнал, который вы мучаете) сначала сняли с головки, потом декодировали, преобразовали во что-то, потом промодулировали, а вы его теперь демодулируете и декодируете. Причём однозначно криво (что у вас с шумами?!) и с недостаточной полосой пропускания (т.е. мыло у вас сразу с первых шагов заложено). Куча сил угрохана с совершенно сомнительным результатом.
Есть хочется по-настоящему декодировать VHS с целью сохранить архив, то сигнал нужно брать RGB+Sync (ну, или хотя бы RGB) с разъёма SCART - и вот тогда будет картинка с минимумом искажений, которую ещё и проще всего обработать. Причём самая кривая китайская карта, которая может его оцифровывать, при записи в MPEG2 даст результат принципиально лучше того, что вы получили или можете получить.
И вы, главное, не задумайтесь, во что это всё кодировать для своего архива, и что именно происходит с interlaced видео в подавляющем большинстве кодеков, а то с таким энтузиазмом...
P.S. Ах, да. Вас там (у вас на экране) не смущает надпись про 576 строк при 25 (!!!) кадрах. Вы же, наверное, слышали, что когда очень давно, во времена VHS, телевидение работало с частотой кадров 50 или 60 герц? Всё ещё ничего не смущает?
Архивы, говорите, сохраняете? За качество боретесь? Разные варианты по качеству (!!!!) сравниваете?! Ну-ну :)))))
Вы не разобрались совсем, а наезжаете на автора... Речь не про антенный разъём, а сигнал с голов. И он RF, т.к. частоты соответствующие
Зачем?! Чтобы что? А частотная компенсация, которая у каждой головки и даже у каждого магнитофона своя? Он же её просто "от балды" пытается угадать. А обратная связь от вращения головки? Без неё можно работать, но зачем? А то, что он своим подключением ещё и поломал всю эту компенсацию и теперь восстановить нормальную картинку ( на уровне того, что магнитофон через SCART выдаёт) из этого будет практически невозможно?
А то, что он рассказывает про качество, а у него полоса недостаточная и про чередование строк он "забыл"?
Почему это полоса недостаточная?) Для VHS нужно порядка 5.5МГц, мы даже не учитываем потери при перезаписях
Чередование строк тоже на месте, в статье же 50i... Каждый кадр - это 2 поля
Вы хоть раз видели захват со свистка в MPEG2? Я видел и внезапно(!), разница с vhs decode, мягко говоря, приличная
Меня и Beholder TV H8 + iuVCS устраивает. А всякие пост-обработки на современном железе - это уже вжух! и готово.
а раньше да - дернул мышкой и рассинхрон )))
Так статья не про вас :)
Decode позволяет вытянуть "мёртвые" ленты и крайне нестабильные источники. Автор правильно написал, это не метод для сгона сотен лент (к тому же полноценной поддержки SECAM пока нет), это инструмент для оцифровки единичных архивов, обладающий максимальной гибкостью (вплоть до настройки фильтров вручную)
Для вытягивания мертвых лен нужна избыточность, а тут ей и не пахнет. Хотя софтина, наверное, позволяет, иначе просто нет смысла огород городить, тк он не лучше TBS.
...я когда-то использовал подобный подход, но у меня была более глубокая модификация видеомагнитофона, который, по сути, превращался в сканер.
Спокойствие, только спокойствие!)
Кто увидел земляную петлю с оплётки из МГТФ и так всё понял :)
А что тут такого? В полосе 5-6 МГц этот кусок провода - слону дробинка. В самом магнитофоне от головы к схеме идёт провод ещё длиннее. А тут скорее всего не с головы сигнал снят, а скорее, с предусилителя.
Гораздо важнее, что нет настоящей петли по заземлению - через провод питания. У магнитофонов, слава богу, заземление в шнуре питания не предусмотрено.
Если это в виде совета переписать, будет так?
У нас здесь аналог пассивного щупа осциллографа (впрочем, несогласованного). И по тем же причинам, по которым в щупах "крокодил" земли меняют на короткую пружину, лучше максимально уменьшить расстояние (или площадь петли) как на картинке.
(заметки по теме: rohde-schwarz, stackexchange[1][2])
Картинки
Вообще начинание-то прекрасное и прекрасно, как vhs-decode снижает стоимость качественной оцифровки. И здесь нет никакого шок-контента, от которого могли бы кадры с полями в голове перепутаться (это к началу ветки).
и кондёр зашунтировать керамикой и точно понять, что это именно та земля
и кондёр зашунтировать керамикой
Что? Мы словно с передачи RF-сигнала на импульсные БП перескочили. Там бы керамика была ultra-low-ESR/ESL дополнением к электролиту, а здесь зачем?
Как я понимаю, здесь конденсатор - это развязка по постоянному току на всякий случай. При этом закрываются глаза на согласование импедансов (=> отражения сигнала) и на поведение видеомагнитофона с этой дополнительной нагрузкой. Потому что и так неплохо работает. А если погружаются глубже, то переходят сразу к установке усилителя.
Да, вы всё правильно понимаете, в драйверах для CX карт даже есть настройка offset.
На согласование импедансов глаза не закрываются, но если оно работает - оно работает :) В моём случае в цепи обязателен пред, на котором будет подбираться нагрузка (встроенному усилителю ожидаемо не очень приятно работать в 75Ом)...
На счёт отражений, мне правильно подсказали на реддите: слишком низкие частоты и слишком малая длина линии передачи чтобы действительно были заметны эффекты от стоячих волн
ну тут работа на кабель, а у него там ёмкость и всё такое, пусть будет, всё же электролит на мегагерцах уже не очень.... но вообще это болезнь такая, если бы я припаял и вы бы мне рекомендовали его поставить, я бы понимал наверное, что некий возможно смысл в этом есть, но уже вроде всё как то стоит и работает :)
ps вспоминаю свои жалкие потуги в оцифровке - и трети не сделал, что в статье, кстати пропустил ещё - а считывать каждый кадр по несколько раз и складывать уже предлагали?:) а ещё как то хотел оцифровать статический видеосигнал с ADC stm32 начальной серии, точнее - распознавать на каком уровне меню находится девайс с видеовыходом, но не особо продвинулся....
а у него там ёмкость и всё такое, пусть будет
Мне здесь компетенций не хватает, но что-то совсем не так. Конкретному решению (поставить параллельно керамику) нужна конкретная проблема, а если опасаться чего-то неопределённого, то это плохо кончится зачем оставлять электролит?
Если опасаться чего-то неопределённого на резонансной частоте конденсатора или за ней, то это вопрос не к электролиту, а к большому номиналу, который выбрали в vhs-decode. Они советуют 10 мкФ керамикой, у которой резонанс будет на 2-4 МГц - в полосе VHS.
vhs-decode. Они советуют 10 мкФ керамикой, у которой резонанс будет на 2-4 МГц - в полосе VHS.
Хотя они же этого и добивались - 10 мкФ ради минимального импеданса на этой частоте, а не ради расширения полосы пропускания вниз?
The impedance of DC Block must be very low ... DC Blocks are usually capacitors with its self-resonant frequency near operating frequency - книжка.
многие видаки как раз были скартом оборудованы
Действительно, что ВЫ несёте? Полное непонимание происходящего как минимум :)
Судя по вот этой картинке, там действительно берут усиленный сигнал прямо с головки: https://raw.githubusercontent.com/wiki/oyvindln/vhs-decode/assets/images/graphics/Laymans-Diagrams-FM-RF-Archival-%26-Decoding-Light-Current.png
P.S. Ах, да. Вас там (у вас на экране) не смущает надпись про 576 строк при 25 (!!!) кадрах. Вы же, наверное, слышали, что когда очень давно, во времена VHS, телевидение работало с частотой кадров 50 или 60 герц? Всё ещё ничего не смущает?Архивы, говорите, сохраняете? За качество боретесь? Разные варианты по качеству (!!!!) сравниваете?! Ну-ну :)))))
25 кадров (25p), если объединять два поля, которые как раз таки идут с частотой 50 Гц (25i). А ещё... Попробуйте найти кассету из NTSC региона с частотой 60 Гц. Такого нигде нет. Есть 59.94 Гц из-за особенностей реализации NTSC. Такое отклонение еле заметно для старой аналоговой техники, а та что работала с цифрой (даже те же DVD) сразу подразумевала 59.94 Гц. Никакого 60 Гц в домашней видеоаппаратуре не было вплоть до появления Blu-ray с поддержкой HEVC (те самые Ultra HD Blu-ray).
25 кадров (25p), если объединять два поля, которые как раз таки идут с частотой 50 Гц (25i)
Всё потому что-то не знает теорию по аналоговому видео, а комментарий высрать хочется. Там и 50 к/с появятся вместо 50 полей...
NTSC и его 29.97 - это вообще отдельная история) В редакторах даже есть отдельная настройка для Drop/Non-Drop frame таймкода
Btw, логичнее будет писать 50i, всё же полей у нас 50 (хотя и 576i25 - это по сути то же самое)
Вопрос дилетанта. А если взять все эти разнообразные SDR приёмники, втыкаемые в USB качестве средства оцифровки этого самого сигнала вместо карты видеозахвата - результат каким будет? Они, вообще, справятся или по характеристикам не подойдут?
Их полосы хватает на захват Hi-Fi сигнала (декодирование Hi-Fi вроде смогли сделать быстрее realtime). Можете почитать в вики vhs decode про разные варианты АЦП
Ага. Понятно.
Но странно, что они другие варианты не пробовали. RTL-SDR -- это самый дешевый и самый паршивый вариант. Уже давно есть лишь немногим дороже но с лучшими параметрами.
Там вариантов немного, т.к. без доп. преда, 50 Ом на входе большинства АЦП сделают их по сути одинаково бесполезными)
Под эти CX чипы написан драйвер под Linux (недавно был порт на Win, но в тестовом режиме) плюс они стоят буквально копейки по сравнению с "полноценными" устройствами...
В целом никто не запрещает юзать что-то другое, просто здесь "каноничный" вариант, который обкатан и работает
так там цена такая что canopus выйдет проще и без заморочек. Плюс еще понять надо что делать с iq потоком или как получить сырой поток с АЦП
они и со звуком то мудрят нехило так https://github.com/oyvindln/vhs-decode/wiki/RTLSDR
Как уже сказали, полосы сигнала не хватает. У DVB, под которую USB-свистки заточены, полоса сигнала меньше, чем у аналогового видео с кассеты.
Второй момент - многие из этих свистков оцифровывают сигнал на промежуточной частоте, типа 10 МГц, а не от 0 Гц. Соответственно, если оцифровывать без суровых танцев с аппаратным бубном, придётся из видео-магнитофона брать сигнал с антенного выхода. А он уже точно по качеству не лучше штатного видео-выхода.
Я как-то лет 10 назад, когда учился в универе, занялся оцифровкой домашнего архива VHS
Денег у студентов конечно же нет, поэтому был выбран бюджетный вариант: куплена самая стандартная карта захвата (вроде бы от beholder), использовался её же софт для захвата видео (без компрессии), VHS магнитофон взят из дома (panasonic из 90х)
Самой большой проблемой была десинхронизация аудио и видео при захвате, получилось её побороть захватом в ASF контейнер, который сохраняет синхронизацию за счет поддержки variable frame rate VFR (метод был прочитан на каком-то форуме). Потом VFR ASF перегонялся в CFR AVI (25 кадров в секунду) через mencoder.
Минимальная обработка (убрать шумы, обрезать мусор по краям и т д) делалась через avisynth. Цель: убрать неразличимые глазом шумы, чтобы снизить размер сжатого файла, минимально улучшить картинку.
Деинтерлейсинг я в итоге не стал делать, так как ни один доступный мне тогда деинтерлейсер не показал достойное качество, все мазали картинку. Решено было сохранить оригинальную чересстрочную картинку. Её было комфортно и так смотреть, а при необходимости деинтерлейсинг всегда можно включить непосредственно в плеере
Конечный результат кодировался в x264 и сохранялся в MKV. Аудио тривиально кодировалось из несжатого CFR AVI в m4a используя ffmpeg и тоже добавлялось в MKV
Весь пайплайн был автоматизирован скриптом и выглядел как-то так: VFR ASF -> mencoder -> CFR AVI -> avisynth -> x264 -> MKV.
Запись одной кассеты занимала часа 3, последующая конвертация еще часов 10. Можно было параллелить это и одновременно записывать на одном компе и конвертировать на другом. Исходный несжатый ASF файл для трехчасовой кассеты занимал 90GB, финальный MKV 4-7 GB. Качество получалось идентично тому, что видно на экране в лайве, артефакты компрессии глазу не видны совсем.
Получился в итоге довольно интересный студенческий проект на лето, было интересно поэкспериментировать с технологиями видеозаписи и видеокомпрессии.
Тоже как-то оцифровывал подобным образом. С шестиголовочного магнитофона захватывал YPbPr сигнал бехолдером 8 (PCI-e 1x). Насколько помню, пришел также в конце концов к захвату в lossless ASF, при записи вручную подстраивал фильтры (нужно было для лучшего качества смотреть на изменение картинки), деинтерлейс делал "на лету" (из всех вариантов, доступных на сайте, был один более или менее подходящий по качеству, как мне показалось), критичной при этом была нагрузка на процессор, настройки фильтров подбирались в том числе исходя из этого. Потом конвертировал ffmpeg в x264 -crf 18. Сейчас, правда при необходимости перекодирую видео видеокартой Nvidia - это намного быстрее, качество вполне устраивает. А в начале захватывал в AVI. Видео со звуком всегда расходилось при этом, причём, насколько помню каждый раз по-разному. Даже скрипт для корректировки расхождения на пайтоне написал исходя из предположения о линейной зависимости, пока не пришёл к описанному выше варианту.
Скрипт: VirtualDub.py
#! python3.5
import bisect
import os
import re
import subprocess
import sys
import threading
import tkinter
from tkinter import ttk
import win32api
import win32com.client
import win32con
import win32console
import win32gui
import mylib
class Application(ttk.Frame):
def __init__(self, master=None):
global padx, pady
super().__init__(master)
master.title(os.path.split(sys.argv[0])[1])
master.resizable(False, False)
# Определим размер шрифта для расчета горизонтальных и вертикальных отступов
ttk.Style().configure("TLabel", font=font)
self.label = ttk.Label(self, text="0" * 2)
self.label.pack()
padx = self.label.winfo_reqwidth()
pady = self.label.winfo_reqheight()
self.label["text"] = self.label["text"][0]
padx -= self.label.winfo_reqwidth()
self.label.destroy()
del self.label
self.correction_value = tkinter.IntVar()
self.correction_value.set(1100)
self.correction_focused = None
self.sign_factor = -1
self.correction0_value = tkinter.IntVar()
self.correction0_value.set(0)
self.sign0_factor = -1
self.correction0_focused = None
self.saved_value = None
self.grid()
self.createWidgets()
def update_application_window(self):
if root.wm_state() == "withdrawn":
x = (root.winfo_screenwidth() - root.winfo_reqwidth()) // 2
y = (root.winfo_screenheight() - root.winfo_reqheight()) // 2
root.wm_geometry("+{0:d}+{1:d}".format(x, y))
root.deiconify() # Делаем видимым основное окно
for suffix in ("", "0"):
correction = getattr(self, "correction{0}".format(suffix))
correction_focused = "focus" in correction.state()
if correction_focused and not getattr(self, "correction{0}_focused".format(suffix)):
correction.select_range(0, "end")
setattr(self, "correction{0}_focused".format(suffix), correction_focused)
state = "disabled" if self.correction_value.get() == self.correction0_value.get() else "normal"
self.hour["state"] = self.minute["state"] = (state, )
self.update_idletasks()
self.update()
self.after(100, self.update_application_window)
def change_sign(self, widget):
def factor():
return "sign{0}_factor".format("0" if correction0 else "")
correction0 = self.nametowidget(widget) in (self.correction0, self.sign0_button)
setattr(self, factor(), -getattr(self, factor()))
button = getattr(self, "sign{0}_button".format("0" if correction0 else ""))
button["text"] = "-" if getattr(self, factor()) < 0 else "+"
def key_return(self, event):
if event.widget == self.run_button:
self.run()
else:
event.widget.tk_focusNext().focus()
next_widget = root.focus_get()
if next_widget == self.sign0_button:
next_widget.tk_focusNext().focus()
next_widget = root.focus_get()
if next_widget in (self.correction, self.correction0, self.hour, self.minute):
next_widget.select_range(0, "end")
def validate_correction(self, widget, data, action):
correction0 = self.nametowidget(widget) == self.correction0
value = getattr(self, "correction{0}_value".format("0" if correction0 else ""))
other_value = getattr(self, "correction{0}_value".format("" if correction0 else "0"))
entry = getattr(self, "correction{0}".format("0" if correction0 else ""))
valid = re.match(r'^\d+$', data) is not None
if action == '0':
self.saved_value = value.get()
elif action == '1':
if not valid:
try:
value.get()
except Exception:
value.set(self.saved_value)
entry.select_range(0, "end")
if data in "-+":
self.change_sign(widget)
elif data == " ":
other_value.set(value.get())
entry.select_range(0, "end")
else:
return False
return valid
def validate_time(self, widget, new_value, data, action):
def process_widget(name, max_value):
widget = getattr(self, name)
if widget.get() == '':
widget.set(self.saved_value)
widget.select_range(0, "end")
if data == "-":
widget.set(str(max(0, int(widget.get()) - 1)))
elif data == "+":
widget.set(str(min(max_value, int(widget.get()) + 1)))
if action == '0':
self.saved_value = self.nametowidget(widget).get()
return True
elif action == '1':
if widget == str(self.hour):
valid = re.match(r'^\d$', new_value) is not None
if not valid:
process_widget('hour', 9)
elif widget == str(self.minute):
valid = re.match(r'^[0-5]?\d$', new_value) is not None
if not valid:
process_widget('minute', 59)
else:
return False
return valid
def run(self, event=None):
config = """VirtualDub.audio.SetSource(1);
VirtualDub.audio.SetMode(1);
VirtualDub.audio.SetInterleave(1,500,1,0,{2});
VirtualDub.audio.SetClipMode(1,1);
VirtualDub.audio.SetConversion(0,0,0,0,1);
VirtualDub.audio.SetVolume();
VirtualDub.audio.SetCompressionWithHint(8192,48000,2,0,32000,1024,"AC3ACM");
VirtualDub.audio.EnableFilterGraph({0});
VirtualDub.video.SetInputFormat(0);
VirtualDub.video.SetOutputFormat(7);
VirtualDub.video.SetMode(0);
VirtualDub.video.SetSmartRendering(0);
VirtualDub.video.SetPreserveEmptyFrames(0);
VirtualDub.video.SetFrameRate2(0,0,1);
VirtualDub.video.SetIVTC(0, 0, 0, 0);
VirtualDub.video.SetCompression();
VirtualDub.video.filters.Clear();
VirtualDub.audio.filters.Clear();
VirtualDub.audio.filters.Add("input");
VirtualDub.audio.filters.Add("time stretch");
VirtualDub.audio.filters.Connect(0, 0, 1, 0);
VirtualDub.audio.filters.instance[1].SetDouble(0, {1:.8});
VirtualDub.audio.filters.Add("output");
VirtualDub.audio.filters.Connect(1, 0, 2, 0);
"""
try:
correction = self.sign_factor * int(self.correction.get())
except ValueError:
threading.Thread(target=mylib.MessageBox, args=('Не задана коррекция!',
win32con.MB_ICONEXCLAMATION, 5)).start()
return
try:
correction0 = self.sign0_factor * int(self.correction0.get())
except ValueError:
threading.Thread(target=mylib.MessageBox, args=('Не задана коррекция нуля!',
win32con.MB_ICONEXCLAMATION, 5)).start()
return
try:
time_span = (int(self.hour.get()) * 60 + int(self.minute.get())) * 60
except ValueError:
time_span = 0
if not time_span:
threading.Thread(target=mylib.MessageBox, args=('Не задано время!',
win32con.MB_ICONEXCLAMATION, 5)).start()
return
if not os.path.exists(PROGRAM):
threading.Thread(target=mylib.MessageBox, args=('Не обнаружен "{0}"!'.format(PROGRAM),
win32con.MB_ICONEXCLAMATION, 5)).start()
return
correction -= correction0
if not correction:
config = re.sub(r'^.*\.audio\.filters\.(?!Clear).*$', '', config, flags=re.MULTILINE).rstrip()
factor = 1.0 + correction / 1000 / time_span
with open(CONFIG_NAME, "w") as config_file:
config_file.write(config.format(1 if correction else 0, factor, correction0))
subprocess.Popen('"' + PROGRAM + '" /s "{0}"'.format(CONFIG_NAME))
self.quit()
def createWidgets(self):
self.config(padding=(padx, int(pady/4)))
style = ttk.Style()
style.configure("TLabel", font=font)
style.configure("TButton", font=font)
style.configure("C.TButton", font=font, foreground="red")
style.configure("TCombobox", font=font)
style.configure("TRadiobutton", font=font)
root.bind('<Key-Return>', self.key_return)
root.bind('<Control-Key-Return>', self.run)
row = 0
self.header = ttk.Label(self, text="Задай коррекцию и время")
self.header.grid(row=row, column=0, columnspan=4)
row += 1
self.correction_label = ttk.Label(self, text="Коррекция(ms)*:")
self.correction_label.grid(row=row, column=0, sticky="e")
self.clear_button = ttk.Button(self, text="C", width=1, style="C.TButton")
self.clear_button["command"] = lambda:self.correction_value.set(0)
self.clear_button.grid(row=row, column=1)
self.sign_button = ttk.Button(self, text="-", width=1)
self.sign_button["command"] = (self.register(self.change_sign), self.sign_button)
self.sign_button.grid(row=row, column=2)
self.correction = ttk.Entry(self, width=5, textvariable=self.correction_value, validate="key",
validatecommand=(self.register(self.validate_correction), '%W', '%S', '%d'))
self.correction.grid(row=row, column=3)
self.correction.focus()
row += 1
self.correction0_label = ttk.Label(self, text="Коррекция нуля(ms)*:")
self.correction0_label.grid(row=row, column=0, columnspan=2, sticky="e")
self.sign0_button = ttk.Button(self, text="-", width=1)
self.sign0_button["command"] = (self.register(self.change_sign), self.sign0_button)
self.sign0_button.grid(row=row, column=2)
self.correction0 = ttk.Entry(self, width=5, textvariable=self.correction0_value, validate="key",
validatecommand=(self.register(self.validate_correction), '%W', '%S', '%d'))
self.correction0.grid(row=row, column=3)
row += 1
self.time_label = ttk.Label(self, text="Время(h:mm):")
self.time_label.grid(row=row, column=0, sticky="e")
self.hour = ttk.Combobox(self, width=1, validate="key",
validatecommand=(self.register(self.validate_time), '%W', '%P', '%S', '%d'))
self.hour["values"] = list(map(lambda x:"{0}".format(x), range(10)))
self.hour.current(0)
self.hour.grid(row=row, column=1)
self.sc1 = ttk.Label(self, text=":")
self.sc1.grid(row=row, column=2)
self.minute = ttk.Combobox(self, width=2, validate="key",
validatecommand=(self.register(self.validate_time), '%W', '%P', '%S', '%d'))
self.minute["values"] = list(map(lambda x:"{0:>02}".format(x*5), range(12)))
self.minute.current(10)
self.minute.grid(row=row, column=3)
row += 1
self.space_label = ttk.Label(self, text="*Space-копировать")
self.space_label.grid(row=row, column=0, sticky="w")
self.run_button = ttk.Button(self, text="Запуск", width=8, command=self.run)
self.run_button.grid(row=row, column=1, columnspan=3, pady=int(pady/4))
self.after(100, self.update_application_window)
if __name__ == "__main__":
FOLDER = os.path.split(sys.argv[0])[0]
PROGRAM = os.path.join(FOLDER, "VirtualDub.exe")
CONFIG_NAME = os.path.join(FOLDER, "config.vcf")
MONIKER = r"winmgmts:{impersonationLevel=impersonate}!\\.\root\cimv2"
SCRIPT_TITLE = os.path.split(sys.argv[0])[1]
keep_output = False
COMSPEC = os.getenv("comspec")
if COMSPEC: # Проверим на запуск в режиме сохраниеия вывода после завершения
parent_process_moniker = (MONIKER + ":Win32_Process.Handle=" + str(os.getppid()))
try:
for i in range(2):
parent_process = win32com.client.GetObject(parent_process_moniker)
keep_output += re.match('("?)' + COMSPEC.replace("\\", "\\\\").replace(".", "\\.") + '\\1\s+/[ck]\s+',
parent_process.CommandLine, re.IGNORECASE) is not None
parent_process_moniker = (MONIKER + ":Win32_Process.Handle=" + str(parent_process.ParentProcessId))
except Exception:
pass
finally:
parent_process = None
main_hwnd = win32console.GetConsoleWindow()
if main_hwnd:
if win32api.GetConsoleTitle() != SCRIPT_TITLE:
win32api.SetConsoleTitle(SCRIPT_TITLE)
if not keep_output:
win32gui.ShowWindow(main_hwnd, win32con.SW_HIDE)
root = tkinter.Tk()
root.withdraw() # Скроем основное окно до прорисовки точно в центре экрана (делаем видимым методом update_application_window)
# Важно! Шрифт моноширинный
font_sizes = [(0, 8), (480, 10), (864, 12)]
font = ("Lucida Console", font_sizes[bisect.bisect(font_sizes,
(root.winfo_screenheight(), float("inf"))) - 1][1], "normal")
app = Application(master=root)
app.mainloop()
try:
root.destroy()
except tkinter.TclError:
passА в начале захватывал в AVI. Видео со звуком всегда расходилось при этом, причём, насколько помню каждый раз по-разному. Даже скрипт для корректировки расхождения на пайтоне написал исходя из предположения о линейной зависимости, пока не пришёл к описанному выше варианту.
Да, я тоже пробовал аналогично корректировать рассинхрон, но такой линейный подход работал не всегда. В конце концов выяснил, что рассинхрон вызывали две независимые причины: (1) разные частоты аудио и видео; (2) дропы кадров, когда видеопоток прерывался
И если с (1) линейная подгонка работала хорошо, то с (2) вообще никак не помогала.
ой, ой а я в MJPEG захватывал
Еще остались неразмагниченные кассеты?
Я работал с кассетами, которые содержат записи 1997-2006 года. Все кроме одной живы и здоровы
Зависит от качества носителя и условий хранения. Тут вот товарищ, например, пишет, что не запись, а сам носитель может разваливаться в прах.
Сейчас для долговременного хранения данных в ЦОД и архивах, на сколько я знаю, пользуются стриммерами, как и 50 лет назад - той же магнитной записью на плёнке. И на HDD в общем та же магнитная запись, и, если производитель не косячит, данные десятками лет хранятся без проблем.
Прикольная идея! Эх, ее бы мне увидеть лет 6 назад. Была у меня Электроника 590, развандаленная аффинажниками. Механика вся была на месте, а плат не было. И хотелось прочитать видеозапись с катушки. Для этого попытался подкинуть туда кишки от vhs, там форматы записи почти похожи. Но подружить их так и не вышло. А с этой программой могло бы и получиться.
Кстати, интересный вопрос: как она разбирает сигнал на кадры? Если начало/конец строки можно вытащить из сигнала с БВГ, то кадровые синхроимпульсы идут с отдельной головки (объединенной со звуковой).
Там не кадровая а синхронизирующая
Не нужно придираться к терминологии без причины. Везде, в т.ч. и в википедии, пишут - кадровая.
Вдоль нижнего края ленты записывается управляющая дорожка[6], содержащая кадровые синхроимпульсы[8]
Тем более если знать, что то, что передается с частотой 50 Гц - это поле, при чересстрочной развертке кадр состоит из двух полей, четного и нечетного. Соответственно, кадры идут с частотой 25 Гц.
А что там пишут и не дай Б-г модерируют на википедии давно уже всем известно.
Там вообще то ссылка на журнал "Радио" за 1987 год. То есть, вы хотите сказать, что в журнале в 1987 году писали и модерировали неправильно?
Не вижу тут никаких факапов. Скорее тут у вас факап. Вы решили доколупаться до слов, но не вывезли. В английском варианте написано ровно то же самое, воспользуйтесь переводчиком.
pulses that mark the beginning of every frame of video
Да нет, все то же самое. Воспользуйтесь переводчиком. Импульс, который обозначает начало каждого кадра - это (внезапно!) кадровый синхроимпульс.
Ну, суть в том, что он не один такой. Для телевизора есть синхронизация в самом видеосигнале на наклонных дорожках - как строчный HBLANK остаётся на месте, так и кадровый VBLANK.
Оффтоп: сейчас странновато смотреть, как в аналоге хранили невидимые части кадра, но тогда это была хорошая идея и в них потом дополнительную информацию пихали. Субтитры, телетекст, мини-настроечная таблица (ITU-T J.63), метаданные на LD...
строчный HBLANK остаётся на месте, так и кадровый VBLANK.
Это гасящие импульсы. Не путайте их с синхронизирующими.
как она разбирает сигнал на кадры?
На наклонных дорожках остаётся информация для этого (VBLANK, кадровый гасящий импульс). Теоретически её могли бы выкинуть для экономии места, но субтитры, защита Macrovision и стоп-кадр сообщают, что (все?) невидимые строки на месте.
Такая экономия места (8-9%) ещё бы Hi-Fi Stereo сломала, если подумать.
Но какие-то из невидимых строк должны быть сильно зашумлены в момент смены головок (head switching noise). Вот в книжке пишут, что пришлось постараться, чтобы дорожка Hi-Fi Stereo не щёлкала 50-60 раз в секунду.
Эээ...
Берём хороший бу живой магнитон типа JVC HM‑DH40 000U, который имеет выход Component (то есть три провода для трех каналов цвета — яркость и две цветоразностные)
Берём карту захвата с компонентом типа Intensity
Пихаем компонент сигнал в комп
На стороне компа захватываем видеопоток в RAW без сжатия и без субдискретизации, можно в RGB
Полученное сырьё реставрируем, цветокорим по вектороскопам/осциллоскопам чтобы вправить моск цветам как было. Доп обработка по вкусу, можно нейросетями и/или апскейлом
Жмём в что‑нибудь с большим битрейтом или вообще в Loseless типа ProRes
Если всё правильно сделать, качество будет максимальное, в прямом смысле: мы здесь на каждом этапе теряем минимум информации.
Опционально можно всё или часть делать за один присест, если не гнать этот пайплайн через софт для монтажа, а сразу пропускать и синхронизировать RAW картинку через софт для видеомикширования (не буду показывать пальцем на Tesseract :) )
Тогда сразу будет захватываться готовый результат.
Аналоговый шум надо убирать
Аналоговый шум алгоритмы сжатия видно часто воспринимают как детали картинки и пытаются их сохранить, выкидывая настоящие детали. В итоге к аналоговому шуму добавляется мыло и/или файл получается больше. Потому что оно искренне пытается сохранить каждую мурашку.
Поэтому шумы лучше убирать (если не писать в RAW конечно). По этой же причине стоит 10 раз подумать, прежде чем добавлять художественный шум в видео, которое заливается в соц сети и телеграмы, где царит низкий битрейт.
Упоротый вариант — подцепить АЦП к головке магнитофона. Но это, кхм, сопряжено некоторыми небольшими сложностями :)
Прочитайте вывод статьи. Я и не настаиваю на том, что это лучший метод. Ваш вариант вполне рабочий. Единственное, в чем VHS-Decode явно лучше других методов - это качество TBC (смотрите второе видео в статье). Ну и цена конечно.
Наверное с точки зрения эффективности разумно было использовать хороший магнитофон и хорошую карту захвата как основной инструмент для оцифровки, а VHS-Decode как вариант для плохо сохранившихся кассет, которые встречаются не так часто.
Да не будет у него лучше качество TBS, а на тянутых лентах даже хуже. Тк и то, и другое происходит в реальном времени, но интегрированный TBS работает в плотной связке с другими системами видеомагнитофона.
Я не отрицаю такой подход более того сам в свое время подобное проворачивал, правда не для VHS, и не в реальном времени, и не только из-за проблем с производительностью. Смысл был в том, чтобы по сути сканировать плёнку, с большой избыточностью. Частота вращения барабана была постоянная и синхронизированная АЦП. А подача плёнки управлялась программно, по мере необходимости.
Более чем согласен. Но имхо это как из орбитального ядерного лазера по воробьям. Если воробей какой‑то особенный то норм, но в общем случае не надо :)
много быстродействующих АЦП на 8–12 разрядов (до сотни МГц сэмплирования)
Есть подозрение, что для качества этого мало, и надо не менее 1 ГГц. А так да.
Для годноты можно ещё в FPGA параллельно завести питание через отдельный АЦП, чтобы если вдруг (ну вдруг) по нему наводятся помехи, то алгоритмы обработки были в курсе и могли через пару обработок вычесть из полезного сигнала.
Берём карту захвата с компонентом типа Intensity
В обычных(начиная с гибридных, я так цеплялся к Beholder-T8) тв-тюнерах компонентные входы тоже встречались, включая поддержку RGB захвата.
Компонентный выход у магнитофона.
Гораздо качественнее композита, где всё по одному проводу
Если принимать это безусловно, можно оцифровку лазердиска испортить. Для него композит - родной формат и наилучший демодулятор вряд ли окажется в старом проигрывателе (а не на стороне приёмника сигнала - т.е. в карте захвата или софте ld-decode).
В случае VHS родной формат на кассете похож на S-Video (цветность отделена от яркости и впихнута в полосу частот под яркостью - т.н. color-under) и компонентный выход (S-Video или YPbPr) позволит избежать лишнего объединения-разделения цветности и яркости, но ЕМНИП, люди не видели однозначного улучшения - полосы частот так порезаны при записи, что заметные артефакты от разделения не возникают.
В S-VHS расширили полосу яркости, в композите она стала явно пересекаться с цветностью (=> артефакты разделения) и поэтому в видаки с поддержкой S-VHS добавили S-Video.
YPbPr в этот видак поставили ради цифрового D-VHS*, HD-сигналу которого есть что терять и который не имел преступных связей с композитом. Ну и ради цифровой обработки (TBC, DNR), то есть ему бы вообще цифровой выход иметь, раз он всё через цифру прогоняет.
Аналоговый шум надо убирать
Сохранять плёночное зерно в 4K сейчас считается нормальным, а тут разрешение в 30 раз меньше и хранить шум слишком дорого? Нет, если шум маскирует нехватку деталей (улучшает субъективное качество), то пусть остаётся. Для видеохостингов SD-видео апскейлят, чтобы заставить их поднять битрейт (потому что это единственный переключатель качества со стороны пользователя, кнопки "576p/480p High Bitrate" у него нет).
Упоротый вариант — подцепить АЦП к головке магнитофона. Но это, кхм, сопряжено некоторыми небольшими сложностями :)
Вся статья про это - в видеомагнитофон залезли настолько глубоко, насколько есть смысл (предусилителю и штуке, которая сигналы с чередующихся головок объединяет, можно и довериться). Залезли в эту точку, получается:
* Это видак 3-в-1 (VHS, S-VHS, D-VHS) и он до сих пор тыщу долларов стоит.
Для видеохостингов SD-видео апскейлят, чтобы заставить их поднять битрейт (потому что это единственный переключатель качества со стороны пользователя, кнопки "576p/480p High Bitrate" у него нет).
Абсолютно точно, именно для этого я в своё время доработал возможность апскейла в фильтры захвата и стрима. Жалко, что многие люди этот приём не используют.
Сохранять плёночное зерно в 4K сейчас считается нормальным, а тут разрешение в 30 раз меньше и хранить шум слишком дорого?
Дело не в дорого, можно, в конце концов, хранить/стримить в loseless или вообще в RAW. PNG/EXR сиквенсы + WAV рулят :)
Дело в том, что этот шум будет отжирать на себя часть битрейта. Ну то есть, грубо говоря, из 100% битрейта 50% уходит на шум. Если битрейт большой вследствие апскейла, 10/16/100500-битности или просто что его большим поставили — да, это допустимо, потому что полезная информация поместится в оставшуюся часть битрейта.
Но часто битрейта не хватает — и я про этот случай. Поголовно люди такие: «О, 576 строк, значит достаточно 480p/720p». И из этого шума вырастает ушатанное пережатое мыло.
если шум маскирует нехватку деталей (улучшает субъективное качество), то пусть остаётся.
Согласен. Но тогда нужно, чтобы этот шум сохранился.
Плёнка есть прогрессивная развёртка. А VHS — это чересстрочка. Которой на стримминговых сервисах и прочих воблачках нет. Поэтому изначальный труъ‑ламповый шум улетает как минимум в деинтерлейсер, который уже превратит его в непойми что. Особенно это касается деинтерлейсеров по оптическому потоку.
Поэтому, если уж заморачиваться, то:
Оцифровываем RAW
Измеряем и сохраняем спектр шума по яркости и цветоразностным (причём в каждом кадре отдельно)
Удаляем шум максимально качественно алгоритмом, способным жрать чересстрочку
Деинтерлейсим качественно
Апскейлим какой‑нибудь хорошей штукой до 4K/8K/16K
На основе ранее запечатлённого спектра генерируем шум яркости и цветоразностных заново. Можно крупный (чтобы пропорционально соотноситься с «пикселями» исходной картинки), можно помельче
YPbPr в этот видак поставили ради цифрового D-VHS*, HD-сигналу которого есть что терять и который не имел преступных связей с композитом. Ну и ради цифровой обработки (TBC, DNR), то есть ему бы вообще цифровой выход иметь, раз он всё через цифру прогоняет.
С одной стороны да, с другой — у нас на том конце провода висит карта захвата, которая тоже может вносить свои косяки. И с компонентом их огрести менее вероятно.
Можно вообще попробовать три карты захвата SVideo для каждого компонента — будет три отдельных АЦП и, по идее, будет вкусно. Но надо тестить, потому что не всё так просто.
но ЕМНИП, люди не видели однозначного улучшения - полосы частот так порезаны при записи, что заметные артефакты от разделения не возникают.
Ну моя идея не в том, что это однозначно улучшит качество, а в том, что при этом мы с меньшей вероятностью потеряем информацию, и даже если она не видна для глаза, она может стать важна для каких‑нибудь алгоритмов обработки, которые мы применим дальше в конвейере.
в конце концов, хранить/стримить в loseless или вообще в RAW. PNG/EXR сиквенсы + WAV рулят :)
Если оставить в YCbCr, то цветность проредить можно будет (хотя бы по горизонтали для чересстрочного). 4:2:2 уменьшит битрейт в полтора раза, 4:1:1 - в два раза, передовым lossless-сжатием для видео вроде остаётся FFV1 в 2 прохода (уменьшит битрейт ещё чуть больше двух раз).
Ну моя идея не в том, что это однозначно улучшит качество, а в том, что при этом мы с меньшей вероятностью потеряем информацию, и даже если она не видна для глаза, она может стать важна для каких‑нибудь алгоритмов обработки, которые мы применим дальше в конвейере.
На кашу из топора похоже - выбрали аппарат по наличию компонентного выхода (польза для VHS туманна), получили в целом качественный аппарат с TBC (польза очевидна), использовали компонентный выход (раз уж есть, то тупо не использовать*), а проверять гипотезы насчёт композита в конце этого длинного пути уже никому не захочется.
* принцип не работает с лазердисками
в видеомагнитофон залезли настолько глубоко, насколько есть смысл (предусилителю и штуке, которая сигналы с чередующихся головок объединяет, можно и довериться)
Нет, некоторые считают, что кроличья нора должна быть глубже.
"2. tapping RF off of pickup rather than internal RF test point (avoids 90s era amplification circuitry)" - forum.lddb (это про аналогичный проект с лазердисками).
Так и делаем... И ещё есть пару своих секретов 😊👍
Из моего опыта - самое главное - это как можно раньше оцифровать видеокассеты. Они деградируют очень быстро. И самой большой проблемой было частое и внезапное загрязнение головок сыпящеся кассетой. Приходилось держать корпус видеомагнитофона открытым для быстрой очистки головок и контролировать изображение на мониторе постоянно. И ещё порадовал "керамический" конденсатор на фото.
Цифровал как-то, используя видеомагнитофон который был и купленную юсб карту захвата.
С учетом того качества с каким снят материал карта захвата давала примерно тот-же результат как при просмотре с магнитофона сразу на тв. Я решил что мне этого достаточно, и даже так размер файлов был не маленький.
Куда больше проблемой стали маленькие кассеты VHS для камеры со стандартной шириной пленки. Для них был адаптер позволяющих вставить их в обычный видеомагнитофон. Но бОльшую часть таких кассет так и не удалось воспроизвести.
Достал камеру - одну кассету воспроизводит неплохо, другу совсем никак. Гугл и Яндекс дяли понять что технология настолько старая что все форумы давно вымерли и информации очень мало, но удалость найти что в некоторых моделях проседали стойки позиционирующие пленку. В итоге так и случилось - стойки были запрессованы в алюминиевый сплав и со временем стали в нем почти свободно двигаться. Закрепил стойки и удалось отрегулировать сначала под одну кассету потом под другую.
Так что проблема может появится там где ее не ждешь.
Имхо можно было просто штатно захватить картой Conexant CX2388x в ASF и пережать в MKV с сохранением черезстрочной развертки.
Можно. Но качество будет невысокое.
MKV — это контейнер, а не кодек. В него не пережимают.
Скорее всего подразумевается какой‑нибудь H264 (маловероятно что H263) с дефолтным битрейтом, ключевыми кадрами и прочими настройками. В любом случае, шумная картинка через композит с двойным пережатием — это не круто. И АЦП в плате интересно какой стоит.
Я предпочитаю ничего не продполагать, т.к. в голову незнакомому человеку уж точно не залезешь, и что там он имел ввиду, возможно, даже он сам не знает, раз путает понятия кодека и контейнера.
Вот вы правильно оговорились про дефолтный битрейт. У многих кодеков кроме битрейта есть ещё куча параметров, которые влияют как на соотношение размер/качество, так и на скорость обработки.
Подразумевалось:
1. ASF - захват таким образом, чтобы исключить рассинхронизацию звука и видео. Контейнер ASF это умеет по умолчанию. При наличии тюнеров BeholdTV, GoTV есть другие возможности в их софте.
1.1. Кодек выбираем под дальнейшую обработку. Я предпочитал MJPEG или Huffyuv codec.
1.2 Обработка в VirtualDub и фреймсервером в кодировщик с сохранением интерлейса либо с удвоением частоты кадров.
2. MKV - контейнер понимаемый большинством современных телевизоров, поэтому внутри скорее всего будет кодек x264. Но скорее всего в картинке и объеме разницы не будет, если сжать в интрелейсный mpeg2
Вопрос дилетанта. На ленте видео и звук физически же записаны синхронно и читаться с отставанием/опережением ну никак не могут. Почему не получается сохранить в синхронном виде и приходится "шаманить"? Существующие форматы хранения аудио не позволяют так сделать? Нет никаких меток, что данный фрагмент соответствует 01:15:24.125 исходника, т. е. информация просто теряется при записи?
Так таймер же у нас есть на обоих устройствах. Через час записи и устройство захвата видео и устройство захвата видео имеют точную информацию, что данный фрагмент соответствует таймингу 01:00:00.000.
Спасибо. Беглый гуглеж показал что " В среднем, типичные часы реального времени могут иметь погрешность от 1,7 до 8,6 секунд в день.". Не ожидал, что все настолько плохо. Электронные наручные часы конца прошлого века обеспечивали лучшую точность. Непонятно почему не берут системное время синхронизируемое по NTP в этом случае.
Я всё равно не понимаю, чего вы привязались к ЧРВ
Это не я привязался. Это живой человек (и судя по всему не только он, а все кто оцифровкой занимаются) вручную в конечном счете именно что привязываются к реальному времени, а не плавающим частотам резонаторов на различных устройствах.
Сигнал при оцифровке получает свою шкалу времени в виде сэмплов и после этого сохраняется в цифровом эквиваленте с ней
А реальное время оказывается нужно для синхронизации потоков, но просто теряется. В статье прямо здоровенный раздел "Подробнее о сведении аудио и видео" где в частности написано:
По завершении захвата требуется запустить следующий скрипт, сохраняющий время, когда началась запись аудио и видео в файл time.txt. Эта информация пригодится далее для сведения дорожек.
Почему в 2025 году это реализуется какими-то костылями скриптами, а не сохраняется прямо в файле с дорожкой? Странно. И сведение в этом случае будет выполняться автоматом.
P. S. На всякий случай дисклеймер. Понятно, что претензии не к Вам лично. Не Вы эти форматы изобретали. Спасибо за отличное описание реального положения дел.
Я сталкивался с подобной задачей, когда делал софт обработки видео в реалтайме. В нём по всему графу текут видеоаудио кадры — картинка (один полный кадр или два полукадра) + кусок звука. Это для того, чтобы внутри софта не ловить рассинхрон ни при каких обстоятельствах — видео и звук железобетонно прикручены друг к другу.
И прикол с тем, что, например, 48 000 нацело не делится на, например, 29,9999 я осознал далеко не сразу. Решил так.
У меня была разработана штука, умеющая преобразовывать разрешение, чересстрочность, частоту кадров, форму пикселей картинки, дискретизацию, число каналов и частоту звука из произвольных величин в другие произвольные величины. Причём настройки можно менять на лету. Сделана она не для синхронизации, а просто чтобы можно было жрать потоки разных форматов и преобразовывать их в один. И выводить тоже в любых форматах
И есть у этой штуки важная настройка — скорость воспроизведения. По факту это вещественный коэффициент, на который она делит частоту выходных кадров. То есть, если у нас частота выходных кадров 30, а скорость воспроизведения 0.5, то она будет работать так, как будто частота выходных кадров 60 — то есть будет плодить доп кадры.
Промежуточные кадры строятся либо выборкой, либо через прозрачность, но по желанию туда можно вставлять свои модули с какими‑нибудь оптическими потоками.
Так вот. Она обнаруживает погрешность при остатке от деления на входных и выходных параметрах — что дискретизация звука нацело не делится на частоту кадров, и считает накопление этой ошибки. Далее в зависимости от настроек, она может:
Медленно повышать/понижать коэффциент скорости воспроизведения видео (с очень большим демпингом и инертностью)
Просто ждать пока накопится ошибка на 1 целый кадр и дропает или дублирует его, в зависимости от того, какой режим выставлен
Просто считывать несколько дополнительных сэмплов звука или наоборот, забывать их считать
В любом случае, она стремится плавно сократить ошибку погрешности до 0.
Хранит оно 1, от силы 2 предыдущих кадра, поэтом задержка потока получается минимальной.
Ну, по факту оно примерно так и делает, правда без промежуточного преобразования: мы просто на выходе сэмплируем входной звук с кубической/линейной выборкой по вещественному номеру сэмпла. Типа как текстуры на видеокарте сэмплируются по вещественным координатам, только в одномерном варианте.
Засада в том, что у выходного формата тоже бывает частота дискретизации, не делящаяся нацело на частоту кадров. Поэтому ошибку всё равно приходится учитывать, копить и потом что‑то с ней делать.
Говорят, в старые времена, были такие железки/программы, которые выбрасывали нераскодированные кадры из финального видеопотока. Бац - и на ровном месте рассинхрон на 1/60..50 секунды. А если запись само по себе шумная, то таких может быть много.
Кстати, как дело с такими кадрами обстоит сейчас?
Коррекция кривой яркости — VHS-Decode экспортирует видео с диапазоном яркости 16-235. Это телевизионный стандарт, который может неправильно отображаться в некоторых видеоплеерах. Поэтому зачастую требуется исправить контраст, растянув яркость на полный диапазон 0-255.
Нет, делать так не стоит.
TV диапазон является стандартом по умолчанию (обычно в потоке он не указывается) и корректно отображается всеми плеерами (растягивая его до полного при конвертации в RGB).
PC диапазон крайне редко поддерживается плеерами и только при условии его указания в потоке.
Судя по разнице в контрастности между скриншотом из редактора и сравнительными скриншотами ниже - ваше закодированное в PC диапазоне видео воспринимается как видео в TV диапазоне вашим плеером (из которого делали скриншоты).
Также не затронут вопрос апскейла и Rec. 601 vs Rec 709. Цветовое пространство обычно не указывается в потоке (а если и указано, то большинством плееров игнорируется) и в плеерах прописана логика: если разрешение HD (обычно высота >= 720), то используй 709, иначе - 601. В итоге если бездумно увеличить разрешение видео, то цвета могут изменится (разница небольшая, но она есть).
Я не знаю какие плееры вы используете, но у меня всё популярное спокойно понимает SD и с full levels и с rec.709. Некоторое время назад видел тесты (притом старые) плееров и там бОльшая часть спокойно читает теги, в т.ч. встроенный в Win. Все проблемы на воспроизведении - от отсутствия зашитых тегов. Имеет смысл экспортировать в rec. 601, но Resolve такой возможности не даёт
При установке тега на limited range вы не можете гарантировать отсутствие жёсткого клиппинга на обоих концах диапазона, т.к. формат убогий и яркость спокойно может плавать (в т.ч. опускаться ниже "чёрного")... Ручное выставление уровней спасает от этой проблемы.
Аппаратные (тв, приставки), мобильные.
При значениях вне диапазона встречал баг с переполнением (белый >235 отображается как черный), поэтому значения лучше ограничить, да, это 1 фильтром делается.
О каком "жестком клиппинге" речь? Значения ниже 16 в ограниченном диапазоне имеют такой же смысл как значения меньше 0 в полном - никакого.
разница небольшая, но она есть
Дополню:
Анимация ошибки при выборе матричных коэффициентах для YUV=>RGB (601 или 709)
# Avisynth+
im_path = "5754835e29ae57e03ae04a7020ab94e1.png"
src = ImageSource(im_path, end=0)
src = src.LanczosResize(src.Width()/2, src.Height()/2)
# 601 interpreted as 709
a = src.ConvertToYUV444(matrix="PC.601").ConvertToRGB24(matrix="PC.709")
# 709 interpreted as 601
b = src.ConvertToYUV444(matrix="PC.709").ConvertToRGB24(matrix="PC.601")
Interleave(
\ a.Subtitle("601 interpreted as 709", size=48)
\ , src.Subtitle("Source", size=48, align=8)
\ , b.Subtitle("709 interpreted as 601", size=48, align=9)
\ , src.Subtitle("Source", size=48, align=8)
\).AssumeFPS(0.75)ffmpeg -i wrong_matrix.avs -plays 0 -y out.apng
Посмотрите пожалуйста на стоп-кадры для Canopus. Кажется, там как раз такая ошибка, из-за чего картинка зеленит
Как я понимаю, получилась бы ошибка в невозможную сторону:
синий уходит в зелёный, если HD-видео ошибочно перевести в RGB как SD-видео
и в невозможном месте:
нет преобразования в RGB - нет места для ошибки, а оно происходит лишь на этапе воспроизведения видео (не в карте захвата).
То есть цвета сильнее плывут по другим причинам и соблюдение правила "601-коэффициенты для SD-видео и 709-коэффициенты для HD-видео" в данном случае это педантичность. Нам оставили в наследство два неудобства:
поменяли без нужды коэффициенты в стандарте на HD-видео
не сделали YUV в видео чисто внутренней деталью реализации (вот JPEG использует коэффициенты из BT.601, но это и не важно)
Но это небольшие проблемы, при цветокоррекции видео меняют сильнее.
Ну, сигнал-то, наверное, не совсем с головы, а хотя-бы с предусилителя. А так вообще интересно. Есть ведь много применений для голого АЦП со скоростью 28 MSPS.
А чем принципиально отличается сигнал с головы от сигнала со штатного видео-выхода магнитофона? Видак - это же тупое аналоговое устройство, там же нет мозгов для обработки картинки. Ведь даже синхросигнал, которым магнитофон синхронизирует движение ленты и вращение головы - вы теряете при таком способе.
Попробую ответить за автора: прелесть метода заключается в независимости от порой ужасной внутренней обработки сигнала (люди, без шуток, годами ищут "тот самый" видак с лучшей картинкой). У меня был JVC из 7ХХХ линейки (с набортным LTBC) который жутко мылил. Сейчас такие начинаются от 16-18к на вторичке :) Тут же есть контроль почти над всем процессом, за который отвечает внутрянка магнитофона...
Если не изменяет память, для определения начала кадра используется сам VBI, а сигнал переключения головок применяется только с сетапом с общим тактированием (clockgen mod). При всём этом, сервосистема магнитофона работает в абсолютно штатном режиме, поэтому мы и можем без особых проблем взять сигнал после предварительного усилителя
А разве на композитный видео-выход не передаётся сигнал прямо с ленты + синхро-импульсы? Линейную обработку усилителей магнитофона ведь можно в каких-то пределах скомпенсировать и в цифре потом. Ну, клиппинг - понятно, что нельзя)
Или всё-таки магнитофон как-то в пост-обработке миксует яркость с цветностью и необратимо всё портит?
Конечно нет) Там внутри куча обработки, в т.ч. улучшайзеры, шумоподавители, лимиттеры и компенсатор выпадений. В большинстве магнитофонов происходит ещё и смешение яркости с цветностью для получения композитного сигнала на выходе (несмотря на то что запись Y/C компонент раздельна, с разными поднесущими)
Синхроимпульсы начала кадра вообще хранятся на линейной дорожке с краю ленты
Да, прям интересно. Я-то больше со звуком работал, но и там улучшайзеры в бытовой аппаратуре всегда были, и их тоже обходить не всегда получалось. Ясно. В общем всё похоже.
компенсатор выпадений
А это что такое?
У меня тоже "основное" хобби - это звук) Там в каком-то смысле проще
Компенсатор выпадений позволяет заменить/маскировать строки с выпадениями (обычно видны как пролетающие по строке точки/линии или линии целиком без полезного сигнала)
заменить/маскировать строки с выпадениями
Ну, это уже более сложный девайс, наверное. Ему же нужно предыдущую хорошую строку где-то запомнить. Хотя, если для декодирования цвета уже стоит линия задержки, то, может быть, и не супер-сложно это.
Там в каком-то смысле проще
Лимитер и шумодав - да, принципиально не обойти. Но вот АРУ - теоретически можно, но, мля, в реальности - только вручную в пост-обработке получалось. В видео-то АРУ тоже есть, но привязывается к уровню синхросигналов, и как-раз проще всё выходит.
К сожалению (для самодельщиков) там высокая степень интеграции. У меня получилось на одном магнитофоне вывести Y/C компоненты до входа в смеситель
На счёт АРУ вы заблуждаетесь, он работает в пределах строки и срабатывает при превышении верхней границы. У меня есть желание попробовать написать avisynth плагин для устранения шлейфов (как и у компрессора в аудио, тут есть условный "release" из-за чего сигнал ослабляется ещё некоторое время после срабатывания)
Ему же нужно предыдущую хорошую строку где-то запомнить
Поэтому во всех видеомагнитофонах стоит линия задержки. Если идёт выпадение (оно детектируется по падению уровня того самого RF сигнала), то вместо текущей строки берётся выход линии задержки.
Вопрос к автору , как вы думаете зачем в касетном магнитофоне в усилителе куча корректирующих цепей изменяющих ачх ? Как это связано с током подмагничивания ? Почему нельзя скопировать с кассеты на касету на повышенной скажем в 3 раза скорости ? Теперь про видео , сколько считывающих головок в видеомагнитофоне ? С какой из них вы сняли видеосигнал ? А конденсатор последовательно с индуктивностью случайно ачх не искажает ? А точно от ёмкости конденсатора и индуктивности ничего не зависит ? Как насчёт согласования входного сопротивления ? А можно конденсатор керамический , чтоб от температуры плыл ? Зачем в магнитофоне линия задержки на кварцевой пластине не подскажите ?
Ну это какой-то лютый перфекционизм. Я помню, что ещё во времена XP и четвёртого пня нормально оцифровал несколько видеокассет, подключив свой видак Панасоник к PCI ТВ-тюнеру Beholder 507. Потом ещё что-то цифровал, обновив комп до 4-ядерного Phenom II, а систему до Win7. И качество результата вполне радовало. Четвёртый пень на 3 ГГц отлично тянул такую оцифровку, как и захват эфира телеканалов. Инженеры, делавшие ТВ-тюнер и ПО к нему, отлично поработали. Небольшая проблемка только была выбрать правильный кодек, так как только с одним получалось видео разумного объёма, все остальные доступные для выбора выдавали видеофайл чрезмерно огромного объёма, или отказывались работать.
Это та же история, как с оцифровкой фотоплёнок. Всё думал - вот, придётся нести плёнки в фотолабу, там, наверное, закажу с оцифровкой в максимальном качестве, но дорого блин... А потом ко мне попал старый планшетный сканер HP G2710 со слайд-модулем, я нашёл инструкцию как выжать из него максимальное качество оцифровки плёнки, попробовал - и увидел, что лучше и не надо: сама любительская плёнка из 90-х, залапанная пальцами, и работавшая в дешёвой "мыльнице", лимитирует качество куда сильнее чем возможности сканера. И то, что оцифрованная фотка в итоге получается около 3 мегапикселей (примерно), не проблема. Если бы я получил тот же скан в 40 мегапикселей, не дало бы никаких новых деталей из-за того, что сам исходник слишком беден на детали.
Так же и с кассетами. Надо ли оно: Ради улучшенного на 5...10% качества картинки и звука столько движений. Ладно там если надо оцифровать потерянный концерт какой-нибудь легенды, выжав всё что можно, но бытовые кассеты писались на дешёвые бытовые VHS-камеры, вряд ли там будет разница.
Но концепт такой оцифровки интересный.
HP G2710
А он не бьёт картинку на квадратики? Я пробовал отсканировать свои фотографии на трёх разных сканерах HP, но все три делили картинку на квадратики с выкидыванием нескольких пикселей изображения на стыках этих квадратиков. Очень сильно бросается в глаза на съезжающих из-за этого диагональных линиях
А что думаете про оцифровку с помощью miroStudio DC10+? Цифровал много кассет - вроде качество вполне приличное.
я цифровал экзотическим вариантом - через mini-dv видеокамеру (sony trv) с незакрытым входом, firewire (dv плата) на компьютере, софт по усмотрению, камера бралась как не новая, но работала, потом съёмка сломалась, но она мне и не очень нужна была. Пытался оцифровывать архив vhs-c, снятый ранее на видеокамеру Panasonic. Качество нормальное выходило, вполне. Secam (то бишь "наши" записи с телеэфира) не оцифруешь, только PAL. Самое муторное что процесс требует постоянного присутствия на месте для контроля, какие бы вы методы не применяли. Мне больше всего понравился данный метод, хотя я пробовал цифровать и через исходную камеру (композит/s-vhs---> тв-тюнер/плата захвата) и через видеомагнитофон тоже на тв-тюнер или "плату захвата" (применял адаптер vhs-c под "большую кассету"). Но само качество записей хромает так как многие сделаны были в LP-режиме, для экономии кассет, они тогда стоили тоже недешево (2005г и далее). До этого я пытался разобрать ещё одну сломанную mini-dv камеру, но рабочую в части электроники и сделать из неё "оцифровщик", но не получилось пока, надо с какой-нибудь электроникой связывать. Кстати на авито иногда встречаются так называемые "медицинские" s-vhs видеомагнитофоны, они наверное хорошую картинку выводят ?
А никто не пытался брать туже самую карту и видак S-VHS и цифровать через S-Video (ну или просто что-то из комбайнов DVD+VHS с выходом S-Video)? Разница существенная будет чем через композит?
Если настоящий SVIDEO-видеовыход в видеомагнитофоне, то разница с композитом будет огромная. У композита есть гадкие эффекты, ради чего и был придумано разделять отдельно цвет и яркость с синхроимпульсами. Вот пример как композит портит картинку - https://rumlin.narod.ru/svideo_vs_composite.htm
Просто не раз налетал на информацию, что на VHS кассете простой запись на пленке уже со смешанным сигналом идет и якобы от того, что условно композит разделяют на компонент проку мало. И гоняться за SVHS видаками в качестве источников, если исходник в простом VHSе проку мало. Просто живых примеров в РФ что-то не встречается, чтоб кто-то провернул данную процедуру.
VHS - это не композитный формат, поэтому пропуск смешения яркости/цветности приведёт к потенциальному уменьшению артефактов.
Особенно это актуально для исходников с камкордеров, так как там RGB с матриц(ы) пишется на ленту как Y/C сигнал...
Для записей с композита, действительно, Y/C выход почти не добавит никакого прироста в "качестве"
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
VHS-Decode — новый метод оцифровки видео