Сказ про мужика, или как поменять пыльные «аглицкие» кодеры чипсетные

[ToSHiC]

А как обстоят дела со стоимостью транскодирования потока на HPE MoonShot? Скажем, если сравнить с двухпроцессорным 1U Proliant DL серии?

[t3hk0d3]

Сказочная маркетинговая графомания серьезно напрягает при прочтении.

Интересно ваша платформа поддерживает заворачивание субтитров и метаданных (например счет футбольного матча) в поток?

Как обстоят дела с 4K?

[aek]

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

[amarao]

Я не совсем понимаю проблемы. А что мешает использовать generic hardware для перекодирования видео при его стриминге? Буферизация решает все проблемы с 'не-realtime', а 32-ядерный сервер вполне может выдавать пару десятков кодированных потоков.

(кроме того, зачем постоянно перекодировать, когда можно закешировать видео один раз и тупо стримить статику с range'ами?)

[BasilioCat]

Для потоков 720p пара десятков потоков на сервер — недостижимый идеал при программном кодировании. Однако, если взять Intel Media Server Studio for Linux, который жадные буржуи продают от 0 до 4k$ (за HEVC), то скорость кодирования возрастает в разы (раз в пять, если не изменяет память). Что интересно, аналогичный продукт под Windows, Intel Media SDK, отдают бесплатно и с HEVC. На последнем я видел «аппаратные» потоковые энкодеры от российской компании, особо интересно они ведут себя после внеплановой перезагрузки.

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

[BasilioCat]

Буферизация у программных энкодеров дает задержку порядка нескольких секунд, что для футбольных трансляций не очень подходит, «аппаратные» решения задержку позволяют регулировать, нижняя граница порядка 0.3 сек

Про кэширование — тут зависит от инфраструктуры доставки. Если используется решение на FMS/Wowza или подобных, то как правило потоки с энкодеров публикуются на раздающий сервер (Origin в терминологии Adobe) по RTMP или RTP, который их преобразует (и сохраняет!) в нужные форматы (HLS для мобильных, HDS для флэша, MPEG-DASH для продвинутых), и которые уже кэшируют раздающие (edge) сервера, в роли которых может выступать nginx. По такой модели работает большинство CDN, причем Origin'ы как правило занимаются и транскодированием в несколько разрешений/битрейтов.

Если делать на опенсорсе, то кодировать можно сразу в HLS, и раздавать/кэшировать как файлы

[erlyvideo]

«Буферизация у программных энкодеров дает задержку порядка нескольких секунд» это конечно же не является правдой.

Буферизация везде настраивается, зависит от выбранных транспортов, настроек и прочего. Тот же libx264 используется для кодирования игр.

[BasilioCat]

Тут я имел ввиду конечно же ffmpeg, я от него не смог добиться малой задержки. Хотя, возможно, просто не докрутил.

[ToSHiC]

Задержка легко убирается, нужно крутить профили libx264 просто, а не самого ffmpeg.

[erlyvideo]

ffmpeg нигде не имеет никаких архитектурно заложенных неустраняемых задержек.

погуглите про x264 zero latency

[erlyvideo]

Глаза свернулись в трубочку и потерял мысль примерно на 3-м абзаце.

Если сделаете перевод на русский язык, будет хорошо и читабельно. Пока получилось лишь выдрать бла-бла-бла реклама Elecard реклама HP реклама бла-бла-бла.

[erlyvideo]

В итоге после «литературной» обработки осталось стойкое ощущение, что вы продаете простой нижегородско-крылатский Intel Quicksync, называя это достижением Элекарда.

[Tigger]

Коллеги, мы посовещались и решили подкрепить материал техническим документом о решении: https://www.hpe.com/h20195/v2/GetPDF.aspx/4AA6-5125ENW.pdf

[erlyvideo]

Давайте конкретнее. Вы продаете Intel Quicksync в стандартной упаковке HPE Moonshot. Так?