Olemme kehittäneet sovelluksen, jolla koodataan .mov-lähdetiedostot .ogg-, .mp4- ja .webm-ulostuloksi. Se toimii tällä hetkellä AWS EC2 -instanssilla g2.8xlarge. Se toimii (yay!).

Kysymykseni: Vaikka välitän -threads 0 ffmpeg-komennolle (asetat itse asiassa ffmpeg.threads kokoonpano php-ffmpeg ), käynnissä oleva prosessi suoritetaan joskus vain yhdellä ytimellä. Miksi tämä tapahtuu? Katso alla oleva htop -komennon lähtö:

htop-lähtö

Kuten näette , Ydin # 21 on maksimoitu. Muutamassa sekunnissa se siirtyy toiseen, sen sijaan, että maksimoi kaikki ne, kuten haluaisin, ja nopeuttaa huomattavasti koodausprosessiani. Tilanne on ohimenevä; joidenkin suoritusten aikana kaikki prosessorit ovat maksimoi, mutta toisten aikana ne eivät ole, ja käytämme vain yhtä prosessoria. Eräs kollega mainitsi, että ehkä koodekki, jota käytämme joissakin muodoissa, ei tue monisäikeistä suoritusta koodauksen aikana, vaikka en voi vielä varmistaa, että käyttäytymistäni vielä tarkkailen.

Onko näin? Jos on, mitkä yllä olevien muotojen koodekit antavat meille mahdollisuuden koodata näihin kohdemuotoihin samalla kun hyödynnämme kaikki käytettävissä olevat laitteistomme? Oletusarvoiset koodekit, jotka on asetettu php-ffmpeg: lle, ovat alla; 

 Video Audio Ogg libtheora libvorbis WebM libvpx libvorbis X264 libx264 libfaac

Päivitä

Käynnissä olevia prosesseja tarkasteltaessa alla on mikä on MP4: lle suoritettava ffmpeg-komento (joka kyllästää kaikki 32 ydintä):

En itse rakenna tätä komentoa suoraan, php-ffmpeg on, vaikka uskonkin, että minulla on ainakin vaatimaton määräysvalta menevään siihen (esimerkiksi minulla ei ole aavistustakaan, miksi alussa on useita -metadata:s:v:0 -merkintöjä)

Kommentit

  • Siellä ’ on paljon yuck-tekijää kyseisessä komentorivissä, lukuun ottamatta päällekkäisiä vaihtoehtoja (-s kolme kertaa , viimeinen erikokoinen). Asettamalla joukko argumentteja nimenomaisesti nykyisiin oletusarvoihinsa (esim. -i_qfactor, -subq, -qcomp) on outo ja voi tuottaa huonoja tuloksia tulevalla libx264: llä. (Luultavasti ei, mutta vain siksi, että libx264 on melkein valmis ja vakaa, ei kovin kehittyneenä. Jos se tekisi tällaisia asioita x265: lle, se olisi huono.) Joka tapauksessa 2-passinen 1200 k on hieno, mutta saatat mieluummin kohdistaa -laatu crf. Se ei ’ t määritä -preset. 🙁
  • libfaac ei ole ’ t yhtä hyvä kuin libfdk_aac . Jos käytät ’ tätä maksullisessa palvelussa, ’ on kuitenkin tarkistettava libfdk_aac-käyttöoikeus. Tästä cmdline-osasta puuttuu myös -movflags +faststart
  • ’ s on myös mahdollista, että ffmpeg tuottaa useita ulostuloja samasta Syötä vain useita komentoja rivillä output-options output-filename. Joten kaiken kaikkiaan en ’ ole kovin vaikuttunut php-ffmpeg-tiedostosta, jos ’ s sellainen cmdline, jonka se keksi. Ehkä voit käyttää sitä eri tavalla saadaksesi sen tuottamaan useita ulostuloja kerralla, joten ’ t olla yksisäikeinen teora-askel. Joka tapauksessa, jos se toimii, niin hieno, mutta varokaa muutoksia kooderin oletusasetuksiin ja x264 subme -tasojen merkityksen muuttumiseen tavalla, joka minä cmdline-rivisi vahingoittaa laatua.
  • @Peter kiittää paljon. Mielestäni vastaus on todella, että minun on selvitettävä, kuinka se cmd rakennetaan. Jos pystyn todella tukemaan useita ulostuloja komentoon, luulen, että se antaisi minulle paremman kuvan laitteiston kuormituksen maksimoimisesta.
  • trac.ffmpeg .org / wiki /% 20multiple% 20lähtöjen luominen . Ja joo, olen samaa mieltä siitä, että ’ on todennäköisesti paras. Muussa tapauksessa sinulla on tehtävä, joka ’ on yksi kierteinen jonkin aikaa, ja lataat kaikki ytimesi jonkin muun ajan. Vaikeasti ajoitettavia töitä, jotka käyttäytyvät tällä tavalla.

