Vi har utviklet et program for å omkode kilde .mov-filer til .ogg-, .mp4- og .webm-utdata. Den kjører for øyeblikket på AWS EC2-forekomst g2.8xlarge. Det fungerer (yay!).

Spørsmålet mitt: Selv om jeg sender inn -threads 0 til ffmpeg-kommandoen (faktisk setter ffmpeg.threads -konfigurasjon i php-ffmpeg ), kjøres prosessen noen ganger bare på en enkelt kjerne. Hvorfor skjer dette? Se nedenfor utdata fra htop kommando:

htop-utgang

Som du kan se , Core # 21 er maksimert. I løpet av få sekunder vil det bytte til en annen, i stedet for å maksimere dem alle som jeg vil, og øke hastigheten på kodingsprosessen. Situasjonen er forbigående. I løpet av noen løpeturer er alle prosessorer maksimert, men i løpet av andre er de ikke det, og vi bruker bare den ene prosessoren. En kollega nevnte at kanskje kodeken vi bruker for noen av formatene ikke støtter utførelse av flere tråder under koding, Selv om jeg ikke kan verifisere at oppførselen jeg observerer ennå.

Er dette tilfelle? Hvis ja, hvilke kodeker for formatene ovenfor vil tillate oss å konvertere til disse målformatene mens vi utnytter all vår tilgjengelige maskinvare? Standardkodekene som er angitt for php-ffmpeg er under; 

 Video Audio Ogg libtheora libvorbis WebM libvpx libvorbis X264 libx264 libfaac

Oppdatering

Ser vi på prosessene som kjører, nedenfor er det som er ffmpeg-kommandoen som kjøres for en MP4 (for øyeblikket metter alle 32 kjernene):

Jeg bygger egentlig ikke denne kommandoen direkte, php-ffmpeg er, selv om jeg tror jeg har minst en beskjeden kontroll over hva som går inn i det (for eksempel aner jeg ikke hvorfor det er flere -metadata:s:v:0 oppføringer i begynnelsen)

Kommentarer

  • Det ‘ er mye yuck-faktor i den kommandolinjen, bortsett fra de dupliserte alternativene (-s tre ganger , den siste med en annen størrelse). Angir eksplisitt en rekke args til gjeldende standardverdier (f.eks. -i_qfactor, -subq, -qcomp) er rart, og kan gi dårlige resultater med fremtidig libx264. (Sannsynligvis ikke, men bare fordi libx264 er ganske ferdig, og stabilt, ikke under tung utvikling. Hvis det gjorde ting som dette for x265, ville det være dårlig.) Uansett er 2-pass 1200k greit, men du foretrekker kanskje mål -kvalitet crf. ‘ t spesifiserer en -preset. 🙁
  • libfaac isn ‘ t så godt som libfdk_aac Hvis du ‘ bruker dette i en betaltjeneste, må du ‘ sjekke lisensiering av libfdk_aac. Dessuten mangler denne cmdline -movflags +faststart
  • Det ‘ er også mulig å få ffmpeg til å produsere flere utganger fra samme input. Bare ha flere sekvenser av output-options output-filnavn på kommandolinjen. Så alt i alt er jeg ‘ ikke veldig imponert over php-ffmpeg, hvis det ‘ er den typen cmdline den kommer opp med. Kanskje du kan bruke den annerledes for å få den til å generere flere utganger samtidig, så det ville ikke være ‘ t vær et teoretrinn med en tråd. Uansett, hvis det fungerer, så bra, men vær oppmerksom på endringer i standardinnstillinger for koderen, og betydningen av x264 subme nivåer som endres, på måter som meg en din cmdline skader kvaliteten.
  • @Peter takk så mye. Jeg tror svaret her egentlig er at jeg trenger å feilsøke hvordan den cmd blir bygget. Hvis jeg virkelig kan fylle ut flere utganger i den kommandoen, tror jeg det sannsynligvis ville gi meg bedre muligheter for å maksimere belastningen på maskinvaren
  • trac.ffmpeg .org / wiki / Opprette% 20multiple% 20outputs . Og ja, jeg er enig i at ‘ sannsynligvis er best. Ellers har du en oppgave som ‘ er en-trådet for en del av tiden, og laster inn alle kjernene dine for en annen del av tiden. Vanskelig å planlegge jobber som oppfører seg på den måten.

Svar

BTW, dette spørsmålet kan være bedre på stackoverflow, eller kanskje unix.stackexchange, eller kanskje serverfeil. Jeg tror dette nettstedet er mindre fokusert på spørsmål som ikke involverer avgjørelser basert på kreativ fortjeneste eller i det minste perseptuell video / lydkvalitet. Imidlertid handler jeg om tekniske detaljer, så jeg svarer.

FFmpeg bruker multi-threading som standard, så du trenger ikke -threads 0. Hvis koden din er flaskehalset på et filter eller dekoder med en tråd, vil du se full belastning på en kjerne og lett belastning på mange andre kjerner.

