スポンサード リンク

T.Ishii's Software Library

HTML5 レトロ風ゲーム館

無料ブログはココログ

« 通信は可能になった | トップページ | 悩みの種は操作系 »

追いかけ再生はAGMのみ

今はAmuseGraphicsの開発フェーズで、AG-デスクトップレコーダー/AG-WebカメラレコーダーとAGMPlayerとの連携機能として、各データをAGMPlayerで録画しつつ、追いかけ再生まで行える様にしようとしているのだが、録画形式はAGM形式に限定する事にする。

今日は、AG-デスクトップレコーダーから送られた映像・音声データをAGMPlayerで再生しつつ、録画してみたりしていたのだが、この様な処理については、性能問題が発生する可能性はあっても、本質的には問題はない。

つまり、上記の確認は、本格的に追いかけ再生機能を実装する前のテスト環境を構築する意味で、行っていた訳なのだが、続いて、録画しているファイルを再生する確認も行った。

録画中の動画ファイルというのは、まず、ファイル作成時の共有設定で、読み込みが許可されていないと、データの読み込みすら出来ない。

AGM形式動画の場合、これは許可してあるのだが、この共有設定を利用する為には、読み込み側も、特別なフラグを立ててファイルをオープンする必要がある。

現行のAGMPlayerの内部処理では、この様な特殊フラグは立てていないので、書きこみ中のAGM形式動画を読み込む事は出来ない。

しかし、これはバグという訳ではなく、確信犯的に、そうしてある訳だ。何故なら、書きこみ中のファイルを読み込めてしまった場合、AGMPlayer的には、そのAGMファイルを壊れたAGMファイルと認識してしまう事になるからだ。

これは何故なのか、というと、動画ファイルには、当然の事ながら、映像・音声データは書きこまれているのだが、それ以外に、色々な情報も、書きこまれている訳だ。

具体的には、そのファイルでは、どういうコーデックが使われているか、だとか、解像度はどうなっているか、だとか、どれだけの動画フレームが書きこまれているか、だとか、それぞれのフレームがどの位置に書きこまれているか、みたいな情報も、書きこまれている。

現行版のAGM形式動画の場合、修復処理を可能にする必要から、書きこみ開始時点で、コーデックや解像度情報等の予め判っている情報については、最初に書きこむ様にしてあるのだが、どれだけのフレームが何処に書きこまれているか、については、書きこみ様が無いので書きこんでいない。

そして、書きこみ中には、上記の情報は常時変わっていく訳なので、それらを一々書きこんでいたのでは、ストレージ性能が足りなくなる。

なので、それらの情報は、ファイルクローズ時に、最終的な値を書きこむ格好にしてあるのだが、にも関わらず、AGM形式動画の場合、書きこみ中にマシンがリブートしてしまった様な場合にも、後から、修復が可能だ。

これは何故なのか、というと、AGM形式動画のコンテナはAVI形式で、AVI形式というのは、冗長な情報を持っているので、どのフレームが何処に書かれているか、という情報が無くても、先頭からシーケンシャルにアクセスして行く分には、全フレームに正しくアクセスできるからだ。

つまり、修復処理では、コーデック情報等については、予め書きこまれているモノを使い、未書き込み状態になっているフレーム位置情報等については、ファイルの先頭から全フレームにアクセスしてみて、その結果から、作成して書きこんでいる訳だ。

上記の通りなので、AGM形式動画ファイルについても、現状では、書きこみ中のファイルの情報を読み出せたとしても、フレーム情報が欠落しているので、普通に再生する事は出来ない。

にも関わらず、AGM形式動画なら、追いかけ再生も簡単、みたいな事を数日前に書いてあるのだが、これは、AGM形式動画用の内部ルーチンでは、上記の欠落している情報をファイルクローズ時にしか書きこめない訳ではないからだ。

つまり、作者的には、追いかけ再生を始める時点で、その時点の最新情報をファイルに書きこませる事も簡単な訳だ。

更に、AGM形式動画の再生処理ルーチンは、ファイルオープン時にフレーム情報を全て読み込んでしまって、その後は、メモリ上の情報に従ってフレームにアクセスする格好になっているので、オープン処理が終わってしまえば、書きこみ中のファイルに対するアクセスは、最低限で済む格好になっている。

と、いう事で、追いかけ再生を開始するタイミングでは、再生ルーチンがそれなりのファイルアクセスを行うので、書きこみ処理を阻害する可能性もあるのだが、AGM形式動画の書き込み処理ルーチンでは、内部的なバッファリングを行っていて、少々、実際のファイルアクセスが行えなくても、エンコーダーを待たせる様な格好にはしていない。

更に言えば、性能的に問題がある、という事になれば、書きこみ中のファイルにデータをフラッシュさせる様な事はさせず、新しいオープン処理ルーチンを作成し、必要な情報は、書きこみ処理ルーチンがメモリ上に持っているものを、メモリ上から持って来れる様にする事も可能な訳だ。

上記の通りなので、AGM形式動画の場合、追いかけ再生を行いたい場合には、そのタイミングでのフレーム情報を使って読み込みルーチンをオープンしてしまえば、後は、普通の再生ルーチンを使って、再生処理を行わせる事も可能だ。

なので、今日は、ファイルに情報をフラッシュさせるルーチンを追加して、その動作確認を行ってみたのだが、当然の事ながら、録画中ファイルに対する再生も可能だった。

と、いう事で、真面目な追いかけ再生を実現するためには、逆に、AGM形式動画用の処理ルーチンが備えている上記の様な特性が必要になる訳なので、OS内蔵だとかDirectShow経由で使用するエンコーダー環境での録画を行いつつの追いかけ再生は、出来る気がしない訳だ。

この問題を解決する為には、数日前に書いた様に、追いかけ再生用には、AGM形式で録画を行いつつ、ユーザー指定の別形式でのエンコードも同時に行う、という手はあるのだが、こんな事をやっていると、ストレージ・CPU性能が厳しくなる環境も多い筈だ。

しかしまあ、真面目なエンコードはAG-デスクトップレコーダーがやってくれる訳なので、AGMPlayerは、その追いかけ再生も可能なリアルタイム視聴が出来る、という位置づけにすれば、AGMPlayer的には、エンコード形式はAGM形式に限定できる。

なので、AGMPlayerでの追いかけ再生用のエンコード形式はAGM形式に限定する事にした。同時にAG-デスクトップレコーダーでエンコード可能にするオプションは、実装は簡単なので用意するとは思うのだが、そういう使い方をする場合には、処理性能的に、4コアCPUのSSDマシンでないと、厳しいかもしれない。

もっとも、本格的な実装は明日以降なので、リリース版の仕様は、まだまだ変わる事になるかもしれない。

= この記事に関連する公開中ソフト =

AmuseGraphics

AmuseGraphics

(2016/10/25追加)

« 通信は可能になった | トップページ | 悩みの種は操作系 »

トラックバック

この記事のトラックバックURL:
http://app.cocolog-nifty.com/t/trackback/534482/64017636

この記事へのトラックバック一覧です: 追いかけ再生はAGMのみ:

« 通信は可能になった | トップページ | 悩みの種は操作系 »

2017年8月
    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 のパートナーは当サイトや他のサイトへのアクセス情報に基づく広告をユーザーに表示できます。

    Cookieを無効にする設定およびAdsenseに関する詳細については、以下のリンクを参照下さい。

    広告 - ポリシーと規約 - Google