Pull to refresh

Comments 27

Читал про этот проект начале 2000-х. Тему про него на форуме pctuner.ru видел. Там же упоминали, что до этого в 1990х для данных был вариант использования VHS кассет. С неплохими характеристиками для того времени.

Есть только один нюанc — камеры с DV-In на европейский рынок почти не поступали. В ЕС на них был налог по типу «болванок Михалкова». Они относились к классу видеомагнитофонов.
По этому большинство камер без возможности записать что-то на ленту.
Тоже сразу про него вспомнил.
и не Вы один :-) У меня до сих пор арвид в гараже лежит — просто так, на память.
Да-да, классная была штука в те времена. Где-то до сих пор лежит…

зы:
— А я написал утилиту для проигрывания avi-шников с арвида!
— Ура! Программистам наконец удалось приспособить видеомагнитофон для просмотра видео! (с) тех времен, вроде бы шутка.
Интересно, качество таким образом можно было получить лучше, чем нативное аналоговое видео?
Ну, там было две скорости 300 Кб/с и 200 Кб/с в совсем старых платах, вот и прикиньте…
… ЕМНИП принцип там был как у спектрума и прочих компов использующих магнитофон, только скорость по шибче ибо полоса частот у видео сигнала шире, но плотность записи на аналоговый носитель можно в разы повысить за раз записывая несколько бит…
Да, для VHS был арвид.


АРВИД был на прядок надежнее:

Я записал на кассету часть фотоальбома 9.5 ГБ как набор файлов фотографий в формате jpg примерно по 1-3 МБ. При считывании сбой был зафиксирован у трёх файлов.


У АРВИДа была хорошая систем коррекции ошибок.
Данные, хранившиеся на нем — дожили до сегодняшнего дня (в конце эпохи видеомагнитофонов они были перезаписаны на DVD-R, а затем и на обычный хард)
Не помню, чтобы был потерян хоть один файл с двух десятков кассет.

У АРВИДа была хорошая систем коррекции ошибок.


Ничто не мешает закодировать файл, как захочется. Но совместимости с dvbackup не будет. А это может быть важно лет через *дцать.
По этому большинство камер без возможности записать что-то на ленту.


Это странно. Все четыре моих MiniDV камеры (от Canon, Panasonic, Samsung и JVC) умеют писать поток по ieee1394. Не встречал камер, не умеющих выполнять запись DV-потока (запись производится в режиме play, а не съёмки).
В начале 2000-х на европейском рынке продавались камеры, заблокированные на запись именно по DV IN. Были модели с возможностью записи, но ценник был больше.
С «тюльпан»-входов они так и так писали.
Свою Sony я покупал в Берлине. Потом «руками» менял в прошивке несколько байт.
С «тюльпан»-входов они так и так писали.


С RCA у меня только Canon умеет делать захват с перекодированием в DV.
И правда, производитель блокировал возможность записи потока — DV IN. Причем блокировка была на уровне прошивки, были энтузиасты, кто разблокировал данную возможность.

Автору однозначно респект. Ранее был потрачен день на поиски подобного проекта. Все что я находил было давно мертво. Обязательно протестирую на днях.

