Добрый!

Собираю информацию для ответа на вопрос "стоит или не стоит?"

Предлагают написать h264 кодек для плис. Насколько это большой объем работы. По своим ощущениям, могу сказать, что достаточно большой, так как в спецификации 264 черт ногу сломит. По крайней мере по x264 я мог часами гулять.

Плюс, правильно ли я понимаю, что это Verilog?

Есть ли opensource наработки, с которых можно начать? Небоьшое подьование гуглом показало, что вроде как есть. Может быть посоветуете что-нибудь?

Здравствуйте, theambient, Вы писали:

T>Добрый!

T> Собираю информацию для ответа на вопрос "стоит или не стоит?"

T> Предлагают написать h264 кодек для плис. Насколько это большой объем работы. По своим ощущениям, могу сказать, что достаточно большой, так как в спецификации 264 черт ногу сломит. По крайней мере по x264 я мог часами гулять.

T> Плюс, правильно ли я понимаю, что это Verilog?

T> Есть ли opensource наработки, с которых можно начать? Небоьшое подьование гуглом показало, что вроде как есть. Может быть посоветуете что-нибудь?

Verilog, VHDL еще.
Скорее всего, результат будет представлять собой модифицированный процессор типа Microblaze со спец-инструкциями для ускорения декодирования.
Я бы сказал, если Вы в VHDL/Verilog не шарите, за разумное время вы это не осилите. Там все по-другому: и разработка, и оптимизация, и отладка. Я бы грубо на глаз оценил проект в один человеко-год и 100-150K USD.

Другое дело, если это откатно-распильный проект и важен сам факт ПЛИС, то можно тупо скомпилировать open-source, загнать это в MicroBlaze или любой другой "софтовый процессор" для FPGA и сдать. Скорость декодирования будет примерно один кадр в год, но формально это будет ПЛИС.

Здравствуйте, bazis1, Вы писали:

B>Здравствуйте, theambient, Вы писали:

T>>Добрый!

T>> Собираю информацию для ответа на вопрос "стоит или не стоит?"

T>> Предлагают написать h264 кодек для плис. Насколько это большой объем работы. По своим ощущениям, могу сказать, что достаточно большой, так как в спецификации 264 черт ногу сломит. По крайней мере по x264 я мог часами гулять.

T>> Плюс, правильно ли я понимаю, что это Verilog?

T>> Есть ли opensource наработки, с которых можно начать? Небоьшое подьование гуглом показало, что вроде как есть. Может быть посоветуете что-нибудь?

B>Verilog, VHDL еще.
B>Скорее всего, результат будет представлять собой модифицированный процессор типа Microblaze со спец-инструкциями для ускорения декодирования.
B>Я бы сказал, если Вы в VHDL/Verilog не шарите, за разумное время вы это не осилите. Там все по-другому: и разработка, и оптимизация, и отладка. Я бы грубо на глаз оценил проект в один человеко-год и 100-150K USD.

B>Другое дело, если это откатно-распильный проект и важен сам факт ПЛИС, то можно тупо скомпилировать open-source, загнать это в MicroBlaze или любой другой "софтовый процессор" для FPGA и сдать. Скорость декодирования будет примерно один кадр в год, но формально это будет ПЛИС.

Спасибо!

Да, практического опыта работы с HDL у меня нет, только так, наслышан.

А HLS тут не поможет? или как всегда будет больше мороки с тем, чтобы полученный RTL пропихнуть в симмуляцию/фпагу?

И неужели нет ничего опенсурсного?

Здравствуйте, theambient, Вы писали:

T>Спасибо!

T>Да, практического опыта работы с HDL у меня нет, только так, наслышан.

T>А HLS тут не поможет? или как всегда будет больше мороки с тем, чтобы полученный RTL пропихнуть в симмуляцию/фпагу?
HLS еще очень сырой. Т.е. proof-of-concept может быть и заработает, но как только появится задача что-нибудь подкрутить или оптимизировать, вы упретесь в нечитаемый генеренный код. Я не знаю, вышел ли уже AutoESL для широкой публики, но когда я щупал внутренний preview, интеграция в Xilinx FPGA там была замечательная, но вот с отладкой/подкруткой результатов было плохо. Ну и, разумеется, код надо переписывать с нуля с учетом специфики тулзы: софтверную библиотеку просто так в RTL вам никто не скомпилирует.

Еще есть куча проектов типа MyHDL, Bluespec и т.п, но они мало что дают. Я в свое время на этом поприще тоже отметился, но быстро пришел к выводу, что с текущей конъюнктурой на этом рынке делать нечего — компании предпочитают нанять 100 индусов, которые за килобакс в год будут кодить руками VHDL (точнее, бомбить форумы вопросами типа "всем привет, меня зовут кумар, я нашел работа и мне надо быстро сделать архиватор на VHDL, помогите будды ради").

T>И неужели нет ничего опенсурсного?
Я не встречал. На OpenCores смотрели?

Здравствуйте, bazis1, Вы писали:

B>Здравствуйте, theambient, Вы писали:

T>>Спасибо!

T>>Да, практического опыта работы с HDL у меня нет, только так, наслышан.

