We hebben een applicatie ontwikkeld om .mov-bronbestanden te transcoderen naar .ogg-, .mp4- en .webm-uitvoer. Het draait momenteel op AWS EC2-instantie g2.8xlarge. Het werkt (ja!).

Mijn vraag: ook al geef ik -threads 0 door aan het ffmpeg-commando (stel in feite ffmpeg.threads configuratie in php-ffmpeg ), wordt het lopende proces soms alleen op een enkele kern uitgevoerd. Waarom gebeurt dit? Zie onderstaande uitvoer van htop commando:

htop uitvoer

Zoals je kunt zien , Core # 21 is maximaal. Binnen een paar seconden zal het overschakelen naar een andere, in plaats van ze allemaal te maximaliseren zoals ik zou willen, en mijn coderingsproces aanzienlijk versnellen. De situatie is van voorbijgaande aard; tijdens sommige runs zijn alle processors maxed out, maar tijdens andere zijn ze dat niet en krijgen we alleen gebruik van de ene processor. Een collega zei dat de codec die we voor sommige van de formaten gebruiken misschien geen multi-threaded executie ondersteunt tijdens het coderen, hoewel ik nog niet kan verifiëren dat dit het gedrag is dat ik observeer.

Is dit het geval? Zo ja, welke codecs voor de bovenstaande indelingen zullen ons in staat stellen om te transcoderen naar deze doelindelingen terwijl we profiteren van al onze beschikbare hardware? De standaard codecs die zijn ingesteld voor php-ffmpeg staan hieronder; 

 Video Audio Ogg libtheora libvorbis WebM libvpx libvorbis X264 libx264 libfaac

Update

Kijkend naar de lopende processen, hieronder is wat uiteindelijk het ffmpeg commando is dat wordt uitgevoerd voor een MP4 (momenteel verzadigd alle 32 cores):

Ik” bouw dit commando niet rechtstreeks, php-ffmpeg is, hoewel ik geloof dat ik op zijn minst een bescheiden hoeveelheid controle heb over wat er gebeurt erin (ik heb bijvoorbeeld geen idee waarom er aan het begin meerdere -metadata:s:v:0 -items staan)

Reacties

  • Er ‘ is een boel bah-factor in die opdrachtregel, afgezien van de dubbele opties (-s drie keer , de laatste met een andere maat). Een aantal args expliciet instellen op hun huidige standaardwaarden (bijv. -i_qfactor, -subq, -qcomp) is raar en kan slechte resultaten opleveren met toekomstige libx264. (Waarschijnlijk niet, maar alleen omdat libx264 vrijwel klaar is, en stabiel, niet onder zware ontwikkeling. Als het dit soort dingen zou doen voor x265, zou dat slecht zijn.) Hoe dan ook, 2-pass 1200k is prima, maar misschien geef je de voorkeur aan target -kwaliteit crf. Het specificeert geen ‘ een -preset. 🙁
  • libfaac isn ‘ t zo goed als libfdk_aac . Als u ‘ dit in een betaalde dienst gebruikt, moet u ‘ de licenties van libfdk_aac controleren. Ook ontbreekt deze cmdline -movflags +faststart
  • Het is ‘ s ook mogelijk om ffmpeg meerdere outputs te laten produceren van dezelfde invoer. Zet gewoon meerdere reeksen uitvoer-opties uitvoer-bestandsnaam op de opdrachtregel. Dus al met al ben ik ‘ niet onder de indruk van php-ffmpeg, als dat ‘ is het soort cmdline waarmee het op de proppen komt. Misschien zou je het op een andere manier kunnen gebruiken om meerdere outputs tegelijk te genereren, dus er zou geen ‘ t een theora-stap met één thread zijn. Hoe dan ook, als het werkt, dan is dat geweldig, maar pas op voor wijzigingen in de standaardinstellingen van de encoder en de betekenis van x264 subme niveaus die veranderen, op een manier waarop ik en je cmdline doet de kwaliteit pijn.
  • @Peter heel erg bedankt. Ik denk dat het antwoord hier echt is dat ik moet debuggen hoe die cmd wordt gebouwd. Als ik echt meerdere uitgangen in die opdracht kan stoppen, denk ik dat dat me waarschijnlijk de betere kans zou geven om de belasting van de hardware te maximaliseren.
  • trac.ffmpeg .org / wiki /% 20multiple% 20outputs maken. En ja, ik ben het ermee eens dat ‘ waarschijnlijk het beste is. Anders heb je de taak die ‘ enige tijd single-threaded is, en al je cores voor een ander deel van de tijd laadt. Het is moeilijk om taken in te plannen die zich zo gedragen.

Antwoord

Tussen haakjes, deze vraag is misschien beter op stackoverflow, of misschien unix.stackexchange, of misschien serverfault. Deze site is volgens mij minder gericht op vragen die geen betrekking hebben op beslissingen op basis van creatieve verdiensten of op zijn minst perceptuele video- / audiokwaliteit. Het gaat me echter helemaal om de technische details, dus ik zal antwoorden.

FFmpeg gebruikt standaard multi-threading, dus je hebt waarschijnlijk geen -threads 0 nodig. Als je codering een bottleneck heeft op een filter of decoder met één schroefdraad, zie je volledige belasting op één kern en lichte belasting op veel andere kernen.

Een ding dat u kunt doen, is de media-informatie van uw uitvoervideo controleren. x264 laat zijn instellingen achter in een ASCII-string in de h.264-header. Dus ofwel strings -n20 of mediainfo voor: 

