Синхронизация вывода видео на VGA монитор, Как синхронизировать отмасштабированное видео c VGA монитором Опции

[Flip-fl0p]

Приверствую уважаемые посетители форума !
Возник вопрос про синхронизацию вывода изображения на VGA.
Поскольку альтеровское ядро scaler II"платное" - пришлось разработать собственный scaler в основе которого лежит алгоритм билинейной интерполяции.
Особых проблем при написании scaler у меня не возникло и моделирование показывает - что все работает правильно.
Но я столкнулся с тем, что никак не могу придумать как правильно синхронизировать вывод отмасштабированного видео с новым разрешением.
Чуть подробнее про проблему:
Допустим что scaler понижает масштаб видео с 800х600х60hz (Vertical refresh 37.878787878788 kHz) до 640х480х60Hz (Vertical refresh 31.46875 kHz). Так вот у нас получается, что не совпадают периоды Vertical refresh на этих разрешениях. И это несовпадение периодов приводит к тому, что выходной видеобуффер либо постоянно переполняется, либо слишком быстро опустошается, в зависимости от того какое разрешение масштабируется. Вот и сижу ломаю голову как правильно синхронизировать новый отмасштабированный видеопоток с выходным разрешением. Очень хотелось бы услышать подсказку от более опытных коллег !

[warrior-2001]

Берем 3 буффера.
В один пишем, из другого читаем, третий на подхвате (кто раньше освободится - чтение или запись).
И так по кругу - для чтения берем последний записанный, для записи - любой свободный. Увеличивая количество буфферов мы получаем меньшую вероятность потери/дублирования кадров.
Или я не правильно понял вопрос?

[Flip-fl0p]

Или я не правильно понял вопрос?

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

[prostoRoman]

...
Возник вопрос про синхронизацию вывода изображения на VGA.
... пришлось разработать собственный scaler ...

Допустим что scaler понижает масштаб видео с 800х600х60hz (Vertical refresh 37.878787878788 kHz) до 640х480х60Hz (Vertical refresh 31.46875 kHz). Так вот у нас получается, что не совпадают периоды Vertical refresh на этих разрешениях. И это несовпадение периодов приводит к тому, что выходной видеобуффер либо постоянно переполняется, ...

У Вас кадровые частоты всегда равны?

Если да, то так существенно проще синхронизировать начало вывода картинки с окончанием получения исходной. Тогда может пересмотреть архитектуру формирования вывода?


Что если сделать так:

1. По поступлению входного кадра формировать пиксель выходной кадр изображения в выходной буффер (допустим с двумя портами: первый на запись, второй на чтение).

2. Простенькая схема формирования выхода со своим, в общем случае, независимым пиксельклоком формирует выходные сигналы стандартным образом.

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

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

[_4afc_]

Допустим что scaler понижает масштаб видео с 800х600х60hz (Vertical refresh 37.878787878788 kHz) до 640х480х60Hz (Vertical refresh 31.46875 kHz).

Не понял. У вас строчная потоков данных 600*60=36000 и 480*60=28800.

А уж с какой частотой вы собрались со всеми полями выдавать 28800 - это ваше дело.

[Flip-fl0p]

У Вас кадровые частоты всегда равны?

Нет. Входная кадровая частота зависит от входного разрешения, которое может быть любым начиная от 640x480 заканчивая 1680x1050. Выходная кадровая всегда одинаковая. Например 1024х768. Scaler автоматически определяет входное разрешение и перенастраивает свои коэффициенты.
Самое интересное, что в Альтеровских IP корках - они как-то реализовали это без применения внешнего буфера.
Но для начала будем считать что они фиксированы. Для начала я хочу сделать масштабирование какого-то фиксированного разрешения, чтобы разобраться. А далее буду "прикручивать" возможность детектирования входного разрешения.

Не понял. У вас строчная потоков данных 600*60=36000 и 480*60=28800.
А уж с какой частотой вы собрались со всеми полями выдавать 28800 - это ваше дело.

Не совсем понял Вас. Т.е Вы предлагаете отойти от стандартов VESA и выдавать строки быстрее чем того требуется ? Или я не так понял ?

[_4afc_]

Не совсем понял Вас. Т.е Вы предлагаете отойти от стандартов VESA и выдавать строки быстрее чем того требуется ? Или я не так понял ?

Возьмите картинку 800x600 отскалируйте её до 640x480 и выведите в левом верхнем углу экрана 800х600.

Что нам останется сделать чтобы получить 640x480@60 ? Очевидно не выводить некоторые строки снизу и подрезать длину строки.

С какой там точностью VESA от вас требует Vertical refresh 31.46875 kHz?

[Flip-fl0p]

С какой там точностью VESA от вас требует Vertical refresh 31.46875 kHz?

Про точность Vertical refresh не скажу т.к стандарта у меня нет, и боюсь никогда не будет , а на просторах сети, я не встретил каких-либо рекомендаций. Да и до этого работал по принципу: что указано на сайте http://tinyvga.com/vga-timing то и применял. Но опыт работы показывает что в несколько процентов ошибка вполне допустима. Т.к PLL например не всегда позволяет получить с большой точностью необходимый pixel_clk.

Возьмите картинку 800x600 отскалируйте её до 640x480 и выведите в левом верхнем углу экрана 800х600.

Что нам останется сделать чтобы получить 640x480@60 ? Очевидно не выводить некоторые строки снизу и подрезать длину строки.

Так это понятно. Можно вообще посередине экрана вывести. Вот только есть один нюанс: картинка поступает с разрешением 800x600 и после масштабирования становится с другим разрешением. Но выводится то она так-же на разрешение 800х600. И тут фактически частота поступления данных и частота вывода данных одна и та-же. В таком ключе задача то вообще простая.

