Vi har udviklet et program til at kode kilden .mov-filer til .ogg-, .mp4- og .webm-output. Den kører i øjeblikket på AWS EC2-forekomst g2.8xlarge. Det fungerer (yay!).

Mit spørgsmål: Selvom jeg sender -threads 0 til ffmpeg-kommandoen (faktisk indstiller ffmpeg.threads -konfiguration i php-ffmpeg ), køres processen undertiden kun på en enkelt kerne. Hvorfor sker dette? Se nedenstående output fra htop kommando:

htop output

Som du kan se , Core # 21 er maksimeret. Om et par sekunder skifter det til en anden i stedet for at maksimere dem alle, som jeg gerne vil, og fremskynde i høj grad min kodningsproces. Situationen er kortvarig; under nogle kørsler er alle processorer maksimeret, men under andre er de ikke, og vi bruger kun den ene processor. En kollega nævnte, at den codec, vi bruger til nogle af formaterne, muligvis ikke understøtter udførelse af flere tråde under kodning, selvom jeg ikke kan bekræfte, at det er den adfærd, jeg observerer endnu.

Er dette tilfældet? Hvis ja, hvilke codecs til ovenstående formater giver os mulighed for at kode om til disse målformater, mens vi drager fordel af al vores tilgængelige hardware? Standardkodecs indstillet til php-ffmpeg er nedenfor; 

 Video Audio Ogg libtheora libvorbis WebM libvpx libvorbis X264 libx264 libfaac

Opdatering

Ser man på de kørende processer, nedenfor er det, der ender med at være kommandoen ffmpeg, der køres til en MP4 (i øjeblikket mætter alle 32 kerner):

Jeg bygger faktisk ikke denne kommando direkte, php-ffmpeg er, selvom jeg tror, at jeg i det mindste har en beskeden kontrol over hvad der går ind i det (for eksempel har jeg ingen idé om, hvorfor der er flere -metadata:s:v:0 poster i starten)

Kommentarer

  • Der ‘ en masse yuck-faktor i denne kommandolinje, bortset fra de duplikerede indstillinger (-s tre gange , den sidste med en anden størrelse). Indstiller en række args eksplicit til deres nuværende standardværdier (f.eks. -i_qfactor, -subq, -qcomp) er underligt og kunne give dårlige resultater med fremtidig libx264. (Sandsynligvis ikke, men kun fordi libx264 er stort set færdig og stabil, ikke under tung udvikling. Hvis det gjorde ting som dette til x265, ville det være dårligt.) Under alle omstændigheder er 2-pass 1200k fint, men du foretrækker måske mål -kvalitet crf. ‘ t angiver en -preset. 🙁
  • libfaac isn ‘ t så godt som libfdk_aac Hvis du ‘ bruger dette i en betalingstjeneste, skal du ‘ dog kontrollere licensen for libfdk_aac. Denne cmdline mangler også -movflags +faststart
  • Det ‘ er også muligt at få ffmpeg til at producere flere output fra det samme har bare flere sekvenser af output-optioner output-filnavn på kommandolinjen. Så alt i alt er jeg ‘ ikke meget imponeret over php-ffmpeg, hvis det ‘ er den slags cmdline, det kommer op med. Måske kan du bruge det anderledes for at få det til at generere flere output på én gang, så der ville ikke være ‘ t være et enkelt tråd-theora-trin. Under alle omstændigheder, hvis det fungerer, så er det godt, men pas på ændringer af koders standardindstillinger, og betydningen af x264 subme niveauer ændrer sig på måder, som jeg en din cmdline skader kvaliteten.
  • @Peter tak så meget. Jeg tror, at svaret her virkelig er, at jeg er nødt til at debugge, hvordan den cmd bygges. Hvis jeg virkelig kan sætte flere output i den kommando, tror jeg, det sandsynligvis ville give mig det bedre skud for at maksimere belastningen på hardwaren
  • trac.ffmpeg .org / wiki / Oprettelse af% 20multiple% 20outputs . Og ja, jeg er enig i, at ‘ sandsynligvis er bedst. Ellers har du en opgave, der ‘ er engevindet noget af sin tid, og indlæser alle dine kerner en anden del af tiden. Svært at planlægge job, der opfører sig sådan.

Svar

BTW, dette spørgsmål er muligvis bedre ved stackoverflow, eller måske unix.stackexchange eller måske serverfejl. Dette websted er efter min mening mindre fokuseret på spørgsmål, der ikke involverer beslutninger baseret på kreativ fortjeneste eller i det mindste perceptuel video / lydkvalitet. Jeg handler dog kun om de tekniske detaljer, så jeg svarer.

FFmpeg bruger multi-threading som standard, så du behøver sandsynligvis ikke -threads 0. Hvis din kode er flaskehalset på et enkelt gevind eller en dekoder, vil du se fuld belastning på en kerne og let belastning på mange andre kerner.

