[Sergey_Bekrenyov 0]

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

[DASM 0]

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

 

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

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

[Sergey_Bekrenyov 0]

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

 

 

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

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

 

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

[blackfin 16]

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

RFC6184?

[Sergey_Bekrenyov 0]

RFC6184?

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

[blackfin 16]

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

 

[myq 0]

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

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

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

[qimbobob12 0]

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

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

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

Изменено 21 июля, 2017 пользователем Qimbo_Bob

[1891ВМ12Я 0]

Xilinx Spartan 3 family - 3174 Slices

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

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

[qimbobob12 0]

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

Изменено 22 июля, 2017 пользователем Qimbo_Bob

[alexPec 3]

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

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

 

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

[qimbobob12 0]

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

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

 

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

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

Изменено 22 июля, 2017 пользователем Qimbo_Bob

[lexx 0]

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

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

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

[x736C 0]

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

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

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

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

Изменено 2 августа, 2017 пользователем x736C

[lexx 0]

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

 

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