スポンサーリンク

T.Ishii's Software Library

HTML5 レトロ風ゲーム館

無料ブログはココログ

« とりあえず、作業を開始 | トップページ | 何となく見えてきた »

かなり期待できそうだ

今はAmuseGraphics Ver1.4.1の開発フェーズで、既に、AGMPlayerとAG-ムービーカッターに引き続き、AG-デスクトップレコーダーの開発に移ったのだが、今回の目玉は、お気軽エンコード時の負荷の軽減で、試してみた所、かなり期待できそうだ。

冒頭では、「お気軽エンコード時の」という条件を付けているのだが、これは、エンコード負荷を軽減する方法として、画面変化がない場合には、エンコードを行わない、という方法を採るからだ。

つまり、例えば、YouTubeの60FPS動画を領域指定してキャプチャーする様な、常に録画対象の全領域で画面変化が発生している様な場合には、エンコード負荷の軽減は行われないからだ。

しかし、例えば、キャプチャーレートを60FPSにして全画面録画している状況で、普通のデスクトップ操作をする様な場合には、多くの時間、60FPSに匹敵するレートでは画面は変化しないし、変化する場合にも、その一部の領域のみ、という事になる。

なので、普通のデスクトップ操作をキャプチャーする場合や、領域指定が面倒だから、とりあえず、YouTube動画なんかは窓再生している状況を全画面録画しておいて、後から、動画領域のみAG-ムービーカッターでトリミングしよう、なんて場合には、録画中の負荷を大幅に減らせる可能性が高くなる訳だ。

で、まだ、真面目な実装は行っていないのだが、試しに、色々とやってみていると、かなり期待できそうな結果が得られ始めている。

具体的には、エンコード形式として、AGM形式のデフォルト、つまり、AGM3-DCTを選択した状態で、Mac mini Late2014のフルHDモニターのキャプチャーを60FPSで行った場合、現行版だと、常時、AG-デスクトップレコーダーのCPU負荷は60%程度以上は必要になっているのだが、画面変化が全くない場合には、エンコードを行わずにNULLフレームを出力する様にしてみると、通常作業時のエンコード負荷は20%未満になっている。

で、画面変化が全くない、という判定は、Windows8.1/10ではデフォルトで使用しているDesktop Duplication APIによる画面キャプチャー時には、殆ど、積極的なチェックをしなくても判定可能なので、上記の様な劇的な効果が得られているのだが、試しに、自分で過去のフレームと比較するチェックルーチンに切り替えても、同等程度に軽くなったので、Desktop Duplication APIが使えないWindows7でも、同様に、通常の操作状況をAGM形式で録画する場合には、結構な、負荷軽減が行える様になりそうだ。

ちなみに、AGM形式動画の場合、自前処理でファイル書き込みまで行っているので、エンコードを行わずにNULLフレームを出力する、みたいな事は確実に行える。

つまり、エンコードをスキップするフレームが出てきても、録画映像に時間的なズレは発生しないので、音ズレなんかも発生しないのだが、mp4だとかwmvだとかavi形式の場合、エンコード出力には、OSのAPIを利用しているだけなので、殆ど、細かい芸当は出来ない状況だ。

ただし、何も出来ないのか、というと、そんな事もないので、前述の様に、MP4形式については、需要も多い感じだし、過負荷の場合にAG-デスクトップレコーダー自体もフリーズしてしまう格好になっているので、何かしらの対策とともに、画面変化が少ない場合の負荷軽減も、同時に行える様にするかもしれない。

もっとも、負荷軽減の本命は、領域毎に変化のあるなしを判定し、無い場合には、その領域用のエンコードを行わない、という処理を追加する事になるので、こういった処理は、AGM形式動画に対してしか適用できない。

と、いう事で、現行版でも、作者的には、AG-デスクトップレコーダーでの録画形式については、AGM形式推しなのだが、次バージョンでは、より一層、AGM形式での録画が有利になるかもしれない。

つまり、普通に無理なく録画できる様な状況なら、mp4形式でリアルタイム録画しても何ら問題はないのだが、長時間録画だとか、録画中に録画内容を確認したい場合だとか、処理負荷が気になる場合には、AGM形式でのリアルタイム録画がお勧め、という事になりそうだ。

まあ、AGM-YV12形式が使えないフリー版では、バッファリングエンコードが最も軽いエンコード方式だったかもしれないので、リアルタイムエンコードではなく、バッファリングエンコードを未だに使っている人もいるかもしれない。

しかし、シェアウェア版では、リアルタイムエンコードでも、AGM-YV12形式が使えるので、バッファリングエンコードを使う必要性は殆どなくなっている筈で、更に、次バージョンで、上記の仕組みを入れる事にすると、バッファリングエンコードよりもリアルタイムエンコードの方が軽い、なんて事にもなってしまうかもしれない今日この頃だ。

まあ、バッファリングエンコードとAGM-YV12形式では、現行版でも、画面変化の有無は、既に、かなり積極的に利用しているので、これらでは、上記の様な仕組みを入れても、あまり負荷は下がらないかもしれないのだが。

« とりあえず、作業を開始 | トップページ | 何となく見えてきた »

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