Vi har utvecklat ett program för att koda om .mov-filer till .ogg-, .mp4- och .webm-utdata. Den körs för närvarande på AWS EC2-instans g2.8xlarge. Det fungerar (ja!).

Min fråga: Även om jag skickar in -threads 0 till ffmpeg-kommandot (ställer faktiskt in ffmpeg.threads -konfiguration i php-ffmpeg ) körs ibland bara en enda kärna. Varför händer det här? Se nedan utdata från htop -kommando:

htop-utdata

Som du kan se , Core # 21 är max. Om några sekunder kommer det att byta till en annan snarare än att maximera dem alla som jag skulle vilja och påskynda min kodningsprocess kraftigt. Situationen är kortvarig; under vissa körningar är alla processorerna maxade, men under andra är de inte det och vi använder bara den ena processorn. En kollega nämnde att kanske kodeken vi använder för några av formaten inte stöder exekvering av flera trådar under kodning, även om jag inte kan verifiera att det är det beteende jag observerar ännu.

Är detta fallet? Om så är fallet, vilka codecs för formaten ovan gör det möjligt för oss att omvandla till dessa målformat samtidigt som vi utnyttjar all vår tillgängliga hårdvara? Standardkodecerna som är inställda för php-ffmpeg är nedan; 

 Video Audio Ogg libtheora libvorbis WebM libvpx libvorbis X264 libx264 libfaac

Uppdatera

Tittar på de körande processerna nedan är vad som slutar vara kommandot ffmpeg som körs för en MP4 (för närvarande mättar alla 32 kärnor):

Jag bygger faktiskt inte det här kommandot direkt, php-ffmpeg är, även om jag tror att jag har åtminstone en liten kontroll över vad som går in i det (till exempel har jag ingen aning om varför det finns flera -metadata:s:v:0 poster i början)

Kommentarer

  • Det finns ’ mycket yuck-faktor i den kommandoraden, förutom de dubblerade alternativen (-s tre gånger , den sista med en annan storlek). Ställer uttryckligen ett gäng args till deras nuvarande standardvärden (t.ex. -i_qfactor, -subq, -qcomp) är konstigt och kan ge dåliga resultat med framtida libx264. (Förmodligen inte, men bara för att libx264 är ganska gjort och stabilt, inte under tung utveckling. Om det gjorde saker som detta för x265, skulle det vara dåligt.) Hur som helst, 2-pass 1200k är bra, men du kanske föredrar mål -kvalitet crf. ’ anger inte -preset. 🙁
  • libfaac isn ’ t så bra som libfdk_aac Om du ’ använder det här i en betaltjänst måste du dock ’ kontrollera licensiering av libfdk_aac. Denna cmdline saknas också -movflags +faststart
  • Det ’ är också möjligt att få ffmpeg att producera flera utgångar från samma har bara flera sekvenser av utdata-alternativ utdatafilnamn på kommandoraden. Så allt som allt, jag ’ är inte så imponerad av php-ffmpeg, om det ’ är den typ av cmdline den kommer med. Kanske kan du använda den annorlunda för att få den att generera flera utgångar samtidigt, så det skulle inte ’ t var ett enda gängat theora-steg. Hur som helst, om det fungerar, så bra, men se upp för att ändringar av kodarens standardinställningar, och innebörden av x264 subme nivåer förändras, på sätt som jag en din cmdline skadar kvaliteten.
  • @Peter tack så mycket. Jag tror att svaret här verkligen är att jag måste felsöka hur den cmd byggs. Om jag verkligen kan fylla flera utgångar i det kommandot, tror jag att det förmodligen skulle ge mig det bättre skottet att maximera belastningen på hårdvaran
  • trac.ffmpeg .org / wiki / Skapa% 20multiple% 20outputs . Och ja, jag håller med om att ’ är förmodligen bäst. Annars har du en uppgift som ’ är engängad under en del av sin tid och laddar alla dina kärnor under någon annan del av tiden. Svårt att schemalägga jobb som beter sig på det sättet.

Svar

BTW, den här frågan kan vara bättre på stackoverflow, eller kanske unix.stackexchange, eller kanske serverfel. Jag tror att den här webbplatsen är mindre fokuserad på frågor som inte handlar om beslut baserade på kreativa meriter eller åtminstone perceptuell video / ljudkvalitet. Men jag handlar om tekniska detaljer, så jag svarar.

FFmpeg använder multi-threading som standard, så du behöver inte -threads 0. Om din kod är flaskhalsad på ett filter eller avkodare med en gänga, ser du full belastning på en kärna och lätt belastning på många andra kärnor.

En sak du kan göra är att kontrollera mediainfo av din utdatavideo. x264 lämnar sina inställningar i en ASCII-sträng i h.264-rubriken. Så antingen strings -n20 eller mediainfo för att få: 

