Яку швидкість можна очікувати від апаратно-H264-кодування?


29

Я спіткнувся в Вікіпедії статтю про те , що Broadcom GPU має апаратну підтримку для кодує H.264 / AVC, не тільки де -coding.

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

Але порівняно зі звичайним настільним ПК із середньою графічною картою, чи буде Raspberry Pi потенційно кодувати H.264 / AVC, можливо, ще швидше ? Якщо користувач робочого столу повинен був оптимізувати його ffmpegдо Core-i5xxx за допомогою 150 -мільйонної відеокарти Ati / Nvidia ... чи пропонує ця комбінація що-небудь способом "апаратної підтримки кодування H.264"? Якщо ні, то спеціально прийнята Raspberry-Pi-ffmpeg буде ще швидшою? Якщо так, то чи вже є порівняння швидкості?


Я не думаю, що Raspberry Pi буде швидше, ніж настільний ПК.
Відхилення

5
Хтось повинен чітко робити орієнтир і показувати певні результати.
XTL

@XTL Ви можете це зробити? ;-)
towi

Це дуже хороший результат ... чи можете ви додайте перекодування звуку до прикладу команди?

Відповіді:


5

На даний момент, здається, досі немає стабільного програмного забезпечення для кодування h264 відео за допомогою апаратного забезпечення, навіть якщо офіційно оголошено, що Raspberry Pi підтримує апаратне кодування h264. Отже, ми не можемо зробити орієнтир для порівняння продуктивності зі звичайним ПК .

Я не знаю, чи працює хтось над цією темою, але розробник, libavмабуть, песимістично ставиться до інтеграції такого модуля в існуючий libavпроект (див. Його відповідь 2 грудня о 09:23).

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


Я поняття не маю, з чого почати, але я, можливо, захочу спробувати. Я завжди шукав причину, щоб мені зануритися в libavcodec src, або - якщо бути точнішим - x264.
букси

2
Бібліотека GStreamer здатна підключитись до чіпів OpenMax чіпів Broadcom, і це, здається, здатне робити апаратне кодування: gstreamer.freedesktop.org/releases/gst-omx/1.0.0.html
speedplane

25

Станом на квітень 2015 року GStreamer 1.2, що входить до програми Raspbian, підтримує апаратне прискорене кодування H.264 через апарат omMAh264enc через апарат OpenMAX.

Я здійснив порівняльний аналіз:

  1. Двоядерний i7-2620M 2,7 ГГц (Sandy Bridge) MacBook Pro (початок 2011 року) - 4 Гб оперативної пам’яті
  2. RaspBerry Pi 2 Модель B 900MHz чотирьохядерний процесор ARM Cortex-A7 - 1 Гб оперативної пам’яті

Файл зразка: зразок 60-х з фільму «Аларісте» (2006). Оригінальний файл - 1080p і займає 30 Мб. Я перекодував файл на 720p. Усі аудіодоріжки були ігноровані, щоб зосередити дослідження на перекодування відео.

Результати:

Увімкнено (1), використовуючи Handbrake (x264 кодек), я перекодував з x264 налаштуваннями veryslow та середнім бітрейтом 1145 кбіт / с (1 пропуск), що призвело до файлу 7,7 МБ. Профіль високий, рівень 4,0. Кодування зайняло 3 хв 36 с, використовуючи 4 потоки. Загальний накопичений процесорний заряд ручного гальма ~ 380%. Якість відео була дуже хороша. Можна було спостерігати невеликі артефакти, і втрата деталей не легко спостерігається. Дивіться ще нижче.

Увімкнено (2), використовуючи GStreamer і omxh264enc (апаратне прискорення), я перекодував цільовий бітрейт = 1145000 (1145 кбіт / с), швидкість управління = 1 (метод управління змінним бітрейтом), що призвело до файлу 6,9 МБ. Кодування зайняло 7 хв 4 з використанням 1 потоку. Загальний накопичений процесорний заряд gst-start-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 в якості кодера загальний накопичений CPU заряд gst-start-1.0 становить приблизно 380%, що підтверджує той факт, що omxh264enc насправді використовує GPU. Крім того, для x264enc в (2) час перевищує 15 хв.

Висновок:

Для досить подібного розміру файлу час, витрачений апаратно-прискореним графічним кодером RaspBerry Pi 2, був майже вдвічі більшим, ніж у програмного кодеру 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) на Raspberry Pi 2

Оновлення:

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


Для якості зображення після перекодування GStreamer слід враховувати ще один фактор. Різні параметри для відеокалі матимуть вплив на зображення до того, як gstreamer надішле його omxh264enc. Відображення відео використовує білінеарний за замовчуванням. Ланцос краще, але він занадто повільний. Розробники gstreamer працюють над додатковими варіантами для відеокали, але вони поки що не знаходяться в стабільному випуску. Деякі згенеровані візерунки можуть бути корисними для порівняння різних варіантів:
ecc29

gst-launch-1.0 -e videotestsrc pattern=zone-plate kx2=80 ky2=45 num-buffers=1 ! video/x-raw, width=1920, height=1080 ! videoconvert ! videoscale method=lanczos ! video/x-raw, width=1280, height=720 ! avimux ! filesink location=lanczos_1280.avi
ecc29

Я оновив публікацію з результатами lanczosметоду масштабування.
М. Рубіо-Рой

Думаючи про купівлю 3 б +. Будь-яке оновлення через 3 з половиною роки? Кодування в режимі реального часу можливе зараз?
акостадінов

1

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

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

Якби мені довелося оцінити особисту думку. Було б, що RPi не був би швидшим, ніж середня специфікація відеокарти. Але я думаю, що це було б набагато швидше, ніж ти думаєш. Можливо, навіть близько 75% швидкості.

Я не міг знайти десь порівняння.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.