スポンサーリンク

T.Ishii's Software Library

HTML5 レトロ風ゲーム館

無料ブログはココログ

« 動作の問題は無くなった | トップページ | ズーム・パンはどうするか »

それなりには整理できた

今は、AmuseGraphics Ver1.4.1の開発フェーズで、macOS版AGMPlayerに続き、macOS版AG-ムービーカッターの変更作業中で、今回の目玉である所のトランジション効果の追加機能の実装は一応は終わったのだが、コードが複雑化したので整理中だ。

今現在開発中のAG-ムービーカッターはmacOS版なのだが、Windows版も、似た様に作りになっている。

と、いうか、そもそもは、Windows版として開発し、それを移植する形でUbuntu版を開発し、更に、それをmacOS用に移植したのがmacOS版という事になる。

なので、Windows版が似た作りになっているのは当たり前の話になるのだが、実際の所、macOS版よりも、更に、Windows版の方が、ソースコードは複雑になっている。

これは、macOS版では、デコーダーはAGM形式用とAVFoundation用しかなく、エンコーダーについても同様なのに対し、Windows版では、デコーダーはAGM形式用以外にDirectShow用とMediaFoundation用があり、エンコーダーについては、AGM形式用/WMV用/AVF用/DirectShow用があったりするからだ。

つまり、Windows版のAG-ムービーカッターでは、扱う動画形式、というか、動画を扱う為に使用しているAPIの種類が多いので、その分、複雑にならざるを得ないのだが、エンコード処理に関して言えば、出力形式は異なっても、入力形式は同じだったりする訳だ。

つまり、AG-ムービーカッターでは、読み込んでいる動画ファイルを別形式でエンコード出力するのが基本的な動作になるので、エンコード出力する形式が異なっても、読み込んでいる動画ファイルが同じなら、エンコード処理ルーチン内で参照するソースファイルは同じになる訳だ。

にも関わらず、数日前に書いた様に、内部構造的には、これらのソースファイルの形式は仮想化していないので、エンコードルーチン内では、ソースファイルの形式に応じて、それぞれ異なる処理ルーチンを動作させたりしている。

もっとも、そういう作りにしてあるのは、AG-ムービーカッターのエンコード処理ルーチンでは、ソースファイルから直接データを読み込んだりはしていないからだ。

具体的には、ソースファイルのデコード出力は、ソースファイルの形式に左右されず、映像はエンコードルーチンが公開しているキューに積まれる格好になっているし、音声はリングバッファに書き込まれる様になっているからだ。

つまり、AG-ムービーカッターでは、ソースファイル自体は仮想化していないのだが、デコード処理は各ファイル形式用のデコードスレッドを起動して動作させる格好にしていて、エンコーダーでは、そのデータを受け取るだけなので、何も、ソースファイル自体を仮想化しなくても、エンコード処理ルーチンが複雑怪奇になる、という事も無かった訳だ。

もっとも、上記の様な方式にしてあっても、各ソースファイル用のデコーダーを起動する処理については、ソースファイルの形式を意識して行う必要があるので、エンコードルーチン内に、結構なボリュームのデコーダーの処理開始用コードが必要になっていた。

で、エンコーダーの本来の仕事は、入力データをエンコードする事なので、上記の様なソースコードは極力目立たせない様にしたかったので、今回、それらの処理ルーチンを、極力、別だしする格好にした。

その結果として、上記の別だしした処理コードは、AGM形式動画用のエンコーダーとAVFoundation用のエンコーダーの両方で使える格好に出来たので、全体のコード量が減らせたと同時に、バグなんかがあった場合の修正も、別だしした処理コードを修正するだけで良くなった。

と、いう事で、トランジション効果を滑らかに適用できる様にするために、特に、エンコードルーチンは、結構、複雑化したのだが、複雑化したのは、ソースファイルの読み込み関連で、それらについては、別だしする格好に出来たので、現行版と比べれば、エンコードルーチンのソースコードは、逆に、より単純化されたかもしれない。

ちなみに、今回のコード整理は、エンコードルーチン内で使用されていたローカル変数を構造体に纏めた事で実現できた、と、言える。

何故なら、エンコードルーチン内の処理コードを別だししたくても、何の対処も行わないと、参照しなければならない変数が多すぎて、別関数を定義すると引数の数が半端ではなくなってしまうからだ。

もっとも、引数の数を減らしたい時に、それらを構造体に纏める、という様な事は、作者的にも、それなりにやってきてはいたのだが、今回の構造体定義の意味は少し違った訳だ。

何故なら、呼び出す関数で使用されない変数も、その構造体に入れてあるからなのだが、これは何を意味するのか、というと、エンコーダーのローカル変数の殆どを構造体に纏めてしまった、という事だ。

その結果として、別だしした処理関数でどのパラメータが参照され、どのパラメータが書き換えられるのかは判らなくなる。

なので、こういうコードは宜しくない、と、いう考え方も成り立ちはするのだが、少なくとも、別だしのコードを出力形式が異なるエンコードルーチンで共用できる様になった効果は大きい筈だ。

« 動作の問題は無くなった | トップページ | ズーム・パンはどうするか »

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