Media ComposerはCPUをどう使うのか?

By in ビデオ

かつて、デスクトップやラップトップ用のソフトウェアを購入して実行することは、思慮深く、時間のかかる行為でした。(まだそれが存在していた頃は)ソフトウェア販売店に出向き、(まだそれが存在していた頃は)ソフトウェアの箱を眺め、自分が持っているコンピューターのスペックと比較しながら、仕様を徹底的に吟味しました。

QuickenやDoomのような家庭用ソフトウェアなら、それは難しいことではありません。しかし、業務用のものとなるとどうでしょう?大きなプロジェクトを担当するプロのエディターにとって、あらゆるプロセスの裏側にあるスペックや技術を理解するのは、とても大切なことでした。

当時 Avid Media Composer は単なるソフトウェアではありませんでした。それは高価なターンキーシステムの一部であり、最高の状態で稼働するように設計されたマシンでした。今でも編集システム一式を「アビッド」と呼ぶことがあるのは、この名残です。

今日、私たちはスマートフォンやタブレット、デスクトップ機に至るまで、目に見えるものはすぐにダウンロードし、インストールしています。まるでApp中毒のように。これが新しいワークフローを試し消費する方法であり、すべて巨大なD.I.Y文化のおかげです。その結果として、エディターやアシスタントは自分のマシンを自分で組み上げ、サポートすることになりました。巨大な施設の設計に関わらない限り、ターンキーシステムを使うことはほぼありません。今や、Media Composerはクリックしてダウンロードし、サブスクリプション料金を毎月払うだけで手に入れることができます。しかし、それを動かすコンピューターはどのようなものでしょう?そのマシンはMedia Composerを動かすことができますか?あるいは、より正確にいうなら、「Media Composerはコンピューターをどのように使うのでしょう?」

何年もの間、私たちはこの種の質問をしてきました。特に学生の頃は。例えば アシスタントエディター・ブートキャンプ のような場所は、新人をこの業界に導くための良い例です。しかし、彼らはこのような基本を学んでいるでしょうか?エディターのためのブートキャンプでNoahが私にこの質問をしてきたとき、私はなんとかして正確に答えたいと考え、そのためにはAvidのエンジニアに直接尋ねるべきだと考えました。

2017年、アシスタントエディター・ブートキャンプにて, lead by Noah Chamow.  (assistbootcamp.com)

素晴らしいことに、最近のAvidはこの種の質問に対して非常にオープンです。

Avid ACAの副議長とAvid Pro Video コミュニティーのボランティアモデレーターである私は、Avidのシニアレベルのエンジニアと連絡を取ることができました。回答は、Avidのいくつかのオフィス(マサチューセッツ、ケベック、カリフォルニア)から寄せられました。

Avid Technology Inc本社., 75 Network Drive, Burlington, MA 01803

回答はVP and Chief Architect のシャイレンドラ・マーサーから送られてきました。私がした質問は以下のようなものです。

私は、今回のアシスタントエディター・ブートキャンプで、レンダリングやAVXプラグイン、リアルタイム再生、プロセッサーを消費するコーデック処理等の局面において、Media Composerがコンピューターの何をどのように使っているのかを説明する1ページのガイドを作りたいと考えています。何か情報をいただけませんか? 

シャイレンドラ・マーサーからの回答は以下のようなものです。

こんにちは、クリス。もちろん、喜んでお手伝いさせていただきます。この種の質問は非常によくいただくので、情報も多く揃っています。1ページには収まらないかもしれません 🙂

間もなく、私は何人ものAvidエンジニアからメールを受け取りました。どうやって1ページにまとめよう・・・?

まずは簡単なコンセプトから始めましょう。アプリケーションの「挙動」を列挙し、例えば4つのビデオエフェクトを処理するときには、CPUGPUのどちらを使いますか?」とか「どのような処理のときにいくつのコアが使われますか?」といった質問を作ります。そしてそこから、詳細な内容へ掘り下げていきます。

ここで少し時間がかかったのは彼らのせいではなく、私の問題でした。さらに私のエディターとしての仕事もありました。その中で、私は何通ものメールをやり取りし、あるいは電話で話をしました。そうしたAvidエンジニアとのやり取りで、私は少しずつ理解を深めていきました。私はエンジニアではないので、物分りが悪かったかもしれません。その点について、Avidエンジニアの忍耐強さに感謝します。それでもまだ完全にわかったと言い切る自信はないのですが、最終目的はエディターによるエディターのためのガイドを作ることです。

そして、これがその結果です。

