Доступна новая редакция: 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));

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

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

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

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

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

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

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

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

Все верно. Именно поэтому более простой стрим он спокойно пережует, т.к. он создан в полном соответствии со стандартом, который в свою очередь допускает не использовать межкадровое сжатие и компенсацию движения. Именно об этом пытался сказать.
Насчет серьезного и несерьезного — это мне всегда было непонятно. Как измерить это серьезно или это не серьезно? Кто и как это определяет?

Когда в декодере есть куча разных вариантов, энкодер в свою очередь можно попросту имплементировать как I picture only, предсказание по одному угловому пикселю, блоки только 8х8. В итоге когда первый раз на это смотришь, то задумываешься - а что, так тоже можно было. Плюс даже минимальое отсутствие управлением квантователя и rate control. На выходе энкодер, с точки зрения тестирования, на порядок проще чем декодер (порядок - из собственного опыта).