Привет всем!

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

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

Два варианта:
1.Засинхронизировать матрицу с клоком 27мгц, а точнее выставить кадровую частоту точно кратно 25 (25/2 или 25/4)
2.Если известен приёмник принимающий bt656 то просто проверить его способность принимать на другой частоте.

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

Вы не догавариваете: что сенсор выдаёт вообще аналоговый сигнал? без тактов?
Приёмник может также тупо считать такты и когда blanking будет не тем он может глюкнуть.
Прогнать весь сигнал через Фифо и в конце выбрость или добавить нужные такты, благо их не много.

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

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

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

Упрощённый принцип его действия такой:
На частоте источника сигнала в первую часть буфера записывается кадр.
Далее, во вторую часть буфера, идёт запись следующего кадра.
Далее, опять в первую часть буфера, идёт запись следующего кадра.

Как только первый кадр записан, на опорной частоте начинаем вычитывание первого кадра.
Если к моменту окончания вычитывания первого кадра второй кадр ещё не записан полностью,
то повторно вычитываем первый. (Это случай в котором частота источника меньше опорной.)
Это будет повтор кадра.

В случае, если частота источника больше опорной, к моменту окончания вычитывания
первого кадра будет начата запись третьего кадра в первую половину буфера.
Пропустим вычитывание второго кадра, сразу перейдём к вычитыванию третьего.
Это будет пропуск кадра.


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

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

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

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

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

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

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

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