Перейти к содержанию
    

Не могли бы вы приблизительно озвучить цену IP-ядра?

 

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 - дайте знать в личку, договоримся.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Сейчас в изобилии HI3518E - но доки на сам чип у меня нет, найти не удалось. А по сравнению с предыдущими чипами переделки у него серьезные. Даже DDR затолкали прямо в корпус. Т.е. ему надо только питание и обвес из пассива-очень заманчиво.

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

И мне и мне!!! :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Повторюсь, тут все сильно зависит от задачи.

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. Только отмечу, что все сильно зависит от вашей договороспособности :biggrin:

Изменено пользователем x736C

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Для разрешения 1280x720 имею примерные цифры для кодеков Alma, которыми могу поделиться.

Baseline, Light Motion Estimation (LME), включая rate control, исключая Intra 4x4 prediction (только Intra 16x16) и без деблочного фильтра требует около 40K LEs для MAX10.

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Либо мизерная задержка, но при этом или высокий битрейт, или низкое качество. Такой треугольник. Причем от цены напрямую не зависит. Не считая алгоритмов LME, IRE, функционал которых на задержу влияет.

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

Я имел в виду общую задержку от несжатого кадра до его отображения потребителю. И обычно, когда говорят о задержке кодирования, имеют в виду именно это.

А не то, справится кодек или нет:)

Чем сильнее коэффициент сжатия (это не только работа квантователя), тем, как правило, выше задержка, если не применяется IRE режим.

Потому что, задержка больше тогда, когда больше разница между максимальным значением битрейта и средним.

Рекомендую статью, в ней все очень понятно.

http://www.cast-inc.com/blog/white-paper-u...ression-systems

 

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

Не мерил, но это очень просто сделать. Могу сжать тестовый видеофрагмент с разными битрейтами и предоставить статистику и результат.

Если мой фрагмент, то Вам потом надо будет прогнать через свой кодек оригинал, либо Вы даете свой фрагмент. Если интересно, пишите в личку.

Мне самому интересно было бы сравнить. Я сравнивал только с x264. И кодек Alma ему проигрывает. x264 очень круто жмет, но не реалтайм.

При сжатии с битрейтом менее 2-3 мегабит/c разрыв становится существенным.

 

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

Мы в свое время пробовали реализовать регистратор на этом процессоре и столкнулись с рядом проблем:

1. Проблема включения кодека H.264 на частоте 1кадр/сек

2. Проблема периодического потребления кодеком 100% процессора, от чего

возникали проблемы при передаче по сети и с другими процессами.

3. При переключении параметров кодека - тип сжатия, частота кадров,

все подвисало. Мы решили это тем, что при смене этих параметров перезапускаем

кодек заново с новыми параметрами, а не применяем их на лету.

4. Собственно, все проблемы шли от того, что кодек это закрытая бинарная библиотека с кучей багов.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Я имел в виду общую задержку от несжатого кадра до его отображения потребителю. И обычно, когда говорят о задержке кодирования, имеют в виду именно это.

А не то, справится кодек или нет:)

Чем сильнее коэффициент сжатия (это не только работа квантователя), тем, как правило, выше задержка, если не применяется IRE режим.

Потому что, задержка больше тогда, когда больше разница между максимальным значением битрейта и средним.

Не соглашусь, там на при передаче еще несколько этапов, куча буферов, так что декодер не влияет на скорость. Опять же, либо он успевает за 33 мс, либо нет.

Отчасти скорость кодирования ограничена временем нахождения исходного кадра с буфере, а поскольку он поступает каждые 33 мс, то в среднем, это время на кодирование одного кадра.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Не соглашусь, там на при передаче еще несколько этапов, куча буферов, так что декодер не влияет на скорость. Опять же, либо он успевает за 33 мс, либо нет.

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

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

 

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

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

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

 

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

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

Все эти режимы и алгоритмы и есть один большой компромисс.

 

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

Вы сейчас выступаете в роли Капитана Очевидность.

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

Изменено пользователем x736C

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

to X736C

 

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

 

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

Изменено пользователем FPG

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

to X736C

 

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

1080.

Полное — после подписания NDA.

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

 

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

1. FPS на 1080 — это ничего не говорит о крутости кодека. Надо сранивать комплексно несколько параметров.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...