Jakiej prędkości mogę oczekiwać po sprzętowym kodowaniu H264?

Natknąłem się na Wikipedii-artykuł, że Broadcom GPU wsparcie sprzętowe dla kodowania H.264 / AVC, nie tylko de -coding.

Znalazłem również artykuł, w którym ktoś podał przykład ffmpeggenerowania plików wideo h264 / mp4. Ok, jego CPU ogólnego przeznaczenia z wyspecjalizowanego procesora graficznego, tak, że naprawdę nie jest niespodzianka.

Ale czy w porównaniu ze standardowym komputerem stacjonarnym ze średnią kartą graficzną, Raspberry Pi potencjalnie koduje H.264 / AVC, może nawet szybciej ? Jeśli użytkownik pulpit było optymalizować ffmpegjego podstawowej-i5xxx z $ 150 Ati / Nvidia karta graficzna ... robi to kombinacja oferta cokolwiek drogami „wsparcia sprzętowego kodowania H.264”? Jeśli nie, czy specjalnie przyjęty Raspberry-Pi-ffmpeg będzie jeszcze szybszy? Jeśli tak, czy istnieje już porównanie prędkości?

W tej chwili wydaje się, że wciąż nie ma stabilnego oprogramowania do kodowania wideo h264 przy użyciu sprzętu, nawet jeśli oficjalnie ogłoszono, że Raspberry Pi obsługuje sprzętowe kodowanie h264. Dlatego nie możemy zrobić testu porównawczego, aby porównać wydajność ze zwykłym komputerem .

Nie wiem, czy ktoś pracuje nad tym tematem, ale programista libavwydaje się pesymistyczny, jeśli chodzi o włączenie takiego modułu do istniejącego libavprojektu (patrz jego odpowiedź 2 grudnia, 09:23).

Z przyjemnością przeprowadzę test porównawczy, jeśli pozwoli na to biblioteka lub oprogramowanie.

Od kwietnia 2015 r. GStreamer 1.2 zawarty w Raspbian obsługuje sprzętowo przyspieszane kodowanie H.264 OpenMAX przez omxh264enc.

Przeprowadziłem kilka testów porównawczych:

1. MacBook Pro (początek 2011 r.) Dwurdzeniowy i7-2620M 2,7 GHz (Sandy Bridge) - 4 GB pamięci RAM
2. RaspBerry Pi 2 Model B Czterordzeniowy procesor ARM Cortex-A7 900 MHz - 1 GB pamięci RAM

Przykładowy plik: próbka z lat 60. z filmu Alatriste (2006). Oryginalny plik ma rozdzielczość 1080p i zajmuje 30 MB. Transkodowałem plik do 720p. Wszystkie ścieżki audio zostały zignorowane, aby skoncentrować badanie na transkodowaniu wideo.

Wyniki:

Na (1), używając Handbrake (kodek x264) transkodowałem przy ustawieniach x264 bardzo powolny i średni przepływność 1145 kb / s (1 przebieg), co dało plik 7,7 MB. Profil wysoki, poziom 4.0. Kodowanie zajęło 3 minuty 36 sekund przy użyciu 4 wątków. Łączne łączne obciążenie procesora hamulca ręcznego ~ 380%. Jakość wideo była bardzo dobra. Można było zaobserwować małe artefakty, a utratę szczegółów nie było łatwo zaobserwować. Zobacz poniżej.

Na (2), używając GStreamer i omxh264enc (sprzętowo przyspieszony) transkodowałem z docelową przepływnością = 1145000 (1145 kb / s), kontrola szybkości = 1 (metoda kontroli zmiennej przepływności), co dało plik 6,9 MB. Kodowanie trwało 7 minut 4s przy użyciu 1 wątku. Łączne łączne obciążenie procesora gst-launch-1,0 ~ 100%. Jakość wideo została zauważalnie obniżona, a artefakty były wyraźnie widoczne i łatwo zauważalna utrata szczegółów. Zobacz poniżej.

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

Gdy używasz GStreamer z x264enc jako koderem, łączna skumulowana opłata procesora gst-launch-1.0 wynosi około 380%, co potwierdza fakt, że omxh264enc faktycznie korzysta z GPU. Ponadto przy x264enc w (2) czas przekracza 15 minut.

Wniosek:

W przypadku dość podobnego rozmiaru pliku czas spędzony przez przyspieszany sprzętowo koder GPU RaspBerry Pi 2 był prawie dwukrotnie dłuższy niż w przypadku programowego kodera x264 na dwurdzeniowym procesorze i7-2620M. Dodanie transkodowania i multipleksowania dźwięku może nieco zlikwidować tę lukę z powodu w dużej mierze nieużywanego procesora na RaspBerry Pi podczas tego testu. Jakość wideo była wyraźnie lepsza w przypadku pliku zakodowanego programowo. Zobacz zdjęcia poniżej.

Dostępne opcje konfiguracji omxh264enc (ujawnione przez gst-inspect-1.0) są ograniczone w porównaniu do kodera x264, ale dalsze eksperymenty mogłyby zapewnić lepszą jakość.

Załącznik:

Instalacja GStreamer i OpenMax z repozytoriów 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 wciąż z wideo 720p transkodowanego przy użyciu HandBrake (x264) na MacBooku Pro (otwórz lub pobierz obraz, aby uzyskać szczegółowe informacje):

QuickTime X wciąż z 720p wideo transkodowanego przy użyciu GStreamer (kodowanie sprzętowe przez OpenMAX) na Raspberry Pi 2 (otwórz lub pobierz obraz, aby uzyskać szczegółowe informacje):

Aktualizacja:

Zgodnie z sugestią ecc29 dotyczącą zastosowania metody skalowania lanczos wykonałem test dodawania method=lanczosdo videoscale. Proces kodowania podwoił się w czasie, skacząc z około 7 minut do 14 minut 37 sekund. Wynik jest prawie równy jakościowo bez metody (domyślnie dwuliniowy). W rzeczywistości defekty pochodzą głównie z procesu kodowania sprzętowego. Są to wyraźnie artefakty kompresji.

Procesor graficzny w RPi jest dość mocny. Przeczytałem, że w zakresie kodowania możesz zakodować 1080p @ 30 fps. Możliwe jest również kodowanie wielu strumieni. Uważa się również, że można zakodować wideo w locie za pomocą RPi.

Ale. Współczesne karty graficzne mogą obsługiwać cały kodowanie na GPU, w czym GPU jest naprawdę dobra.

Gdybym musiał ocenić osobistą opinię. Byłoby tak, że RPi nie byłby szybszy niż karta graficzna o średniej specyfikacji. Myślę jednak, że byłoby to o wiele szybsze niż myślisz. Może nawet blisko 75% prędkości.

Nigdzie nie mogłem znaleźć porównania.