А в моем случае есть ЖК матрица, тайминги которой соответствуют VESA. И понимает она только одно разрешение: 1024х768 60 Hz.
А входной видеопоток может быть любым: от 640x480 до 1680x1050 60 Hz. И задача состоит в том, чтобы преобразовать входной поток в разрешение ЖК матрицы. Я прекрасно осознаю, что в процессе преобразования может быть небольшое искажение данных, и качество "неродного" разрешения будет хуже....
Так вот я сейчас тестирую scaler на обычном VGA мониторе. Пытаюсь входной видеопоток 800х600 понизить до 640x480 и вывести в формате 640x480. Такие разрешения выбрал просто "на шару". Первое что попало в голову. Вот тут я и перестал понимать, как это сделать.
P.S. Прошу прощения за тупые вопросы, но мозг уже слишком зациклился на текущей задаче и могу банально тупить и не видеть решения перед носом....

[_4afc_]

Так это понятно. Можно вообще посередине экрана вывести. Вот только есть один нюанс: картинка поступает с разрешением 800x600 и после масштабирования становится с другим разрешением. Но выводится то она так-же на разрешение 800х600. И тут фактически частота поступления данных и частота вывода данных одна и та-же. В таком ключе задача то вообще простая.

У вас тоже простая:

1. Частота кадров одинаковая

2. За один кадр приходит 600 строк выходит 480 строк.

3. На каждые пришедшие 5 строк выдаётся синхронно 4 строки.

4. в каждой принятой строке 800 пиксель клоков внутри строчной - в каждой отданной - 640.

Размер буфера - 5 строк, если интерполировать надо.

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

[Plain]

1080 / 768 = 1,4 строки FIFO, округляется до 2, плюс 1 строка — итого, 3 строки на FIFO и N строк на интерполятор.

FIFO виртуальный — при смене выдаваемой строки его целые строки переходят интерполятору, а FIFO — выпавшие интерполятора.

Частота кадров естественно одна и её естественно задаёт источник.

[warrior-2001]

Я вот так и не понять сути проблемы.
Указал выше, что если скорость получения данных и скорость выдачи отличаются - то в результате как не крути, либо иногда будут выдаваться два подряд одинаковых кадра, либо некоторые кадры будут пропадать.
Всё просто.

[Flip-fl0p]

Мне стыдно признаться, но даже сейчас я не совсем Вас понимаю . Возможно связано с тем, что я сам себя своими рассуждениями загнал в тупик и не вижу способа из него выбраться.
Попробую обьяснить свою логику, может так получится понять друг друга и если я ошибаюсь мне укажут на ошибку в моих рассуждениях.
Итак, за основу своих рассуждений я беру следующую аксиому: для того чтобы вывести на матрицу правильно изображение я должен выполнить требования стандарта VESA, а именно:

Код

pixel_clk    25.175 MHz
Visible area 640    pixel    
Front porch     16     pixel    
Sync pulse     96     pixel    
Back porch     48     pixel    
Visible area 480    lines
Front porch     10     lines
Sync pulse     2        lines
Back porch     33     lines

И сли отклонение частоты pixel_clk ±100...500 КГц еще допускается, то изменение длительности Front porch, Back porch приводит к тому, что видимая область изображения будет отображаться за пределами экрана, т.е часть выводимого изображеня будет обрезана. Неточность же Sync pulse приводит к тому, что матрица вообще может отказываться понимать входной видеосигнал.

Итого мы имеем 3 клоковых домена:
Домен Vga_sync_gen - синхрогенератор, который генерирует сигналы H_sync, V_sync, Data_enable для разрешения 640х480х60Hz
Домен source_data - источник виедосигнала, данные которого я масштабирую. Он имеет свои синхросигналы H_sync, V_sync, Data_enable, имеет свой pixel_clk 40MHz.
Домен scaler - собственно сам scaler который работает на частоте выше доменов Vga_out и source_data. Это сделано специально для того, чтобы scaler успевал обрабатывать данные независимо от входной или выходной частоты.

Данные из домена source_data посредством FIFO переносятся в домен scaler, обрабатываются там по алгоритму билинейной интерполяции и scaler выдает сигналы:
Данные нового отмасштабированного пикселя new_pixel.
Сигнал Data_valid - показывающий что данные нового пикселя можно использовать.
Сигнал SOL (start of line ) - сообщающий что это у нас первый пиксель в линии.
Сигнал EOL (end of line ) - сообщающий что это у нас последний пиксель в линии.
Сигнал SOF (start of frame) - сообщающий что это у нас первый пиксель кадра.
Сигнал EOF (end of frame) - сообщающий что это у нас последний пиксель в кадре.


Вы говорите, что:

Частота кадров одинаковая.

Но ведь кадровые синхроимпульсы формируются на разных частотах, и частота кадров реально будет разная.
Например прии разрешении 640x480 частота кадров 16.683217477656 ms.
А вот на разрешении 800х600 частота кадров уже 16.5792 ms.

С этими я полностью согласен, да это и так вроде очевидно :

2. За один кадр приходит 600 строк выходит 480 строк.
3. На каждые пришедшие 5 строк выдаётся синхронно 4 строки.
4. в каждой принятой строке 800 пиксель клоков внутри строчной - в каждой отданной - 640.

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

А вот это утверждение уже интересно, и непонятно одновременно. У нас же после строчного импульса - каждый клок начинает отсчитывать рамку Front porch. Соответственно через определенное количество импульсов у нас должны быть поданы данные. Иначе картинка будет смещена относительно краев видимой области.

Для примеря я покажу структуру проекта.



