Jump to content

    

Синхронизация вывода видео на VGA монитор

Данное утвержение мной не совсем подтвердилось. Собственно произошло ровно то, о чем я говорил : изменение любого из параметров 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-памяти.

Edited by lembrix

Share this post


Link to post
Share on other sites
Да я как-то там не нашел такого модуля как clocked_video_output...

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

alt_vip_cvo

Share this post


Link to post
Share on other sites
Странно. Я тоже думаю, что вот эти неактивные интервалы между строками и кадрами (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. А если необходимо обойтись без внешней памяти для буферизации? менять пиксельклок?

Share this post


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

 

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

 

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

 

Share this post


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

 

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

 

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

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

А если не сложно то скажите с какими параметрами идет выходной сигнал ?

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

Share this post


Link to post
Share on other sites
А если не сложно то скажите с какими параметрами идет выходной сигнал ?

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

 

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

 

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

 

Share this post


Link to post
Share on other sites
Прореживание дает уж больно некрасивый результат. Примените тогда уж алгоритм ближайшего соседа...

 

 

А если не сложно то скажите с какими параметрами идет выходной сигнал ?

Частота 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 должна быть без разрывов.

 

image.png

 

Share this post


Link to post
Share on other sites
1280х720 60 Гц ... получить 640х360

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

Share this post


Link to post
Share on other sites

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

Можете глянуть как у меня это сделано:

CALC_pipeline.vhd

Share this post


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

 

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

Share this post


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

 

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

 

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

 

А никто вам не предлагал ничего бланкировать в синхре.

На две пришедшие строчные должна выйти одна строчная.

 

Share this post


Link to post
Share on other sites
Данное усреднение или прореживание актуально только по горизонтальной развертке, тогда действительно пару буферов на 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 раза меньше. Качество выходного видео- вполне нормальное. Не билинейная интерполяция конечно. Но и алгоритм с математикой простейшие.

Share this post


Link to post
Share on other sites
Вот почему никто не указывает остальные параметры входного сигнала?

 

остальные параметры из 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

 

 

 

 

А никто вам не предлагал ничего бланкировать в синхре.

На две пришедшие строчные должна выйти одна строчная.

 

 

Вывод это я для себя сделал)

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

 

Share this post


Link to post
Share on other sites
пару буферов на 640 точек будет достаточно. Но как быть с вертикальной разверткой?

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

Share this post


Link to post
Share on other sites
Берем 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 разрыв. Кадр не отобразится на мониторе.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now