ソースの.movファイルを.ogg、.mp4、.webm出力にトランスコードするアプリケーションを開発しました。現在、AWSEC2インスタンスg2.8xlargeで実行されています。動作しています（イェーイ！）。

私の質問：-threads 0をffmpegコマンドに渡していますが（実際には php-ffmpeg ）の構成では、実行中のプロセスがシングルコアでのみ実行される場合があります。なぜこうなった？以下のhtopコマンドの出力を参照してください。

htop出力

ご覧のとおり、コア＃21が最大になります。数秒で、必要に応じてすべてを最大化するのではなく、別のプロセッサに切り替えて、エンコードプロセスを大幅に高速化します。状況は一時的なものです。一部の実行中は、すべてのプロセッサが は最大になりましたが、他の場合はそうではなく、1つのプロセッサしか使用できません。同僚は、一部の形式で使用しているコーデックは、エンコード中のマルチスレッド実行をサポートしていない可能性があると述べました。まだ観察している動作であることを確認することはできませんが。

そうですか？そうであれば、上記の形式のコーデックを使用すると、これらのターゲット形式にトランスコードできます。利用可能なすべてのハードウェア？php-ffmpegに設定されているデフォルトのコーデックは以下のとおりです。

 Video Audio Ogg libtheora libvorbis WebM libvpx libvorbis X264 libx264 libfaac

更新

実行中のプロセスを見ると、MP4（現在32コアすべてが飽和状態）に対して実行されるffmpegコマンドが次のようになります。

私は実際にこのコマンドを直接作成しているわけではありませんが、php-ffmpegは作成していますが、少なくとも適度な制御ができると思います。その中に（たとえば、最初に複数の-metadata:s:v:0エントリがある理由がわかりません）

コメント

  • '重複したオプション（-s 3回）を除いて、そのコマンドラインには多くのyuck-factorがあります、サイズの異なる最後のもの）。一連の引数を現在のデフォルト値に明示的に設定します（例：-i_qfactor、-subq、-qcomp）は奇妙で、将来のlibx264で悪い結果をもたらす可能性があります。 （おそらくそうではありませんが、libx264がほぼ完成していて安定していて、大規模な開発が行われていないためです。x265でこのようなことをした場合、それは悪いことです。）とにかく、2パス1200kは問題ありませんが、ターゲットを好むかもしれません-品質のcrf。 ' -presetを指定していません。 🙁
  • libfaacは' libfdk_aacほど良くありません。'これを有料サービスで使用している場合は、' libfdk_aacのライセンスを確認する必要があります。また、このコマンドラインには-movflags +faststart
  • 'がありません。ffmpegで同じものから複数の出力を生成することもできます。 input。コマンドラインにoutput-optionsoutput-filenameの複数のシーケンスがあるだけです。したがって、全体として、'は、php-ffmpegにあまり感銘を受けていません。'は、思いついたコマンドラインの種類です。別の方法で使用して、一度に複数の出力を生成できる可能性があるため、' tシングルスレッドの理論ステップになります。とにかく、それが機能する場合は素晴らしいですが、エンコーダのデフォルトの変更と、x264 submeレベルの意味の変更に注意してください。コマンドラインは品質を損ないます。
  • @Peterありがとうございます。ここでの答えは、そのcmdがどのように構築されているかをデバッグする必要があるということだと思います。本当に複数の出力をそのコマンドに詰め込むことができれば、ハードウェアの負荷を最大化するためのより良いショットが得られると思います
  • trac.ffmpeg .org / wiki / Creation％20multiple％20outputs 。そうですね、'がおそらく最善であることに同意します。それ以外の場合は、'が一部の時間シングルスレッドであり、他の一部の時間はすべてのコアをロードするタスクがあります。そのように動作するジョブをスケジュールするのは難しいです。

回答

BTW、この質問はスタックオーバーフローの方が良いかもしれません。または多分unix.stackexchange、または多分serverfault。このサイトは、創造的なメリットや少なくとも知覚的なビデオ/オーディオ品質に基づく決定を伴わない質問にはあまり焦点を当てていないと思います。しかし、私は技術的な詳細がすべてなので、答えます。

FFmpegはデフォルトでマルチスレッドを使用するため、おそらく-threads 0は必要ありません。シングルスレッドのフィルターまたはデコーダーでエンコードがボトルネックになっている場合は、1つのコアで全負荷が発生し、他の多くのコアで軽負荷が発生します。

できることの1つは、出力ビデオのmediainfoを確認することです。 x264は、h.264ヘッダーのASCII文字列に設定を残します。したがって、strings -n20または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