Источник разрешения 800x600 сейчас находится внутри FPGA, но в последствии это будет отдельное внешнее устройство. Сейчас для отладки так удобнее. Поэтому на блок-схеме он изображен пунктиром

[_4afc_]

А я считаю, что

1. Back porch 48 pixel - может быть хоть 148
2. Back porch 33 lines - может быть хоть 133
3. pixel_clk не 25.175 MHz, а 25 175 000 импульсов в секунду, с довольно свободной скважностью.

у меня покупной видеодатчик, когда из 1600х1200 делает 640х480 выдаёт 4 строчных синхры - потом пропуск. Его что тоже никуда не подключишь?

[warrior-2001]

у меня покупной видеодатчик, когда из 1600х1200 делает 640х480 выдаёт 4 строчных синхры - потом пропуск. Его что тоже никуда не подключишь?

Отчего же, подключишь. Туда, где есть входной видеобуфер.


По теме - может эта ссылка поможет в понимании вопроса.
https://www.intel.com/content/dam/altera-ww...re/an/an648.pdf

[ikm]

у меня покупной видеодатчик, когда из 1600х1200 делает 640х480 выдаёт 4 строчных синхры - потом пропуск. Его что тоже никуда не подключишь?

Хм, напрямую к VGA монитору? Тогда у вас на экране будет изображение размером 640х480, но разрешением 1600х1200, остальное черный экран. Если конечно контроллер сможет правильно воспринять, что вы на него подаете. А ТС нужно именно "размытие" кадра 640х480 на весь монитор

[_4afc_]

Но ведь кадровые синхроимпульсы формируются на разных частотах, и частота кадров реально будет разная.
Например при разрешении 640x480 частота кадров 16.683217477656 ms.
А вот на разрешении 800х600 частота кадров уже 16.5792 ms.

Нет. Частота кадров у вас будет та же как пришла 60Гц или 59,94Гц. Иначе вам придётся кадры иногда пропускать или дублировать.

И частота строк у вас будет пропорциональна входной с учётом полей.

Если полученный сигнал не возьмёт дисплей - значит входной до ресайза - кривой.

Хм, напрямую к VGA монитору? Тогда у вас на экране будет изображение размером 640х480, но разрешением 1600х1200, остальное черный экран. Если конечно контроллер сможет правильно воспринять, что вы на него подаете. А ТС нужно именно "размытие" кадра 640х480 на весь монитор

не будет. потому что пока строчная равна нулю - данные не выводятся.

[prostoRoman]

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

Ещё раз посоветую Вам произвести декомозицию проблемы, сделайте и отладьте простые вещи.

Если ресурсы позволяют:

1. Сделайте генератор видео из фреймбуфера. (то, что у Вас на схеме VGA_SYNC_GEN + кусок ОЗУ с картинкой)

2. Сделайте и отладьте свой скайлер.

3. В тупую соедините это дело и посмотрите что Вас не устраивает.

4. Итеративно добавляйте функционал: двойную/тройную буферизацию, синхронизацию и т.д.

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

[_4afc_]

А в моем случае есть ЖК матрица, тайминги которой соответствуют VESA. И понимает она только одно разрешение: 1024х768 60 Hz.
Так вот я сейчас тестирую scaler на обычном VGA мониторе.

Вот зачем? Почему сразу не на ЖК матрице 1024х768?

Она по своему может интерпретировать кадровую и строчную.
По своему определять наличие синхронизации.
По своему реагировать на иголки на пиксельклоке...

Может задача проще, чем то как вы её решаете...

[Flip-fl0p]

Ещё раз посоветую Вам произвести декомозицию проблемы, сделайте и отладьте простые вещи.

Если ресурсы позволяют:

1. Сделайте генератор видео из фреймбуфера. (то, что у Вас на схеме VGA_SYNC_GEN + кусок ОЗУ с картинкой)

2. Сделайте и отладьте свой скайлер.

3. В тупую соедините это дело и посмотрите что Вас не устраивает.

4. Итеративно добавляйте функционал: двойную/тройную буферизацию, синхронизацию и т.д.

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

Так с видео буфером не интересно . Шутка...
С внешним буфером на SDRAM сделать это вообще не проблема, благо есть нормальный самописный контроллер., но мне ресурсы SDRAM нужны, для реализации режима PIP (картинка в картинке), поскольку планируется вывод изображения на матрицу с двух независимых источников DVI видеосигнала Хотя память работает на частоте 144 Мгц - то может на определённом соотношении выходных разрешений после скалеров её и будет хватать, надо эту мысль подумать.
Во всяком случае IP ядра Altera (но они гады платные) делают все то, что я хочу без внешних буферов. А раз делают они, значит и я смогу, надо просто разобраться с алгоритмом. Сейчас некоторые мысли появились после слов:

А я считаю, что
1. Back porch 48 pixel - может быть хоть 148
2. Back porch 33 lines - может быть хоть 133
3. pixel_clk не 25.175 MHz, а 25 175 000 импульсов в секунду, с довольно свободной скважностью.

Надо попробовать и потестировать...

[Plain]

покажу структуру проекта

Итого, никакой синхронизации нет вообще, тогда как тема именно о ней.

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

[Sergey_Bekrenyov]

По-моему, у TC в голове все смешалось. Scaler только масштабирует, согласовывать частоты кадров - не его задача

https://www.intel.com/content/dam/altera-ww...e/ug/ug_vip.pdf

"The Scaler II IP core resizes video streams, and supports nearest neighbor, bilinear, bicubic and polyphase (with or without simple edge adaptation) scaling algorithms."

