Comments 141
“оцифровывать его с высокой частотой простым ЦАП” - дальше читать не стал.
Стоило дочитать хотя бы до того места, где упоминается вполне доступный ЦАП:
Карта видеозахвата формата 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Ом)...
На счёт отражений, мне правильно подсказали на реддите: слишком низкие частоты и слишком малая длина линии передачи чтобы действительно были заметны эффекты от стоячих волн
Действительно, что ВЫ несёте? Полное непонимание происходящего как минимум :)
Судя по вот этой картинке, там действительно берут усиленный сигнал прямо с головки: 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) вообще никак не помогала.
Еще остались неразмагниченные кассеты?
Я работал с кассетами, которые содержат записи 1997-2006 года. Все кроме одной живы и здоровы
Зависит от качества носителя и условий хранения. Тут вот товарищ, например, пишет, что не запись, а сам носитель может разваливаться в прах.
Сейчас для долговременного хранения данных в ЦОД и архивах, на сколько я знаю, пользуются стриммерами, как и 50 лет назад - той же магнитной записью на плёнке. И на HDD в общем та же магнитная запись, и, если производитель не косячит, данные десятками лет хранятся без проблем.
Прикольная идея! Эх, ее бы мне увидеть лет 6 назад. Была у меня Электроника 590, развандаленная аффинажниками. Механика вся была на месте, а плат не было. И хотелось прочитать видеозапись с катушки. Для этого попытался подкинуть туда кишки от vhs, там форматы записи почти похожи. Но подружить их так и не вышло. А с этой программой могло бы и получиться.
Кстати, интересный вопрос: как она разбирает сигнал на кадры? Если начало/конец строки можно вытащить из сигнала с БВГ, то кадровые синхроимпульсы идут с отдельной головки (объединенной со звуковой).
Там не кадровая а синхронизирующая т.н. "трекинг". Причем 25 Гц. Смещение фазы этой частоты приводит к смешению траектории описываемой видеоголовками на ленте. А на саму голову пишется полноценный видеосигнал в FM кодировании со всеми служебными интервалами, поэтому он и называется RF. Разве что цветность может транскодироваться в другой формат (часто видеомагнитофон пишет всегда только в PAL или NTSC, но принимает любой, даже SECAM). Причем, так как головы 2 а обхват чуть более 180 градусов, то они работают по очереди, коммутатор находится непосредственно рядом с трансформатором БВГ вместе с усилителем. Технически, в статье снимают сигнал не с самой головы а после коммутатора-усилителя.
Там не кадровая а синхронизирующая
Не нужно придираться к терминологии без причины. Везде, в т.ч. и в википедии, пишут - кадровая.
Вдоль нижнего края ленты записывается управляющая дорожка[6], содержащая кадровые синхроимпульсы[8]
Тем более если знать, что то, что передается с частотой 50 Гц - это поле, при чересстрочной развертке кадр состоит из двух полей, четного и нечетного. Соответственно, кадры идут с частотой 25 Гц.
Ещё раз: это не кадровая. Но она вынуждена быть таковой, потому что 1 проход 1 головы это одно поле. 2 прохода 2 голов это как раз 2 поля или 1 оборот барабана - 1 кадр черезстрочной развёртки. И эта синхронизация лишь частично-косвенно используется для восстановления настоящей кадровой синхронизации. Вот RPM БВГ как раз настоящая кадровая частота. И она держится стабильной даже при стоп-кадре, когда синхрочастота равна 0. Если бы бвло как пишут на этой вашей википедии то стопкадр был бы в принципе невозможен.
А что там пишут и не дай Б-г модерируют на википедии давно уже всем известно.
А что там пишут и не дай Б-г модерируют на википедии давно уже всем известно.
Там вообще то ссылка на журнал "Радио" за 1987 год. То есть, вы хотите сказать, что в журнале в 1987 году писали и модерировали неправильно?
При всём авторитете журнала Радио (и моём личном уважении к нему) даже в нём бывают факапы. Если бы вы его читали как я, то знали бы про постоянную рубрику "По следам публикаций". Вон, ниже уточнили, что в ангельском разделе вики написано правильно.
Не вижу тут никаких факапов. Скорее тут у вас факап. Вы решили доколупаться до слов, но не вывезли. В английском варианте написано ровно то же самое, воспользуйтесь переводчиком.
А давайте.
Another linear control track at the tape's lower edge holds pulses that mark the beginning of every frame of video; these are used to fine-tune the tape speed during playback, so that the high speed rotating heads remained exactly on their helical tracks rather than somewhere between two adjacent tracks (known as "tracking"). Since good tracking depends on precise distances between the rotating drum and the fixed control/audio head reading the linear tracks, which usually varies by a couple of micrometers between machines due to manufacturing tolerances, most VCRs offer tracking adjustment, either manual or automatic, to correct such mismatches.
Ну и? Где кадровая? Есть только "метка начала кадра". И при этом указано, для чего она там. Ещё раз: как возможен стопкадр или поиск вперёд/назад? Ну, как, если кадровая записана только в синхродороге?
pulses that mark the beginning of every frame of video
Это что, по вашему? Смотрю в книгу, вижу фигу?
Метка != синхроимпульс. Ниже вам написал. Смиритесь уже вы, не вывозите вы в техчасть да что с того то? А про стопкадр и поиск вы так и не ответили.
A control track is a track that runs along an outside edge of a standard analog videotape (including VHS). The control track encodes a series of pulses, each pulse corresponding to the beginning of each frame. This allows the video tape player to synchronize its scan speed and tape speed to the speed of the recording. Thus, the recorded control track defines the speed of playback (e.g. SP, LP, EP, etc.), and it is also what drives the relative counter clock that most VCRs have.
Вот вам ещё про истинное назначение синхродороги. Заметьте - ни слова про видеосигнал!
Что за бред вы несете. Синхроимпульс - он везде синхроимпульс. Если он начал выполнять другую функцию, он не перестал от этого быть синхроимпульсом.
Верно, но есть нюанс что именно он синхронизирует. Позицию головы на дорожке или луч кинескопа в телевизоре. Подумайте над этим на досуге.
The control track is used to fine-tune the tape speed during playback, so that the high speed rotating heads remained exactly on their helical tracks rather than somewhere between two adjacent tracks (known as "tracking"). Since good tracking depends on precise distances between the rotating drum and the fixed control/audio head reading the linear tracks, which usually varies by a couple of micrometers between machines due to manufacturing tolerances, most VCRs offer tracking adjustment, either manual or automatic, to correct such mismatches.
pulses that mark the beginning of every frame of video
Да нет, все то же самое. Воспользуйтесь переводчиком. Импульс, который обозначает начало каждого кадра - это (внезапно!) кадровый синхроимпульс.
Ещё раз, чисто для вас:
Each of the diagonal-angled tracks is a complete TV picture field, lasting 1⁄60 of a second (1⁄50 on PAL) on the display. One tape head records an entire picture field. The adjacent track, recorded by the second tape head, is another 1⁄60 or 1⁄50 of a second TV picture field, and so on. Thus one complete head rotation records an entire NTSC or PAL frame of two fields.
Видеоголова пишем весь кадр целиком, со всеми синхроимпульсами. Точка. Синхродорога пишет сигнал, внезапно, синхронизации БВГ к этим дорожкам. Смиритесь уже с этим.
Ну, суть в том, что он не один такой. Для телевизора есть синхронизация в самом видеосигнале на наклонных дорожках - как строчный HBLANK остаётся на месте, так и кадровый VBLANK.
Оффтоп: сейчас странновато смотреть, как в аналоге хранили невидимые части кадра, но тогда это была хорошая идея и в них потом дополнительную информацию пихали. Субтитры, телетекст, мини-настроечная таблица (ITU-T J.63), метаданные на LD...
строчный HBLANK остаётся на месте, так и кадровый VBLANK.
Это гасящие импульсы. Не путайте их с синхронизирующими.
Вот это точнее. По синхродороге весь ЛПМ подстраивается под записанный контент, прямо как дисковод под отформатированный диск: скорость протягивания для правильного звука и фаза поворота БВГ для правильного трекинга (это фаза переключения между головами и продольное, по отношению к ленте, смещение "сканирования" головами нанесённых дорожек). При записи видеомагнитофон всё делает по внутренним опорным генераторам, подпёртыми кварцевыми резонаторами, а при воспроизведении полностью опирается на сигнал с ленты, сравнивая с эталоном только частоту синхросигнала для получения правильной высоты звука. Физически же при этом отклонение движения ленты может быть даже заметным на глаз - полоса ФАПЧ мотора капстана (тонвала) достаточно широкая. Я в бытность ремонта помню модифицировал свой ВМ12 так, что 3 часовая кассета вмещала 4 часа. При этом он без проблем воспроизводил и записи с других магнитофонов.
как она разбирает сигнал на кадры?
На наклонных дорожках остаётся информация для этого (VBLANK, кадровый гасящий импульс). Теоретически её могли бы выкинуть для экономии места, но субтитры, защита Macrovision и стоп-кадр сообщают, что (все?) невидимые строки на месте.
Ничего там не выкинуто, всё в наличии. Немного модифицировано, чтобы влезать в модуляцию, только и всего.
Такая экономия места (8-9%) ещё бы Hi-Fi Stereo сломала, если подумать.
Но какие-то из невидимых строк должны быть сильно зашумлены в момент смены головок (head switching noise). Вот в книжке пишут, что пришлось постараться, чтобы дорожка Hi-Fi Stereo не щёлкала 50-60 раз в секунду.
Ну да, угол HiFi при этом меняется, но о каком HiFi идёт речь в рамках ВМ12? Кассеты предназначались только для воспроизведения на нём же. HiFi и не требовалось, а вот Арвид радовался дополнительной ёмкости.
Я про саму теоретическую возможность с её теоретическими последствиями.
И приправляю коммент тем, что не знаю, сколько там в норме шума в момент переключения и что там ещё теряется кроме фазы этого антисоветского FM-звука (допустим, сколько частей строки, если бы на ней хранилось что-то полезное).
Вы не поняли. Я по сути сделал LP для ВМ12. Это влияло только на скорость протягивания ленты и, как итог, только на стандартную линейную аудиодорожку, как и в другом видеомагнитофоне со штатной функцией LP. А HiFi пишется головками на БВГ, с углом смещения 60 или 42 градуса. Смещение позволяет сдвинуть аудиодорожку относительно видеодорожки потому что плёнка движется непрерывно. Причём, HiFi магнитофоны с функцией LP в большинстве своём умеют писать HiFi даже на скорости LP. Ну а в тракте HiFi там сигнал/шум и частотный диапазон не зависят от скорости протягивания ленты потому что HiFi головки находятся на БВГ и их скорость перемещения стабильная и высокая.
Эээ...
Берём хороший бу живой магнитон типа JVC HM‑DH40 000U, который имеет выход Component (то есть три провода для трех каналов цвета — яркость и две цветоразностные)
Берём карту захвата с компонентом типа Intensity
Пихаем компонент сигнал в комп
На стороне компа захватываем видеопоток в RAW без сжатия и без субдискретизации, можно в RGB
Полученное сырьё реставрируем, цветокорим по вектороскопам/осциллоскопам чтобы вправить моск цветам как было. Доп обработка по вкусу, можно нейросетями и/или апскейлом
Жмём в что‑нибудь с большим битрейтом или вообще в Loseless типа ProRes
Если всё правильно сделать, качество будет максимальное, в прямом смысле: мы здесь на каждом этапе теряем минимум информации.
Опционально можно всё или часть делать за один присест, если не гнать этот пайплайн через софт для монтажа, а сразу пропускать и синхронизировать RAW картинку через софт для видеомикширования (не буду показывать пальцем на Tesseract :) )
Тогда сразу будет захватываться готовый результат.
Аналоговый шум надо убирать
Аналоговый шум алгоритмы сжатия видно часто воспринимают как детали картинки и пытаются их сохранить, выкидывая настоящие детали. В итоге к аналоговому шуму добавляется мыло и/или файл получается больше. Потому что оно искренне пытается сохранить каждую мурашку.
Поэтому шумы лучше убирать (если не писать в RAW конечно). По этой же причине стоит 10 раз подумать, прежде чем добавлять художественный шум в видео, которое заливается в соц сети и телеграмы, где царит низкий битрейт.
Упоротый вариант — подцепить АЦП к головке магнитофона. Но это, кхм, сопряжено некоторыми небольшими сложностями :)
Прочитайте вывод статьи. Я и не настаиваю на том, что это лучший метод. Ваш вариант вполне рабочий. Единственное, в чем VHS-Decode явно лучше других методов - это качество TBC (смотрите второе видео в статье). Ну и цена конечно.
Наверное с точки зрения эффективности разумно было использовать хороший магнитофон и хорошую карту захвата как основной инструмент для оцифровки, а VHS-Decode как вариант для плохо сохранившихся кассет, которые встречаются не так часто.
Да не будет у него лучше качество TBS, а на тянутых лентах даже хуже. Тк и то, и другое происходит в реальном времени, но интегрированный TBS работает в плотной связке с другими системами видеомагнитофона.
Я не отрицаю такой подход более того сам в свое время подобное проворачивал, правда не для VHS, и не в реальном времени, и не только из-за проблем с производительностью. Смысл был в том, чтобы по сути сканировать плёнку, с большой избыточностью. Частота вращения барабана была постоянная и синхронизированная АЦП. А подача плёнки управлялась программно, по мере необходимости.
Упоротый вариант — подцепить АЦП к головке магнитофона. Но это, кхм, сопряжено некоторыми небольшими сложностями :)
Однако, это единственный правильный метод вытащить то, что по факту на носителе, исключая все артефакты постобработки конкретного аппарата. Точно так же работает декодирование RF с фотоприёмника LD проигрывателя. Вопрос лишь в целесообразности: насколько важен записанный контент. Есть очень много быстродействующих АЦП на 8-12 разрядов (до сотни МГц сэмплирования), есть хорошие и быстрые FPGA. Можно всё сделать даже ещё лучше, чем описано в статье, вопрос лишь в том, какая конечная цель преследуется.
Более чем согласен. Но имхо это как из орбитального ядерного лазера по воробьям. Если воробей какой‑то особенный то норм, но в общем случае не надо :)
много быстродействующих АЦП на 8–12 разрядов (до сотни МГц сэмплирования)
Есть подозрение, что для качества этого мало, и надо не менее 1 ГГц. А так да.
Для годноты можно ещё в FPGA параллельно завести питание через отдельный АЦП, чтобы если вдруг (ну вдруг) по нему наводятся помехи, то алгоритмы обработки были в курсе и могли через пару обработок вычесть из полезного сигнала.
так вроде в статье как раз и говорится что метод хорошо подходит для проблемных кассет, в отличии от записи с "бытовых" проигрывателей.
Более того, если снять то, что по факту на ленте, причём если ещё и стабилизацию протягивания сделать внешнюю, то можно избавиться и от артефактов инертности ФАПЧ капстана и трекинга в целом, при потере сигнала в синхродорожке. А там время реагирования измеряется в секундах.
Точка RF, кстати, используется при ремонте и настройке видеомагнитофона с помощью осциллографа, до получения стабильного равномерного сигнала от обеих голов. Например, вот так:
Настраивается как механика (направляющие ролики и азимут самих кристаллов) так и электроника (средняя фаза автоматического трекинга). Поэтому, тестовая точка RF есть у каждого видеомагнитофона.
Берём карту захвата с компонентом типа 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) и он до сих пор тыщу долларов стоит.
Сохранять плёночное зерно в 4K сейчас считается нормальным
Аналоговый шум работает как дизеринг. Он визуально (в случаях звука - аудиально) улучшает качество оцифровки на малых уровнях, когда битовая глубина исчерпывается.
Для видеохостингов 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.
У вас нет общего таймера. У вас есть лишь единственная опорная величина времени - сэмпл. Как у звука так и у видео. Разные устройства мало того запускаются по очереди (в статье про это - начальный сдвиг, корректируется каждый раз) так ещё и у устройств собственные тактовые генераторы, которые всегда имеют джиттер относительно эталона (измеряется в +-ppm). Так вот, если у вас звуковая карта при настройке 48000 сэмплов в секунду захватывает по факту 47996 сэмплов в секунду, то вы, трактуя эту запись как 48000, набираете ошибку в 4 сэмпла каждую секунду. Через примерно 3 часа и 20 минут у вас накопится ошибка в целую секунду. И это, ещё, кстати, не самый плохой показатель. А почему это важно? Да потому что записи VHS обычно измеряются часами. Но если это сборник клипов, то вы можете делать короткие сессии по 1 клипу за раз, например, если точно знаете их тайминги (ну или используете контрольный телевизор).
Спасибо. Беглый гуглеж показал что " В среднем, типичные часы реального времени могут иметь погрешность от 1,7 до 8,6 секунд в день.". Не ожидал, что все настолько плохо. Электронные наручные часы конца прошлого века обеспечивали лучшую точность. Непонятно почему не берут системное время синхронизируемое по NTP в этом случае.
Я всё равно не понимаю, чего вы привязались к ЧРВ? Сигнал при оцифровке получает свою шкалу времени в виде сэмплов и после этого сохраняется в цифровом эквиваленте с ней. Будучи в цифровой форме он уже вне времени и только период сэмпла остаётся единственной привязкой к реальному времени. И трактовать это время можно по-разному. А при, собственно, захвате сэмплов АЦП использует свою опорную частоту, а не ЧРВ компьютера. Эта частота ещё и может дрейфовать во времени от температуры. И генераторов в ПК много, вот такие маленькие блестящие штучки замечали же?
На этой материнской плате с первого взгляда уже 6 кварцевых резонаторов (один низкочастотный часовой - трубочка справа вверху). А на платах расширения (видеокарта, звуковая карта и т.д.) свои резонаторы стоят. И всё это асинхронно жужжит на своих частотах с биениями. А шины между элементами уже рассчитаны на такую какофонию, но для главного PLL есть ещё и настройка, специально изменяющая частоту в сторону: Spread Spectrum называется.
Я всё равно не понимаю, чего вы привязались к ЧРВ
Это не я привязался. Это живой человек (и судя по всему не только он, а все кто оцифровкой занимаются) вручную в конечном счете именно что привязываются к реальному времени, а не плавающим частотам резонаторов на различных устройствах.
Сигнал при оцифровке получает свою шкалу времени в виде сэмплов и после этого сохраняется в цифровом эквиваленте с ней
А реальное время оказывается нужно для синхронизации потоков, но просто теряется. В статье прямо здоровенный раздел "Подробнее о сведении аудио и видео" где в частности написано:
По завершении захвата требуется запустить следующий скрипт, сохраняющий время, когда началась запись аудио и видео в файл time.txt. Эта информация пригодится далее для сведения дорожек.
Почему в 2025 году это реализуется какими-то костылями скриптами, а не сохраняется прямо в файле с дорожкой? Странно. И сведение в этом случае будет выполняться автоматом.
P. S. На всякий случай дисклеймер. Понятно, что претензии не к Вам лично. Не Вы эти форматы изобретали. Спасибо за отличное описание реального положения дел.
А реальное время оказывается нужно для синхронизации потоков, но просто теряется.
А вы представляете, что эта кроличья нора гораздо глубже?
Например, уже в цифровом виде, где уже кадр это двумерный массив пикселей (без относительно метода сжатия) а аудио набор таких же сэмплов PCM. Есть FPS, когда кадр должен демонстрироваться некоторое время, например, 25FPS. Абсолютное время будет 1/25=0.04с или 40мс. А вот у вас звук с частотой 48к и время его сэмпла это 1/48000=0.000020833333 секунды или 20.83мкс. Допустим, вы хотите синхронизировать эти 2 процесса а получается, что вы не можете выделить целое число сэмплов на каждый отдельный кадр, как было бы очевидно. Потому что время звукового сэмпла не кратно да ещё и 3 там в периоде. На каждый кадр выходит по 1920,0003 сэмпла. И приходится вам искать их НОК (наименьшее общее кратное), чтобы расхождение было минимальным и это, скорее всего, будет 25 кадров и 48000 сэмплов, т.е. 1 секунда реального времени. А монитор у вас 60 Гц, т.е. для отсчёта времени отображения кадра вы не можете использовать логичный VBlank/VSync видеокарты. Остаётся лишь одна синхронизация - звук. Теперь имеете некоторое представление, что там у видеоплееров под капотом в части рендера (и видео и аудио)? И это только касаемо готового клипа с, допустим, идеальными таймингами видео и звука.
Забавно то, что в аналоговом мире прошлого абсолютное время синхронизации было само видео и звук синхронизировался под частоту полукадров. А в цифровом современном мире всё с точностью наоборот...
Я сталкивался с подобной задачей, когда делал софт обработки видео в реалтайме. В нём по всему графу текут видеоаудио кадры — картинка (один полный кадр или два полукадра) + кусок звука. Это для того, чтобы внутри софта не ловить рассинхрон ни при каких обстоятельствах — видео и звук железобетонно прикручены друг к другу.
И прикол с тем, что, например, 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 сигнала), то вместо текущей строки берётся выход линии задержки.
В последних поколениях топовых видеомагнитофонов уже DSP ставили, там практически весь тракт в цифре был, прямо как у 100Гц ЭЛТ телевизоров. Я видел, как оно восстанавливало легко половину выпавшего кадра от помятости на ленте. А когда у него сломался кристал одной головы, он пытался вытянуть остальными. Это давало забавные артефакты, типа тиринга, но помех было всё равно крайне мало.
В видео-то АРУ тоже есть, но привязывается к уровню синхросигналов, и как-раз проще всё выходит.
Не к самим синхросигналам а к уровню чёрного в интервале кадрового гашения. Из-за этого работала защита от копирования: в сигнал внедрялся ошибочный уровень чёрного, который постоянно менялся, телику пофигу, а видик от этого сходил с ума. У меня такое было на видеокарте GeForce2 T200, там кодек от Chrontel был и даже галочка была в драйверах, при активации которой я не мог записать кино с видеовыхода. Забавно, но позже уже в кодеке от Conexant и в GeForce2 MX400 это убрали и никакой защиты от записи уже не было.
Видимокарта с видимовыходом
Вопрос к автору , как вы думаете зачем в касетном магнитофоне в усилителе куча корректирующих цепей изменяющих ачх ? Как это связано с током подмагничивания ? Почему нельзя скопировать с кассеты на касету на повышенной скажем в 3 раза скорости ? Теперь про видео , сколько считывающих головок в видеомагнитофоне ? С какой из них вы сняли видеосигнал ? А конденсатор последовательно с индуктивностью случайно ачх не искажает ? А точно от ёмкости конденсатора и индуктивности ничего не зависит ? Как насчёт согласования входного сопротивления ? А можно конденсатор керамический , чтоб от температуры плыл ? Зачем в магнитофоне линия задержки на кварцевой пластине не подскажите ?
Ну это какой-то лютый перфекционизм. Я помню, что ещё во времена XP и четвёртого пня нормально оцифровал несколько видеокассет, подключив свой видак Панасоник к PCI ТВ-тюнеру Beholder 507. Потом ещё что-то цифровал, обновив комп до 4-ядерного Phenom II, а систему до Win7. И качество результата вполне радовало. Четвёртый пень на 3 ГГц отлично тянул такую оцифровку, как и захват эфира телеканалов. Инженеры, делавшие ТВ-тюнер и ПО к нему, отлично поработали. Небольшая проблемка только была выбрать правильный кодек, так как только с одним получалось видео разумного объёма, все остальные доступные для выбора выдавали видеофайл чрезмерно огромного объёма, или отказывались работать.
Это та же история, как с оцифровкой фотоплёнок. Всё думал - вот, придётся нести плёнки в фотолабу, там, наверное, закажу с оцифровкой в максимальном качестве, но дорого блин... А потом ко мне попал старый планшетный сканер HP G2710 со слайд-модулем, я нашёл инструкцию как выжать из него максимальное качество оцифровки плёнки, попробовал - и увидел, что лучше и не надо: сама любительская плёнка из 90-х, залапанная пальцами, и работавшая в дешёвой "мыльнице", лимитирует качество куда сильнее чем возможности сканера. И то, что оцифрованная фотка в итоге получается около 3 мегапикселей (примерно), не проблема. Если бы я получил тот же скан в 40 мегапикселей, не дало бы никаких новых деталей из-за того, что сам исходник слишком беден на детали.
Так же и с кассетами. Надо ли оно: Ради улучшенного на 5...10% качества картинки и звука столько движений. Ладно там если надо оцифровать потерянный концерт какой-нибудь легенды, выжав всё что можно, но бытовые кассеты писались на дешёвые бытовые VHS-камеры, вряд ли там будет разница.
Но концепт такой оцифровки интересный.
HP G2710
А он не бьёт картинку на квадратики? Я пробовал отсканировать свои фотографии на трёх разных сканерах HP, но все три делили картинку на квадратики с выкидыванием нескольких пикселей изображения на стыках этих квадратиков. Очень сильно бросается в глаза на съезжающих из-за этого диагональных линиях
VHS-Decode — новый метод оцифровки видео