[VCucumber 0]

в СТМ32 нет такого АЦП чтобы эти 6 МГц полосы с 27МГц оцифровать.

в стм есть такой ацп, которым можно около 6.5 * 2 == 13 мгц оцифровать

этого должно быть вполне достаточно для видео

 

 

если с секам уже понятно, то что делать с пал/нтсц ?

 

[_pv 52]

в стм есть такой ацп, которым можно около 6.5 * 2 == 13 мгц оцифровать

этого должно быть вполне достаточно для видео

у f4 - нет, разве что только у f303, но там ядро 72МГц, отсутствует внешняя память, а внутренней совсем немного.

 

[Fusion 0]

Вот тут я эксперементировал с АЦП F303:

stm32f303 АЦП 16 мГц

СТМ разогнан до 80 мГц

 

А это оцифровка видеосигнала внешним АЦП (СТМовский хуже-валит фронты):

Строчный синхроимпульс и вспышка.

 

[_pv 52]

Вот тут я эксперементировал с АЦП F303:

сложить кадр ему некуда, а в jpeg пожать на лету - силёнок не хватит.

а f4 c уменьшенным разрешением, соответствующим возможностям его АЦП, может и справился бы.

[VCucumber 0]

у f4 - нет

странно, в моём есть

скажите, а вот как синхру поймать, успеет ?

ибо lm1881 преотвратительнейшее создание, не имеет pll, ловит тупо компаратором

 

[_pv 52]

странно, в моём есть

ну может тогда точное название МК укажете?

а то насколько я знаю во всех F4 АЦП до 2.4МГц, в некоторых есть по 3 штуки которые в interleave умеют работать все вместе.

скажите, а вот как синхру поймать, успеет ?

картинку двумя постами выше видите?

[VCucumber 0]

это 7.2мгц * 15 тактов

или 12мгц * 9 тактов

[SpyBot 0]

это 7.2мгц * 15 тактов

или 12мгц * 9 тактов

15 тактов * 3 ацп

9 тактов * 2 ацп

[Fusion 0]

В 8 битном режиме 7.2 MSPS (10 тактов)

В 6 битном режиме 9 MSPS (8 тактов)

 

Два АЦП дают 18 MSPS при 6 битах.

Но это в interleaved mode - либо вычитывать в память через ДМА, либо на асме считать четко такты.

При 18 мГц на все про все 4 такта между измерениями.

 

[VCucumber 0]

мнения разделились

я сам не проверял, только 5 секунд чтения ds

12 мгц достаточно, 18 хорошо для видео, но уже избыточно для памяти и нагрузки на шину

кроме того, пиксели будут не квадратные

 

[Tarbal 4]

1)полоса цветоразностных сигналов - 1.3МГц.

их можно конечно и на 100МГц оцифровать, и сказать потом что там на самом деле 5000 пикселей, но картинка от этого лучше не станет.

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

 

100 мегагерц будет слижком и оно никому не нужно, но если провести исследования, то можно найти оптимальную частоту. Исследования были проведены, частота была найдена и стандартизирована. Именно ее я и привел.

 

Я вам рассказываю о стандартных значениях телевизионного сигнала в цифровой форме, а не о желаниях и предположениях. Поверьте мне на слово если вам лень посмотреть в интернете эти вещи (PAL SECAM NTSC) в цифровом формате стандартизированы и имеются соответствующие документы. Я привел значения из этих документов, а не мои мечты.

 

Например здесь приведен параметр:

Pixel Clock frequency

(digital sources with 704

or 720 active Pixel/Line)

https://en.wikipedia.org/wiki/PAL

 

 

Как вы думаете откуда взяты эти значения и что такое Pixel Clock frequency для PAL signal details если никаких пикселей в телевизионном сигнале нет. Я два года занимался цифровым видео в серьезной фирме и если будут вопросы -- обращайтесь.

 

Вот по-русски рассказывают, что пиксели таки есть:

https://ru.wikipedia.org/wiki/%D0%A1%D1%82%...BD%D0%B8%D0%B5)

 

 

мнения разделились

я сам не проверял, только 5 секунд чтения ds

12 мгц достаточно, 18 хорошо для видео, но уже избыточно для памяти и нагрузки на шину

кроме того, пиксели будут не квадратные

 

В телевизионном изображении пиксели итак не квадратные.

Формат кадра 3х4 дает 480х640, а никак не 480х720 NTSC. PAL Secam вместо 480 будет 576 при том же формате кадра.

Вот в стандарте VESA (компьютерные форматы) 460х640 один из стандартных форматов, но там все форматы имеют квадратные пиксели.

 

Вот тут я эксперементировал с АЦП F303:

stm32f303 АЦП 16 мГц

СТМ разогнан до 80 мГц

 

А это оцифровка видеосигнала внешним АЦП (СТМовский хуже-валит фронты):

Строчный синхроимпульс и вспышка.

 

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

[_pv 52]

Я вам рассказываю о стандартных значениях телевизионного сигнала в цифровой форме, а не о желаниях и предположениях. Поверьте мне на слово если вам лень посмотреть в интернете эти вещи (PAL SECAM NTSC) в цифровом формате стандартизированы и имеются соответствующие документы. Я привел значения из этих документов, а не мои мечты.

да в цифровом формате пожалуйста, никто с этим не спорит.

 

раз вам так нравятся цифирки из википедии, нарисуйте пожалуйста как будет выглядеть картинка (720х576) из чередующихся пикселей (черные/белые, а особоенно хорошо если красные/синие) с частотой 13.5МГц, после прохождения через PAL, если там аналоговая полоса пропускания для цветоразностных сигналов - всего 1.3МГц? или цветонесущуюю 4.43МГц получается можно с частотой 6.25МГц промодулировать? да так, чтобы общая полоса в 5МГц взела?

 

будет ли эта картинка хоть чем нибудь отличаться от такой же (чередующиеся красно/синие пиксели) если пиксели будут чередоваться с частотой 6.25МГц (два красных два синих)? и чем, если будет? а если нет, то зачем тогда насиловать несчастный stm32 заставляя его цифровать на такой большой частоте, он и с уменьшенным разрешением-то вряд ли справится.

 

Как вы думаете откуда взяты эти значения и что такое Pixel Clock frequency для PAL signal details если никаких пикселей в телевизионном сигнале нет. Я два года занимался цифровым видео в серьезной фирме и если будут вопросы -- обращайтесь.

да тема вроде как про аналоговое видео, а не про цифровое.

 

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

если шумов там будет немного (SNR~50 учитывая амплитуду color burst) то по этим десяти периодам фазу при 15МГц оцифровки можно с где-то с 0.5гр определить, что к концу строки приведёт к расползанию на 150градусов и цвета поплывут, но если с усреднением по многим строкам думаю получится.

 

[VCucumber 0]

фазу нелегко определить

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

 

 

Формат кадра 3х4 дает 480х640, а никак не 480х720 NTSC. PAL Secam вместо 480 будет 576 при том же формате кадра

если взять секам 576 линий умножить на 4 разделить на 3, то получится 768, а не 640

Изменено 18 апреля, 2016 пользователем Огурцов

[Tarbal 4]

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

 

 

 

если взять секам 576 линий умножить на 4 разделить на 3, то получится 768, а не 640

 

Вы вроде про пал и нтсц тоже говорили

[VCucumber 0]

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