Странно. Я тоже думаю, что вот эти неактивные интервалы между строками и кадрами (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

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