HDVSplit прекрасно управляет камерой, но я не уверен что исходники можно найти. Если только попробовать связаться с автором.
Подключалась камера через переходник к COM порту, а дальше был вопрос в наличии программы. В свое время я находил только для пары моделей инструкцию о редактированию регистров и ПО.
В упомянутым выше Арвиде данные защищались с помошью помехоустойчивого кода Рида-Соломона. Это давало возможность исправления большого количества одиночных ошибок в отдельных блоках, некоего количества двойных и небольшого количаества тройных ошибок.
Что это означало на практике. Данные, записанные на одном видеомагнитофоне без проблем считывались на другом таком (той же марки и модели) же и с некой достаточно высокой вероятностью на совсем другом видеомагнитофоне (лишь бы он не был сильно заезженым). У меня была модель 1020.
Я вот тоже не так давно «захотел странного».
Захотел изучить основы C#, но скольку просто учиться по урокам не так интересно, а в моем случае когда изучаешь скорее из любопытства — даже вредно, то решил реализовать старую идею возможности хранения данных в видео файлах с возможностью заливать их на видеохостинги типа Youtube.
Начал с черно-белых квадратов и в итоге дошел до использования DCT с возможностью уместить до 7 бит на 8х8 пикселей для случая работы с Youtube, без ошибок при распаковке. Впрочем, без опыта в подобной области многое писал чисто интуитивно.
Писал я скорее ориентируясь на увеличение количества данных на пиксель, но есть предположение что простое использование черно-белых квадратов будет практичнее из-за меньшего веса видео (до 3-х раз больше от размера исходных данных против до 10 для случая с DCT), да и сам алгоритм работает значительно быстрее, хоть видео и будет более длительным.
И какой объём получается упаковать в минутный видеоролик?
Кстати, по какой книжке вы С# изучаете?
Для мака есть DV Backup, насчёт совместимости вопрос, но она также пишет в картинку и звук, и ошибок почти нет, правда и лезет на кассету всего лишь 4,7 гига.
Очень круто!)) А можно то же самое для аудиокассеты? Так сказать, вдохновляясь Kansas City Standart'ом, сделать на современных алгоритмах круче, быстрее, надёжнее?
Вряд ли. Там частоты низкие. Фактически, спектрум и подобные получится с его загрузкой/сохранением. :)
Тут дело вовсе не в современных алгоритмах — формат DV цифровой. Кадр имеет всегда одинаковый размер и одинаковое количество коэффициентов ДКП. Вот в них-то и спрятаны данные файлов.
Отличная статья! Спасибо автору за проделанную работу. Если в мои руки попадет аналогичная камера обязательно попробую такой способ сохранения данных. Just for fun!
Прошу прощения, когда вчера занимался «украшательством» написал в одном месте по инерции неверно (вместо указателя src вписал target в функции распаковки). Программа обновлена.
А напрямую камерой в конце концов получилось управлять? Или проект уже заброшен? Я тут камеру нашел… захотелось попробовать чего-нибудь странного)
Нет, не получилось. Нет никакой информации (по крайней мере, на русском — я с английским не очень дружу), как вообще работать с устройствами на шине FireWire. Единственная книжка, где хоть что-то написано также ничего внятного сообщить не может.
Кроме того, судя по «многочисленным» откликам на мой вопрос:
Поэтому, если кто-нибудь может рассказать о работе с камерой по ieee1394 с использованием WinAPI и на Си/Си++, то буду очень ему благодарен.

(а их ровно ноль), можно сделать вывод, что ни один из посмотревших статью (а их почти 11 тысяч) также понятия не имеет, как работать на достаточно низком уровне с видеокамерой.
Поэтому для записи/чтения DV-файла придётся применять отдельные программы.
В ваше ПО еще бы избыточность добавить и будет вполне все солидно. Правда это можно решить другим путём — найти нечто типа dvdisaster для образа RAW. Сходу правда не нашел)
Нельзя. Если я поменяю формат пакета, то не будет совместимости с dvbackup. А её очень хотелось сохранить, потому как через много лет (практически, потомки) dvbackup найти можно будет (она известная), а мою программу нет (её видели 1.5 человека).
Это-то понятно. Я имел ввиду другое. Формат пакета менять не нужно, можно играться самим контентом. Никто ж не запрещает для всех файлов посчитать коды коррекции для файлов и писать их на плёнку в разные части кассеты. А при чтении вычитывать содержимое, коды, делать сверку кодов и восстанавливать их при необходимости (например, мажоритарной логикой), ну и восстанавливать контент при необходимости. Вашей проге тогда бы цены не было — арвид для видеокамер) А совместимость с dvbackup, конечно, останется, она только будет распаковывать RAW контейнер, воспринимая корректирующие коды как обычные файлы.

И тут вот момент — в принципе, это всё можно и не делать в рамках вашей программы. Можно просто подготовить массив данных для записи с этими кодами коррекции, прогнать через вашу программу и записать на кассету. dvdisaster подобное делает для iso, правда предполагается, что файлы с кодами коррекции будут храниться где-то в отдельном надежном месте. Посвободнее буду — надо попробовать поискать подобное ПО для произвольных файлов, сходу что-то этакое универсальное не нашел.
Sign up to leave a comment.

Articles

Change theme settings