Vastaa

BTW, tämä kysymys saattaa olla parempi pinonsiirrossa, tai ehkä unix.stackexchange, tai kenties serverfault. Tämä sivusto on mielestäni vähemmän keskittynyt kysymyksiin, joihin ei liity luovien ansioiden tai ainakin havainnollisen video- / äänenlaadun perusteella tehtäviä päätöksiä. Olen kuitenkin kaikki teknisistä yksityiskohdista, joten vastaan.

FFmpeg käyttää oletuksena monisäikeistä ketjutusta, joten et todennäköisesti tarvitse -threads 0. Jos koodauksesi pullonkaulana on yksisäikeinen suodatin tai dekooderi, näet yhden ytimen täyden kuormituksen ja kevyen kuormituksen monille muille ytimille.

Yksi asia, jonka voit tehdä, on tarkistaa lähtövideosi mediatiedot. x264 jättää asetukset h.264-otsikon ASCII-merkkijonoon. Joten joko strings -n20 tai mediainfo saadaksesi: 

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

Huomaa ”säikeet = 4” siellä. Luulen, että asetin sen manuaalisesti neliytimiseen i5 2500k: een sen sijaan, että annoin x264: n käyttää oletusprosessoreita * 1.5, koska minulla oli suoritinta vaativia suodattimia (hqdn3d ja lanczos-downscale) käynnissä.

Joka tapauksessa, libx264: llä, jolla on esimääritetty slower, pitäisi olla ei ongelmia pitää paljon ytimiä varattuina. On joitain koodauksen osia, jotka ovat luonnostaan sarjatuotteita (esim. Viimeisen bittivirran CABAC-koodaus), joten korkean bittinopeuden video, joka ei kuluta paljon prosessorin aikaa viitteiden tarkentamiseen (high subme) useisiin kehyksiin (korkea ref) saattaa näyttää sinun kaltaisen latauskuvion (yksi ketju käyttää 100-prosenttista suoritinta, toiset eivät).

I ”En ole 100% varma siitä, että nopeammat esiasetukset ovat vähemmän rinnakkaisia, mutta tiedän, että CABAC on sarja.

Saadakseen massiivisen yhdensuuntaisen, libx264 voisi käyttää venematkalla RAM-muistia kehysten pitämiseen ja etsiä edelleen 2 tai useampi GOP ja koodaa ne itsenäisesti. Sillä ei kuitenkaan ole mahdollisuutta toimia tällä tavalla.

Yksi tapa käyttää PALJON ytimiä on suorittaa useita erillisiä koodauksia rinnakkain sen sijaan, että vain yksi yksittäinen koodaus käyttää kaikkia ytimiä. Tämä toimii vain, jos sinulla on useita syötetiedostoja, jotka haluat koodata erikseen. Kaupankäynnin aikana ketjutetaan enemmän kuin muistikapasiteetilla ja kaistanleveydellä (mikä vaikuttaa välimuistiin, ellei tämä ole monipistorasiajärjestelmässä, jossa on erilliset L3 ja DRAM-muistit) kullekin suorittimien ryhmälle ja sinulla on prosessit kiinnitetty ytimiin, joten yksi koodaus käyttää ytimiä yhdessä ja toinen toisessa).

