[mux 1]

Quote

Скажу очевидное. Как только мы начинаем сжимать видеопоток с максимальным соотношением качество/битрейт, передавая по узкому каналу, задержка (latency) увеличивается.

с 2010 оно че то не решается ( со времен первых дронов - птеродактилей) 

[Elsystems 0]

А может все гораздо проще - не оптимально выбрана платформа для задачи. Полно процессоров и модулей сейчас копеечных, в котором аппаратные кодеки встроены.

[mantech 142]

1 час назад, Elsystems сказал:

Полно процессоров и модулей сейчас копеечных, в котором аппаратные кодеки встроены.

С встроенной программной логикой?? Например?

[thermit 5]

40 минут назад, mantech сказал:

С встроенной программной логикой?? Например?

Не понятно про логику, но есть чипы из семейства stm32 с аппаратным jpeg кодеком. По входу/выходу стандартный видеокодек. Если я ничего не путаю. 

[mantech 142]

1 минуту назад, thermit сказал:

но есть чипы из семейства stm32 с аппаратным jpeg кодеком.

Т.е. хотите сравнить стм с цинком?))) Ну так себе сравнение запорожца с мерседесом)))  Уж если что так, с нормальными аллвиннерами или рокчипами тогда, но там нет PL, а судя по всему ТС выбрал цинк именно из-за нее...

[thermit 5]

4 минуты назад, mantech сказал:

Т.е. хотите сравнить стм с цинком?))) Ну так себе сравнение запорожца с мерседесом)))  Уж если что так, с нормальными аллвиннерами или рокчипами тогда, но там нет PL, а судя по всему ТС выбрал цинк именно из-за нее...

Я не знаю, что там с производительностью, ответил на вопрос. Не более. Ну а что касается цинка, если взгромоздить кодек на пл, ваще никаких проблем с потребностями тс быть не должно. Дело за малым: простой алгоритм. Примерно 2 месяца работы за 5-6кр/час минимум. Как-то так. Ну там еще ввод-вывод не совсем понятен. Может серьезно осложнить ситуацию. Устроит такая диспозиция тс? Не уверен.

[mantech 142]

12 часов назад, thermit сказал:

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

Думаю, хотя бы часть кодека, которую нельзя эффективно реализовать на НЕОНе, например...

[x736C 1]

On 6/9/2025 at 10:18 PM, thermit said:

Примерно 2 месяца работы за 5-6кр/час минимум. Как-то так.

Это на сколько человек? Только не говорите, что на одного %)

[thermit 5]

33 минуты назад, x736C сказал:

Это на сколько человек? Только не говорите, что на одного %)

На 1. 

[Elsystems 0]

On 6/9/2025 at 9:18 PM, mantech said:

С встроенной программной логикой?? Например?

Если это очень нужно, тогда надо брать FPGA со встроенным ARM и аппаратным кодеком, у Xilinx такие есть. Но если такого требования или нужны нет, ничто не мешает поставить рядом Artix например. Я думаю можно подобрать процессорный модуль + Artix-7 на своей плате и они вместе будут и меньше и дешевле чем модуль с Zynq-7020. Нужно конечно знать задачу целиком, чтобы говорить конкретно. У меня есть система видеообработки на Jetson Nano + Artix-7, нет проблем ни с ценой комплектующих, ни с 1080p H.264/H.265.

Edited June 11, 2025 by Elsystems

[mantech 142]

1 час назад, Elsystems сказал:

У меня есть система видеообработки на Jetson Nano + Artix-7, нет проблем ни с ценой комплектующих, ни с 1080p H.264/H.265.

Ну и цена такого комплекта будет явно в разы больше, чем у "китайцев", ну а задачи ТСа я не знаю, может там и вообще задачу на PL можно сделать софтово, например на неск. ядрах кортекса или еще что, то это меняет сразу картину всего..

Edited June 11, 2025 by mantech

[fpga_dev 11]

Если уж делать именно на цинке то надо смотреть на TICO или его развитие JPES-XS. https://en.wikipedia.org/wiki/JPEG_XS 
Он сильно проще чем Н.26х и 10:1 должен сделать без проблем. И никаких проблем с задержкой. И фиксированый размер кадра на выходе.
Я в свое время писал TICO кодек и никаких особых проблем там не было за исключением кол-ва BRAM (но это у всех так и от разрешения зависит) и Rate Control там кривоват, но так все работает.
Но это конечно серьезный проект и [censored] не на выходной день. Будут вопросы - пишите fpga_dev собака mail точка ru
 

[Практик 5]

Есть еще и такой вариант. Когда-то я придумал  алгоритм сжатия в 2 раза  с небольшими искажениями данных, но без сужения спектра.  Т.е  алгоритм возвращает 4 байта после обработки 8 байт и при обратном преобразовании выдает исходные 8 байт почти таких же значений.  Думаю,  для видео, как и для речи,  это не принципиально. Если после него установить стандартный кодек с сжатием 5, но только без потерь, можно получить суммарное сжатие 10,  а при обратном преобразовании получить точно те самые 4 байта, из которых будут получены исходные 8.  Алгоритм использует таблицу перекодировок.

 

Edited July 31, 2025 by Практик