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動画としては、少しイリーガルな筈だ。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リソースをより一層使う事になる分割並列エンコードは利用しない方が良いかもしれない。2016モデルなので、CPUは4コア8スレッドになる。AGMエンコードの形式は、AGM形式の中では最も重い、AGM3-DCT+になる。Adsense)サービスを利用しています。使用して、ユーザーのウェブサイトでの閲覧履歴に基づく広告を配信します。パートナーは当サイトや他のサイトへのアクセス情報に基づく広告をユーザーに表示できます。収集された情報がGoogleによってどの様に使用されるか、収集される情報をユーザーが管理する方法については、以下のリンクを参照下さい。