T>>А HLS тут не поможет? или как всегда будет больше мороки с тем, чтобы полученный RTL пропихнуть в симмуляцию/фпагу?
B>HLS еще очень сырой. Т.е. proof-of-concept может быть и заработает, но как только появится задача что-нибудь подкрутить или оптимизировать, вы упретесь в нечитаемый генеренный код. Я не знаю, вышел ли уже AutoESL для широкой публики, но когда я щупал внутренний preview, интеграция в Xilinx FPGA там была замечательная, но вот с отладкой/подкруткой результатов было плохо. Ну и, разумеется, код надо переписывать с нуля с учетом специфики тулзы: софтверную библиотеку просто так в RTL вам никто не скомпилирует.

B>Еще есть куча проектов типа MyHDL, Bluespec и т.п, но они мало что дают. Я в свое время на этом поприще тоже отметился, но быстро пришел к выводу, что с текущей конъюнктурой на этом рынке делать нечего — компании предпочитают нанять 100 индусов, которые за килобакс в год будут кодить руками VHDL (точнее, бомбить форумы вопросами типа "всем привет, меня зовут кумар, я нашел работа и мне надо быстро сделать архиватор на VHDL, помогите будды ради").

Ходят слухи/шутки, что интеловские индусы до сих пор транзисторы руками двигают =)))

T>>И неужели нет ничего опенсурсного?
B>Я не встречал. На OpenCores смотрели?

Есть, Baseline декодер и планирующийся енкодер =))) но это бегло.

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

А не подскажите какие-нибудь отдельные кодеки для h.264, которые не сильно оптимизированны (и, следовательно, не мозговыносящи) и написанны на чистых плюсах? Кроме x264 и reference codec. Есть ли какой-нибудь study?

В целом вроде как кажется, что же там сложного, флоу достаточно простой, но когда начинаешь разбираться / смотреть в код как-то мне становится мутно. Не хватвает базовых навыков чтения?
.

З
T>В целом вроде как кажется, что же там сложного, флоу достаточно простой, но когда начинаешь разбираться / смотреть в код как-то мне становится мутно. Не хватвает базовых навыков чтения?
T>.


До боли знакомая ситуация. Тема сложная и нахрапом ее не возьмешь, полгода назад сам влез в такой же проект — нужно было броадкастить флв потоки на сервера. Для этого использовал ffmpeg (c X264) и librtmp. Код сложный, не для чайников, много теории знать надо. Начал в марте и только сейчас вышел на бета тестирование, а планировалось сделать за месяц. Хорошо, что заказчик толковый попался, быстро в тему влез. А то бы резьбу на этом Х264 себе точно сорвал.

Здравствуйте, theambient, Вы писали:

T>Сейчас еще раз пообщался с человеком, там все же не на меня одного все повеситься должно. Просто я пионер предполагающейся команды.
T>А не подскажите какие-нибудь отдельные кодеки для h.264, которые не сильно оптимизированны (и, следовательно, не мозговыносящи) и написанны на чистых плюсах? Кроме x264 и reference codec. Есть ли какой-нибудь study?
Увы, именно по видео я не в теме. Я в свое время lossless-компрессией занимался.

T>В целом вроде как кажется, что же там сложного, флоу достаточно простой, но когда начинаешь разбираться / смотреть в код как-то мне становится мутно. Не хватвает базовых навыков чтения?
Просто нужно время, чтобы научиться думать параллельно. В терминах критических путей, параллельных конечных автоматов и шин с синхронизацией.

Вы же когда софт пишете/читаете, имеете в голове набор стандартных подходов и шаблонов. Ну, например, когда что заинлайнить, когда закешировать, где нужен list, где vector, а где вообще set. Как упростить код, вынеся часть реализации в отдельный метод, или инкапсулировав алгоритм в аккуратный класс... В hardware design таких вещей не меньше, и их надо нащупать прежде чем делать что-то серьезное, иначе получится индокод.

Здравствуйте, theambient, Вы писали:

T> Собираю информацию для ответа на вопрос "стоит или не стоит?"
Все скрыто в деталях При данных вводных я бы не стал.

1. Не понятна цель проекта, для чего и где будет использоваться
2. Не ясно какие ограничения на железо, из-за этого не понятно какие подходы нужно будет использовать
3. H264 на FPGA коммерческих уже "куча" и тратить время на разработку H264, да и при условии, что все кто могут сейчас клепают H265 — совсем не разумно
4. И я так понял опыта разработки кодеков тоже нет

T> Предлагают написать h264 кодек для плис. Насколько это большой объем работы. По своим ощущениям, могу сказать, что достаточно большой, так как в спецификации 264 черт ногу сломит. По крайней мере по x264 я мог часами гулять.
По поводу времени очень сложно прикинуть, если коммерческая разработка то думаю от года-полутора с тимом в несколько человек, если ярый энтузиаст то можно и меньше чем в год, но насколько полученнй результат реально будет продакшен...

Если бы я брался за это то выносил бы в FPGA не весь кодек, а только отдельные функции (трансформы, поиск MV, деблокинг, сад-ы, кабак и т.п., в общем все ресурсоемкое и распараллеливаемое), а основную логику оставил на процессоре общего назначения если он есть или есть возможность, если нет возможности то взять реализацию того же арма под FPGA (например Amber) и там выполнять основную логику.

ЗЫ. Я не FPGA-шник так на всякий случай