スポンサード リンク

T.Ishii's Software Library

HTML5 レトロ風ゲーム館

無料ブログはココログ

« 長時間録画も行いつつ | トップページ | 来週で終われれば・・・ »

もう一週間みておけば・・・

今は、Windows用AmuseGraphicsの開発フェーズで、既に、最終的な動作確認を行っている段階なのだが、今日の時点で、本体の確認は終わった。なので、作業はAG-ムービーカッターに移ったのだが、早速、微妙なバグを1つ潰した。本体にも、バグはあったので・・・

今日から、AG-ムービーカッターの動作確認を始めたのだが、その方法としては、本体とほぼ同様だ。

つまり、メニュー項目を順番に実行していっているのだが、AmuseGraphicsファミリーソフトでは、動画の読み込み時には、そのファイル形式に応じて、Media Foundation / DirectShow / 自前AGMライブラリの何れかが使われる格好になっている。

なので、例えば、「開く」メニューの動作確認についても、一つの動画を開けばよい、という事にはならなくて、少なくとも、前述の全ての処理ルーチンが動作する様に、3種類の動画を読み込む必要があるのだが、より正確には、AGM形式にも9種類あるし、DirectShow経由での読み込み時にも、内部的には、異なる画像タイプが選択される事があるので、1種類だけでOk、という事にはらなない。

と、いう事なので、「開く」メニューの動作確認一つをとっても大変なのだが、今日は、実質的には、その次の動作確認項目になる「音声トラックの別指定」でトラブった訳だ。

具体的には、音声トラック用に映像付きのmp4動画を指定した場合に限り、設定状況で、再エンコードを行うと、エンコード終了後に、AG-ムービーカッターがクラッシュする、という現象が発生した訳だ。

で、デバッグモードで動作させた場合にも、クラッシュが発生するのであれば、何が起きているのかは判るのだが、デバッグモードでは現象は発生しなかった訳だ。

そして、何故か、Windows10では、macOSとは異なり、クラッシュが発生すると、その状況がマイクロソフトには送信される様なのだが、その原因となる情報を作者には、一切、見せてくれない訳だ。

macOSの場合には、クラッシュ発生時に、詳細をユーザーが確認でき、Appleに送信する必要が無いと判断すれば、送信しないボタンも押せるのだが、Windows10には、そんなボタンはなく、クラッシュ発生後に、既に送信した、みたいな表示が行われるので、作者的には、どうしようもない。

と、いう事で、今日は、何故、クラッシュが発生するのかが判らないまま、状況を変化させつつ、何度もクラッシュを発生させたので、マイクロソフトの所には、何度も、AG-ムービーカッターのクラッシュ情報が送信された筈だ。

このため、AG-ムービーカッター Ver1.3.2は、リリース前から、Windows10的には、不安定なソフト、という事にされてしまったかもしれないのだが、デバッグモードでは現象は発生せず、現象が発生しても例外情報等が一切表示されないので、作者的には、現象を何度も起こす必要があった訳だ。

で、結果的には、色々と状況を変化させ、現象の発生有無を確認した後、関連するソースコードを真面目に見ていった結果、バグを見つけて、不具合は解決できたのだが、そのバグというのは、「音声トラックの別指定」時には、音声トラック用の動画は再生中にシークする事があるのだが、その処理に問題があった。

つまり、再生中の動画よりも音声トラックが短い場合に限り、かつ、動画を音声トラックよりも長く再生した場合に限り、問題のシークは発生するのだが、そのシーク処理では、再生を停止せずに、シーク処理を行い、シーク処理後に再生を再開していた訳だ。

このため、シーク完了後には、本来なら1つだけの筈の再生用スレッドが2つになってしまっていた訳なのだが、スレッドというのは、同一のプロセスメモリを使う。

つまり、クラス変数なんかについては、同じモノを参照するので、スレッドが無駄に増えても、動作的には、どちらか早く気が付いた方が動作する、みたいな感じになっていたので、通常動作では問題は発生しなかったのだが、処理が終了してメモリを破棄する段階で、問題が発生する場合があった訳だ。

具体的には、再生終了時には、再生用スレッドの終了を待ってから、それが使っているメモリを破棄しているのだが、再生用スレッドが2つあった場合、そのどちらかが終了すると、スレッド終了の旨のフラグが立つので、メモリを破棄してしまっていた訳だ。

その結果として、アロケートされていない状態のメモリ空間にアクセスするスレッドが出てくる場合があったので、その場合には、クラッシュが発生する事になった訳だ。

上記の通りなので、デバッグモードなんかの場合、タイミング的に、スレッドの終了要求が出ると、メモリの破棄が行われる前に、2つのスレッドが両方共終了する格好になるので、問題は発生しなかった、と、思われるのだが、とりあえず、クラッシュ発生時に、macOSみたいに、このスレッドでメモリ参照例外が発生した、みたいな単純な報告でも得られてさえいれば、問題の解決はもっと速かった筈ではある。

と、いう事で、本体でも、微妙なバグは何個かあったので、先はまだ長いかもしれないのだが、動作確認作業の期間として、来週一杯くらいまでをみておけば、それなりに安心なバイナリが出来上がるかもしれない。

もっとも、今日の現象についても、タイミング的に、たまたま、作者環境ではクラッシュが発生しただけで、別環境ではクラッシュしなかったかもしれない。

つまり、いくら真面目に動作確認してみても、バグは潰しきれない筈なので、あまり動作確認に時間を使いすぎるのも、得策ではないかもしれない。

« 長時間録画も行いつつ | トップページ | 来週で終われれば・・・ »

トラックバック

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

この記事へのトラックバック一覧です: もう一週間みておけば・・・:

« 長時間録画も行いつつ | トップページ | 来週で終われれば・・・ »

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

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

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