さて…もっと詳しく知りたい?もちろん!それが私たちクラフトエディターの仕事ですから!

まず…全体像はどんなものか、それはいつから使われているのか?

現在Avid Intelligent Compute Architecture と呼ばれているアーキテクチャーは、Avid Media Composer v3.0のときに開発されました。これはシステム全体(OS、ハードウェア、GPU性能、使用可能なCPUとコア数)を評価し、タイムライン上の異なるセグメントにおける特定のタスクに対し、最も適したデバイスに動的に処理を分配します。あらゆることをGPUCPU、FPGAベースのカード「だけ」に任せるのではなく、それら全体を使用する形に変わったのです。すなわち、システム全体がアクセラレーターとなります。Intelligent Media Playerはいわばオーケストラの指揮者のように、パフォーマンスが必要な処理に対して可能なリソースを割り当てようとします。常に全体を意識しつつ、重い処理が必要なビデオデータに対しては特に注意を払いながら、どのハードウェアを使用するかが決定されます。

では、ひとつずつ見てみましょう。先ほどの表の一部を切り取ったものです。その下にはAvidアーキテクチャーチームとの会話中に書き取ったメモを添えておきます。

 

RAMとキャッシュ

1. RAMは多いほど良い。マシンが搭載できる最大量のRAMを搭載することが推奨される。RAMが少なければ、MCのパフォーマンスは制限される。

Media Composerは、当然のことながら、環境的な制限が最小限の時に最高のパフォーマンスを発揮します。RAMにおいては特に顕著です。例えば、MacPro 2014 16GB RAMで、再生ボタンを押してアクティビティモニターを見てみましょう。(これは稼働しているアプリケーションとその効率をモニタリングする方法です)。Media Composerは8GB程度を使用します。しかし、システムはそのままでRAMを32GBに増やしてみると、Media Composerは14-16GB程度を使用し始めます。これは、Media Composerが必要なRAMを奪い取ったというよりは、少ないRAM環境においてシステムがMedia Composerの動作を制限していたと考えるべきです。これが、システムのRAMは多いほど良いと考えられる一つの根拠です。 

RAMが増えるということは、「コンピューターの屋根」が高くなるようなものです。屋根が高くなれば、すべての機能がシステム側の制約を受けることなく、自身の必要最大値で動作することができるようになります。新しいiMacの物理的な最大可能RAM搭載量が64GBなら、それがAvidが推奨するシステムとなります。

RAMを増やすのは、コンピューターをアップグレードする最も安価で簡単な方法であるため、Avidはこれを最大限に利用するための64-bitプレイバックエンジンを設計しています。

もちろん、最小稼働要件は存在します。例えばDNxHDを再生するためのラップトップマシンの最小稼働要件は、8GB RAMと5400RPMドライブです。

 

2. 画像サイズが大きい(UHD4K等)ほどRAMを多く消費する 

画像サイズが大きいということは、ピクセル数が多いということであり、リアルタイム再生するために大きなパワーが必要になるということです。

https://commons.wikimedia.org/wiki/File:Aspect_Ratios_and_Resolutions.svg

3. インタラクティブ・フレーム・キャッシュ 設定は、再生時に役立つ。キャッシュはRAMに保存されるので、[Media Cache] 設定 -> Video Memory を大きくすると、ストリーム数を上げることができる。これにより、レンダリングしないでリアルタイム再生できるレイヤー数を増やすことができる。必要に応じて、この設定をしておくべき。

Avid Media Composer: Settings -> Media Cache

[必要なビデオメモリ] を常に最大値にしておくと、他の処理やアプリケーションに悪影響を及ぼします。

Media Composerの再生時の処理アルゴリズムでは、ビデオは「独立したフレームの集合」として捉えられています。再生処理の間、Media Composerはこれらのフレームをいかにしてストリームに乗せるかを決定します。例えばDNxHDメディア1レイヤーは1ストリームとして認識されます。レイヤーやエフェクトが増えれば、それらが新たなストリームとなります。

ここで言う「処理」とは、再生のために必要な作業を指します。部分レンダーのような明らかな前処理だけではなく、ドライブ内のデータから映像出力させるためのあらゆる行為を「処理」と呼びます。

「キャッシュ」とは再生処理を分散するための方法です。再生処理が非常に高密度かつ複雑になると、CPUキャッシュが助けになります。

