Vyvinuli jsme aplikaci pro překódování zdrojových souborů .mov do výstupů .ogg, .mp4 a .webm. Aktuálně běží na instanci AWS EC2 g2.8xlarge. Funguje to (jo!).
Moje otázka: I když předávám -threads 0 příkazu ffmpeg (ve skutečnosti nastavuji konfigurace v php-ffmpeg ), běžící proces se někdy provádí pouze na jednom jádru. Proč se tohle děje? Podívejte se na výstup z htop příkazu:
Jak vidíte , Core # 21 je maxed. Za pár sekund se to přepne na jiný, místo aby je všechny maximálně, jak bych chtěl, a výrazně urychlilo můj proces kódování. Situace je přechodná; během některých běhů jsou všechny procesory maxed out, but during others they are not and we only get use the one processor. Kolega zmínil, že kodek, který „používáme pro některé formáty, nepodporuje během kódování vícevláknové provádění, i když zatím nemůžu ověřit, jaké chování chovám.
Je tomu tak? Pokud ano, jaké kodeky pro výše uvedené formáty nám umožní překódovat do těchto cílových formátů s využitím výhod veškerý náš dostupný hardware? Výchozí kodeky nastavené pro php-ffmpeg jsou níže;
Video Audio Ogg libtheora libvorbis WebM libvpx libvorbis X264 libx264 libfaac Aktualizovat
Podíváme-li se na běžící procesy, níže je to, co skončí jako příkaz ffmpeg, který je spuštěn pro MP4 (aktuálně saturuje všech 32 jader):
Tento příkaz ve skutečnosti nevytvářím přímo, php-ffmpeg je, i když se domnívám, že mám alespoň malou míru kontroly nad tím, co jde do toho (například nemám ponětí, proč je na začátku několik -metadata:s:v:0 záznamů)
Komentáře
- ‚ v tomto příkazovém řádku je spousta faktorů yuck, kromě duplicitních možností (
-střikrát , poslední s jinou velikostí). Explicitní nastavení řady argů na jejich aktuální výchozí hodnoty (např.-i_qfactor,-subq,-qcomp) je divný a s budoucím libx264 by mohl způsobit špatné výsledky. (Pravděpodobně ne, ale jen proto, že libx264 je do značné míry hotový a stabilní, není pod těžkým vývojem. Pokud by to pro x265 udělal takové věci, bylo by to špatné.) 2-pass 1200k je každopádně v pořádku, ale můžete upřednostňovat cíl -kvalitní crf. Nezadává ‚ t-preset. 🙁 -
libfaacnení ‚ tak dobrý jakolibfdk_aac. Pokud to ‚ používáte ve službě for-pay, musíte ‚ zkontrolovat licencování libfdk_aac. V této cmdline také chybí-movflags +faststart - Je ‚ také možné, aby ffmpeg produkoval více výstupů ze stejného vstup. Stačí mít na příkazovém řádku několik sekvencí možností výstupu output-filename. Celkově tedy na mě ‚ není php-ffmpeg příliš ohromen, pokud ‚ s typem cmdline, s nímž přichází. Možná byste jej mohli použít jinak, abyste jej mohli vygenerovat více výstupů najednou, takže ‚ t být krokem teora s jedním vláknem. Každopádně, pokud to funguje, pak skvělé, ale pozor na změny výchozích hodnot kodéru a význam změn úrovní x264
submezpůsobem, který mě vaše cmdline bolí kvalita. - @Peter moc děkuji. Myslím, že zde je opravdu odpověď, že musím ladit, jak se ten cmd staví. Pokud do tohoto příkazu opravdu mohu nacpat více výstupů, myslím, že by mi to pravděpodobně poskytlo lepší šanci na maximalizaci zatížení hardwaru
- trac.ffmpeg .org / wiki / Vytváření% 20 více% 20 výstupů . A ano, souhlasím, že ‚ s je pravděpodobně nejlepší. V opačném případě máte úkol, který ‚ po určitou dobu má jedno vlákno, a po nějakou dobu načítáte všechna jádra. Je těžké naplánovat úlohy, které se tak chovají.
Odpovědět
BTW, tato otázka může být na stackoverflow lepší, nebo možná unix.stackexchange, nebo možná serverfault. Myslím, že se tento web méně zaměřuje na otázky, které nezahrnují rozhodnutí na základě tvůrčích zásluh nebo alespoň vjemové kvality videa / zvuku. Věnuji se však pouze technickým podrobnostem, takže na ně odpovím.
FFmpeg standardně používá více vláken, takže pravděpodobně nepotřebujete -threads 0. Pokud je vaše kódování úzkým hrdlem na filtru nebo dekodéru s jedním vláknem, uvidíte plné zatížení na jednom jádru a nízké zatížení na mnoha dalších jádrech.
Jedna věc, kterou můžete udělat, je zkontrolovat mediainfo výstupního videa. x264 ponechává svá nastavení v řetězci ASCII v záhlaví h.264. Takže buď strings -n20 nebo mediainfo získat:
... 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 Poznámka tam „vlákna = 4“. Myslím, že jsem to ručně nastavil na svém čtyřjádrovém i5 2500k, místo toho, abych nechal x264 používat výchozí CPU * 1,5, protože jsem měl spuštěné filtry náročné na CPU (hqdn3d a lanczos-downscale).
Každopádně, libx264 s přednastavením, jako je slower, by mělo mít žádné potíže se zaměstnáním mnoha jader. Existují některé části kódování, které jsou neodmyslitelně sériové (např. Kódování CABAC konečného bitového toku), takže video s vysokou přenosovou rychlostí, které netráví mnoho časů na dolaďování procesoru (vysoké subme) na více snímků (vysoký ref) může zobrazit vzor načítání, jako je váš (jedno vlákno se 100% CPU, jiné ne).
I „Nejsem si 100% jistý tím, že rychlejší předvolby budou méně paralelní, ale vím, že CABAC je sériový.
Aby byl program paralelně paralelní, mohl by libx264 použít loď RAM k udržení rámců kolem a pokračovat ve vyhledávání pro 2 nebo více GOP a kódovat je nezávisle. Nemá však možnost takto fungovat.
Jedním ze způsobů, jak využít MNOHÝCH jader, je spustit více samostatných kódování paralelně, namísto pouhé série jediného kódování pomocí všech jader. Funguje to pouze v případě, že máte více vstupních souborů, které chcete zakódovat samostatně. Vyměňujete režii podprocesů vs. větší kapacitu paměti a šířku pásma (s dopadem na ukládání do mezipaměti, pokud se nejedná o systém s více sokety se samostatnými L3 a DRAM pro každý klastr procesorů a máte procesy připnuté k jádrům, takže jedno kódování používá jádra v jedné zásuvce a druhé v druhé).
Komentáře
Odpověď
libtheora má jedno vlákno. Existuje vícevláknové experimentální sestavení, ale není udržováno. Navrhoval bych běh paralelně s ostatními kódováními. Pokud je to možné, použijte libfdk-aac nad libfaac.Mnohem vyšší věrnost zvuku při stejném datovém toku.
-preset veryfast. Pokud ano, pak může být dekódováním vstupu úzké místo s jedním vláknem. Nebo jak jsem řekl, možná pomalý filtr.-movflags +faststartza běhu s jiným muxerem. Myslím, že jsem si o tom něco přečetl. Jinak, pokud ‚ Při výstupu mp4 je třeba výstup do souboru, aby ffmpeg mohl umístitmoovatom dopředu a zamíchat data když je kódování hotové.)