注そこにある「threads = 4」。 CPUを集中的に使用するフィルター（hqdn3dおよびlanczos-downscale）を実行していたため、x264にデフォルトのCPU * 1.5を使用させるのではなく、クアッドコアi52500kで手動で設定したと思います。

とにかく、 slowerのようなプリセットを備えたlibx264は、多くのコアをビジー状態に保つのに問題がないはずです。本質的にシリアルであるエンコーディングのいくつかの部分があります（たとえば、最終ビットストリームのCABACエンコード）。そのため、CPU時間のリファイン参照をあまり消費しない高ビットレートのビデオ（高subme）から複数のフレーム（高ref）にすると、あなたのような負荷パターンが表示される場合があります（1つのスレッドは100％CPUを使用し、他のスレッドは使用しません）。

I 「より高速なプリセットの並列性が低いことについて100％確信はありませんが、CABACがシリアルであることはわかっています。

超並列化するために、libx264は大量のRAMを使用してフレームを維持し、2秒間先読みを続けることができます。以上のGOPを使用し、それらを個別にエンコードします。ただし、そのように動作するオプションはありません。

多くのコアを利用する1つの方法は、すべてのコアを使用する一連の単一エンコードではなく、複数の個別のエンコードを並行して実行することです。これは、個別にエンコードする複数の入力ファイルがある場合にのみ機能します。スレッドのオーバーヘッドとメモリ容量および帯域幅の増加をトレードオフします（これが個別のL3とDRAMを備えたマルチソケットシステムでない限り、キャッシュに影響します） CPUのクラスターごとに、およびプロセスがコアに固定されているため、一方のエンコードで一方のソケットのコアが使用され、もう一方のソケットでコアが使用されます。

コメント

  • 洞察に感謝します。ここで質問したのは、主に' "コード"そして舞台裏で何が起こっているかについてもっと知り、これがより適していると思いました。 'モデレーターが移行するようにフラグを立てると、モデレーターが電話をかけることができます。
  • 現在、'各ファイルへのリンクがあるAWSSQSキューにメッセージを貼り付け直します。このインスタンスには、これらのメッセージをリッスンし、ファイルをダウンロードしてトランスコードし、それぞれが完了すると出力ファイルをアップロードするジョブが実行されています。私がこれを正しく読んでいるとしたら、'先に進んで、これらのワーカープロセスのいくつかを起動し、複数のファイルを並行してトランスコードするよりも、おそらくもっと理にかなっていると言っています。すべてのコアを単一のプロセスに集中させようとしますか？
  • ええ、'より多くのコアを飽和させるのに問題がある場合は、'は、エンコードまたは3を並行して実行するのに問題ありません。 x264は32コアのほとんどを飽和させることができるはずですが、おそらくより遅いプリセットでのみ飽和するでしょう。質問にffmpegコマンドラインオプションとコンソール出力を投稿してください。 ' -preset veryfastのようなばかげた低品質のものを使用している場合はIDK。その場合、入力のデコードがシングルスレッドのボトルネックになる可能性があります。または、私が言ったように、おそらく遅いフィルターです。
  • 'あるxcodeのダウンロード/アップロードを別のxcodeのCPU使用率とオーバーラップさせたいと思うでしょう。 xcode、'本番環境で使用するためにffmpegとの間でオンザフライでストリーミングする予定がない場合。 （別のマルチプレクサを使用して、-movflags +faststartに相当するものをその場で入手できる可能性があります。それについて何か読んだと思います。 ' mp4を出力する場合、ffmpegがmoovアトムを先頭に配置してデータをシャッフルできるように、ファイルに出力する必要があります。エンコードが完了したら。）
  • ああ、あなたのQをもっと詳しく読みました。 ' 3つのフォーマットすべてを一度に出力する場合（同じffmpegコマンドラインを使用するため、入力のデコードは1回だけ行う必要があります）、3つのエンコーダーのいずれかシングルスレッドであるため、プロセス全体がボトルネックになります。 libtheoraはマルチスレッドではないと思います。 wiki.xiph.org/TheoraEncoders は、マルチスレッドフォークがあったと言っていますが、それは死にました。 （うまく機能しなかったか、'他のエンコーダーの改善と互換性がなかった可能性がありますか？'がマージされなかった多くの理由が考えられます。） lists.xiph.org/pipermail//theora-dev/2015-February/004374.html

回答

libtheoraはシングルスレッドです。マルチスレッドの実験的なビルドがありますが、維持されていません。他のエンコードと並行して実行することをお勧めします。また、可能であれば、libfaacではなくlibfdk-aacを使用してください。同じビットレートではるかに高いオーディオ忠実度。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です