Синхронизация вывода видео на 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 на этих разрешениях. И это несовпадение периодов приводит к тому, что выходной видеобуффер либо постоянно переполняется, либо слишком быстро опустошается, в зависимости от того какое разрешение масштабируется. Вот и сижу ломаю голову как правильно синхронизировать новый отмасштабированный видеопоток с выходным разрешением. Очень хотелось бы услышать подсказку от более опытных коллег !

[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 без внешнего буффера работает - пока загадка. Проведу ещё пару экспериментов и скорее всего начну делать двойную или тройную буфферизацию.

[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

[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. А если необходимо обойтись без внешней памяти для буферизации? менять пиксельклок?

[Flip-fl0p]

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

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

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

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

[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 будет определяться качеством синхронизации.

[Alexey_Rostov]

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

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

[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]

Берем 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 разрыв. Кадр не отобразится на мониторе.