Am dezvoltat o aplicație pentru transcodarea fișierelor .mov sursă în ieșirile .ogg, .mp4 și .webm. În prezent rulează pe instanța AWS EC2 g2.8xlarge. Funcționează (da!).

Întrebarea mea: Chiar dacă trec -threads 0 la comanda ffmpeg (de fapt setarea ffmpeg.threads configurație în php-ffmpeg ), procesul de rulare este uneori executat doar pe un singur nucleu. De ce se întâmplă asta? Vedeți mai jos ieșirea din comanda htop:

ieșire htop

După cum puteți vedea , Core # 21 este maximizat. În câteva secunde, va trece la altul, mai degrabă decât să-i maximizez pe toți așa cum aș dori și îmi grăbesc foarte mult procesul de codificare. Situația este trecătoare; maxim, dar în timpul altora nu sunt și folosim doar un singur procesor. Un coleg a menționat că poate codecul pe care îl folosim pentru unele dintre formate nu acceptă execuția multi-thread în timpul codificării, deși nu pot verifica că acesta este comportamentul pe care îl observ încă.

Este cazul? Dacă da, ce codecuri pentru formatele de mai sus ne vor permite să transcodăm în aceste formate țintă în timp ce profităm de tot hardware-ul nostru disponibil? Codecurile implicite setate pentru php-ffmpeg sunt mai jos; 

 Video Audio Ogg libtheora libvorbis WebM libvpx libvorbis X264 libx264 libfaac

Actualizare

Privind procesele care rulează, mai jos este ceea ce se termină fiind comanda ffmpeg care este rulată pentru un MP4 (în prezent saturând toate cele 32 de nuclee):

Eu nu construiesc de fapt această comandă direct, php-ffmpeg este, deși cred că am cel puțin o cantitate modestă de control asupra a ceea ce merge în el (de exemplu, nu am idee de ce există mai multe intrări -metadata:s:v:0 la început)

Comentarii

  • Există ‘ o mulțime de yuck-factor în acea linie de comandă, în afară de opțiunile duplicate (-s de trei ori , ultima cu o dimensiune diferită). Setați în mod explicit o grămadă de argumente la valorile lor implicite curente (de exemplu, -i_qfactor, -subq, -qcomp) este ciudat și ar putea da rezultate proaste cu viitoarea libx264. (Probabil că nu, ci doar pentru că libx264 este destul de mult realizat și stabil, nu este în curs de dezvoltare intensă. Dacă ar face astfel de lucruri pentru x265, ar fi rău.) Oricum, 2-pass 1200k este bine, dar s-ar putea să preferați ținta -calitate crf. Nu ‘ nu specifică un -preset. 🙁
  • libfaac nu este ‘ la fel de bun ca libfdk_aac . Dacă ‘ îl utilizați într-un serviciu contra cost, totuși, ‘ trebuie să verificați licențierea libfdk_aac. De asemenea, această cmdline lipsește -movflags +faststart
  • Este ‘ posibil, de asemenea, ca ffmpeg să producă mai multe ieșiri din același input. Doar aveți mai multe secvențe de opțiuni de ieșire output-filename pe linia de comandă. Deci, în general, nu