... Chroma subsampling : 4:2:0 Bit depth : 8 bits Scan type : Progressive Bits/(Pixel*Frame) : 0.051 Stream size : 455 MiB (89%) Writing library : x264 core 146 r2538+1 d48ec67 Encoding settings : cabac=1 / ref=6 / deblock=1:0:0 / analyse=0x3:0x133 / me=umh / subme=10 / psy=1 / psy_rd=0.70:0.10 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-3 / threads=4 / lookahead_threads=1 / sliced_threads=0 / nr=50 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=5 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=60 / rc=crf / mbtree=1 / crf=22.5 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=3:0.60 Color primaries : BT.709 Transfer characteristics : BT.709 Matrix coefficients : BT.709

Opmerking de “threads = 4” daarin. Ik denk dat ik dat handmatig heb ingesteld op mijn quad core i5 2500k, in plaats van x264 de standaard CPUs * 1.5 te laten gebruiken, aangezien ik CPU-intensieve filters (hqdn3d en lanczos-downscale) had draaien.

Hoe dan ook, libx264 met een preset zoals slower zou nee problemen moeten hebben om veel cores bezig te houden. Sommige delen van de codering zijn inherent serieel (bijv. De CABAC-codering van de laatste bitstream), dus een video met een hoge bitsnelheid die niet veel CPU-tijd besteedt aan het verfijnen van verwijzingen (hoge subme) naar meerdere frames (high ref) kan een laadpatroon weergeven zoals dat van jou (één thread gebruikt 100% CPU, andere niet).

I “Ik ben er niet 100% zeker van dat snellere presets minder parallel zijn, maar ik weet dat CABAC serieel is.

Om massaal parallel te worden, zou libx264 een bootlading RAM kunnen gebruiken om frames rond te houden, en voor 2 of meer GOPs, en codeer deze onafhankelijk. Het heeft echter geen optie om op die manier te werken.

Een manier om gebruik te maken van VEEL cores is om meerdere afzonderlijke coderingen parallel te draaien, in plaats van slechts een reeks enkele coderingen die alle cores gebruiken. Dit werkt alleen als je meerdere invoerbestanden hebt die je apart wilt coderen. Je ruilt threading overhead in tegen meer geheugencapaciteit en bandbreedte (met een impact op caching, tenzij dit op een multi-socket systeem is met aparte L3 en DRAM voor elk cluster van CPUs, en heb je de processen vastgemaakt aan kernen, dus de ene codering gebruikt de kernen in de ene socket en de andere in de andere).

Opmerkingen

  • Bedankt voor het inzicht. Ik heb het hier voornamelijk gesteld omdat ik geen ‘ vragen heb over ” code ” en meer over wat er achter de schermen gebeurt en dacht dat dit beter zou passen. Ik ‘ ll markeren voor de aandacht van de moderator om te migreren en dan kunnen ze bellen.
  • Op dit moment ‘ opnieuw een bericht op een AWS SQS-wachtrij plaatsen met een link naar elk bestand. Deze instantie heeft een taak die naar die berichten luistert, het bestand downloadt, transcodeert en de uitvoerbestanden uploadt zodra elk klaar is. Als ik dit goed lees, zeg je ‘ dat het waarschijnlijk logischer zou zijn om door te gaan en een paar van deze werkprocessen te starten en meerdere bestanden parallel te transcoderen in plaats van proberen om alle cores op één proces te focussen?
  • Ja, als je ‘ problemen ondervindt bij het verzadigen van meer cores, is het ‘ s prima om een codering of 3 parallel uit te voeren. Ik denk dat x264 de meeste van je 32 cores zou moeten kunnen verzadigen, maar misschien alleen met een langzamere preset. Plaats uw ffmpeg cmdline-opties en console-uitvoer in uw vraag. IDK als je ‘ iets dwaas en van lage kwaliteit gebruikt, zoals -preset veryfast. Als dit het geval is, kan het decoderen van de invoer de bottleneck met één thread zijn. Of zoals ik al zei, misschien een traag filter.
  • U ‘ zult zeker het downloaden / uploaden van een xcode willen overlappen met het CPU-gebruik van een andere xcode, als je ‘ niet van plan bent om on-the-fly naar / van ffmpeg te streamen voor productiegebruik. (Het is misschien mogelijk om het equivalent van -movflags +faststart on-the-fly te krijgen, met een andere muxer. Ik denk dat ik daar iets over heb gelezen. Anders, als je ‘ Als u mp4 uitvoert, moet u een beetje naar een bestand uitvoeren, zodat ffmpeg het moov atoom vooraan kan plaatsen en de gegevens kan schudden als het coderen is voltooid.)
  • Oh, ik heb je Q zojuist in meer detail gelezen. Als je ‘ alle 3 de formaten in één keer uitvoert (met dezelfde ffmpeg-opdrachtregel, dus het decoderen van de invoer hoeft maar één keer te gebeuren), als een van de 3 encoders is single-threaded, het zal het hele proces verstoren. Ik denk dat libtheora niet multi-threaded is. wiki.xiph.org/TheoraEncoders zegt dat er een multi-thread fork was, maar deze stierf. (werkte misschien nooit goed, of was niet ‘ t compatibel met andere coderingsverbeteringen? Er kunnen veel redenen zijn waarom het niet ‘ werd samengevoegd.) lists.xiph.org/pipermail//theora-dev/2015-February/004374.html

Antwoord

libtheora is een enkele thread. Er is een experimentele build met meerdere threads, maar deze wordt niet onderhouden. Ik zou willen voorstellen om het parallel met de andere coderingen uit te voeren. Gebruik ook indien mogelijk libfdk-aac in plaats van libfaac.Veel hogere geluidskwaliteit bij dezelfde bitrate.

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *