Привет

кто-нибудь реализовывал задачу сжатия в h.264 на Арме в SoC'e?

интересно какой производительности можно достичь?

Программно что ли? Ну, есть x264, можно собрать версию с оптимизациями NEON и прочими арм-штучками, но это не так хорошо как аппаратно...
Производительность будет низкая, буду рад если 720x576 сожмет софтово в реалтайме хотя бы один канал.

x264 имеет богатые настройки. На самых простых пресетах может и сожмет.
Но качество будет просто вырвиглаз.
Надо поиграться на обычной машине (i7 к примеру). При сжатии кодек выводит скорость сжатия (кадров/сек).
В свое время тоже прицеливался на SoC. Была даже мысль вынести на FPGA какие-то алгоритмы для ускорения x264.
Но задача была оценена на грани выполнимого. Скорее за гранью. В итоге купили кодек.

UPD: Поясню, что имел в виду под «поиграться на обычной машине».
Скорее всего окажется так, что при нахождении таких параметров сжатия (на достаточно мощной многоядерной машине с включенной оптимизацией), что сжатие будет осуществляться 25-30 кадров/c, качество при этом будет неприемлемым. Совершенно ясно, что арм с тем же качеством будет жать намного медленнее. В моем случае сразу был поставлен крест на этой идее, т.к. качество совсем не понравилось, мягко говоря.

Игрались c Nano-SOC и Tegra TK1

640х480

Nano-SOC порядка 20 кадров в секунду
Tegra TK1 около 140 кадров в секунду

Ну там же настроек немерено. И качество может быть очень разным. Надо говорить не только о разрешении.
Если бы получилось их найти где-нибудь в батнике и привести, очень Вам был бы благодарен. Для Nano-SoC очень интересно.

Сразу хочется спросить "зачем". Хватает недорогих микросхем и соков, которые могут с этим справиться.

Если же хочется fpga, но нет денег на готовое ip-ядро, то я бы пошел по пути opencl и оффлоада тяжелых операций на плис (арм - хост, кернелы - в плис)

Готовые кодеки в интегральном исполнении не всегда походят по тем или иным причинам.
Качество сжатия для низких битрейтов, смена параметров «на лету» без перезагрузки кодека.
Хотя за последние пару лет появилось еще несколько кодеков, о них не знаю.
Существуют и другие соображения контекста применения.

А насчет «оффлоада тяжелых операций на плис» -- имхо не так просто, как может показаться.

Не подскажете какие-нибудь варианты микросхем с аппаратным кодеком H264? И автору темы пригодится.
Как раз ближайшее время предстоит задействовать, но давно не интересовался вопросом.

Сейчас практически в каждый процессор встроен кодек или набор аппаратных ускорителей для сжатия, так скажем.
Любой более-менее мощный ARM-SoC типа малинки. Даже в отечественном 1892ВМ14Я уже встроен кодек.
Поэтому Вам лучше искать в Сети что-то свежее.
Когда я занимался вопросом, было несколько вариантов:
Самый ходовой FreeScale iMX6 и что было у меня под рукой. Проблемы с ним обозначил выше.
Еще были интегральные кодеки:
MG1264
MG3500/MG2580
Специализированные SoC
FTMCP210
N3292x
FIE8130/FIE8180
GM8125/GM8126/GM8128.
Этот зоопарк отбросил сразу по тем или иным причинам.

Существует аппаратно-софтовое решение на сигнальниках Ti.

И очень много IP ядер из которых я бы выделил AlmaTech, которое перепродавало CAST под своим брендом.
Мы его купили, вся система получилась в одном Cyclone V 150.

Надо исходить от задачи, какое нужно качество с битрейтом. Какая задержка.
Писать на флешку или передавать по эфиру на большое расстояние -- две разные задачи.

Nano-SOC с x264 c включенным Neon

По поводу настроек - лучше посмотрите доку на х264. Насколько я помню там были наборы параметров готовые - fastest, slowest и т.п.

Это да. Настроек очень много. Они для удобства объединены в пресеты. Интересно, на каком пресете Nano-SoC тянет 640x480.

Оу, всем спасибо за ответы.
Правда все равно не решил как делать ))))
Использовать старые кодеки типа MG1264 не хочется - могут снять с производства.
Использовать SoC'и с армами и аппаратными кодеками не хочется, потому что в системе уже есть CPU, не хочется усложнять разработку ПО под 2 разные платформы.
По поводу IP-ядра идея хорошая, но чуствую его цена поставит крест на разработке....
Не могли бы вы приблизительно озвучить цену IP-ядра?


Еще интересно было б действительно на OpenCL запустить. Но нужен код opencl'вский.. Буду искать

И где же он готовый оптимизированный будет просто бесплатно лежать?

