[Tarbal 4]

да, а так же, про то, что не понятно, как их победить

 

Да непонятно и даже не уверен, что возможно. В американских телевизорах видеодецодер сделан без линии задержки как это делается в ПАЛ. С линией задержки вроде как две оси разложения вектора цветности. Поэтому цвет сильно зависит от помехи и может измениться от шума, при наличии отраженногио сигнака.

К чему я это? А вот к тому, что даже там где нет проблем с быстродействием (аналоговая схема) есть масса других проблем. А ведь есть еще множество разных модификаций всех трех стандартов.

Вы из проблем них не выберетесь. Если же взять специализированнуя микросхему, то там все сделано.

Все конечно зависит от поставленной задачи. Мне она неизвестна.

[alexf 0]

Да непонятно и даже не уверен, что возможно. В американских телевизорах видеодецодер сделан без линии задержки как это делается в ПАЛ. С линией задержки вроде как две оси разложения вектора цветности. Поэтому цвет сильно зависит от помехи и может измениться от шума, при наличии отраженногио сигнака.

 

PAL меняет фазу одного цветоразностного сигнала через строку, так что ошибка меняет знак, а линия задержки помогает усреднять 2 строки в идеале подавляя ошибку (фазы).

 

Обычно для оцифровки используют ровно 4х поднесущую цветности (4.43 или 3.58), но синхронно с фазой, захваченой PLL по вспышке. Но если захватить поднесущую, то можно и выделить аналоговые Y-R и Y-B и цифровать на относительно низкой частоте. Я про PAL/NTSC - с Секамом дела не имел.

 

[Tarbal 4]

PAL меняет фазу одного цветоразностного сигнала через строку, так что ошибка меняет знак, а линия задержки помогает усреднять 2 строки в идеале подавляя ошибку (фазы).

 

Обычно для оцифровки используют ровно 4х поднесущую цветности (4.43 или 3.58), но синхронно с фазой, захваченой PLL по вспышке. Но если захватить поднесущую, то можно и выделить аналоговые Y-R и Y-B и цифровать на относительно низкой частоте. Я про PAL/NTSC - с Секамом дела не имел.

 

Так вот речь как я понял о том чтобы PLL в программе исполнить. Если часть рещить аппаратно, то все упрощается немеряно. Самое простое будет поставить специализированный чип.

[ШСА 0]

Так вот речь как я понял о том чтобы PLL в программе исполнить. Если часть рещить аппаратно, то все упрощается немеряно. Самое простое будет поставить специализированный чип.

Какой специализированный чип?

STM32F4 "в лоб" видеосигнал не оцифрует. Нужно либо подстраивать тактирующий МК кварц, либо ставить мультистандартный декодер. В любом случае всё начинается с привязки к цветовой вспышке, причём аналоговыми средствами. Существует ли ГУН на 4.43361875 и 3.579545 МГц с диапазоном перестройки порядка 250 ppm?

[zipzap 0]

а в секаме не нужна фаза ...

Не знаю, насколько это важно при оцифровке, но в SECАMe фаза сигнала меняется через пару строк для снижения заметности

муара от поднесущей.

[Gradient 1]

Хех... Затея обречена на провал, с громким треском. Даже DSP процессора не оцифровывают сигналы цветности самостоятельно, а используют для этого аппаратные декодеры. Конечно, возможно оцифровать и ресурсами STM, но смотреть такой сигнал вряд-ли кто то захочет. А могут ещё и побить... ;)

 

Video Decoders

[Tarbal 4]

PAL меняет фазу одного цветоразностного сигнала через строку, так что ошибка меняет знак, а линия задержки помогает усреднять 2 строки в идеале подавляя ошибку (фазы).

 

Обычно для оцифровки используют ровно 4х поднесущую цветности (4.43 или 3.58), но синхронно с фазой, захваченой PLL по вспышке. Но если захватить поднесущую, то можно и выделить аналоговые Y-R и Y-B и цифровать на относительно низкой частоте. Я про PAL/NTSC - с Секамом дела не имел.

 

Уточнение:

 

Линия задержки позволяет восстанавливать второй цветоразностный сигнал при передаче только одного цветоразностного -- предыдущий приходит из линии задержки. Так чередуя на передающей стороне цветоразностные сигналы и осуществляется передача. Это кстати объясняет почему цветное разрешение по вертикали вдвое ниже разрешения яркостного сигнала. Та функция, что вы описали уже вторична. Просто начли решение, подходящее к имеющимся принципам.

[khach 35]

Конечно, возможно оцифровать и ресурсами STM, но смотреть такой сигнал вряд-ли кто то захочет.

Даже после оцифровки с помощью ADV7xxx, прикрученного на параллельную шину камеры DCMI не совсем понятно, что потом с потоком делать. Его же перекодировать надо для показа на экране, а ресурсов не хватает. Более-менее начал справляться только STM32F746. А до этого только захват отдельных кадров получалось сделать.