En ting du kan gjøre er å sjekke mediainfo av utdatavideoen. x264 etterlater innstillingene i en ASCII-streng i h.264-overskriften. Så enten strings -n20 eller mediainfo for å 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

Merk «tråder = 4» der inne. Jeg tror jeg har satt det manuelt på min firekjerne i5 2500k, i stedet for å la x264 bruke standard CPUer * 1.5, siden jeg hadde CPU-intensive filtre (hqdn3d og lanczos-nedskala) i gang.

Uansett, libx264 med en forhåndsinnstilling som slower burde ha nei problemer med å holde mange kjerner opptatt. Det er noen deler av kodingen som iboende er serielle (f.eks. CABAC-koden til den endelige bitstrømmen), så en video med høy bithastighet som ikke bruker mye CPU-tid på å foredle referanser (høy subme) til flere bilder (høy ref) kan vise et lastemønster som ditt (en tråd bruker 100% CPU, andre ikke).

I «Jeg er ikke 100% sikker på at raskere forhåndsinnstillinger er mindre parallelle, men jeg vet at CABAC er seriell.

For å bli enormt parallell, kan libx264 bruke en båtmengde RAM for å holde rammer rundt, og fortsette å gjøre lookahead i 2 eller flere GOP, og koder dem uavhengig. Det har ikke mulighet til å operere på den måten, skjønt.

En måte å gjøre bruk av MANGE kjerner på er å kjøre flere separate koder parallelt, i stedet for bare en serie med enkeltkoder som bruker alle kjerner. Dette fungerer bare hvis du har flere inndatafiler du vil kode kodet hver for seg. Du bytter ut tråder overhead mot mer minnekapasitet og båndbredde (med innvirkning på hurtigbufring, med mindre dette er på et fleruttakssystem med separat L3 og DRAM for hver klynge av CPUer, og du har prosessene festet til kjerner, slik at den ene koden bruker kjernene i den ene kontakten, og den andre den andre).

Kommentarer

  • Takk for innsikten. Jeg spurte her hovedsakelig fordi jeg ikke har ‘ t i det hele tatt spørsmål angående » kode » og mer om hva som skjer bak kulissene og tenkte at dette ville passe bedre. Jeg ‘ flagg for moderatorens oppmerksomhet for å migrere, og så kan de ringe.
  • Akkurat nå ‘ re stikker en melding i en AWS SQS kø som har en lenke til hver fil. Denne forekomsten har en jobb som kjører som lytter etter disse meldingene, laster ned filen, transkoder den og laster ut utdatafilene når hver gang er fullført. Hvis jeg leser dette riktig, sier du ‘ at det sannsynligvis ville være mer fornuftig for oss å fortsette og starte noen av disse arbeidsprosessene og omkode flere filer parallelt i stedet for forsøke å fokusere alle kjerner på en enkelt prosess?
  • Ja, hvis du ‘ har problemer med å mette flere kjerner, er det ‘ er greit å kjøre en kode eller 3 parallelt. Jeg tror x264 skal kunne mette de fleste av de 32 kjernene dine, men kanskje bare med en langsommere forhåndsinnstilling. Legg ut ffmpeg cmdline-alternativene og konsollutgangen i spørsmålet ditt. IDK hvis du ‘ bruker noe dumt og lav kvalitet som -preset veryfast. I så fall kan dekoding av inngangen være flertallet med en tråd. Eller som jeg sa, kanskje et tregt filter.
  • Du ‘ vil absolutt ønske å overlappe nedlasting / opplasting av en xcode med CPU-bruken til en annen xcode, hvis du ‘ ikke planlegger å streame til / fra ffmpeg i farta for produksjonsbruk. (Det kan være mulig å få ekvivalenten -movflags +faststart på farten, med en annen muxer. Jeg tror jeg har lest noe om det. Ellers hvis du ‘ Hvis du sender ut mp4, må du ganske enkelt sende til en fil slik at ffmpeg kan plassere moov -atomet foran og blande dataene over når koden er ferdig.)
  • Åh, jeg har bare lest Q-en din mer detaljert. Hvis du ‘ sender ut alle 3 formatene på en gang (med samme ffmpeg-kommandolinje, så avkodingen av inngangen bare må skje en gang), så hvis en av de tre koderne er en-trådet, vil det flaskehalsen hele prosessen. Jeg tror libtheora er ikke flertrådet. wiki.xiph.org/TheoraEncoders sier det var en gaffel med flere tråder, men den døde. (fungerte kanskje aldri bra, eller var ikke ‘ t kompatibel med andre forbedringer av koderen? Kan det være mange grunner til at den ikke ‘ ikke ble slått sammen.) lists.xiph.org/pipermail//theora-dev/2015-February/004374.html

Svar

libtheora er en tråd. Det er en flertrådet eksperimentell build, men vedlikeholdes ikke. Jeg vil foreslå å kjøre den parallelt med de andre kodene. Bruk om mulig også libfdk-aac fremfor libfaac.Mye høyere lydfidelitet ved samme bithastighet.

Legg igjen en kommentar

Din e-postadresse vil ikke bli publisert. Obligatoriske felt er merket med *