Spørgsmål:
Hvilken hastighed kan jeg forvente af hardware-H264-kodning?
towi
2012-12-10 21:58:22 UTC
view on stackexchange narkive permalink

Jeg snuble over Wikipedia-artiklen, at Broadcom GPU har hardwaresupport til kodning H.264 / AVC, ikke kun de -kodning.

Jeg fandt også en artikel, hvor nogen gav et eksempel ved hjælp af ffmpeg til at generere en h264 / mp4-videofiler. Ok, det er en almindelig CPU med en specialiseret GPU, så det er ikke virkelig overraskelsen.

Men sammenlignet med en standard stationær pc med et gennemsnitligt grafikkort, vil Raspberry Pi muligvis kode H.264 / AVC måske endnu hurtigere ? Hvis en desktopbruger skulle optimere sin ffmpeg til sin Core-i5xxx med $ 150 Ati / Nvidia grafikkort ... tilbyder denne kombination noget i vejen for "hardware H.264-kodningsunderstøttelse"? Hvis ikke, vil en specielt vedtaget Raspberry-Pi-ffmpeg være endnu hurtigere? Hvis ja, er der allerede en hastighedssammenligning?

Jeg skulle ikke tro, at Raspberry Pi vil være hurtigere end en stationær pc.
Nogen skal helt klart lave et benchmark og vise nogle resultater.
@XTL Kan * du * gøre det? ;-)
Dette er meget godt resultat..kan du tilføje lydkodning til eksempelkommando?
Tre svar:
M. Rubio-Roy
2015-04-12 22:55:39 UTC
view on stackexchange narkive permalink

Fra april 2015 GStreamer 1.2 inkluderet i Raspbian understøtter OpenMAX-hardwareaccelereret H.264-kodning gennem omxh264enc.

Jeg har lavet nogle benchmarking-sammenligninger:

  1. MacBook Pro (Tidlig 2011) dual-core i7-2620M 2,7 GHz (Sandy Bridge) - 4 GB RAM
  2. RaspBerry Pi 2 Model B 900MHz quad-core ARM Cortex-A7 CPU - 1 GB RAM
    3. ol >

    Eksempelfil: 60'ers prøve fra filmen Alatriste (2006). Den originale fil er 1080p og tager 30 MB. Jeg kodede filen til 720p. Alle lydspor blev ignoreret for at koncentrere undersøgelsen om videokodning.

    Resultater:

    On (1) ved hjælp af håndbremse (x264 codec) transkodede jeg med x264-indstillinger er meget lav og gennemsnitlig bithastighed 1145 kbps (1-pass), hvilket resulterede i en 7,7 MB-fil. Profil Høj, niveau 4.0. Kodningen tog 3 min. 36 s ved hjælp af 4 tråde. Samlet kumuleret CPU-opladning af håndbremse ~ 380%. Videokvaliteten var meget god. Små artefakter kunne observeres, og tab af detaljer kunne ikke let observeres. Se stadig nedenfor.

    On (2) ved hjælp af GStreamer og omxh264enc (hardwareaccelereret) transkodede jeg med target-bitrate = 1145000 (1145kbps), control-rate = 1 (variabel bitrate-kontrolmetode) hvilket resulterede en 6,9 MB fil. Kodningen tog 7 min 4 s ved hjælp af 1 tråd. Samlet kumuleret CPU-opladning på gst-launch-1.0 ~ 100%. Videokvaliteten blev mærkbart forringet med artefakter, der var tydeligt synlige og let observerbare tab af detaljer. Se stadig nedenfor. 

      gst-launch-1.0 -v filesrc location = sample-1080p.mp4! dekodebin! videokonverter! \ videoskala! video / x-raw, bredde = 1280, højde = 688! omxh264enc control-rate = 1 \ target-bitrate = 1145000! h264parse! mp4mux! \ filesink location = sample-720p-OMX-1145kbps.mp4

    Når du bruger GStreamer med x264enc som koder, går den samlede kumulerede CPU-opladning af gst-launch-1.0 til ca. 380%, hvilket understøtter det faktum, at omxh264enc faktisk bruger GPU'en. Også med x264enc i (2) går tiden ud over 15 minutter.

    Konklusion:

    For en ret ens filstørrelse var den tid, der blev brugt af den hardwareaccelererede RaspBerry Pi 2 GPU-indkoder, næsten dobbelt så lang som for software x264-koderen på en dual core i7-2620M. Tilføjelse af lydkodning og multiplexing kunne lukke lidt dette hul på grund af den stort set ubrugte CPU på RaspBerry Pi under denne test. Videokvaliteten var klart overlegen på den softwarekodede fil. Se stillbilleder nedenfor.

    Tilgængelige konfigurationsindstillinger for omxh264enc (eksponeret af gst-inspect-1.0) er begrænsede sammenlignet med x264-koderen, men yderligere eksperimenter kan give bedre kvalitet.

    Bilag:

    Installation af GStreamer og OpenMax fra Raspbian-arkiver: 

      $ 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-grim gstreamer1.0-plugins-grim-dbg gstreamer1.0-plugins-grim-doc gstreamer1.0-pulseaudio gstreamer1.0-værktøj gstreamer1.0-x libgstreamer-plu gins-bad1.0-0 libgstreamer-plugins-bad1.0-dev libgstreamer-plugins-base1.0-0 libgstreamer-plugins-base1.0-dev $ gst-launch-1.0 --versiongst-launch-1.0 version 1.2. 0GStreamer 1.2.0

    QuickTime X stadig med 720p video transkodet ved hjælp af HandBrake (x264) på ​​en MacBook Pro (åbn eller download billede for den fulde detalje):

    QuickTime X still of 720p video transcoded using HandBrake (x264) on a MacBook Pro

    QuickTime X stadig med 720p video transkodet ved hjælp af GStreamer (hardwarekodning gennem OpenMAX) på en Raspberry Pi 2 (åbn eller download billede for den fulde detalje):

    QuickTime X still of 720p video transcoded using GStreamer (hardware encoding through OpenMAX) on a Raspberry Pi 2

    Opdatering :►

    Efter ecc29s forslag om at bruge lanczos skaleringsmetode udførte jeg en test, der tilføjede method = lanczos til videoscale . Kodningsprocessen fordobles i tide og springer fra ca. 7 minutter til 14 minutter 37'ere. Resultatet er næsten ens i kvalitet som uden metode (standard bilinear). Faktisk kommer fejlene hovedsageligt fra kodningsprocessen i hardware. De er tydeligt komprimeringsartefakter.