"The locked frame rate conversion allows the Frame Buffer II IP core to synchronize the input and output frame rates through an Avalon-MM slave interface. "

[Flip-fl0p]

По-моему, у TC в голове все смешалось. Scaler только масштабирует, согласовывать частоты кадров - не его задача

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

[Flip-fl0p]

Итак господа, провел вчера весь вечер за эксперементами. В качестве эксперемента был применен обычный синхрогенератор и генератор цветных полос. Выводы таковы:

1. Back porch 48 pixel - может быть хоть 148
2. Back porch 33 lines - может быть хоть 133
3. pixel_clk не 25.175 MHz, а 25 175 000 импульсов в секунду, с довольно свободной скважностью.

Данное утвержение мной не совсем подтвердилось. Собственно произошло ровно то, о чем я говорил : изменение любого из параметров Back porch в небольших пределах приводит к тому что изображение смещается. Если же изменять это значение в больших пределах - то матрица не определяет синхронизациию и изображение не выводится вообще...
Но ! Если изменить соотношение Back porch и Front porch таким образом, чтобы суммарная длина строки оставалась одинаковой (для разрешения 640 x 480 длина линии равна 800 pix) - то изображение нормальное т.е. если мы увеличили значение Back porch на 50 то должны и уменьшить Front porch на 50. В случае если длина строки изменяется: Back porch увеличили на 50 а Front porch не трогали - требуется пререрасчет частоты и в этом случа мы фактиески получаем новое разрешение, которое совместимо с большинством VGA мониторов.
Думаю, можно попробовать применить данный способ в качестве синхронизации с источником. Но надо проверять на живой матрице, поймет ли она тайминги, не совпадающие с теми, что указаны в datasheet на неё. Похоже на очень и очень грязный хак. Но может и сработает !

у меня покупной видеодатчик, когда из 1600х1200 делает 640х480 выдаёт 4 строчных синхры - потом пропуск. Его что тоже никуда не подключишь?

А можно узнать параметры выходных синхросигналов которые выдает датчик:
Какая частота pixel_clk
Каковы параметры Back porch, Front porch, sync pulse, полярность импульсов ?
Неужто он выдает 4 строчки с параметрами VESA 640х480, затем делает пропуск в одну строчку. затем опять выдает 4 строчки ? И все это делает с частотой pixel_clk разрешения 1600х1200 ?

Почему сразу не на ЖК матрице 1024х768?

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

Итого, никакой синхронизации нет вообще, тогда как тема именно о ней.

Тема была о том, как сделать такую синхронизацию...

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

А не будет так работать, поскольку формируя сигнал сброса по началу данных от источника - мы фактически искажаем периоды front_porch нашего выходного сигнала со всеми вытекающими последствиями в виде сдвига изображения. И пока мы передаем сигнал из домена source_data в домен Vga_sync_gen для формирования сброса - мы натыкаемся на 1 такт нестабильности - что приводит к неравномерному периоду front_porch - что приводит к дерганию изображения и сильнейшему искажению. Если интересно могу фотографию сделать, ибо этот вариант я сразу попытался применить.

Как мне кажется без буфферизации кадров во внешнем буффере не обойтись. Хотя как в IP ядрах Altera без внешнего буффера работает - пока загадка. Проведу ещё пару экспериментов и скорее всего начну делать двойную или тройную буфферизацию.

[warrior-2001]

Ну я же скинул ссылку на проект рабочий от Альтеры. Там и фрейм-буферы и масштабаторы!

[Flip-fl0p]

Ну я же скинул ссылку на проект рабочий от Альтеры. Там и фрейм-буферы и масштабаторы!

Просто мне очень хочется разобраться как Altera сделала синхронизацию без применения внешнего буфера !
Я специально создал в Qsys проект где есть генератор тестовых сигналов 800х600 и скалер, который понижает до 640х480... И ведь работает гад без всяких внешних буферов !
А за ссылочку спасибо изучаю её !

[Plain]

Тема была о том, как сделать такую синхронизацию

На вход подано неизвестных размеров изображение, следовательно:

1) измерить его размеры, для чего посчитать в его CLK длину его DE и количество DE за интервал его VS;

2) на основе этих данных пересчитать коэффициенты интерполятора и задать длину всех буферов;

3) измерить интервал от VS до DE и посчитать требуемую положительную или отрицательную задержку для получения в требуемый, т.е. с учётом задержки на FIFO, момент аналогичных выходных сигналов;

4) по очередному входному VS зафиксировать собранные данные в качестве новых настроек выходного автомата и начать выдачу им сигналов;

5) продолжать измерять всё вышеперечисленное.

[Sergey_Bekrenyov]

.. от Scaler. Он занимается только преобразованием разрешения, и выдает сигналы начала кадра, конец кадра, начала строки, конец строки и строб валидности данных...

Scaler получается генерирует синхронизацию, а не только масштабирует?

Ваш генератор синхросигналов для монитора должен быть мастером и забирать данные из буфера. Как сказал Warrior-2001, 3 (или больше) буффера позволят дропать или повторять кадры. На частоте 60 Гц человек это не почувствует.

[Flip-fl0p]

Scaler получается генерирует синхронизацию, а не только масштабирует?

Ваш генератор синхросигналов для монитора должен быть мастером и забирать данные из буфера. Как сказал Warrior-2001, 3 (или больше) буффера позволят дропать или повторять кадры. На частоте 60 Гц человек это не почувствует.

Там немного не так.
Есть у них модуль scaler - который масштабирует.
Есть модуль clocked_video_output который генерирует синхросигналы, но к сожалению его исходнтки закрыты.
Сейчас собственно пишу тройную буфферизацию, которая будет либо повторять кадры, либо пропускать.

