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

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

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

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

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


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

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

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

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

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

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

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

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


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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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


И сли отклонение частоты 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.

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



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

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



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

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

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 строчных синхры - потом пропуск. Его что тоже никуда не подключишь?

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


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

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

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

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

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




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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

По-моему, у 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. "

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

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

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

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


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


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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

alt_vip_cvo

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



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

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

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

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


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

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

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

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

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

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

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



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

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

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

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

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



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

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

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

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

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

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

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

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

VESA стандарт pdf

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

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

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

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