Kifejlesztettünk egy alkalmazást a .mov forrásfájlok átkódolására .ogg, .mp4 és .webm kimenetre. Jelenleg AWS EC2 g2.8xlarge példányon fut. Működik (igen!).

Kérdésem: Annak ellenére, hogy átadom a -threads 0 fájlt az ffmpeg parancsnak (valójában a konfiguráció a php-ffmpeg fájlban), a futási folyamat néha csak egyetlen magon fut. Miért történik ez? Lásd az alábbi kimenetet a htop parancsból:

htop kimenet

Amint láthatja , A # 21-es mag maximalizálva van. Néhány másodperc múlva át fog váltani egy másikra, ahelyett, hogy maximalizálnám az összeset, ahogy szeretném, és nagyban felgyorsítja a kódolási folyamatomat. A helyzet átmeneti; egyes futások során az összes processzor t kibővítették, de mások alatt nem, és csak az egyik processzort használjuk. Egy kollégám megemlítette, hogy talán az a kodek, amelyet egyes formátumoknál használunk, nem támogatja a többszálas végrehajtást a kódolás során, bár még nem tudom ellenőrizni, hogy ezt a viselkedést még megfigyelem-e.

Ez a helyzet? Ha igen, akkor a fenti formátumok mely kodekei lehetővé teszik számunkra, hogy átkódolják ezeket a célformátumokat, miközben kihasználják a az összes rendelkezésre álló hardverünk? A php-ffmpeg számára beállított alapértelmezett kodekek alább vannak; 

 Video Audio Ogg libtheora libvorbis WebM libvpx libvorbis X264 libx264 libfaac

Frissítés

A futó folyamatokat tekintve az alábbiak jelentik az MP4 számára futtatott ffmpeg parancsot (amely jelenleg telíti mind a 32 magot):

Ezt a parancsot nem közvetlenül készítem, a php-ffmpeg van, bár úgy gondolom, hogy legalább csekély mértékű irányítással rendelkezem azzal, ami megy benne (például fogalmam sincs, miért van az elején több -metadata:s:v:0 bejegyzés)

Megjegyzések

  • ‘ sok yuck-faktor van abban a parancssorban, a duplikált opciókon kívül (-s háromszor , a végleges más méretű). Egy csomó argumentum kifejezett beállítása az alapértelmezett értékükre (pl. -i_qfactor, -subq, -qcomp) furcsa, és rossz eredményeket hozhat a jövőbeli libx264 használatával. (Valószínűleg nem, de csak azért, mert a libx264 nagyjából kész, és stabil, nincs nagy fejlesztés alatt. Ha ilyesmit csinálna az x265-hez, az rossz lenne.) Egyébként a 2-pass 1200k rendben van, de lehet, hogy inkább a targetet -minőségi crf. Nem ad meg ‘ t -preset. 🙁
  • libfaac nem ‘ t olyan jó, mint libfdk_aac . Ha ‘ ezt fizetős szolgáltatásban használja, akkor ‘ ellenőriznie kell a libfdk_aac engedélyét. Ez a cmdline is hiányzik -movflags +faststart
  • ‘ az is lehetséges, hogy az ffmpeg több kimenetet is produkáljon ugyanabból bemenet. Csak a output-options output-fájlnév szekvenciája legyen a parancssorban. Összességében tehát