キャッシュは、システムの混乱を抑え再生を補助するための、「見えないビデオミックスダウンの一種」だと考えることができます。この定義はあまりにも一面的で、技術的には正確ではないかもしれませんが、基本的な理解の助けにはなるでしょう。より正確に説明するなら、「複雑な同じ計算を何度も行う(=処理)のではなく、計算結果をRAMに残しておくことで、同じことを再処理しないで済むようにする」ためのものです。キャッシュは処理の下流にあり、処理の結果を記憶します。

キャッシュはいつかいっぱいになります。一定の量が溜まったら、キャッシュは古いものから削除され、新しいデータに置き換わります。もっとたくさんの結果をためておきたいなら、RAMを追加する必要があります。

Avid Media Composer: 設定 -> Media Cache (デフォルト設定)

Avid Media Composer: 設定 -> Media Cache (最高値設定)

Note: 32GB RAMを搭載した特定のマシンでは、Media Composerは通常8GB程度を消費します。ここでMedia Cacheを22GBに設定すると、合計で30GBを消費することになります。残りは2GBしかありません。この状態でDropboxやiTunesのような別のアプリケーションを起動すると、メモリに問題が発生する可能性があります。

Media Composerを終了すると、メモリキャッシュはすべて削除されるため、このあとすばやく簡単に再起動できます。

Note: ビデオメモリキャッシュをあまり過剰に大きく設定することは、これ以外のRAMを必要とする処理に悪影響を与える場合があります。必要に応じて、適切な値に設定するようにしてください。

 

4. Playback Video Frame Cache は単一フレームの反応性を高める

Avid Media Composer v8.9.2: 設定 -> Media Cache -> ビデオメモリ タブ

Media Cache -> Video Memory で保存できるフレーム数を増やすことができ、再生中の反応性を上げることができます。ビデオメモリの値を上げれば、よりよい結果を得ることができます。

 

コーデック

5. コーデックのエンコード/デコードにはCPUが使用される。

RED カメラファイル(R3D)は例外です。R3Dファイルのエンコード/デコードにはGPUが使われます。Red Rocketカードがインストールされている場合には、よりパフォーマンスを上げることができます。

ほとんどのコーデックは、「GPUを回避」と呼ばれる方式で構成されています。しかし、これは将来的には変わるかもしれません。ビットストリームフォーマットとしてのコーデックがもっとGPUフレンドリーになれば、Avidも間違いなくその方式に追随するでしょう。

 

6. タイムライン上でコーデックを再生するにはCPU処理が必要。これにはCPUコアが多いほうが良い。ラスターサイズ(解像度)が大きなコーデックに対しても、コアが多いほうが高いパフォーマンスが得られる。

リンクされた(AMA)クリップや多くのエフェクトを載せたクリップを再生することは、ストリーム数を増やすことになります。コーデックが複雑であればなおさらです。これらを効率的に処理するには、多くのコアがあったほうが良いでしょう。

 

7.すべてのコーデックがRAMの恩恵を受ける。LongGOPAVC/H.264のようなコーデックでは、さらに多くのRAMが必要になる。

DNxHDのようなコーデックであれば、編集時や再生時にコンピューターに不要な負荷をかけることはありません。しかし、許容できるレベルのパフォーマンスを出すためにも多くのCPUパワーが必要になる複雑なコーデックもあります。MCの最低稼働要件レベルのマシンでは、これらの複雑なコーデックを扱いきれないかもしれません。この場合はRAMを追加する必要があります。

ソースブラウザからアクセスできるファイルはAvidコーデックにトランスコード([クリップ] > [コンソリデート/トランスコード])でき、ストリーム数を減らしたり、CPUへの負荷を下げることができます。HDサイズのAvidコーデックなら、それほどのコア数も必要としません。

Note: H.264 コーデック (.mov および.mp4) は32-bit QuickTimeエンジンでは扱えません。Media Composer 8.9.1のように、64-bitエンジンで再生します。これはXAVC-S(.mp4)でも同じです。

 

Video Quality Menu

8. ビデオクオリティメニュー を切り替えることで、表示される画像のラスターサイズを変更できる。これにより、パワーのないマシンでも複雑なコーデックをスムースに再生できる。Green/Green モードではフルラスターで再生する。Yellow/Green では25%、Yellow/Yellow では6.25%(1/16)になる。このラスターサイズの変更は、GPUではなくCPUによって行われる。

オリジナルサイズからのリサイズはCPUによって行われます。性能の低いコンピューターで、タイムラインをスムースに再生させるために使います。

HD以上のプロジェクトだと、リサイズにより大きなCPUパワーが必要となるため、この機能を使用することがボトルネックになってしまう場合もあります。

 

