я попробовал поменять разрешение - все упирается в логические ресурсы, так как RAM для буферизации описана как регистры и не переводится компиляторами автоматом на Block Ram

Только только с либеро разобрался под Smartfusion 2, подключил OV5642, байер с матицы пошел... но.. время блин, пытаюсь успеть все. да еще и лицензия на Либеро у меня позволяет писать либо на VHDL, либо на Verilog, я только последний понимаю. Но ребята на работе нашли решение.Так что в выходные думаю продолжать.


Не, так не пойдет. Работать с кадром в блочной памяти половое извращение. Надо в ДДР. Будем переписывать значит, менее чем фулл эйчди он неинтересен.

Насколько я понимаю все равно будет нужно окошко 4х4 - то есть буфер на 4 строки однозначно понадобится с подкачкой из ДДР.

Для меня самая главная загадка как в Ethernet уложить NAL

RFC6184?

спасибо, буду учить матчасть

Доступна новая редакция: H.265, (Approved in 2014-10)

ASIC IP-ядро хевка продаётся в закриптованном виде за 350k$ + роялти; либо за 1.8M$ дают все сорцы без роялти.
В одной из команд в России, которая девелопала h.265 на плисе для буржуйских заказчиков, пыхтел десяток человек с утра до вечера по полтора-два года.
Отсюда сомнения, что можно сделать продукт силами энтузиастов в свободное время...

Народ, помогите, пожалуйста, разобраться с моделью приведенного в топике кодировщика, в VHDL не сильно силен. Моделировал в ISE и Vivado встроенных симуляторах. ругается на конструкции:
write(sout,"Reusing framenum: ");write(sout,framenum);
write(sout,". Using QP: ");write(sout,conv_integer(QP));

Сообщение отредактировал Qimbo_Bob - Jul 21 2017, 20:24

Всего 3Кслайсов??? Фантастика! А разрешение 640x480? А что по части памяти оно требует?
P.S. Как я мог это пропустить?

Он параметризуемый, не имеет предела по разрешению, 3 к слайсов для разрешения которое по дефолту вбито. Разводил для 4400*2250 тогда уже 9000 лутов кушает на спартане 6(слайсов хз). Пиксельная скорость что- то порядка 110 MHZ для спартана получилась, больше не хочет никак. Кадров предсказания движения у него нету. ни B ни P, есть только I, но для камер я так понял этого вполне достаточно. Тем более с такой занимаемой площадью.

Сообщение отредактировал Qimbo_Bob - Jul 22 2017, 21:08

Это кодер на 3к слайсов? Тоже хочу! Где взять? Кто-то тестил?

Оно по памяти в том виде, в котором есть, ничего почти не требует, есть только I кадры, которые почти на лету обрабатываются, памяти пару Block Ram кушает. Но заложена возможность добавления P и B кадров предсказания.
Автор данного кода пишет, что коэффициент сжатия 1:10, с кадрами B было бы порядка 1:50, естественно в зависимости от типа входного видеосигнала (насколько там много всего движется).

Сообщение отредактировал Qimbo_Bob - Jul 22 2017, 21:14

От I picture особого смысла нет, там только половина по железу, причем не самое сложное.

Единственный смысл, который вижу, это если файл или стрим используется каким-нибудь стандартным декодером (например аппаратным в смартфоне). И для удобства ему можно скормить стандартный h.264.
Тут ключевое слово стандартный. Пусть и без использования всей мощи стандарта видеосжатия.
Если учесть, что он кушает очень немного ресурсов от ПЛИС, то это неплохая альтернатива MJPEG.

Сообщение отредактировал x736C - Aug 2 2017, 02:07

В качестве домашней поделки пойдет, на что-то серьезное оно уже не годится. Уровень P/B фреймов все гораздо серьезней. Хотя энкодер в каком-то смысле проще, чем декодер, можно урезать все по максмуму и все равно он будет кодиорвать, хоть и не так качественно как референс.

Что вы имеете ввиду под стандартным/не стандартным декодером, по моему видению декодер либо поддерживает все согласно спекам, либо нет. В мобильных телефонах (поскольку он в железе) как раз изначально закладыватся полная имплементация до определенного level/profile.