H.264 の処理が遅い。Mac Pro(Late 2013)

その後、検索を続けたところ下記のリンク先にハードウェアエンコードについての記載がありました。実は2011 年以降のMac でハードウェアエンコードが出来る機種について明記したApple のサポート記事を一昨日見つけたのですが、何故か今日確認すると見つけることが出来ませんでした。その記事に依れば2011 年以降のMac に搭載されているようですが、そのリストの中にMac Pro は有りませんでした。CPU がi シリーズのMac が対応しているとの事です。

OS X Mavericks：一部のファイルを QuickTime Player で開くと変換される場合がある - Apple サポート

粕谷 明 さんによる書き込み:

IntelのGPU内蔵CPUは、SandyBrigde以降はMPEG2/MPEG4 AVC用ハードウェアエンコーダ「Quick Sync Video」が実装されているので、Core iシリーズ搭載MacはQSVをエンコードに利用しているのでは？

諸々調べると、どうやらそのようです。この件についてはApple サポートのFinal Cut Pro X 担当部署は把握していませんでした。なるほどネットに情報が無いわけです。

HandBrake で試すとMac Pro の方が早いようです。HandBrake はハードウェアエンコーダーに未対応らしいので、それが原因かと思います。

H.264 が絡まなければMac Pro が早いハズだと思いますので、

もしかしたらCompressor の分散処理ならMac Pro での処理より早いかもと持って確認してみましたが、子細は興味が無いと思いますので書きませんがCompressor の分散処理は少なくとも単純な動画では4 倍くらい遅いです。しかもエラーが出ることもあるので、Compressor の分散処理が有用な状況が想定できません。

このトピックのタイトルと外れますが動画処理絡みと言う事で書き込みます。Compressor4.2 の分散処理についてです。

Mac Pro がH.264 の処理が遅い話とは別ですがMac Pro(Late 2013) を分散処理に参加させても、やはり単独で処理するより時間がかかります。Mac の負担を分散するのみで処理時間的にはデメリットなようです。各Mac のCPU の使用率を見ていても単独で処理させるときより、どのMac も低いのでこの気宇のは分散が目的であって処理時間の短縮が目的ではないようです。

OS X 10.10.4

ni_ki による書き込み:

この気宇の機能は分散が目的であって処理時間の短縮が目的ではないようです。

OS X 10.10.4

誤字訂正。と、

分散も不安定です。本日試しましたが、分散処理に参加しているMac が1 台停止すると処理の全体がエラーで失敗します。

なので長時間の動画の変換には不安定で向きません。短時間の動画処理か、よほど多くのMac を安定的に運用できるかた向けの機能です。「安定的」という言葉の中にはMac の再起動を禁止することや、他の作業に使用したさいの不安定要素をあらかた排除する必要があります。なので、およそそのような環境は一般的には不可能です。

書き込みありがとうございます。参考にさせて頂き、思考してみたいと思います。自分で確認した内容が自分自身解せないので。

yui さんによる書き込み:

Thunderbolt でネットワークを組めるようなので、それで測定すれば処理速度も短縮されるかもしれません。

これはノートMac2 台だったかで試したのですが大差なかったです。(「大差ない」というのは単機で処理させる時間に比べてかなり遅いという意味です。)

Thunderbolt ブリッジは通常時は単一ファイルのコピーで1.5Gbps 程度の速度なのでGigabit Ethernet 接続と比べると差が出にくいようです。ときどきファイルコピーで目が覚めるようなスピードが出るのですが。

あとは分散処理以前に、どの程度までマルチスレッドが効くのかという話もあると思います。

もし、12コア Mac Pro ２台とか数台とかだと、HyperThreading で 24スレッド x 台数で 48スレッドとかだと、もし 1フレームを分けているなら効率は悪くなるかなとも思います。

確かにご指摘の点は私も不明な点が多いです。処理中の画面を見ていると単純に動画を頭から時間軸に沿って処理能力数で割り各Mac に割り振っているようではあります。