[Sergey_Bekrenyov]

Там немного не так.
Есть у них модуль scaler - который масштабирует.
Есть модуль clocked_video_output который генерирует синхросигналы, но к сожалению его исходнтки закрыты.
Сейчас собственно пишу тройную буфферизацию, которая будет либо повторять кадры, либо пропускать.

Вы же писали в ветку с декриптованными, там и vip есть https://electronix.ru/forum/index.php?act=a...t&id=113329

[Flip-fl0p]

Вы же писали в ветку с декриптованными, там и vip есть https://electronix.ru/forum/index.php?act=a...t&id=113329

Да я как-то там не нашел такого модуля как clocked_video_output...
Может в 16 Quartus он по-другому уже называется. Завтра попробую скачать и посмотреть там

[lembrix]

Данное утвержение мной не совсем подтвердилось. Собственно произошло ровно то, о чем я говорил : изменение любого из параметров Back porch в небольших пределах приводит к тому что изображение смещается. Если же изменять это значение в больших пределах - то матрица не определяет синхронизациию и изображение не выводится вообще...

Странно. Я тоже думаю, что вот эти неактивные интервалы между строками и кадрами (front porch, back porch) допускается менять в определенных пределах. Разумеется pixel clock при этом тоже плавает. Но на параметры изображения это не должно влиять, разрешение и частота кадра остаются постоянными (частота строк может при этом совпадать, а может и нет).
Я делал вывод изображения на промышленную матрицу, в спецификации на нее было указаны разрешенные диапазоны для всех этих porch-ей. Например, Vertical front porch: min = 7, recomended = 51, max = 100. Правда, horizontal back porch и vertictal back porch по спецификации менять не разрешалось, они были заданы строго.
А по задаче, самое универсальное решение это буфер на весь кадр в DDR-памяти.

Сообщение отредактировал lembrix - Aug 24 2018, 07:12

[Sergey_Bekrenyov]

Да я как-то там не нашел такого модуля как clocked_video_output...
Может в 16 Quartus он по-другому уже называется. Завтра попробую скачать и посмотреть там

alt_vip_cvo

[Alexey_Rostov]

Странно. Я тоже думаю, что вот эти неактивные интервалы между строками и кадрами (front porch, back porch) допускается менять в определенных пределах. Разумеется pixel clock при этом тоже плавает. Но на параметры изображения это не должно влиять, разрешение и частота кадра остаются постоянными (частота строк может при этом совпадать, а может и нет).
Я делал вывод изображения на промышленную матрицу, в спецификации на нее было указаны разрешенные диапазоны для всех этих porch-ей. Например, Vertical front porch: min = 7, recomended = 51, max = 100. Правда, horizontal back porch и vertictal back porch по спецификации менять не разрешалось, они были заданы строго.
А по задаче, самое универсальное решение это буфер на весь кадр в DDR-памяти.

Решаю аналогичную задачу, только интерфейс HDMI. Действительно porch можно менять в определенных пределах. Масштабирование получилось только если выдавать синхросигналы все на своих местах (кроме datavalid), изменять только datavalid сигнал, причем сначала необходимо выдавать все активные пиксели.

Возьмите картинку 800x600 отскалируйте её до 640x480 и выведите в левом верхнем углу экрана 800х600.

Можно поподробней про "отскалируйте". Как я понимаю делаем следующее: прореживаем каждую линию видео кадра, буферизируем полученный масштабированный кадр и выдаем его на экран 800х600. А если необходимо обойтись без внешней памяти для буферизации? менять пиксельклок?

[_4afc_]

Можно поподробней про "отскалируйте". Как я понимаю делаем следующее: прореживаем каждую линию видео кадра, буферизируем полученный масштабированный кадр и выдаем его на экран 800х600. А если необходимо обойтись без внешней памяти для буферизации? менять пиксельклок?

Если без внешней памяти, то нужна внутренняя память на как минимум на 4*640 точек (может две таких для буферизации двойной)

Тогда 800*5 валидных клоков надо заменить на 640*4. Т.е. на каждые 25 входящих выдать 16 наружу.

[Flip-fl0p]

Можно поподробней про "отскалируйте". Как я понимаю делаем следующее: прореживаем каждую линию видео кадра, буферизируем полученный масштабированный кадр и выдаем его на экран 800х600. А если необходимо обойтись без внешней памяти для буферизации? менять пиксельклок?

Прореживание дает уж больно некрасивый результат. Примените тогда уж алгоритм ближайшего соседа...

Если без внешней памяти, то нужна внутренняя память на как минимум на 4*640 точек (может две таких для буферизации двойной)
Тогда 800*5 валидных клоков надо заменить на 640*4. Т.е. на каждые 25 входящих выдать 16 наружу.

А если не сложно то скажите с какими параметрами идет выходной сигнал ?
Частота Pixel_clk как я понимаю соответствует входному разрешению. А полярность кадрового и строчного импульса, их длительность чему должны соответствовать ?

[_4afc_]

А если не сложно то скажите с какими параметрами идет выходной сигнал ?
Частота Pixel_clk как я понимаю соответствует входному разрешению. А полярность кадрового и строчного импульса, их длительность чему должны соответствовать ?

Я ответил про вариант когда на выходе экран 640х480 и малый буфер.

Когда на выходе 800х600 - красиво не получится, надо что-то в 5 строку пихать - или нули или дублировать. Но для отладки алгоритма пойдёт.

[Alexey_Rostov]

Прореживание дает уж больно некрасивый результат. Примените тогда уж алгоритм ближайшего соседа...


А если не сложно то скажите с какими параметрами идет выходной сигнал ?
Частота Pixel_clk как я понимаю соответствует входному разрешению. А полярность кадрового и строчного импульса, их длительность чему должны соответствовать ?