nem vagyok nagy hatással a php-ffmpeg-re, ha az ‘ s az a fajta cmdline, amellyel előáll. Lehet, hogy másképp is használhatja, hogy egyszerre több kimenetet generáljon, tehát nem lenne ‘ t legyen egyszálú theora lépés. Mindenesetre, ha működik, akkor nagyszerű, de vigyázzon a kódoló alapértelmezéseinek változásaira, és az x264submeszintek jelentéseinek megváltoztatására, olyan módon, ahogyan én an cmdline fáj a minőség.

  • @Peter nagyon köszönöm. Azt hiszem, a válasz valóban az, hogy ki kell derítenem, hogyan épül fel az a cmd. Ha valóban több kimenetet tudok beilleszteni ebbe a parancsba, akkor azt gondolom, hogy ez jobban megalapozná a hardver terhelésének maximalizálását.
  • trac.ffmpeg .org / wiki /% 20multiple% 20output létrehozása . És igen, egyetértek abban, hogy ‘ valószínűleg a legjobb. Ellenkező esetben van egy olyan feladata, amely ‘ egyszálú egy ideig, és az összes magját az idő másik részében tölti be. Nehéz ütemezni az ilyen módon viselkedő feladatokat.

    • Válasz

    BTW, ez a kérdés jobb lehet stackoverflow esetén, vagy esetleg unix.stackexchange, vagy esetleg serverfault. Úgy gondolom, hogy ez a webhely kevésbé azokra a kérdésekre összpontosít, amelyek nem tartalmaznak kreatív érdemeken vagy legalábbis perceptuális videó / hangminőségen alapuló döntéseket. Mindazonáltal a technikai részletekről szólok, ezért válaszolni fogok.

    FFmpeg alapértelmezés szerint több szálat használ, így valószínűleg nem szükséges -threads 0. Ha kódolásának szűk keresztmetszete van egyszálú szűrőn vagy dekóderen, akkor az egyik mag teljes terhelését és sok más magnak a könnyű terhelését fogja látni.

    Egy dolgot megtehet, hogy ellenőrizze a kimenő videó mediainfóját. Az x264 a h.264 fejléc ASCII karakterláncában hagyja a beállításait. Tehát vagy strings -n20, vagy mediainfo: 

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

    Megjegyzés a “szálak = 4” benne. Azt hiszem, ezt kézzel állítottam be a négymagos i5 2500k-n, ahelyett, hogy az x264-nek az alapértelmezett CPU-kat használnám * 1.5, mivel CPU-intenzív szűrők (hqdn3d és lanczos-downscale) futottak.

    Egyébként, A libx264-nek egy olyan előre beállított beállítással, mint a slower, nem gondja lehet a sok mag elfoglaltságában. A kódolásnak vannak olyan részei, amelyek eredendően sorosak (pl. A végső bitfolyam CABAC kódolása), ezért egy olyan nagy bitrátájú videó, amely nem tölt sok CPU-idejű referenciát (high subme) több képkockára (high ref) előfordulhat, hogy a tiédhez hasonló terhelési minta jelenik meg (egy szál 100% -os CPU-t használ, mások nem).

    I “Nem vagyok 100% -ig biztos abban, hogy a gyorsabb presetek kevésbé párhuzamosak, de tudom, hogy a CABAC soros.

    A tömeges párhuzamosság érdekében a libx264 egy csomó RAM-ot használhat a keretek megtartásához, és 2 percig keresgélhet. vagy több GOP-t, és függetlenül kódolja azokat. Ennek ellenére nincs lehetősége az ilyen módon történő működésre.

    A SOK mag használatának egyik módja az, hogy több különálló kódot futtat párhuzamosan, ahelyett, hogy egyetlen, az összes magot használó egyetlen kódolás sorozata lenne. Ez csak akkor működik, ha több bemeneti fájlja van, amelyeket külön kódolni szeretne. Kereskedjen a menetes rezsivel szemben a nagyobb memóriakapacitással és sávszélességgel (kihatással van a gyorsítótárra, kivéve, ha ez egy különálló L3-mal és DRAM-mal rendelkező sokfoglalatos rendszeren van) A CPU-k minden egyes csoportjához és a folyamatok a magokhoz vannak rögzítve, így az egyik kódolás a magokat használja az egyik foglalatban, a másik pedig a másikat).

    Megjegyzések

    • Köszönöm a betekintést. Főként azért kérdeztem itt, mert nekem ‘ egyáltalán nincs kérdésem a ” kóddal kapcsolatban ” és még többet a kulisszák mögött zajló eseményekről, és úgy gondoltam, hogy ez jobban megfelel. ‘ Megjelölöm a moderátor figyelmét, hogy migrálhasson, majd hívást kezdeményezhessenek.
    • Most ‘ újraragaszt egy üzenetet egy AWS SQS várólistára, amely linket tartalmaz minden fájlhoz. Ennek a példánynak van egy futó feladata, amely meghallgatja ezeket az üzeneteket, letölti a fájlt, átkódolja és feltölti a kimeneti fájlokat, miután mindegyik befejeződött. Ha jól olvasom, ‘ azt mondja, hogy valószínűleg értelmesebb lenne, ha elindítanánk néhányat ezekből a dolgozói folyamatokból, és több fájlt kódolnánk párhuzamosan, nem pedig párhuzamosan. megpróbálja az összes magot egyetlen folyamatra összpontosítani?
    • Ja, ha ‘ problémája van további magok telítésével, akkor ‘ s finom egy kódolás vagy 3 párhuzamos futtatásához. Szerintem az x264-nek képesnek kell lennie a 32 magja nagy részének telítésére, de talán csak egy lassabb előre beállított értékkel. Tegye fel kérdésére az ffmpeg cmdline opciókat és a konzol kimenetét. IDK, ha ‘ valami ostoba és alacsony minőségű terméket használ, például -preset veryfast. Ha igen, akkor a bemenet dekódolása lehet az egyszálas szűk keresztmetszet. Vagy ahogy mondtam, talán lassú szűrő.
    • Ön ‘ biztosan át akarja fedni az egyik xcode letöltését / feltöltését egy másik processzor használatával. xcode, ha ‘ nem tervezed az ffmpeg-be való közvetítést menet közben gyártási célokra. ( Lehet lehetséges, hogy menet közben megkapja a (z) -movflags +faststart megfelelőjét egy másik muxerrel. Azt hiszem, olvastam erről valamit. Egyébként, ha ‘ Ha az mp4-et kiírja, akkor biztosan ki kell küldenie egy fájlba, hogy az ffmpeg elé tudja tenni a moov atomot, és az adatokat átkeverje. amikor elkészült a kódolás.)
    • Ó, csak a Q-t olvastam részletesebben. Ha ‘ egyszerre adja vissza mind a 3 formátumot (ugyanazzal az ffmpeg parancssorral, így a bemenet dekódolásának csak egyszer kell megtörténnie), akkor ha a 3 kódoló egyikének egyszálú, szűk keresztmetszetet jelent az egész folyamat számára. Szerintem a libtheora nem több szálú. A wiki.xiph.org/TheoraEncoders szerint többszálas villa volt, de az elhunyt. (lehet, hogy soha nem működött jól, vagy ‘ nem volt kompatibilis más kódoló fejlesztésekkel? Sok oka lehet annak, hogy nem egyesült ‘.) lists.xiph.org/pipermail//theora-dev/2015-February/004374.html

    Válasz

    A libtheora egyszálú. Van egy többszálas kísérleti felépítés, de nincs fenntartva. Azt javaslom, hogy futtassuk párhuzamosan a többi kóddal. Ha lehetséges, használja a libfdk-aac-t a libfaac felett is.Sokkal nagyobb hanghűség ugyanabban a bitráta mellett.

    Vélemény, hozzászólás?

    Az email címet nem tesszük közzé. A kötelező mezőket * karakterrel jelöltük