Kommentit

  • Kiitos oivalluksista. Kysyin tästä lähinnä siksi, että minulla ’ ei ole lainkaan kysymyksiä ” -koodista ” ja enemmän kulissien takana tapahtuvista asioista ja ajattelin, että tämä sopisi paremmin. ’ Ilmoitan, että moderaattorin huomio siirtyy ja he voivat sitten soittaa.
  • Tällä hetkellä ’ viestin kiinnittäminen uudelleen AWS SQS -jonoon, jolla on linkki jokaiseen tiedostoon. Tässä instanssissa on käynnissä työ, joka kuuntelee kyseisiä viestejä, lataa tiedoston, koodaa sen uudelleen ja lähettää tulostustiedostot ulos, kun jokainen on valmis. Jos luet tätä oikein, ’ sanot, että meidän olisi todennäköisesti järkevämpää edetä ja käynnistää muutama näistä työntekijäprosesseista ja koodata useita tiedostoja rinnakkain eikä yritätkö keskittää kaikki ytimet yhteen prosessiin?
  • Joo, jos ’ sinulla on ongelmia ytimien kyllästämisessä, se ’ s hieno suorittaa koodaus tai 3 rinnakkain. Mielestäni x264: n pitäisi pystyä kyllästämään suurin osa 32 ytimestäsi, mutta ehkä vain hitaammalla esiasetuksella. Lähetä ffmpeg cmdline -vaihtoehdot ja konsolilähtö kysymykseesi. IDK, jos ’ käytät jotain typerää ja heikkolaatuista, kuten -preset veryfast. Jos näin on, tulon dekoodaus voi olla yhden säikeisen pullonkaula. Tai kuten sanoin, ehkä hidas suodatin.
  • Sinä ’ haluat varmasti päällekkäin yhden xcode-tiedoston lataamisen / lataamisen toisen suorittimen kanssa. xcode, jos ’ et aio suoratoistaa ffmpegiin / lennosta lennossa tuotantokäyttöön. ( voi olla mahdollista saada -movflags +faststart: n ekvivalentti lennossa toisella äänenvoimakkuudella. Luulen, että luin siitä jotain. Muuten, jos ’ Tulosta mp4 uudelleen, sinun on tietysti tulostettava tiedostoon, jotta ffmpeg voi laittaa moov -atomin eteen ja sekoittaa tietoja toisistaan kun koodaus on valmis.)
  • Voi, luin vain Q: si tarkemmin. Jos ’ syötät kaikki 3 muotoa kerralla (samalla ffmpeg-komentorivillä, joten syötteen dekoodaamisen on tapahduttava vain kerran), niin jos jokin kolmesta kooderista on yksisäikeinen, se pullottaa koko prosessin. Luulen, että libtheora ei ole monisäikeinen. wiki.xiph.org/TheoraEncoders sanoo, että haarukka oli monisäikeinen, mutta se kuoli. (ei ehkä koskaan toiminut hyvin tai ei ollut ’ yhteensopiva muiden kooderiparannusten kanssa? Voisiko se olla monista syistä, miksi ’ ei yhdistetty.) lists.xiph.org/pipermail//theora-dev/2015-February/004374.html

Vastaus

libtheora on yksisäikeinen. Kokeellinen koontiversio on monisäikeinen, mutta sitä ei ylläpidetä. Ehdotan sen suorittamista rinnakkain muiden koodausten kanssa. Käytä myös, jos mahdollista, libfdk-aacia libfaacin yli.Paljon korkeampi äänenlaatu samalla bittinopeudella.

Vastaa

Sähköpostiosoitettasi ei julkaista. Pakolliset kentät on merkitty *