9. 8-bit以上のコーデックを使うときは、Green/Green/10-bitモードにしたほうが処理効率がよくなる場合がある。これは、クリップ上に載せられたエフェクトの数にもよる。

 

Video Effects, Timeline & Playback

10. タイムライン再生時には、まずGPUが使われる。再生時には、まず1ストリームとして認識される、タイムラインの最上位トラックを見る。

タイムラインの最上位トラックがGPUの最初のターゲットとなります。これを「フロント・ローディング」と呼びます。シークエンスが再生されると、Media Composerはプレイヘッド(青いバー)の部分を上から縦方向に読み込みます。例えばコピー機のスキャナーのように、シークエンスを横方向に読み込むわけではありません。

エフェクトが載せられたシークエンスの場合、Media Composerは再生の前にタイムラインをできるだけGPUに振りわけようとします。CPUにも多少振り分けますが、これはエフェクトがCPUでないと処理できない場合や、エフェクトがマルチスレッドを必要とする場合に限られます。

このようにする最も大きな理由は、GPUからはストリームを1つだけ読み出したいからです。したがって、最新モデルのGPUと最大量のGPU RAMは、この処理の大きな助けとなります。RAM搭載量が大きければ、CPUに振り分ける必要も少なくなります。

前もってレンダリングが行われていれば、リアルタイム再生時のシステム負荷は最小限に抑えられます。

 

11. エフェクトの中にはCPUしか使用しないものもある。最近の新しいエフェクトほどGPUに依存する傾向が強い。

Avid Media Composer v8.9.2: エフェクトパレット

12.  カラーアダプター(ソース設定等)はパワフルなGPUを使うほどパフォーマンスが上げられる。 

 

雑記

これでメインとなる説明は終わりですが、その他のいくつかの情報を書き出しておきます。

– Media Composer v8.8.3以降、QuickTime AMAプラグインはQuickTimeエンジン(Media Composer外のバックグラウンドでの操作)やComposer独自の再生エンジンにほとんど依存しません。

– 高フレームレートのクリップは、コア数とバンド幅の恩恵を受けます。高フレームレートクリップはStream-based Parallelism(ストリームベース並列処理 - つながるフレームを並行処理すること)」と呼ばれるアルゴリズムによって処理されるからです。この処理には大量のRAMを必要とします。これもRAMを追加する動機になるでしょう。Note: これはI-Frame Onlyコーデックの話です。GOPコーデックの場合、話はもっと複雑になります。GOPコーデックにおけるフレームレートは、どのような分割方式を使っても扱うことはできません。設計上、GOPコーデックはフレーム間に多くの相互依存性を持っています。前のフレームが処理されないと次のフレームが処理できない構造であるため、デコードの際はリニアな処理を必要とします。

 

参考文献

もっと詳細な内容に興味がある場合は、Avidアーキテクチャーチームにより以下の文書をご参照ください。

リンク:

1) アーキテクチャーに関するブログ – the Avid Intelligent Compute Architecture:
http://community.avid.com/blogs/mediacomposer/archive/2013/03/12/how-intelligent-computing-powers-our-editorial-architecture.aspx

2) これは個人的なお気に入りです – the public file ion Google of the patent filed which includes the performance: https://www.google.com/patents/US8358313

 

ご質問

何かご質問がありますか?そうでしょう。ここまで読んで何も疑問がないのなら、そちらのほうが驚きです。できるだけ多くの質問を受けるために、ご質問は以下のAvid Communityに書き込んでください。

link: http://community.avid.com/forums/p/182676/849425.aspx#849425

どんな質問でも構いません。もし私にわからないことがあれば(えぇ、山のようにあります)、誰か別の人に回答をお願いすることにします。あるいは、他の読者の方がわかるかもしれませんね。目標は、私達自身の技術をステップアップさせるための、普遍的な理解です。これが正しい方向へのより良い一歩になることを期待しています。

Thank you for you time!

Chris Bové

(AKA “Pixel Monkey” on the Avid Community)

Media Composerについて

一流の映画、テレビ、放送局のエディターが使用するツールでストーリー制作を加速します。HDやハイレゾの編集もこれまでになくスピーディかつ簡単に行えます。

A leader if the Avid ACA, I’ve been in the entertainment business for 30 years, 25 of them as editor and story editor. Primary genres have been PBS documenraries, TV shows and independent films - hundreds of hours of programming - all made with Avid Media Composer. I’ve also many years as an educator, writing curriculum for film schools, producing tutorials and user group outreach.