Jump to content

    

H.264 Hardware Encoder in VHDL

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

Share this post


Link to post
Share on other sites

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

 

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

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

Share this post


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

 

 

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

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

 

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

Share this post


Link to post
Share on other sites

ASIC IP-ядро хевка продаётся в закриптованном виде за 350k$ + роялти; либо за 1.8M$ дают все сорцы без роялти.

В одной из команд в России, которая девелопала h.265 на плисе для буржуйских заказчиков, пыхтел десяток человек с утра до вечера по полтора-два года.

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

Share this post


Link to post
Share on other sites

Народ, помогите, пожалуйста, разобраться с моделью приведенного в топике кодировщика, в VHDL не сильно силен. Моделировал в ISE и Vivado встроенных симуляторах. ругается на конструкции:

write(sout,"Reusing framenum: ");write(sout,framenum);

write(sout,". Using QP: ");write(sout,conv_integer(QP));

Edited by Qimbo_Bob

Share this post


Link to post
Share on other sites
Xilinx Spartan 3 family - 3174 Slices

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

P.S. Как я мог это пропустить?

Share this post


Link to post
Share on other sites

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

Edited by Qimbo_Bob

Share this post


Link to post
Share on other sites
Всего 3Кслайсов??? Фантастика! А разрешение 640x480? А что по части памяти оно требует?

P.S. Как я мог это пропустить?

 

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

Share this post


Link to post
Share on other sites
Всего 3Кслайсов??? Фантастика! А разрешение 640x480? А что по части памяти оно требует?

P.S. Как я мог это пропустить?

 

Оно по памяти в том виде, в котором есть, ничего почти не требует, есть только I кадры, которые почти на лету обрабатываются, памяти пару Block Ram кушает. Но заложена возможность добавления P и B кадров предсказания.

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

Edited by Qimbo_Bob

Share this post


Link to post
Share on other sites
Оно по памяти в том виде, в котором есть, ничего почти не требует, есть только I кадры, которые почти на лету обрабатываются, памяти пару Block Ram кушает. Но заложена возможность добавления P и B кадров предсказания.

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

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

Share this post


Link to post
Share on other sites
От I picture особого смысла нет, там только половина по железу, причем не самое сложное.

Единственный смысл, который вижу, это если файл или стрим используется каким-нибудь стандартным декодером (например аппаратным в смартфоне). И для удобства ему можно скормить стандартный h.264.

Тут ключевое слово стандартный. Пусть и без использования всей мощи стандарта видеосжатия.

Если учесть, что он кушает очень немного ресурсов от ПЛИС, то это неплохая альтернатива MJPEG.

Edited by x736C

Share this post


Link to post
Share on other sites

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

 

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

 

 

 

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
Sign in to follow this