lembrix 0 24 августа, 2018 Опубликовано 24 августа, 2018 (изменено) · Жалоба Данное утвержение мной не совсем подтвердилось. Собственно произошло ровно то, о чем я говорил : изменение любого из параметров 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-памяти. Изменено 24 августа, 2018 пользователем lembrix Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Sergey_Bekrenyov 0 24 августа, 2018 Опубликовано 24 августа, 2018 · Жалоба Да я как-то там не нашел такого модуля как clocked_video_output... Может в 16 Quartus он по-другому уже называется. Завтра попробую скачать и посмотреть там alt_vip_cvo Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Aleksei_Rostov 0 28 августа, 2018 Опубликовано 28 августа, 2018 · Жалоба Странно. Я тоже думаю, что вот эти неактивные интервалы между строками и кадрами (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_ 24 28 августа, 2018 Опубликовано 28 августа, 2018 · Жалоба Можно поподробней про "отскалируйте". Как я понимаю делаем следующее: прореживаем каждую линию видео кадра, буферизируем полученный масштабированный кадр и выдаем его на экран 800х600. А если необходимо обойтись без внешней памяти для буферизации? менять пиксельклок? Если без внешней памяти, то нужна внутренняя память на как минимум на 4*640 точек (может две таких для буферизации двойной) Тогда 800*5 валидных клоков надо заменить на 640*4. Т.е. на каждые 25 входящих выдать 16 наружу. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Flip-fl0p 4 29 августа, 2018 Опубликовано 29 августа, 2018 · Жалоба Можно поподробней про "отскалируйте". Как я понимаю делаем следующее: прореживаем каждую линию видео кадра, буферизируем полученный масштабированный кадр и выдаем его на экран 800х600. А если необходимо обойтись без внешней памяти для буферизации? менять пиксельклок? Прореживание дает уж больно некрасивый результат. Примените тогда уж алгоритм ближайшего соседа... Если без внешней памяти, то нужна внутренняя память на как минимум на 4*640 точек (может две таких для буферизации двойной) Тогда 800*5 валидных клоков надо заменить на 640*4. Т.е. на каждые 25 входящих выдать 16 наружу. А если не сложно то скажите с какими параметрами идет выходной сигнал ? Частота Pixel_clk как я понимаю соответствует входному разрешению. А полярность кадрового и строчного импульса, их длительность чему должны соответствовать ? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_4afc_ 24 29 августа, 2018 Опубликовано 29 августа, 2018 · Жалоба А если не сложно то скажите с какими параметрами идет выходной сигнал ? Частота Pixel_clk как я понимаю соответствует входному разрешению. А полярность кадрового и строчного импульса, их длительность чему должны соответствовать ? Я ответил про вариант когда на выходе экран 640х480 и малый буфер. Когда на выходе 800х600 - красиво не получится, надо что-то в 5 строку пихать - или нули или дублировать. Но для отладки алгоритма пойдёт. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Aleksei_Rostov 0 29 августа, 2018 Опубликовано 29 августа, 2018 · Жалоба Прореживание дает уж больно некрасивый результат. Примените тогда уж алгоритм ближайшего соседа... А если не сложно то скажите с какими параметрами идет выходной сигнал ? Частота 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 168 29 августа, 2018 Опубликовано 29 августа, 2018 · Жалоба 1280х720 60 Гц ... получить 640х360 Надо усреднять 2х2 точки, разбирать входной кадр и синхронизироваться с ним вышеописанным способом, потому что интервалы гашения имеют право быть произвольными. Соответственно, для усреднения достаточно буфера на одну строку длиной 640 точек и чередования, но размер FIFO будет определяться качеством синхронизации. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Flip-fl0p 4 29 августа, 2018 Опубликовано 29 августа, 2018 · Жалоба В 2 раза уменьшить - вообще легко: берете данные цвета от каждого из 4 соседних пикселей и вычисляете среднее арифметическое между ними. Можете глянуть как у меня это сделано: CALC_pipeline.vhd Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Aleksei_Rostov 0 29 августа, 2018 Опубликовано 29 августа, 2018 · Жалоба Надо усреднять 2х2 точки, разбирать входной кадр и синхронизироваться с ним вышеописанным способом, потому что интервалы гашения имеют право быть произвольными. Соответственно, для усреднения достаточно буфера на одну строку длиной 640 точек и чередования, но размер FIFO будет определяться качеством синхронизации. Данное усреднение или прореживание актуально только по горизонтальной развертке, тогда действительно пару буферов на 640 точек будет достаточно. Но как быть с вертикальной разверткой? Просто бланкировать каждую вторую линию для получения 360-ти линий не получится: зона active pixels должна быть без пропусков. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_4afc_ 24 29 августа, 2018 Опубликовано 29 августа, 2018 · Жалоба У меня задача попроще чем у ТС. Входной поток 1280х720 60 Гц (74.25 МГц пиксельклок). Вот почему никто не указывает остальные параметры входного сигнала? Собрал свой источник видеосигнала 1280х720 60 Гц, уменьшал зону active pixel в несколько раз, монитор кадры отображает. Если в зоне active pixel бланкировать через линию и в линии через пиксель (для масштабирования на 2), то монитор не отображает видео кадр. Отсюда вывод: зона active pixel должна быть без разрывов. А никто вам не предлагал ничего бланкировать в синхре. На две пришедшие строчные должна выйти одна строчная. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Flip-fl0p 4 29 августа, 2018 Опубликовано 29 августа, 2018 · Жалоба Данное усреднение или прореживание актуально только по горизонтальной развертке, тогда действительно пару буферов на 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 раза меньше. Качество выходного видео- вполне нормальное. Не билинейная интерполяция конечно. Но и алгоритм с математикой простейшие. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Aleksei_Rostov 0 29 августа, 2018 Опубликовано 29 августа, 2018 · Жалоба Вот почему никто не указывает остальные параметры входного сигнала? остальные параметры из 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 168 29 августа, 2018 Опубликовано 29 августа, 2018 · Жалоба пару буферов на 640 точек будет достаточно. Но как быть с вертикальной разверткой? Суммируете входную точку с буфером, если это чётная строка, либо с нулём, если нечётная, и записываете сумму в тот же буфер, суммируете следующую точку с этим же буфером и записываете сумму в него же, увеличиваете указатель буфера, по окончании работы входного и выходного буферов, т.е. по началу обоих строчных интервалов гашения, меняете буферы местами. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Aleksei_Rostov 0 29 августа, 2018 Опубликовано 29 августа, 2018 · Жалоба Берем 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 разрыв. Кадр не отобразится на мониторе. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться