スポンサーリンク

T.Ishii's Software Library

HTML5 レトロ風ゲーム館

無料ブログはココログ

« ユーザーの要望にも応えつつ | トップページ | 変更内容を微修正 »

本質的な部分の改良も

今はAmuseGraphics Ver1.4.1の開発フェーズで、既に、AGMPlayerとAG-ムービーカッターに引き続き、AG-デスクトップレコーダーの開発を行っているのだが、今回は、処理負荷を左右する本質的な部分にも改良が入る事になる。

今回追加する機能は色々とあって、その中には、画面変化が無い場合には、エンコード時に書きこむフレーム数を減らす事で、エンコード負荷を減らす、という改良があったり、AGM-DCT出力時には、画面上の変化領域を検出して、無変化部分のエンコードはスキップする、みたいな、ある意味、姑息な性能向上施策があったりする。

もっとも、「姑息」、といっても、例えば、60FPSでデスクトップ操作を録画したい、なんて場合には、殆どの録画時間で、画面変化は60FPSでは発生しないし、全領域が変化する事も少ない筈なので、実用上、この「姑息」な改良の効果は絶大だったりもする訳だ。

で、上記の改良オプションは既に適用済みなので、適用した場合には、かなりの処理負荷の低減が行えるのだが、その効果をテストしていると、上記のオプションの有無に関係なく、バッファリングエンコードでのエンコード負荷と、AGM2-YV12(高圧縮エンコードを行わないYV12モード)を使ったリアルタイムエンコードでは、CPU負荷にかなりの違いがある事が判った。

具体的には、AGM2-YV12を使ったリアルタイムエンコードの方が処理負荷が、かなり高くなっていた訳だ。

で、AGM2-YV12というのは、ハフマン圧縮とYV12変換を行ったバファリングエンコード時に使用しているエンコード出力をAVIコンテナに出力するのと同様のエンコード形式になっているので、デフォルト設定では30フレーム毎にキーフレームを作成している分、若干、処理負荷が高くなるのは当然なのだが、作者的な感覚からすると、上記の違いは大きすぎた訳だ。

なので、その理由を調べてみた所、リアルタイムエンコードでは、より複雑なマルチスレッド処理を行っているので、その分、CPU使用率が高くなっていた事が判った。

上記のより複雑なマルチスレッド処理というのは、映像処理部とコード処理部を分けて、独立したスレッドで処理させる様になっていて、そもそもは、AG-ムービーカッターで、AGM形式にエンコードする時に、CPU使用率が低い、つまり、マルチスレッド化が足りない、という事から開発した方式だ。

なので、基本的には、利用可能なCPU資源を使いきる格好になっていて、その分、AG-ムービーカッターでのAGMエンコード速度は向上するのだが、処理効率自体は低下させている。

つまり、例えば、1コアで10の仕事ができる場合、マルチスレッド化していないと、2コアあっても、10の仕事しかできないのだが、強引にマルチスレッド化する事で、1コアで8の仕事しか出来なくなっても、2コアあれば、16の仕事が出来る様になるので、処理時間は短縮できる訳だ。

しかし、必要な仕事量が10しかない場合、本来ならもう一つのコアは完全に別目的で使えたのだが、強引なマルチスレッド化を行った場合には、0.8コア分しか、他の仕事に割り振る事が出来なくなる訳だ。

と、いう事で、現行版では、AG-デスクトップレコーダーのAGM形式を使ったリアルタイムエンコード時にも、上記の強引なマルチスレッド化を行うエンコード方式が適用されているので、バッファリングエンコード時よりも、AGM2-YV12でのリアルタイムエンコード時の方が、かなり、CPU使用率が高くなっている訳だ。

そして、AG-デスクトップレコーダーのリアルタイムエンコード時には、CPU資源を使いきる訳にはいかないので、Ver1.4.1では、より単純なエンコード方式に戻す事にした。

現行版でも、マルチスレッド動作を禁止していれば、その方式で動作しているのだが、Ver1.4.1では、マルチスレッド動作時にも、上記の様な強引なマルチスレッド化は禁止する事にする。

その場合にも、AGM-DCT/DCT+のDCT変換なんかはマルチスレッドで行われるので、フルHDモニターの全画面録画を行っても、通常は、十分な処理性能が確保できる筈だ。

ただし、最近は、16コアだとか32コアの様な、コア数が多いCPUが使われる事も多くなっているので、その様な場合には、効率よりも最大処理能力、というケースも出て来るかもしれないので、現行版と同様の強引なマルチスレッド化によって最大処理性能を増やすモードにも、変更可能にしておく予定だ。

ちなみに、昨日書いていた、領域指定録画時にウインドウを指定するモードは、コンボボックスの項目として追加するのではなく、チェックボックスを追加し、それで指定する格好にした。

その理由は、やはり、コンボボックスの項目を変更して指定するのは、操作性上、面倒だったからなのだが、その結果としては、領域指定するユーザーがこの機能の追加に気が付かない、という事はなくなる筈だ。

また、AGM形式でのエンコード時に、領域変化の有無をチェックして処理負荷を減らす処理については、AGM-DCT用のオプションと言う事にする。

つまり、AGM-RGB/YV12/DCT+では適用できなくするのだが、これは、実際に試してみた所、チェック処理による負荷増大分よりもエンコード負荷を減らせるケースが稀だったからだ。

なので、上記の有無の設定はAGM形式のエンコード設定ダイアログで指定する格好にしたのだが、MP4形式で、過負荷時に書きこみ量を減らすオプションについても、MP4形式のエンコードダイアログで指定する格好にした。

過負荷時に書きこみ量を減らす事で過負荷状態を悪化させない、という処理は、他のエンコード形式でも同様に適用できそうなモノなのだが、実際の所としては、AGM/AVI形式では、現行版でも、過負荷状態となると、自動的に画像フレームの書き込み頻度は減って、不足するフレームに対しては、NULLフレームが書きこまれる様になっている。

また、WMV形式でも、似た様な処理を入れてあるので、既に、オプションを追加する必要はないのだが、それでは、何故、MP4形式だけ、相手にしていなかったのか、というと、MP4形式の場合、書きこむフレームを減らすと、ファイルのフレームレートが変更されてしまうからだ。

具体的には、60FPSを指定してエンコードすると、現行版では、実質フレーム数が30FPS程度しかなくても、MP4形式の出力ファイルは60FPSで作成されるのだが、実質フレーム数に従って書き込みフレーム数を減らすと、他のエンコード形式とは異なり、出力ファイルのフレームレートは30FPSになってしまう訳だ。

なので、ユーザー的には、これはオカシイ!、と、いう事になるかもしれないので、現行版では、上記の様な場合にも、無理して指定されているフレームレートで出力データを書きこんでいるので、フレームレートは指定通りになるのだが、無理して書きこんでいる分、処理負荷はより増えるので、実質フレーム数は、その分、より低くなってしまう場合もある訳だ。

と、いう事で、次バージョンでは、MP4形式についても、上記のオプションを用意するので、例えば、現行版だと60FPSで出力させると、見た目上は60FPSのファイルが出来上がっても、実質フレームレートは30FPSしかなかった様な場合でも、上記オプションを適用すれば、出力ファイルのFPSは40に下がっても、実質フレームレートを40FPSに向上させる、なんて事も可能になる筈だ。

« ユーザーの要望にも応えつつ | トップページ | 変更内容を微修正 »

2019年12月
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 31        

広告

プライバシーポリシー

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

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

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

    ポリシーと規約 - Google