スポンサーリンク

T.Ishii's Software Library

HTML5 レトロ風ゲーム館

無料ブログはココログ

« WiMAXサービスが提供終了らしい | トップページ | 目玉機能は動体検知録画? »

対応可能な環境も増える

今はAmuseGraphics Ver1.4.1の開発フェーズで、AG-Webカメラレコーダー Ver1.4.1の開発に入っているのだが、基本処理も改良するので、現行版だと上手く録画できないWebカメラでも、Ver1.4.1では、マトモに録画可能になるかもしれない。

AG-Webカメラレコーダーの開発のために、作者的には、USB接続のWebカメラを幾つか購入し、それらを使って動作確認したりもしてきたのだが、それらの全てで、仕様通りに仕事をしてくれていない感じの挙動が見られている。

例えば、BUFFALOのBSW32KM04というWebカメラは、至極普通の640x480の解像度にしてみても、8FPSくらいしか出ていないし、得られる映像には残像みたいなモノが含まれている。

また、そのまま長時間使っていると、何故か、1FPS程度にまで映像のフレームレートが低下してしまったりもしているのだが、1280x720の解像度にすると、7FPS程度しか出ていない感じなのだが、とりあえず、数時間経っても、フレームレートは落ちないので、通常は、このモードで使ったりしている。

もっとも、上記については、まだ、とりあえずは、使えているのだが、作者環境にあるもう一つのUSB接続のWebカメラである所のELECOMのUCAM-C0220Fでは、もっと大きな問題が発生する事が、今回、判った。

具体的には、解像度を30FPS出ない800x600や1280x720なんかに設定すると、AG-Webカメラレコーダーに表示されるプレビュー映像が、1分も動作させていると、1,2秒、遅れて出力されてくる感じになっていた。

UCAM-C0220Fの場合、解像度を640x480にすると普通に30FPSで動作してくれるので、最近は、こちらを使っていたのだが、今回、色々なモードでテストしてみていると、上記の様な問題がある事に気が付いた訳だ。

で、上記の原因は作者製の処理ルーチンにある可能性もあったので、graphedt.exeを使って、単純なDirectShowグラフを作成し、作者製ルーチンが関与しない状況でテストしてみたのだが、やはり、同じ問題が発生した。

なので、上記の問題は、UCAM-C0220Fの問題、という事になる筈なのだが、graphedt.exeには、何故か、メニューに「use clock」という項目があって、最初はチェックしていたのだが、チェックを外してテストしてみた所、問題はなくなった。

それ以前に、AG-Webカメラレコーダーの内部ルーチンを使って、DirectShowから送られてくるサンプルタイムをトレースしてみていたのだが、その時間は、明らかにずれていた。

と、いう事もあり、作者的には、上記の問題は、DirectShowのグラフで使用される同期クロックに問題があるのだろう、と、いう結論に達したので、AG-Webカメラレコーダーでも、グラフ作成時に同期クロックを使用しない設定を追加してみた所、上記の問題は発生しなくなった。

なので、Ver1.4.1では、上記の様に、通常は、Webカメラから出力される筈の同期クロックを使用しないモードをデフォルトにする予定だ。

また、現行版では、フレームレート制限を1FPSにして、オーディオも録音していると、MP4エンコード中にプレビュー映像が頻繁に止まってしまう感じになる場合がある。

上記は、mp4エンコーダーが入力される映像データと音声データの時間差が大きくなりすぎると、両方の時間を同期させようとして? エンコードを遅らせる?様になるからだ。

なので、例えば、Webカメラからの音声データが、暫く入って来なくなると、mp4エンコーダーの処理に異常に時間がかかる様になるので、AG-Webカメラレコーダー的にも、フリーズした感じになってしまう訳だ。

そして、AG-デスクトップレコーダー Ver1.4.1の開発時に書いた様に、現在、作者製のDirectShowルーチンでは、音声レベルの表示用に使っているグラフでは、音声キャプチャーデバイスのバッファリング時間を20mSecに設定しているのだが、録画時には、その設定を行っていない訳だ。

このため、マイクなんかでは、デフォルトで0.5秒くらいのバッファリング時間が設定されているので、mp4エンコーダー的には、映像と音声のタイミングに前述の様な問題が発生するケースが出て来る可能性もあるので、今回、そういう事態が発生しずらくする努力も行った。

具体的には、Ver1.4.0だと、映像データに待ちを入れたりする場合には、その待ちが終わってからしか音声データの入力をチェックしなかったのだが、より頻繁にチェックする様にした。

また、AG-デスクトップレコーダーと同様に、バッファリング時間の指定も行える様にするので、設定を行うと、より頻繁に音声データの入力が行われる様にもなるので、より一層、上記の映像と音声の時間差が発生する可能性を減らせるので、MP4エンコード時にチョクチョク、映像が停止する、みたいな現象は発生し辛くなる筈だ。

ちなみに、上記の通り、次バージョンのAG-Webカメラレコーダーでは、AG-デスクトップレコーダーにも追加した、音声入力デバイスのバファリング時間設定オプションだとか、映像遅延なんかが発生するWebカメラ用に、同期クロックを使用しない機能も追加する。

つまり、AG-Webカメラレコーダー Ver1.4.1についても、基本的な処理コードに改良が入るので、挙動が変で、現行版では上手く録画出来ない様なWebカメラを使っている人も、次バージョンでは、マトモに録画が行える様になるかもしれないのだが、多くのユーザーは、現行版でも問題なく録画できている筈なので、変更内容がこれだけだと、多くの人にとって、次バージョンは魅力が無いモノになってしまう。

なので、AG-Webカメラレコーダーにも、目玉機能を用意するのだが、とりあえず、今日の時点で、それ関連のテストも色々とやってみていて、格好が付きそうな感じになっている。

しかし、上記の様な問題の解決に時間がかかったので、目玉機能については、まだ、本実装には入れていない。

このため、AG-Webカメラレコーダー Ver1.4.1のプレビュー版のリリースは今週末、という訳にも行かなくなったのだが、多分、来週早々には、コレを追加し、既に書いていた様なAG-デスクトップレコーダーの変更も入れたPreview4を公開する事になる筈だ。

« WiMAXサービスが提供終了らしい | トップページ | 目玉機能は動体検知録画? »

2020年1月
      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