For billedkvaliteten efter GStreamer-kodning bør en anden faktor overvejes. Forskellige parametre for videoskala vil have indflydelse på billedet, før gstreamer sender det til omxh264enc. Videoscale bruger bilinear som standardindstilling. Lanczos er bedre, men det er for langsomt. Udviklerne af gstreamer arbejder på flere muligheder for videoskala, men de er ikke i den stabile udgivelse endnu. Nogle genererede mønstre kan være nyttige ved sammenligning af forskellige muligheder:
`gst-launch-1.0 -e videotestsrc mønster = zone-plade kx2 = 80 ky2 = 45 num-buffere = 1! video / x-raw, bredde = 1920, højde = 1080! videokonverter! videoscale-metode = lanczos! video / x-raw, bredde = 1280, højde = 720! avimux! filsink placering = lanczos_1280.avi`
Jeg har opdateret indlægget med resultaterne af skaleringsmetoden `lanczos`.
Tænker på at købe 3 b +. Enhver opdatering 3 og et halvt år senere? Realtidskodning mulig nu?
Morgan Courbet
2012-12-14 02:11:02 UTC
view on stackexchange narkive permalink

I øjeblikket ser det ud til, at der stadig ikke er nogen stabil software til at kode h264-video ved hjælp af hardware, selvom det er officielt annonceret, at Raspberry Pi understøtter h264-hardwarekodning. Så vi kan ikke lave et benchmark for at sammenligne præstationer med en almindelig pc .

Jeg ved ikke, om nogen arbejder på emnet, men en udvikler fra libav synes pessimistisk om at integrere et sådant modul i det eksisterende libav -projekt (se hans svar den 2. december, 09:23) .

Jeg er glad for at lave et benchmark, når et bibliotek eller software tillader det.

Jeg aner ikke, hvor jeg skal starte, men jeg er måske villig til at prøve det. Jeg søgte altid efter en grund til, at jeg skulle grave i libavcodec src eller - for at være præcis - x264.
GStreamer-biblioteket er i stand til at tilslutte sig Broadcom-chips OpenMax API, og det ser ud til at være i stand til at udføre hardwarekodning: http://gstreamer.freedesktop.org/releases/gst-omx/1.0.0.html
Vincent P
2012-12-11 17:41:02 UTC
view on stackexchange narkive permalink

GPU'en i RPi er ret bøfagtig. Jeg har læst, at med hensyn til kodning kan du kode 1080p @ 30fps. Det er også muligt at kode flere streams. Det antages også, at du kunne kode vidoer i farten ved hjælp af RPi.

Men. Moderne grafikkort har evnen til at køre hele koden på GPU'en, hvilket er en GPU, der er rigtig god til.

Hvis jeg skulle måle en personlig mening. Det ville være, at RPi ikke ville være hurtigere end et medium spec grafikkort. Men jeg tror, ​​at det ville være meget hurtigere, end du tror. Måske endda nær 75% af hastigheden.

Jeg kunne ikke finde en sammenligning tilgængelig overalt.



ⓘ
Denne spørgsmål og svar blev automatisk oversat fra det engelske sprog.Det originale indhold er tilgængeligt på stackexchange, som vi takker for den cc by-sa 3.0-licens, den distribueres under.
Loading...