En ting du kan gøre er at kontrollere mediainfo af din outputvideo. x264 efterlader sine indstillinger i en ASCII-streng i h.264-overskriften. Så enten strings -n20 eller mediainfo for at 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

Bemærk “tråde = 4” derinde. Jeg tror, jeg indstiller det manuelt på min quad-core i5 2500k i stedet for at lade x264 bruge standard-CPUerne * 1.5, da jeg havde CPU-intensive filtre (hqdn3d og lanczos-downscale) kørende.

Alligevel, libx264 med en forudindstilling som slower burde have nej problemer med at holde mange kerner optaget. Der er nogle dele af kodning, der iboende er serielle (f.eks. CABAC-koden for den endelige bitstrøm), så en video med høj bitrate, der ikke bruger meget CPU-tid på at raffinere referencer (høj subme) til flere rammer (høj ref) viser muligvis et belastningsmønster som dit (en tråd bruger 100% CPU, andre ikke).

I “Jeg er ikke 100% sikker på, at hurtigere forudindstillinger er mindre parallelle, men jeg ved, at CABAC er seriel.

For at få massiv parallel kan libx264 bruge en bådfyldt RAM til at holde rammer rundt og fortsætte med at se lookahead i 2 eller flere GOPer og koder dem uafhængigt. Det har dog ikke en mulighed for at fungere på den måde.

En måde at gøre brug af MANGE kerner på er at køre flere separate koder parallelt i stedet for kun en række enkeltkoder ved hjælp af alle kerner. Dette fungerer kun, hvis du har flere inputfiler, som du vil have kodet separat. Du handler med at tråde overhead versus mere hukommelseskapacitet og båndbredde (med indvirkning på cache, medmindre dette er på et system med flere stik med separat L3 og DRAM for hver klynge af CPUer og har du processerne fastgjort til kerner, så den ene kode bruger kernerne i den ene stikkontakt, og den anden den anden).

Kommentarer

  • Tak for indsigten. Jeg spurgte her hovedsagelig fordi jeg ikke ‘ slet ikke har nogen spørgsmål angående ” kode ” og mere om, hvad der foregår bag kulisserne og troede, at dette ville være en bedre pasform. Jeg ‘ Flag for moderatorens opmærksomhed for at migrere, og så kan de foretage opkaldet.
  • Lige nu ‘ re stikker en besked i en AWS SQS-kø, der har et link til hver fil. Denne forekomst har et job, der kører, der lytter til disse beskeder, downloader filen, transkoder den og uploader outputfilerne, når hver er færdig. Hvis jeg læser dette korrekt, siger du ‘ at det sandsynligvis ville give mere mening for os at gå videre og starte et par af disse arbejdsprocesser og omkode flere filer parallelt i stedet for forsøg at fokusere alle kerner på en enkelt proces?
  • Ja, hvis du ‘ har problemer med at mætte flere kerner, er det ‘ er fint til at køre en kode eller 3 parallelt. Jeg synes, x264 burde være i stand til at mætte de fleste af dine 32 kerner, men måske kun med en langsommere forudindstilling. Send dine ffmpeg cmdline-muligheder og konsoloutput i dit spørgsmål. IDK hvis du ‘ bruger noget fjollet og lav kvalitet som -preset veryfast. Hvis det er tilfældet, kan dekodning af input muligvis være single-thread flaskehalsen. Eller som jeg sagde, måske et langsomt filter.
  • Du ‘ vil helt sikkert overlappe download / upload af en xcode med CPU-brugen af en anden xcode, hvis du ‘ ikke planlægger at streame til / fra ffmpeg i farten til produktionsbrug. (Det kan være muligt at få ækvivalenten af -movflags +faststart på farten med en anden muxer. Jeg tror jeg læste noget om det. Ellers hvis du ‘ Når du udsender mp4, skal du ganske enkelt output til en fil, så ffmpeg kan placere moov atom foran og blande data over når kodningen er færdig.)
  • Åh, jeg har lige læst din Q mere detaljeret. Hvis du ‘ udsender alle 3 formater på én gang (med den samme ffmpeg-kommandolinje, så afkodningen af input kun skal ske en gang), så hvis en af de 3 kodere er en tråd, vil det flaskehals hele processen. Jeg synes, libtheora er ikke multi-threaded. wiki.xiph.org/TheoraEncoders siger, at der var en gaffel med flere tråde, men den døde. (måske aldrig fungeret godt, eller var det ikke ‘ t kompatibelt med andre kodningsforbedringer? Det kan være mange grunde til, at det ikke ‘ ikke blev flettet.) lists.xiph.org/pipermail//theora-dev/2015-February/004374.html

Svar

libtheora har en enkelt tråd. Der er en multithreaded eksperimentel build, men vedligeholdes ikke. Jeg vil foreslå at køre det parallelt med de andre koder. Brug også hvis det er muligt libfdk-aac fremfor libfaac.Meget højere lydfidelitet ved samme bithastighed.

Skriv et svar

Din e-mailadresse vil ikke blive publiceret. Krævede felter er markeret med *