У меня задача попроще чем у ТС. Входной поток 1280х720 60 Гц (74.25 МГц пиксельклок). Необходимо масштабировать с коэффициентом равным 2, т.е. получить 640х360 разрешение. При этом алгоритм использует только внутреннюю память ПЛИС, т.е. места для хранения всего кадра нет.

Решение вижу следующее:

1. Генерировать пиксельклок ниже чем 74.25 (при этом как прочитал выше значение частоты выбирается согласно стандарта VESA), использовать буферизацию только по одной линии и расставлять согласно стандарта vsync, hsync со своими back\front porch'ами и длительностями. При этом в буфер записывать каждый второй пиксель.

Кто нибудь реализовывал аналогичным способом или есть другой вариант?

Если без внешней памяти, то нужна внутренняя память на как минимум на 4*640 точек (может две таких для буферизации двойной)

Тогда 800*5 валидных клоков надо заменить на 640*4. Т.е. на каждые 25 входящих выдать 16 наружу.

Собрал свой источник видеосигнала 1280х720 60 Гц, уменьшал зону active pixel в несколько раз, монитор кадры отображает. Если в зоне active pixel бланкировать через линию и в линии через пиксель (для масштабирования на 2), то монитор не отображает видео кадр. Отсюда вывод: зона active pixel должна быть без разрывов.

[Plain]

1280х720 60 Гц ... получить 640х360

Надо усреднять 2х2 точки, разбирать входной кадр и синхронизироваться с ним вышеописанным способом, потому что интервалы гашения имеют право быть произвольными. Соответственно, для усреднения достаточно буфера на одну строку длиной 640 точек и чередования, но размер FIFO будет определяться качеством синхронизации.

[Flip-fl0p]

В 2 раза уменьшить - вообще легко: берете данные цвета от каждого из 4 соседних пикселей и вычисляете среднее арифметическое между ними.
Можете глянуть как у меня это сделано:

Прикрепленные файлы

 CALC_pipeline.vhd ( 9.62 килобайт ) Кол-во скачиваний: 7

 

[Alexey_Rostov]

Надо усреднять 2х2 точки, разбирать входной кадр и синхронизироваться с ним вышеописанным способом, потому что интервалы гашения имеют право быть произвольными. Соответственно, для усреднения достаточно буфера на одну строку длиной 640 точек и чередования, но размер FIFO будет определяться качеством синхронизации.

Данное усреднение или прореживание актуально только по горизонтальной развертке, тогда действительно пару буферов на 640 точек будет достаточно. Но как быть с вертикальной разверткой? Просто бланкировать каждую вторую линию для получения 360-ти линий не получится: зона active pixels должна быть без пропусков.

[_4afc_]

У меня задача попроще чем у ТС. Входной поток 1280х720 60 Гц (74.25 МГц пиксельклок).

Вот почему никто не указывает остальные параметры входного сигнала?

Собрал свой источник видеосигнала 1280х720 60 Гц, уменьшал зону active pixel в несколько раз, монитор кадры отображает. Если в зоне active pixel бланкировать через линию и в линии через пиксель (для масштабирования на 2), то монитор не отображает видео кадр. Отсюда вывод: зона active pixel должна быть без разрывов.

А никто вам не предлагал ничего бланкировать в синхре.
На две пришедшие строчные должна выйти одна строчная.

[Flip-fl0p]

Данное усреднение или прореживание актуально только по горизонтальной развертке, тогда действительно пару буферов на 640 точек будет достаточно. Но как быть с вертикальной разверткой? Просто бланкировать каждую вторую линию для получения 360-ти линий не получится: зона active pixels должна быть без пропусков.

Берем 4 буфера:
buff0 - на пол строки.
buff1 - на пол строки.
buff2 - на 1 пиксель. (Фактически обычный регистр с сигналом разрешения)
buff3 - на 1 пиксель. (Фактически обычный регистр с сигналом разрешения)
Начинаем писать видеоданные первой строки:
В buff0 - пишем нечетные пиксели.
В Buff1 - пишем четные пиксели.
В итоге мы имеем всю строку записанную в буфер.
Когда пошла вторая строка - опять записываем сначала четные пиксели но уже в buff2 , и нечетные пиксели в buff3.
Как только у вас будут записаны данные в buff3 вы фактически получили 4 пикселя в буфферах из которых можно будет рассчитать банальным усреднением новый пиксель.
Выглядит это так (цифра- номер буфера куда пишутся пиксели):

Код

-- |                 | Верхняя строка: 0 1  0 1  0 1  0 1  0 1  0 1  0 1  0 1  0 1  
-- |                 | Нижнняя строка: 2 3  2 3  2 3  2 3  2 3  2 3  2 3  2 3  2 3

Соответственно у вас по горизонтали и по вертикали картинка будет в 2 раза меньше. Качество выходного видео- вполне нормальное. Не билинейная интерполяция конечно. Но и алгоритм с математикой простейшие.

[Alexey_Rostov]

Вот почему никто не указывает остальные параметры входного сигнала?

остальные параметры из VESA стандарта

// Pixel Clock 74.25 MHz
// Pixel Time 13.468 ns
// Active Pixels 921,600 total
// 8-bit Memory 7,200 Kbits
// 32-bit Memory 28,800 Kbits
// Data Rate 1.78 Gbps

// Horizontal Timings
// Active Pixels 1280
// Front Porch 72
// Sync Width 80
// Back Porch 216
// Blanking Total 368
// Total Pixels 1648
// Sync Polarity pos