... 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

Obs ”trådarna = 4” där inne. Jag tror att jag ställer in det manuellt på min fyrkärna i5 2500k, istället för att låta x264 använda standardprocessorerna * 1,5, eftersom jag hade ett CPU-intensivt filter (hqdn3d och lanczos-nedskala) igång.

Hur som helst, libx264 med en förinställning som slower borde ha nej problem med att hålla många kärnor upptagna. Det finns vissa delar av kodningen som i sig är seriella (t.ex. CABAC-kodningen för den slutliga bitströmmen), så en video med hög bitrate som inte spenderar mycket CPU-tid på att förfina referenser (hög subme) till flera ramar (hög ref) kan visa ett belastningsmönster som ditt (en tråd med 100% CPU, andra inte).

I ”Jag är inte 100% säker på att snabbare förinställningar är mindre parallella, men jag vet att CABAC är seriell.

För att bli massivt parallella skulle libx264 kunna använda en båtmängd RAM för att hålla ramar runt och fortsätta göra lookahead i 2 eller fler GOP, och kodar dem oberoende. Det har dock inte ett alternativ att fungera på det sättet.

Ett sätt att använda MÅNGA kärnor är att köra flera separata kodar parallellt, istället för bara en serie med enkel kodning med alla kärnor. Detta fungerar bara om du har flera inmatningsfiler som du vill koda separat. Du byter ut trådning över huvudet jämfört med mer minneskapacitet och bandbredd (med inverkan på cachning, såvida det inte sker på ett system med flera socklar med separat L3 och DRAM för varje kluster av CPU: er, och har du processerna fästa på kärnor så att den ena koden använder kärnorna i ett uttag och det andra det andra).

Kommentarer

  • Tack för insikten. Jag frågade här främst för att jag inte ’ inte alls har några frågor angående ” kod ” och mer om vad som händer bakom kulisserna och trodde att detta skulle passa bättre. Jag ’ kommer att flagga för moderatorns uppmärksamhet att migrera och sedan kan de ringa samtalet.
  • Just nu ’ åter infoga ett meddelande i en AWS SQS-kö som har en länk till varje fil. Denna instans har ett jobb som lyssnar på dessa meddelanden, laddar ner filen, kodar om den och laddar upp utdatafilerna när alla har slutförts. Om jag läser detta korrekt säger du ’ att det förmodligen skulle vara vettigare för oss att gå vidare och starta några av dessa arbetsprocesser och koda om flera filer parallellt snarare än försöka fokusera alla kärnor på en enda process?
  • Ja, om du ’ har problem med att mätta fler kärnor, ’ är bra för att köra en kod eller 3 parallellt. Jag tror att x264 borde kunna mätta de flesta av dina 32 kärnor, men kanske bara med en långsammare förinställning. Lägg upp dina ffmpeg cmdline-alternativ och konsolutgång i din fråga. IDK om du ’ använder något dumt och låg kvalitet som -preset veryfast. Om så är fallet kan avkodning av ingången vara flertrådsflaskan med en tråd. Eller som sagt, kanske ett långsamt filter.
  • Du ’ kommer säkert att vilja överlappa nedladdning / uppladdning av en xkod med CPU-användningen av en annan xcode, om du ’ inte planerar att strömma till / från ffmpeg i farten för produktionsanvändning. (Det kan vara möjligt att få motsvarigheten till -movflags +faststart i farten, med en annan muxer. Jag tror att jag har läst något om det. Annars, om du ’ om du matar ut mp4 måste du mata ut till en fil så att ffmpeg kan lägga moov -atomen på framsidan och blanda data över när kodningen är klar.)
  • Åh, jag läste bara din Q mer detaljerat. Om du ’ återmatar alla 3 format på en gång (med samma ffmpeg-kommandorad, så måste avkodningen av ingången bara ske en gång), om en av de tre kodarna är en tråd, kommer det att flaskhalsa hela processen. Jag tror att libtheora är inte flertrådad. wiki.xiph.org/TheoraEncoders säger att det fanns en gaffel med flera trådar, men den dog. (kanske aldrig fungerat bra, eller var inte ’ inte kompatibelt med andra kodarförbättringar? Det kan vara många anledningar till att det inte ’ slogs samman.) lists.xiph.org/pipermail//theora-dev/2015-February/004374.html

Svar

libtheora är en tråd. Det finns en flertrådad experimentell byggnad men underhålls inte. Jag föreslår att du kör den parallellt med de andra koderna. Använd även libfdk-aac över libfaac om möjligt.Mycket högre ljudkvalitet vid samma bithastighet.

Lämna ett svar

Din e-postadress kommer inte publiceras. Obligatoriska fält är märkta *