Какую скорость я могу ожидать от аппаратного кодирования H264?

Я наткнулся на статью Википедии о том, что GPU Broadcom имеет аппаратную поддержку кодирования H.264 /AVC, а не только de -кодирования.

Я также нашел статью, где кто-то дал пример с помощью ffmpeg для создания видеофайлов h264 /mp4. Хорошо, это универсальный процессор со специализированным графическим процессором, так что это не удивительно .

Но по сравнению со стандартным настольным ПК со средней графической картой, Raspberry Pi потенциально может кодировать H.264 /AVC, возможно, еще быстрее ? Если бы пользователь настольного компьютера должен был оптимизировать свой ffmpeg на свой Core-i5xxx с графической платой $ em /atv /nvidia ... эта комбинация предлагает что угодно в способах «аппаратной поддержки кодирования H.264»? Если нет, будет ли еще приемная малина-пи-ffmpeg еще быстрее? Если да, есть ли сравнение скорости уже?

25 голосов | спросил towi 10 MonEurope/Moscow2012-12-10T19:58:22+04:00Europe/Moscow12bEurope/MoscowMon, 10 Dec 2012 19:58:22 +0400 2012, 19:58:22

3 ответа


5

В настоящий момент, похоже, до сих пор нет стабильного программного обеспечения для кодирования видео h264 с использованием аппаратного обеспечения, даже если оно было официально объявлено , что Raspberry Pi поддерживает аппаратное кодирование h264. Итак, , мы не можем сравниться с обычным ПК .

Я не знаю, работает ли кто-то над этим предметом, но разработчик из libav кажется пессимистичным об интеграции такого модуля в существующий libav (см. его ответ 2 декабря, 09:23).

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

ответил Morgan Courbet 14 FriEurope/Moscow2012-12-14T00:11:01+04:00Europe/Moscow12bEurope/MoscowFri, 14 Dec 2012 00:11:01 +0400 2012, 00:11:01
23

По состоянию на апрель 2015 года GStreamer 1.2, входящий в состав Raspbian, поддерживает аппаратное ускорение H.264 с поддержкой OpenMAX через omxh264enc.

Я сравнивал сравнительный анализ:

  1. MacBook Pro (начало 2011 года) двухъядерный i7-2620M 2,7 ГГц (Sandy Bridge) - 4 ГБ оперативной памяти
  2. RaspBerry Pi 2 Модель B 900 МГц четырехъядерный процессор ARM Cortex-A7 - 1 ГБ ОЗУ

Пример файла: 60-е место из фильма «Алатристе» (2006). Исходный файл - 1080p и занимает 30MB. Я перекодировал файл на 720p. Все аудиодорожки были проигнорированы, чтобы сконцентрировать исследование на транскодировании видео.

Результаты:

Вкл. (1), используя Handbrake (кодек x264), я перекодировал с настройками x264 veryslow и средним битрейтом 1145 кбит /с (1-проход), что привело к созданию файла размером 7,7 МБ. Профиль High, уровень 4.0. Кодировка заняла 3мин 36 с использованием 4 потоков. Общий кумулятивный заряд центрального процессора ~ 380%. Качество видео было очень хорошим. Небольшие артефакты можно было наблюдать, а потеря деталей нелегко наблюдалась. См. Ниже.

Вкл. (2), используя GStreamer и omxh264enc (аппаратное ускорение), я перекодировал с целевым битрейтом = 1145000 (1145 кбит /с), control-rate = 1 (метод управления переменным битрейтом), который привел к 6,9 МБ-файлу. Кодировка занимает 7 минут 4 с использованием 1 потока. Общий кумулятивный заряд процессора gst-launch-1.0 ~ 100%. Качество видео заметно ухудшалось, и артефакты отчетливо видны и легко наблюдаются потери деталей. См. Ниже.

gst-launch-1.0 -v filesrc location=sample-1080p.mp4 ! decodebin ! videoconvert ! \
videoscale ! video/x-raw,width=1280,height=688 ! omxh264enc control-rate=1 \
target-bitrate=1145000 ! h264parse ! mp4mux ! \
filesink location=sample-720p-OMX-1145kbps.mp4