оптимизированный нигде наверное, хотя бы просто под GPU найти например. шансов больше.

x264 имеет оптимизацию под GPU.

Сняли давным-давно :-)))

MG1264 - сразу НЕТ, пытался его запустить - потерял кучу времени, так и не получил поток, хотя консоль говорила что битрейт идет, кадры кодируются. Поддержки по нему никакой, версии firmware, которая при инициализации грузится - все разные (из тех что в инете нашел), затачиваются видимо под конкретные требования. И получить под свои требования сейчас уже никак.

По IP ядрам - в прошлом году H264 baseline profile стоил с использованием роялти 25000$, т.е. в каждое изделие надо было плюсом покупать лицензию за 10$. Без роялти цена была 42000$. Main profile стоил начиная 50000-90000$, в зависимости от наворотов. Там еще цена варьировалась от задержки кодирования. Было 3 варианта - что-то около 50мс (вроде даже меньше) - жрало чудовищно много логики, порядка 200мс - примерно занимало ядро 60-70% чипа 5CSEMA5, и был вариант low bitrate - задержка чуть меньше секунды- тоже много логики съедал.

В общем, мы отказались от этой идеи - толкать кодек в ПЛИС. проще и дешевле действительно на ARM+акселераторы. Есть еще вариант HI3518 - китайский копеечный чип, только вот документацию нашел только на HI3518A HI3518C - а они сняты с производства. Сейчас в изобилии HI3518E - но доки на сам чип у меня нет, найти не удалось. А по сравнению с предыдущими чипами переделки у него серьезные. Даже DDR затолкали прямо в корпус. Т.е. ему надо только питание и обвес из пассива-очень заманчиво.

Кстати, если у кого завалялась документация на HI3518E - дайте знать в личку, договоримся.

И мне и мне!!!

Повторюсь, тут все сильно зависит от задачи.
Baseline profile подходит для жирных битрейтов при относительно невысоком сжатии.
Для передачи по эфиру профиль не очень, мягко говоря.
Для main profile очень желательно иметь Full Motion Estimation. Это отъедает значительную часть ресурсов.
Если кодек поддерживает Intra Refresh encoding mode, то можно добиться очень незначительной задержки.
Субъективно немного снижает качество при том же битрейте.
Самое главное, размер требуемых ресурсов напрямую зависит от максимального разрешения, которое задается на этапе компиляции.
Для разрешения 1280x720 имею примерные цифры для кодеков Alma, которыми могу поделиться.
Baseline, Light Motion Estimation (LME), включая rate control, исключая Intra 4x4 prediction (только Intra 16x16) и без деблочного фильтра требует около 40K LEs для MAX10. Без учета контроллера памяти, который тоже требуется. Но он немного занимает.
Существует вариант конфигурации в 15К, но параметры сжатия ограничивают сферу применения такого кодека.
В самом полном варианте, mainline profile кодек занимает 90К от Cyclone V. Позволяет варьировать задержку в широких пределах, меняя параметры кодирования.
Задержка побольше -- качество повыше, лучше сжатие динамичных фрагментов.
Либо мизерная задержка, но при этом или высокий битрейт, или низкое качество. Такой треугольник. Причем от цены напрямую не зависит. Не считая алгоритмов LME, IRE, функционал которых на задержу влияет.
Это согласуется более-менее с Вашими цифрами.
Чем понравился кодек Alma, у них есть исполняемая BAM (bit-accurate model). Можно все режимы протестировать, сравнить с x264.
И для этого необязательно его покупать, достаточно подписать NDA.
Списывался еще с парой фирм. У них вообще BAM не оказалось.
По поводу цены не скажу, т.к. NDA. Только отмечу, что все сильно зависит от вашей договороспособности

А не мерили какой битрейт получается при каком PSNR в 40К конфигурации? Или может где-то можно глянуть видео в каком-то конкретном битрейте? Лучше бы конечно видео глянуть. Хочу сравнить с кодером на IMX.

Не понимаю причем тут задержка, кодек либо успевает, либо нет.
Битрей / качество (квантователь) это лямбда в rate control и является основной функцией энкодера.

Не все так просто. Задержка определяется не кодером, а декодером. Просто надо понимать, что мы говорим об одном и том же, говоря о задержке кодирования.
Я имел в виду общую задержку от несжатого кадра до его отображения потребителю. И обычно, когда говорят о задержке кодирования, имеют в виду именно это.
А не то, справится кодек или нет
Чем сильнее коэффициент сжатия (это не только работа квантователя), тем, как правило, выше задержка, если не применяется IRE режим.
Потому что, задержка больше тогда, когда больше разница между максимальным значением битрейта и средним.
Рекомендую статью, в ней все очень понятно.
http://www.cast-inc.com/blog/white-paper-u...ression-systems