ただ、もし Thunderbolt でネットワークを組んだ 2コアの Mac mini x 2台（SSD 搭載）でも性能が出ないなら、ほとんど意味がないかなと思います。

処理時間の問題はその通りですね。

先の書き込み以降も考えていたのですが最大の問題は、多機で処理するさいの不安定さかと思います。数回に1 回はエラーがでますので。しかもエラーが出た後、分散処理で使用したMac でCompressor を起動してリセットをかけないと動画の変換プロセスが止まらないことも複数回ありました。

yui さんによる書き込み:

ただ、もし Thunderbolt でネットワークを組んだ 2コアの Mac mini x 2台（SSD 搭載）でも性能が出ないなら、ほとんど意味がないかなと思います。

Mac mini2011 年モデル2 台でThunderbolt 接続で試して見ましたが、単機で処理するより遅かったです。

さらにそこにEthernet 接続の他のMac を加えて試して見ましたが、Mac mini だけのときより更に遅くなったので途中で処理を止めました。

どのような時に役に立つのか不明瞭な機能のようです。

Apple をなめていました申訳有りません。

OS X 10.11.6 Final Cut Pro 10.2.3 でH.264 1080p 59.94fps 28 分28 秒の動画の変換時間です。下記のようでした。Mac の型は略して書きます。変換時間の単位は分です。プラスマイナス最大1 分の誤差があると思って下さい。

MBP2011 31m

Mm2011GPU 27m

MBP2012 20m

iMac2014 8m

MP2013 15m

Mm2014 31m

iMac の2014 年モデルが速いですが、Mac Pro がかなり善戦しています。以前確認した際には、足元にも及ばなかったので、相撲に例えるならMac Pro 2013 も入幕を果たしたという感じでしょうか。以前書き込んだ際にはMac Pro の入幕を予想していませんでした。H.264 への変換はMac Pro はこのまま引退と思っていたので。

それと、この処理はMac mini 2014 は遅いですね。2011 年のノートMac と同じ結果です。

なお台数が多いので子細は観測しませんでしたが動画変換時、CPU の使用率はかなり低いです。5 割りいかいようです。GPU の方に処理させているのかもです。

Mac Pro(Late 2013)OS X 10.10.2Final Cut Pro 10.2.1 で一年二ヶ月ぶりに確認してみたところ、十四ヶ月前の遅さが嘘のように確認できませんでした。当時、Apple にも確認してもらっていますので、遅いのが勘違いということはありえませんが、何故早くなったのか不明です。クリーンインストールではなくバックアップから戻したのが、良くなかったか。

ni_ki による書き込み:

クリーンインストールではなくバックアップから戻したのが、良くなかったか。

本日、パーティションマップも再作成しOS X 10.10.2 をインストールしFinal Cut Pro 10.2.1 で28 分程度動画をApple デバイス720p 品質優先で書出したところ、38 分かかりました。その後、OS X 10.10.3 にアップデートして試しても37 分程度で大差無しでした。

昨日はバックアップからOS X を戻して15 分ですから、この差が何故出たのかを探りたいと思います。計測間違いの可能性も否定せず確認を進めたいと思います。

ni_ki による書き込み:

昨日はバックアップからOS X を戻して15 分ですから、この差が何故出たのかを探りたいと思います。計測間違いの可能性も否定せず確認を進めたいと思います。

間違いでした。

このトピックを立てたときは「品質優先」での検証結果でした。この前、書き込んだのは処理速度優先の結果でした。混同してしまいました。申し訳有りません。

ただし、この前、書き込んだ内容は処理速度優先の結果として間違い有りません。処理速度優先だとMac Pro もなかなか早いようです。

ちなみに、特定の動画だとApple デバイス1080p 品質優先で書き出しが失敗します。複数のMac で確認できるので恐らくバグです。

H.265 とやらがmacOS High Sierra で搭載されてくるようですが、もしかすると在来Mac ならMac Pro 2013 がMac mini 2011 にエンコードで負けずに済むかもですね。もっともMac mini 2011 で4K の変換ができるのか疑問ですが。