スポンサーリンク

T.Ishii's Software Library

HTML5 レトロ風ゲーム館

無料ブログはココログ

« リリース前の評価中 | トップページ | プレビュー版として公開 »

64Bit版でもメモリ量は問題?

今はAmuseGraphics Ver1.4.1の開発フェーズで、AGMPlayerに引き続き、AG-ムービーカッターのリリースも間近なのだが、昨日書いた様に、限界テストも必要かなあ、という事でやってみた所、メモリ不足で4k出力も不可な場合があった。

4k出力というのは、一般的には、3840x2160になるのだが、内部的に、各ピクセルを32Bitで保持する事にすると、1フレーム用のバッファサイズは、3840x2160x4=約32MBになる。

なので、今時のPCが8GB程度のメモリは実装しているであろう事を鑑みると、4k解像度なんてどうってことは無さそうなのだが、AGM形式動画の場合、そのエンコード速度を向上させるために、演算処理を各部に分け、かつ、各部でもマルチスレッド動作させている訳だ。

つまり、動画ファイルの再エンコードの場合、デコードとエンコードは独立動作させているし、それらについても画像処理部とデータ処理部は独立動作させ、かつ、それぞれの処理でCPUスレッド分のスレッドを同時動作させたりしていて、それらの処理は間にキューを挟む事で、同期しなくてもよくしている。

具体的には、デコーダーはデコード結果をキューに積んでしまえば、エンコーダーの処理が終わるのを待たずに、次の処理に進む格好になっているので、例えば、デコーダーに関しては、フレームバッファとしては処理用以外にキューイング用にも別に持っている、という事になる。

と、いう事なので、AGM形式動画の再エンコード時には、単純に鑑みても、(デコーダー前段+デコーダー後段+エンコーダー前段+エンコーダー後段)*2*スレッド数分のフレームバッファは存在しているので、4スレッドで4k出力の場合、32*4*2*4= 1024MB、つまり、1GB程度のメモリは普通に消費する格好になっている訳だ。

で、今時のPCなら、1GB程度のメモリ消費なら、まだ、何とかなる筈なのだが、上記は単純化した話になっているので、実際にやってみた所では、DVD画質のAGM形式動画をエンコード設定を変更して出力サイズを4k解像度にして再エンコード出力させようとすると、作者のMac mini Late2014では、クラッシュしてしまう場合がある事が判った。

作者のMac mini Late2014には8GBのメモリが実装されていて、CPUは2コア4スレッドになる。

なので、一見、上記の計算からすれば、エンコード出力できそうなのだが、実際にやってみると、メモリアロケーションに失敗する事が多々あった訳だ。

もっとも、現在のバイナリでは、ビルド設定で、2GB以上のメモリは使わない様になっているので、メモリ不足が頻発するのだが、次バージョンでは、2GB以上のメモリも使える様にビルドするので、少しは楽になった感じだ。

少しは、と、書いているのは、その様なビルドを行っても、作者のMac mini Late2014 (Windows8.1)では、4GB程度のメモリを確保すると、それ以上のメモリはnewでもmallocでも取得できなくなるので、例えば、4096x4096程度の出力解像度でも、異常終了してしまう場合があった。

と、いう事で、今時のエンコーダーとしては、やはり、4k解像度くらいは、余裕をもってエンコードしたい所ではあるので、次バージョンでは、エンコード時に使用するメモリ量を節約できる様にしようかなあ、と、思ったりもしている。

もっとも、その為には、マルチスレッド動作用に独立バッファを持たせたりするのを制限する必要が出てきたりするので、その分、処理性能は低下する事になるかもしれないし、もっとメモリ容量があるWindows10 PCでなら、そんな制限を加える必要もないかもしれない。

なので、Preview版については、そこまでの細工はせず、とりあえず、2GB以上のメモリを使える様にした現時点のコードを公開しておき、その後、AG-デスクトップレコーダーなんかについても、4k録画は余裕をもって行える様にしたいので、同時に改良しつつ、AG-デスクトップレコーダーのPreview版を公開するタイミングで、AG-ムービーカッターについても、Preview版を更新する格好にしようか、と、思ったりもしている今日この頃だ。

ちなみに、上記の通りなので、CPUのコア数が多く、より多くのマルチスレッド動作が行える場合にも、スレッド数を制限しないと、今時の多コアCPUでは、使用メモリ量が爆発的に増加してしまうので、Preview版として公開予定の手元バイナリでは、最大スレッド数は8に制限している。

もっとも、前述の様に、4スレッドなら使用メモリ量が1GBですむ所が8スレッドだと2GBは必要になる! みたいな所もあるので、最終的には、使用スレッド数はユーザー指定可能にしようかと思ったりもしている今日この頃だ。

なお、Windows用のC++アプリが使用可能な最大メモリ量については、ネットで色々と調べてみたのだが、良くわからないのが実状だ。

具体的には、newで取得可能な配列の要素数は2GBを越えられない、という仕様は見つかったのだが、それでは、という事でmallocで取得しようとしてみても取得してくれなかったりしたのだが、1GBにすれば、取得可能だったので、それを何個か取得しようとすると、やはり、4GB程度取得した所で取得できなくなったりした。

上記は、メモリ容量8GBのWindows8.1環境である所の作者のMac mini Late2014上での話なので、メモリ容量16GBのWindows10環境にもできるMacBook Pro上でテストすれば、異なる結果が出てくるかもしれないのだが、いずれにしても、64BitOSでは、論理的には利用可能なメモリ量はGB程度ではなく、かつ、仮想記憶なので、実メモリ量が少なくても、足りない分をストレージから取って来れる筈なので、性能問題は発生するにしても、メモリ不足、なんて事象は発生しないか、と、思っていたのだが、Windows環境では、簡単に「メモリ不足」と、言われてしまう様だ。

Windows環境では、と、書いているのは、macOS環境用のAG-ムービーカッターでは、処理性能的には使いものにはならないのだが、8192x8192の解像度のAGM形式動画に再エンコードする事も普通にできているからだ。

と、いう事で、メモリ使用量の削減については、次のAG-デスクトップレコーダーのPreview版作成時に、同時に検討する事にして、AG-ムービーカッター Ver1.4.1のPreview版については、とりあえず、無茶な解像度設定なんかをしなければ、機能的には普通に動作している現状のモノを明日にでも、公開しておく事にする。

« リリース前の評価中 | トップページ | プレビュー版として公開 »

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