Не мерил, но это очень просто сделать. Могу сжать тестовый видеофрагмент с разными битрейтами и предоставить статистику и результат.
Если мой фрагмент, то Вам потом надо будет прогнать через свой кодек оригинал, либо Вы даете свой фрагмент. Если интересно, пишите в личку.
Мне самому интересно было бы сравнить. Я сравнивал только с x264. И кодек Alma ему проигрывает. x264 очень круто жмет, но не реалтайм.
При сжатии с битрейтом менее 2-3 мегабит/c разрыв становится существенным.

Еще чем может стандартный кодек не подойти. _Watcher_ писал на форуме:

Не соглашусь, там на при передаче еще несколько этапов, куча буферов, так что декодер не влияет на скорость. Опять же, либо он успевает за 33 мс, либо нет.
Отчасти скорость кодирования ограничена временем нахождения исходного кадра с буфере, а поскольку он поступает каждые 33 мс, то в среднем, это время на кодирование одного кадра.
Все эти режимы простая фикция, хороший алгоритм для motion estimation & rate control определяет все. Можно сказать, что референсный алгоритм кодирования (с full search) закрывает все, а потом ищутся методы как не сильно потерять при оптимизации или минимизации/поиск алгоритма, который был бы балансом между качеством, битрейтом и скоростью кодирования.

Все этапы там указаны. Вот чуть дополненная статья, ссылку на которую уже приводил. В ней полный бюджет задержки для кодирования с очень низкой задержкой сведен в таблицу. Кодер легко успеет за 33 мс. Успевает или нет -- этот вопрос вообще не рассматривается в этой теме. Не понятно, почему он Вами поднят. Если кодер не успевает кодировать в темпе (например x264), то он просто не используется для приложений реального времени. Далее, типовой хардверный кодер кодирует гораздо быстрее и может начать отдавать кадр гораздо раньше, чем 33 мс. И полный кадр будет закодирован тоже раньше. Значит ли это, что суммарный бюджет задержки, который складывается, повторюсь, на стороне декодера, будет немногим более 33 мс. Нет, не значит.
Даже если кодер кодирует 60 кадров в секунду, успевая обработать их все, это вовсе не означает, что декодирование и воспроизведение не произойдет с задержкой в секунду или более. Чем больше задержка, тем лучше можно сжать видео (2-pass еще лучше). Лучше сжимаются динамичные сцены, на которых будет выплеск информации. Как только эти всплески будут срезаться изменением уровней квантования, моментально заметно упадет качество. Посмотрите на любое решение с ультра-низкими задержками (например в статье), решение об изменении уровней квантования принимается по части фрейма. Естественно ценой уменьшения качества. Я бы даже сказал исходя из личного опыта -- ценой значительного уменьшения качества. И этот эффект очень сильно зависит от коэффициента сжатия. Чем жирнее битрейт, тем меньше увеличение степени сжатия заметно. Ибо на маленьких битрейтах PSNR и так невысокий.

Разумеется, должен оговориться, что имеется в виду канал с ограниченной пропускной способностью, когда она выбирается немногим более среднего битрейта, чтобы максимального использовать энергетику канала. Для уменьшения дисперсии мгновенного битрейта был придуман режим IRE, когда опорный кадр, как самый затратный с точки зрения объема информации, передается не целиком, а размазывается во времени.
Для гигабитного эзернета или оптоволокна бюджет задержки будет другим, и такой критичности нет.
Поэтому два раза оговорился, что в выборе кодека и параметров кодирования все зависит от задачи, которую этот кодек будет решать.


Простите, но это смешно. Попробуйте референсный алгоритм уложить в 90К, и так, чтобы этот референсный алгоритм работал в реалтайм режиме, а потом поговорим.
Все эти режимы и алгоритмы и есть один большой компромисс.


Вы сейчас выступаете в роли Капитана Очевидность.
Об этих методах, «как не сильно потерять при ...», и шла речь.

to X736C

не могу найти подробное описание от ALMA. Оно под NDA только дается?

Кстати, почему ALMA? У IntoPIX вроде предложение круче - они 120 fps обещают на 1080.

Полное — после подписания NDA.
Можно зарегистрироваться на design-reuse.com, там можно найти краткое описание. Его достаточно, чтобы понять базовые вещи об их кодеке.


1. FPS на 1080 — это ничего не говорит о крутости кодека. Надо сранивать комплексно несколько параметров.
2. Не нашел у Into PIX кодер h264, только JPEG. Если имелся в виду JPEG, то его корректно сравнивать с аналогичным. Не думаю, что JPEG-энкодер Alma уступает по скорости обработки. Его исходники кстати давно утекли в свободный доступ и тут на форуме, кажется, выкладывались.