// Vertical Timings
// Active Pixels 720
// Front Porch 3
// Sync Width 5
// Back Porch 22
// Blanking Total 30
// Total Pixels 750
// Sync Polarity pos




А никто вам не предлагал ничего бланкировать в синхре.
На две пришедшие строчные должна выйти одна строчная.

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

[Plain]

пару буферов на 640 точек будет достаточно. Но как быть с вертикальной разверткой?

Суммируете входную точку с буфером, если это чётная строка, либо с нулём, если нечётная, и записываете сумму в тот же буфер, суммируете следующую точку с этим же буфером и записываете сумму в него же, увеличиваете указатель буфера, по окончании работы входного и выходного буферов, т.е. по началу обоих строчных интервалов гашения, меняете буферы местами.

[Alexey_Rostov]

Берем 4 буфера:
buff0 - на пол строки.
buff1 - на пол строки.
buff2 - на 1 пиксель. (Фактически обычный регистр с сигналом разрешения)
buff3 - на 1 пиксель. (Фактически обычный регистр с сигналом разрешения)
Начинаем писать видеоданные первой строки:
В buff0 - пишем нечетные пиксели.
В Buff1 - пишем четные пиксели.
В итоге мы имеем всю строку записанную в буфер.
Когда пошла вторая строка - опять записываем сначала четные пиксели но уже в buff2 , и нечетные пиксели в buff3.
Как только у вас будут записаны данные в buff3 вы фактически получили 4 пикселя в буфферах из которых можно будет рассчитать банальным усреднением новый пиксель.
Выглядит это так (цифра- номер буфера куда пишутся пиксели):

Код

-- |                 | Верхняя строка: 0 1  0 1  0 1  0 1  0 1  0 1  0 1  0 1  0 1  
-- |                 | Нижнняя строка: 2 3  2 3  2 3  2 3  2 3  2 3  2 3  2 3  2 3

Соответственно у вас по горизонтали и по вертикали картинка будет в 2 раза меньше.

Сигнал valid в HDMI в течении линии будет прерываться, если я правильно понял. То есть записали в buf3 данные рассчитали первый выходной пиксель, как сумму четного, нечетного пикселя 1-ой и 2-ой строки, деленную на 4. Ждем пока запишется в buf3 четный пиксель второй строки, рассчитываем второй выходной пиксель. Когда ожидаем в сигнале valid разрыв. Кадр не отобразится на мониторе.

[Flip-fl0p]

Сигнал valid в HDMI в течении линии будет прерываться, если я правильно понял. То есть записали в buf3 данные рассчитали первый выходной пиксель, как сумму четного, нечетного пикселя 1-ой и 2-ой строки, деленную на 4. Ждем пока запишется в buf3 четный пиксель второй строки, рассчитываем второй выходной пиксель. Когда ожидаем в сигнале valid разрыв. Кадр не отобразится на мониторе.

Выдавайте через промежуточный буфер. Иначе никак....

[Alexey_Rostov]

Суммируете входную точку с буфером, если это чётная строка, либо с нулём, если нечётная, и записываете сумму в тот же буфер, суммируете следующую точку с этим же буфером и записываете сумму в него же, увеличиваете указатель буфера, по окончании работы входного и выходного буферов, т.е. по началу обоих строчных интервалов гашения, меняете буферы местами.

Приходит кадр из 720 строк, за длительность кадра необходимо выдать подряд 360 строк. Причем 360-ую строку буду формировать во время прихода 719 и 720. То есть в любом случае необходимо копить линии, т.к. нельзя выдать одну линию, следующую не выдавать (сигналы hsync и valid бланкированы).

VESA стандарт pdf

Прикрепленные файлы

 VESA_standart.pdf ( 790.41 килобайт ) Кол-во скачиваний: 9

 

[Plain]

360-ую строку буду формировать во время прихода 719 и 720

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

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

[Alexey_Rostov]

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

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

Собираемый выходной кадр необходимо хранить во внешней памяти, а у меня условие использовать только внутренние ресурсы ПЛИС.

[Plain]

Собираемый выходной кадр необходимо хранить во внешней памяти

С чего вдруг? Создание кадра — всего лишь создание трёх сигналов синхронизации.

[Alexey_Rostov]

С чего вдруг? Создание кадра — всего лишь создание трёх сигналов синхронизации.

Нет, во время Вы не можете, только по прошествии — я же сразу сказал, что входной кадр сперва надо разобрать, а выходной затем собрать...

[Plain]

Извлечение из поступающих сигналов полезной информации и создание из полезной информации исходящих сигналов — так понятнее?

Если Вы не способны создать синхронизацию, о чём собственно эта тема, то Вам, как и её автору, придётся делать послабление — сперва создание полного кадра в памяти, для эмоционального ощущения его целостности.

[Flip-fl0p]

Извлечение из поступающих сигналов полезной информации и создание из полезной информации исходящих сигналов — так понятнее?

Если Вы не способны создать синхронизацию, о чём собственно эта тема, то Вам, как и её автору, придётся делать послабление — сперва создание полного кадра в памяти, для эмоционального ощущения его целостности.

Так тема была создана для того, чтобы уважаемые гуру помогли помочь разобраться как правильно реализовать такую синхронизацию. И есть есть такой способ - то без применения внешнего кадрового буфера. И если мы не понимаем - чтобы нам дали пинка и разъяснили в чем мы не правы, и почему надо делать именно так, а не иначе, и данный процесс повторялся пока не наступит просветление в наших головах. Тогда и нам хорошо - мы поймем и будем знать как делать, и вам плюсик в карму. И база знаний накопится ещё одной толикой мудрости гуру(а форум я считаю в первую очередь отличной базой знаний), и вновь пришедшим и непросветлённым будет дана возможность созерцая эти страницы тоже наполниться мудростью...
Но уважаемые гуру лишь упрекают нас в неспособности создать такую синхронизацию....