nu sunt foarte impresionat de php-ffmpeg, dacă ‘ este genul de linie de cmd cu care vine. Poate l-ați putea folosi diferit pentru a obține generarea mai multor ieșiri simultan, deci nu ar fi ‘ t fii un pas teoretic cu un singur fir. Oricum, dacă funcționează, atunci grozav, dar ferește-te de modificările la valorile implicite ale codificatorului și de semnificația nivelurilor x264submecare se modifică, o linie de cmd dvs. dăunează calității.

  • @Peter mulțumesc foarte mult. Cred că răspunsul aici este că trebuie să depan cum se construiește acel cmd. Dacă într-adevăr pot introduce mai multe ieșiri în acea comandă, cred că asta mi-ar oferi probabil o șansă mai bună de a maximiza încărcarea pe hardware
  • trac.ffmpeg .org / wiki / Crearea% 20multiple% 20outputs . Și da, sunt de acord că ‘ este probabil cel mai bun. În caz contrar, aveți sarcina care ‘ este cu un singur fir pentru o parte din timpul său și vă încărcați toate nucleele pentru o altă parte a timpului. Greu de programat lucrări care se comportă așa.

    • Răspunde

    BTW, această întrebare ar putea fi mai bună pe stackoverflow, sau poate unix.stackexchange sau poate serverfault. Cred că acest site este mai puțin concentrat pe întrebări care nu implică decizii bazate pe meritul creativ sau cel puțin pe calitatea video / audio perceptuală. Cu toate acestea, mă refer la detaliile tehnice, așa că voi răspunde.

    FFmpeg folosește implicit multi-threading, deci nu aveți nevoie de -threads 0. Dacă codul dvs. este blocat pe un filtru sau decodor cu un singur fir, veți vedea încărcarea completă pe un singur nucleu și o încărcare ușoară pe multe alte nuclee.

    Un lucru pe care îl puteți face este să verificați informațiile media ale videoclipului dvs. de ieșire. x264 își lasă setările într-un șir ASCII din antetul h.264. Deci, fie strings -n20, fie mediainfo pentru a obține: 

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

    Notă „firele = 4” de acolo. Cred că am setat manual acest lucru pe quad-core-ul meu i5 2500k, în loc să-i las pe x264 să utilizeze CPU-urile implicite * 1.5, întrucât am rulat filtre intensive (hqdn3d și lanczos-downscale).

    Oricum, libx264 cu o presetare ca slower ar trebui să aibă nu probleme în a menține o mulțime de nuclee ocupate. Există câteva părți ale codificării care sunt inerent serial (de exemplu, codificarea CABAC a fluxului de biți final), deci un videoclip cu rată mare de biți care nu „cheltuiește o mulțime de referințe de rafinare a procesorului (high subme) la mai multe cadre (high ref) ar putea afișa un model de încărcare ca al tău (un fir utilizând 100% CPU, altele nu).

    I „Nu sunt 100% sigur că presetările mai rapide sunt mai puțin paralele, dar știu că CABAC este serial.

    Pentru a deveni masiv paralel, libx264 ar putea folosi o încărcătură de memorie RAM pentru a păstra cadrele în jur și a continua să facă față sau mai multe GOP-uri și le codifică independent. Totuși, nu are opțiunea de a funcționa în acest fel.

    O modalitate de a folosi MULTE nuclee este de a rula mai multe coduri separate în paralel, în loc de doar o serie de coduri unice folosind toate nucleele. Acest lucru funcționează numai dacă aveți mai multe fișiere de intrare pe care doriți să le codificați separat. Treceți la tranzacționare overhead-uri vs. mai multă capacitate de memorie și lățime de bandă (cu impact asupra memorării în cache, cu excepția cazului în care acesta este pe un sistem cu mai multe socketuri cu L3 și DRAM separate pentru fiecare cluster de procesoare, și aveți procesele fixate pe nuclee, astfel încât un cod să utilizeze nucleele dintr-un socket, iar celălalt celălalt).

    Comentarii

    • Vă mulțumim pentru informații. Am întrebat aici, în principal, deoarece nu am ‘ deloc întrebări referitoare la ” cod ” și mai multe despre ce se întâmplă în spatele scenei și am crezut că acest lucru ar fi mai potrivit. ‘ voi semnaliza pentru ca atenția moderatorului să migreze și apoi ei pot efectua apelul.
    • În acest moment ‘ lipiți din nou un mesaj pe o coadă AWS SQS care are un link către fiecare fișier. Această instanță rulează o lucrare care ascultă acele mesaje, descarcă fișierul, îl transcodează și încarcă fișierele de ieșire după finalizarea fiecăruia. Dacă citesc corect acest lucru, ‘ spuneți că probabil ar avea mai mult sens să mergem mai departe și să lansăm câteva dintre aceste procese de lucru și să transcodăm mai multe fișiere în paralel decât încercați să focalizați toate nucleele pe un singur proces?
    • Da, dacă ‘ întâmpinați probleme la saturarea mai multor nuclee, ‘ e bine pentru a rula un cod sau 3 în paralel. Cred că x264 ar trebui să poată satura majoritatea celor 32 de nuclee, dar poate doar cu o presetare mai lentă. Postați opțiunile cmdline ffmpeg și ieșirea consolei în întrebarea dvs. IDK dacă ‘ utilizați ceva prostesc și de calitate scăzută, cum ar fi -preset veryfast. Dacă da, atunci decodarea intrării ar putea fi blocajul cu un singur fir. Sau, așa cum am spus, poate un filtru lent.
    • Cu siguranță ‘ veți dori să suprapuneți descărcarea / încărcarea unui cod x cu utilizarea procesorului unui alt cod xcode, dacă ‘ nu intenționați să transmiteți în flux din / către ffmpeg din mers pentru utilizare în producție. ( poate să fie posibil să obțineți echivalentul -movflags +faststart din mers, cu un alt muxer. Cred că am citit ceva despre asta. Altfel, dacă ‘ re scoateți mp4, trebuie să ieșiți într-un fișier, astfel încât ffmpeg să poată pune moov atomul în față și să amestece datele peste când codificarea este terminată.)
    • Oh, tocmai am citit Q-ul dvs. mai detaliat. Dacă ‘ redați toate cele 3 formate dintr-o dată (cu aceeași linie de comandă ffmpeg, deci decodarea intrării trebuie să se întâmple o singură dată), atunci dacă unul dintre cele 3 codificatoare este cu un singur fir, va bloca întregul proces. Cred că libtheora nu este nu multi-threaded. wiki.xiph.org/TheoraEncoders spune că a existat o furcă cu mai multe fire, dar a murit. (poate că nu a funcționat niciodată bine sau nu a fost ‘ compatibil cu alte îmbunătățiri ale codificatorului? Ar putea fi multe motive pentru care nu ‘ nu a fost îmbinat.) lists.xiph.org/pipermail//theora-dev/2015-February/004374.html

    Răspuns

    libtheora are un singur fir. Există o versiune experimentală multithread, dar nu este menținută. Aș sugera să îl rulați în paralel cu celelalte coduri. De asemenea, dacă este posibil, utilizați libfdk-aac peste libfaac.Fidelitate audio mult mai mare la același bitrate.

    Lasă un răspuns

    Adresa ta de email nu va fi publicată. Câmpurile obligatorii sunt marcate cu *