[alexkarnaukhov 0]

Привет всем!

 

Проблема такая: на плис заводится видеосигнал с частотой кадров в 3 раза меньше стандарта PAL (25/3=8.3 Гц) и кладется в фреймбуфер. Далее из фреймбуфера полукадрами это изображение выводится наружу по протоколу bt656. проблема в том, что клок, по которому работает сенсор не синхронен с клоком bt656, т.е. картинка с сенсора может приходить с чуть меньшей частотой, или слегка большей. Есть ли возможность в bt656 каким-то образом увеличивать или уменьшать blanking - интервал, чтобы вывод видео наружу шел синхронно с поступающими кадрами? Или может можно слегка отклоняться от 27МГц?

 

Ни в стандарте bt656, ни на популярной страничке http://www.spacewire.co.uk/video_standard.html, ни на этом форуме ничего похожего не находил....

Спасибо.

[tvcam 0]

Два варианта:

1.Засинхронизировать матрицу с клоком 27мгц, а точнее выставить кадровую частоту точно кратно 25 (25/2 или 25/4)

2.Если известен приёмник принимающий bt656 то просто проверить его способность принимать на другой частоте.

[alexkarnaukhov 0]

Спасибо за ответ, но это в моем случае не подходит-у сенсора свой внутренний клок, причем наружу не выводится - наружу идет только одиночный импульс при старте каждого кадра. На другой частоте - все равно придется каким-то образом подстраиваться под эти внешние синхроимпульсы, потому что эта частота точно не известна, известно, что она отличается примерно на 0.0001% от 27МГц в меньшую сторону. Там около десятка тактов за 6 полукадров набегает.

Хотелось тупо blanking период в самом конце кадра укорачивать, но вот непонятно будут ли хавать приемники такой поток с укороченной длиной последней строки...

[tvcam 0]

Вы не догавариваете: что сенсор выдаёт вообще аналоговый сигнал? без тактов?

Приёмник может также тупо считать такты и когда blanking будет не тем он может глюкнуть.

Прогнать весь сигнал через Фифо и в конце выбрость или добавить нужные такты, благо их не много.

[alexkarnaukhov 0]

Вы не догавариваете: что сенсор выдаёт вообще аналоговый сигнал? без тактов?

Приёмник может также тупо считать такты и когда blanking будет не тем он может глюкнуть.

Прогнать весь сигнал через Фифо и в конце выбрость или добавить нужные такты, благо их не много.

 

Сенсор по выдает данные пачками по паралельной шине, тактируются они по своему клоку ~10Мгц, т.е не кратному 27Мгц. Да и вообще с сенсора идет кадр гораздо меньшего разрешения, чем pal. Так что клок сенсора мне не поможет. Да и вообще там еще фреймбуфер стоит, так что не важно каким именно образом данные с сенсора читаются. Главное тут что фреймбуфер обновляется с частотой почти точно в три раза меньшей PAL. Т.е. около 120мс.

[alexkarnaukhov 0]

В общем при выбрасывании/добавлении тактов в bt656 потоке не годится - картинка начинает слегка помаргивать. На разных мониторах немного по-разному, но в любом случае как решение не пойдет.

Хотя свою проблему я надеюсь что решил - вроде как все-таки можно запускать сенсор по внешнему синхроимпульсу...

[zxcv 0]

То что Вы делаете в видеотехнике называется кадровый синхронизатор.

 

Упрощённый принцип его действия такой:

На частоте источника сигнала в первую часть буфера записывается кадр.

Далее, во вторую часть буфера, идёт запись следующего кадра.

Далее, опять в первую часть буфера, идёт запись следующего кадра.

 

Как только первый кадр записан, на опорной частоте начинаем вычитывание первого кадра.

Если к моменту окончания вычитывания первого кадра второй кадр ещё не записан полностью,

то повторно вычитываем первый. (Это случай в котором частота источника меньше опорной.)

Это будет повтор кадра.

 

В случае, если частота источника больше опорной, к моменту окончания вычитывания

первого кадра будет начата запись третьего кадра в первую половину буфера.

Пропустим вычитывание второго кадра, сразу перейдём к вычитыванию третьего.

Это будет пропуск кадра.

 

 

Рассмотрим Ваш случай.

При частоте кадров источника ровно в 3 раза меньше опорной частоты кадров один кадр будет вычитываться ровно 3 раза.

 

При меньшей частоте кадров источника вычитывание одного кадра изредка будет производиться 2 раза, а в основном 3 раза.

 

При большей частоте кадров источника вычитывание одного кадра изредка будет производиться 4 раза, а в основном 3 раза.

 

[alexkarnaukhov 0]

zxcv спасибо вам конечно за ответ, ваш вариант я реализовал почти сразу, но нас он не очень-то устраивает - во-первых задержка между считыванием кадра с сенсора и его выводом на bt656 будет медленно плавать от 0 до 40мс, а хотелось бы обеспечить минимальную задержку. во-вторых нам по некоторым соображениям, связанным с дальнейшей обработкой видеосигнала будет не очень удобно работать с потоком, в котором интервал между обновлением картинки меняется от 2 до 3 или от 3 до 4.

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

Кстати с синхронизацией сенсора по внешнему импульсу тоже не все гладко оказалось, глючит иногда, но это все решаемо...

[Alex11 3]

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

[alexkarnaukhov 0]

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

Да, будет так называемый эффект "tearing". Так что сейчас я просто синхронизирую само чтение из сенсора, благо все-таки удалось от него этого добиться.

[zxcv 0]

Описанная Вами ошибка по частоте 0.0001% это 1 ppm.

Не нашел какая ошибка по частоте допустима в стандарте ITU-R BT.656, но в стандарте MPEG-2 ISO/IEC 13818-1 (ITU-T H.222.0) допустимая погрешность системной частоты 27 МГц составляет ±30 ppm.

 

Как вариант.

Можете попробовать подстроить схемой ФАПЧ частоту 27 МГц по уровню заполнению буфера входными данными.

Это позволит Вам после захвата петли ФАПЧ выводить видео практически без задержки.