При использовании GStreamer с x264enc в качестве кодера общий кумулятивный заряд процессора gst-launch-1.0 составляет около 380%, что подтверждает тот факт, что omxh264enc фактически использует графический процессор. Кроме того, с x264enc в (2) время выходит за пределы 15 минут.

Вывод:

Для довольно близкого размера файла время, затрачиваемое аппаратным ускорителем RaspBerry Pi 2 GPU, было почти в два раза выше, чем у программного кодека x264 на двухъядерном i7-2620M. Добавление аудио транскодирования и мультиплексирования может немного сократить этот разрыв из-за использования в основном неиспользуемого процессора на RaspBerry Pi во время этого теста. Качество видео было явно выше в файле с программным обеспечением. Смотрите ниже.

Доступные параметры конфигурации для omxh264enc (выставлены gst-inspect-1.0) ограничены по сравнению с кодером x264, но дальнейшее экспериментирование может обеспечить лучшее качество.

Приложение:

Установка GStreamer и OpenMax из репозиториев Raspbian:

$ apt-get install libgstreamer1.0-0 libgstreamer1.0-0-dbg libgstreamer1.0-dev liborc-0.4-0 liborc-0.4-0-dbg liborc-0.4-dev liborc-0.4-doc gir1.2-gst-plugins-base-1.0 gir1.2-gstreamer-1.0 gstreamer1.0-alsa gstreamer1.0-doc gstreamer1.0-omx gstreamer1.0-plugins-bad gstreamer1.0-plugins-bad-dbg gstreamer1.0-plugins-bad-doc gstreamer1.0-plugins-base gstreamer1.0-plugins-base-apps gstreamer1.0-plugins-base-dbg gstreamer1.0-plugins-base-doc gstreamer1.0-plugins-good gstreamer1.0-plugins-good-dbg gstreamer1.0-plugins-good-doc gstreamer1.0-plugins-ugly gstreamer1.0-plugins-ugly-dbg gstreamer1.0-plugins-ugly-doc gstreamer1.0-pulseaudio gstreamer1.0-tools gstreamer1.0-x libgstreamer-plugins-bad1.0-0 libgstreamer-plugins-bad1.0-dev libgstreamer-plugins-base1.0-0 libgstreamer-plugins-base1.0-dev
$ gst-launch-1.0 --version
gst-launch-1.0 version 1.2.0
GStreamer 1.2.0

QuickTime X по-прежнему транслируется 720p видео с помощью HandBrake (x264) на MacBook Pro (полностью или полностью загружайте изображение):

QuickTime X по-прежнему 720p видео транскодируется с использованием HandBrake (x264) на MacBook Pro

QuickTime X по-прежнему 720p видео транскодируется с использованием GStreamer (аппаратное кодирование через OpenMAX) на Raspberry Pi 2 (открыть или скачать изображение дляполная деталь):

QuickTime X по-прежнему 720p видео транскодируется с использованием GStreamer (аппаратное кодирование через OpenMAX) на малине Pi 2

Update:

Следуя предложение ecc29 с использованием метода масштабирования lanczos. Я выполнил тест, добавив method=lanczos в videoscale. Процесс кодирования удвоился во времени, прыгая с 7 минут до 14 минут 37 секунд. Результат почти равен по качеству, чем без метода (по умолчанию билинейный). Действительно, дефекты в основном происходят из процесса кодирования в аппаратном обеспечении. Они явно являются артефактами сжатия.

ответил M. Rubio-Roy 12 PMpSun, 12 Apr 2015 20:55:39 +030055Sunday 2015, 20:55:39
1

Графический процессор в RPi довольно мягок. Я читал, что с точки зрения кодирования вы можете кодировать 1080p @ 30fps. Также возможно кодирование нескольких потоков. Также считается, что вы можете кодировать vidoes на лету, используя RPi.

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

Если бы мне пришлось оценивать личное мнение. Было бы так, что RPi не будет быстрее, чем видеокарта среднего размера. Но я думаю, что это будет намного быстрее, чем вы думаете. Возможно, даже около 75% скорости.

Я не мог найти нигде сравнение.

ответил Vincent P 11 TueEurope/Moscow2012-12-11T15:41:01+04:00Europe/Moscow12bEurope/MoscowTue, 11 Dec 2012 15:41:01 +0400 2012, 15:41:01

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132