Вот вы писали что:

На вход подано неизвестных размеров изображение, следовательно:
1) измерить его размеры, для чего посчитать в его CLK длину его DE и количество DE за интервал его VS;
2) на основе этих данных пересчитать коэффициенты интерполятора и задать длину всех буферов;
3) измерить интервал от VS до DE и посчитать требуемую положительную или отрицательную задержку для получения в требуемый, т.е. с учётом задержки на FIFO, момент аналогичных выходных сигналов;
4) по очередному входному VS зафиксировать собранные данные в качестве новых настроек выходного автомата и начать выдачу им сигналов;
5) продолжать измерять всё вышеперечисленное.

Тут понятно все кроме пункта 4.
Приведу картину для наглядности:

Из неё следует что одна строка состоит из:
1. Периода строчного импульса горизонтальной синхронизации(HSYNC)
2. Периода задней границы (Horisontal back porch).
3. Периода активных даных (data_enable).
4. Периода передней границы (Horisontal front porch).
Допустим я измерил интервал интервал времени источника от конца импульса VS до начала активных данных.
Получил некую константу. Что мне с ней делать ? Расскажите поподробнее про это, если Вас не затруднит...
Я изучаю исходники альтеры, и мне кажется скоро я плюну на это. Жуть жуткая. Несколько тысяч строк кода без комментариев и какой-либо логики...
PS UPD
А вообще тут правильно подметили, что такая синхронизация без применения внешнего буфера невозможна. Тому подтверждение найдено в xilinx appnote: https://www.xilinx.com/support/documentatio...g-with-vpss.pdf

[Plain]

измерил интервал времени источника от конца импульса VS до начала активных данных

Измерить реальный интервал (т.е. непрерывными собственными (выходными) тактами) от начала входного VS до конца первого входного DE и прибавить к этому задержку на FIFO, т.е. измеренный теми же единицами интервал DE, умноженный на размер FIFO — получится задержка готовности входных данных (т.е. завершения принятия N входных строк, требуемых для вычисления первой выдаваемой строки) от фронта кадрового синхроимпульса.

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

П.4 и п.5. напоминают о том, что о формате входного изображения всегда требуется знать всё, и он имеет право в любой момент смениться на другой, тупая молотилка захлебнётся.

[Flip-fl0p]

Огромное и Человеческое спасибо за то что вы пытаетесь нам помочь !
Но всё-же хотелось бы немного уточнить про выходной автомат.
Что понимается под термином "выходной автомат" ?

В моем случае в качестве автомата, который задает выходные синхроимпульсы - является пара автоматов:
Один прыгает по состояниям back_porch_st => visible_area_st => front_porch_st => HS_st => back_porch_st ... и.т.д. Он генерирует сигнал DE для горизонтальных линий, он генерирует сигнал строчной синхронизации, и генерирует сигнал окончания строки для второго автомата.
Другой автомат точно также прыгает по состояниям: back_porch_st => visible_area_st => front_porch_st => VS_st => back_porch_st ... И.Т.Д. Он принимает сигнал окончания строки от первого автомата считает строки и генерирует DE для вертикальных линий, генерирует сигнал кадровой синхронизации.
Фактически пара автоматов - реализуют классический синхрогенератор для генерации таймингов в соответствии с VESA.
Я могу запустить мой "синхрогенератор" в нужное мне время за счет того, что у меня автоматы начинают работу с состояния IDLE (которое нужно для первичной инициализации счетчиков, и возможности сброса синхрогенератора).

Я всё пытаюсь понять сказанное Вами, и никак не могу взять в толк, а что я должен делать с автоматом, чтобы добиться синхронности ?
Допустим я посчитал положительную или отрицательную задержку и запустил автомат в нужное время и первый кадр нового изображения вывелся как положено.
Но потом у нас получается, что в реальности новый кадр может начать генерироваться либо чуть раньше (относительно прошлого кадра, т.е мой синхрогенератор ещё не завершил работу - досчитывает длительность кадрового импульса), либо чуть позже (т.е выходной автомат начал рассчет back_porch_st нового кадра). Я могу даже величину этой рассинхронизации посчитать в pixel_clk нового изображениея. И для того чтобы синхронность не нарушилась я должен:
1. Либо раньше начать генерировать изображение, в случае если у нас входные кадры идут чуть чаще чем выходные. т.е не выдать полную длительность VSYNC а начать генерировать back_porch_st нового кадра.
2. Либо я должен чуть подождать при генерации нового изображения случае если у нас выходные кадры идут чуть медленнее чем выходные - т.е удлинить длительность back_porch_st нового кадра.
Но в обоих вариантах ожидание или "опережение" приводит к тому, что фактически искажается back_porch_st (в первой строке) что неминуемо ведет к искажению всего изображения (проверено на практике).

[Plain]

Для любой синхронизации естественно должен быть запас (на опережение/отставание) — в данном случае, запас по фазе.

Я не в курсе, может мониторы и в самом деле зачем-то считают CLK, тогда этот запас, например, должен быть в виде большей частоты этого CLK, т.е. требуемый фиксированный интервал реального времени, в нём фиксированная пачка импульсов и изменяемая пауза, чтобы количество CLK в каждом интервале гашения не менялось. Ну или сделать простецкую цифровую ФАПЧ, т.е. дискретно менять частоту CLK (неактивный его перепад), управляя его делителем измеренной фазовой ошибкой, запас будет гораздо больше, т.е. уже можно будет менять частоту кадров.