スポンサーリンク

T.Ishii's Software Library

HTML5 レトロ風ゲーム館

無料ブログはココログ

« 他に何かあったかなあ? | トップページ | 主役も張れる? »

macOSでも意外と使える?

今は、AmuseGraphics Ver1.4.1の開発フェーズで、macOS版AGMPlayerに続き、macOS版AG-ムービーカッターの更新版のリリース準備中なのだが、一応、準備は完了するものの、例によって、不具合が見つかるのでリリースを順延している状況だ。

リリース直前に見つかった不具合としては、「ループ再生」を指定していると、再生の最後で最初に戻らず、ずっと、同じ箇所を再生し続ける、というものと、トランジションの最後付近のフレームが再生されない、というものがあった。

で、当然の事ながら、今回の更新では、「ループ再生」関連の変更は行なっていないのだが、上記の様になってしまったのは、トランジション関連の変更時に、極力、トランジションの開始/終了タイミングでの待ち時間を減らそうとして追加した細工が「ループ再生」時に、適切に働かなかったから、という事になる。

トランジションの最後付近のフレームが再生されない、というのは、一昨日書いた分割並列エンコード時に、微妙な問題が出る対策として行なった変更が悪影響していた、という事になる。

今日の時点では、上記の問題は解決できているのだが、何かしらの目的で変更を行うと、思ってもいなかった所で悪影響が出る、というのは良くある話なので、上記の対策用に行なった変更が、更に、別の箇所に悪影響を与えている可能性も否定はできない。

なので、作者的には、変更を行う度に、それなりに、全般的な再評価が必要になるので、例によって、リリースは順延しているのだが、今のところ、致命的な問題は見つかっていないので、明日か明後日くらいには、リリース出来ている様な気はしている。

ちなみに、今日の表題はどういう事なのか、というと、上記の文章にも出ている「分割並列エンコード」の話だ。

一昨日書いた様に、AGMエンコーダーの並列化が進んでいる今現在、AGMエンコーダーをマルチスレッド動作させるために「分割並列エンコード」を行わせる意味は殆どない。

と、いうか、「分割並列エンコード」というのは、ある意味、力技なので、AGMエンコーダー的には、そんな事をされると、逆に、処理が遅くなる事もある。

何故なら、エンコーダーが自分しかいなければ、極力、不必要なタスクスイッチングは発生しない様になっているし、メモリアクセスもスムーズに行われるのに対して、「分割並列エンコード」が行われると、強引に、頻繁なタスクスイッチングが発生するし、メモリアクセスも、ある意味、ランダムになるので、アクセス性能が低下してしまうからだ。

なので、Windows環境とは違って、大昔の遅いデコーダーが動作する事はないmacOS環境では、「分割並列エンコード」は不要、みたいな事を書いていたのだが、リリース前テストの一環として、mp4動画を「分割並列エンコード」でAGM形式動画にしてみると、通常のエンコード時と比べて、約2倍程度は高速化された訳だ。

確認のために、mp4動画の代わりに、その動画をAGM形式に再エンコードしたソース動画を「分割並列エンコード」/「通常エンコード」で再エンコードしてみたのだが、その場合にも、「分割並列エンコード」の方が高速なケースもあったのだが、2倍も高速になる事はなかった。

つまり、mp4動画をソース動画とした場合に「分割並列エンコード」で2倍程度、エンコードが高速になった理由は、mp4動画のデコード性能が低いから、という事になる筈だ。

もっとも、テストに使ったmp4動画というのは、大昔、スカパーか何かでやっていた映画をMPEG1でキャプチャーしていたMPEG1動画をAGM形式に再エンコードして持っていたモノを更にmp4形式に再エンコードしていたモノだ。

なので、解像度は352x240しかなかったので、今時のmp4動画としては、少しイリーガルな筈だ。

で、総時間は1時間27分33秒で、通常エンコードは3分50秒で完了したので、mp4デコーダーも、1時間27分33秒 = 5253秒 x 29.97FPS = 157432フレームを、その時間で処理した事になる。

なので、mp4デコーダーの処理性能は、少なくとも、157432/(3*60+50)=684FPSはある、という事になる。

にも関わらず、「分割並列エンコード」で高速化が行えるのは、AGMエンコーダーがより高いフレームレートでエンコードできてしまうからなので、macOSに内蔵されたmp4デコーダーは遅い、と、いうのは問題があるかもしれない。

しかしまあ、上記の通りなので、macOS環境でも、mp4動画をAGM動画に変換する場合には、「分割並列エンコード」での処理速度向上は可能かもしれない。

なお、「分割並列エンコード」用の設定では、分割数を指定できるのだが、上記については、分割数を2にすると、エンコード時間は、2分30秒、3にすると2分10秒、4にすると2分5秒、8にすると2分10秒だった。

上記のmp4動画をAGM3-DCTにエンコードした動画をソースとした場合には、エンコード時間は、通常のAGMエンコード時には1分45秒、分割並列エンコードで分割数を2にした場合には1分27秒、分割数を3にした場合には1分29秒、分割数を4にした場合には1分33秒、分割数を8にした場合には2分1秒だった。

上記の様に、分割数を8にした場合には、通常エンコードよりも遅くなっているのだが、その理由は前述の通りだ。

まあ、それでも、分割数が2の場合には、若干、エンコードは高速化されているので、AGM形式動画をソースとする場合にも、「分割並列エンコード」は無用、という事はないのかもしれない。

もっとも、上記は解像度が352x240しかないので、念のため、DVD画質852x480のAGM形式動画(2時間14分)を再エンコードしてみた所では、以下のようになった。

通常エンコード = 6分丁度、2分割並列エンコード=5分53秒、mp4へのエンコード=7分7秒。

上記mp4動画からの、通常エンコード=8分12秒、2分割並列エンコード=6分45秒、3分割並列エンコード=6分26秒。

上記を見ていると、DVD解像度でも、やはり、mp4デコード性能がAGMエンコーダーの処理性能よりも低い感じなので、macOS環境でも、mp4動画なんかの一般動画をAGM形式動画に再エンコードする場合には、「分割並列エンコード」による性能向上は期待できそうだ。

もっとも、DVD解像度程度になってくると、ソース動画がAGM形式の場合には、通常エンコード時と分割並列エンコード時の差は殆どないので、それでも、CPUリソースをより一層使う事になる分割並列エンコードは利用しない方が良いかもしれない。

なお、上記の測定環境は、MacBook Pro 15インチ 2016モデルなので、CPUは4コア8スレッドになる。

また、AGMエンコードの形式は、AGM形式の中では最も重い、AGM3-DCT+になる。

« 他に何かあったかなあ? | トップページ | 主役も張れる? »

2020年9月
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30      

広告

プライバシーポリシー

  • 当サイトでは、第三者配信による広告(Google Adsense)サービスを利用しています。

    Google を含む第三者配信事業者は、Cookie を使用して、ユーザーのウェブサイトでの閲覧履歴に基づく広告を配信します。 Google 広告 Cookie を使用することにより、Google や Google のパートナーは当サイトや他のサイトへのアクセス情報に基づく広告をユーザーに表示できます。

    収集された情報がGoogleによってどの様に使用されるか、収集される情報をユーザーが管理する方法については、以下のリンクを参照下さい。

    ポリシーと規約 - Google