「 2013年05月 」一覧

自分コーデックの作成


調査を始めてから約2日で、無圧縮コーデックに何とかたどり着いた。思いの外、ここまでは早く到達できたと思う。

途中で悩んだポイントは WindowsのメディアプレイヤーやMediaPlayerClassicでは正しく再生できない状況があり、そのときでもAVIUtlやVirtualDubは問題なく表示できていたという妙な挙動で手こずっていた。

これらで何が違ったかというと、再生前のプレイヤー側のフォーマット調査の際に、ICM_DECOMPRESS_GET_FORMAT を投げるかどうか。
他、DECOMPRESS_QUERYの実装で自分が間違っていてRGB系フォーマットならOKを返してしまっていた点。
入門として最初に作るなら、フォーマットはコレ!ときめてそれ以外全く受け付けないようにしていればこのトラブルを避けられたと思う。

今できている Hello World的Codec では RGB24のみを受け付ける状態。このくらいだとコードがシンプルになる。
作り方がわかったところで、ちゃんとしたコーデック作成に向け準備を始めようかと思います。

それとは別に、Video For Windowsの、このコーデックにより対応フォーマットを増やせることをみこしたAPI設計は良く出来ていると思った。長年変わらずとも使えるってのはホント良く出来てる・・・もしかすると今となっては不都合なことも多いのかもしれないが、動く&使えるってところはやっぱり感心する。

まとめ

入門の際には RGB24の完全固定のフォーマットのみを受けることにしてまずは実装すべし。
動作を確認するツールは複数で試すこと。
infファイルの記述が難解・・・。先人のコピーをスタートとして、出来なければレジストリ直書きしてしまう。

これから始める場合には↑のことに注意したら、余計なハマリポイントに陥らないですむかもしれない。


コーデック作成のための下調べ


今作ろうとしているのは Video for Windows(VFW)のコーデックとして振る舞える何か、です。
これをどうやって作るかはさておき、どのようにロードされるのかを調べてみました。

AVIUtlではアプリケーションの起動時にそのシステムで使用可能なVFWコーデックの一覧を取得するようです。
一方で、VirtualDubはコーデック選択時に一覧を取得するようです。

これらの違いから、デバッグのやり方にも差が出てきます。
すなわちAVIUtlを利用してアタッチしてのデバッグの際には、正しくロードできる前提ということになります。
アタッチしたときにはコーデックは既にロード完了し、そしてアンロードされてしまっているので、アタッチのほうでは状況を追いかけることが出来ません。

コーデックのエントリポイントはどうやら DriverProc という関数になるようです。
これさえわかれば後は何とか追いかけていけそうです。


WIC用コーデックを作ってみようかと思った


Windows Imaging Componentのコーデックを追加して、対応画像フォーマットを増やしてみようかと思ったのですが、
このコーデックに要求されるのが、署名だったため自作を諦めました。

WICは利用するだけで、自分で作らない(作れない)ということで。

署名さえ不要だったら、独自フォーマット表示とか、対応形式を自前で増やしたりとか簡単にできそうでおもしろそうだったのに残念です。

参考にしたのはMicrosoftから出てる、WICCODEC.doc というわかりやすいドキュメントです。


これから何をやろうか


前回のでひとまず熱を入れてやっていたことが終わったので、次のネタをぼちぼち取りかかる予定です。
内容は少し前から興味があった動画のCODECを自分で作ってみようかと思ってます。
まずは勉強目的で。

これについてちょっと必要になってくるのが inf ファイルなのでちょっと調べてました。
まず一番最初のステップとして、このファイルのInstallでファイルがコピーされる、という単純なものを作ってみました。

[version]
signature="$Windows NT$"

[DefaultInstall]
CopyFiles = FilesSection

[FilesSection]
hello.dll,,,0

[DestinationDirs]
FilesSection=11

これでひとまずはinfと同じ場所にある hello.dll が Windows/System32 以下にコピーされます。
まずとっかかりとしてはここから。

CODECのほうも今やオープンソースでいくつかありますし、これを元に解析&挙動について追いかけていけば、なんとなく勉強できるのではないかと感じています。
しばらくはこれにつきっきりでブログはおろそかになりそうです。

残ってること

もうちょっとMMDの仕上げを。レンダリング周りは全く手を付けていなかったし。カメラアニメもついさっきまで頭にすらなかった。
Androidでの動作もやってみてもよかったかもなぁ。


MMDの再生、物理演算いれてみた


MMDのデータの再生を相変わらず今更ですががんばって実装していました。
今回は、IKと物理演算について実装を進めてました。前の実装を一度捨ててます…。
そのため、表情モーフも無効となってしまっている状態ですが、今回の物は以下の点を盛り込んでみました。

  • DirectXの算術(D3DX)を用いたり、Bullet が持っている算術を使用したり切り替えられること
  • Bulletのバージョンに縛られないこと。

これらのメリットを説明しますと、扱っている行列並びや演算順序の部分での余計なトラブルを避けたいため、まずはBulletの算術に統一して扱おう!という考えによるものです。
また、Bulletのバージョンが変わっても(ある程度は)大丈夫というのも、MMDが当初 2.75らしく、それが今のBullet最新では2.81だそうで。なるべく追従していきたいと考えているからです。特に 2.81 ではSIMD最適化も入っているらしくここに実装を変えられるという点はかなり大事だと思っています。

今回は初めて、YouTubeに録画した動画をあげてみました。でもってこれをこのブログに貼ってみるという試みにチャレンジもしてみます。

画質の問題とキャプチャ速度の問題からツールを変えて再キャプチャしたものに差し替えました。 (5/20)
まずは、Bulletの算術を使って 2.81 を用いて再生したものです。

上記をベースにして、DirectXの算術で実装してみた物です。

※ 実時間による補正をいれてないため、使用している演算の速度でこんなに変わってます。DXのほうが速い。

今度はモーションを変えて、Bulletのバージョン違いを試してみました。どちらもBulletの算術使ってます.

こちらが 2.81 を使ってみたものです。

そしてこれが 2.79 を使ってみたものです。

感想など

今までは 2.79で試行錯誤した時間が長かったので一番最後のが安定して動く気はしてます。
ただ問題なさそうな範囲で 2.81 も動いているように見えるので、今回の目標は達成できたかなと思っています。

ちなみにこれらはDirectXの算術をつかっているにもかかわらず全てOpenGLの簡単な描画でやっています。
最後の状態だけ見るとかなりちゃんぽんしてる状態なので、覚えているうちにコードをリファクタリング&コメント付けしておこうと思います。なお、扱っている座標系は全て右手系にしています。これをさらに左手系に対応させるとなるとさらに倍のコード分岐が必要になると思うのでこれにはもう絶望ですね。

というか、Bulletを左手系でうまく駆動させる自信がないです・・・。


Windows 8でXAudio2のトラブルに出遭う 解説編


前回の日記でふれたVisualStudio 2012 + XAudio2 + Windows 8 というコンボ発動で、アプリケーションを正常に起動出来ない!という罠にはまった内容を説明したいと思います。

実は、Windows 7で使用している(できる)最新のXAudio2は、 2.7 というバージョンのもので、これは DirectX SDK 2010 Juneに含まれています。またDirectXの再頒布ランタイムをインストールすることで導入できます。
一方、Windows 8で標準で使用するXAudio2は 2.8 というバージョンのものになります。これは VisualStudio 2012付属のWindows SDKを使用してアプリケーションを作成するとこちらを使うようになります。

標準状態の Windows 8 では、XAudio2は 2.8 のものだけが入っており、従来のDirectX SDKを使用していると 2.7のものを要求するために動作しません。
.Net framework をインストールした後で、DirectXのランタイムをインストールすると、Windows 8でも動作するようになりますが、これをアプリケーションを単に動かしたい人々がやるには手間もいいところです。
できるなら、そのままアプリケーションが動くのを目指したいところです。

これを表にするとこうなります。

DirectX SDKを使ってXAudio2 Windows 8ではそのまま動作しない
VS2012のWindowsSDKでXAudio2 Windows8では動作、Windows7では動かない

Windows7までの環境では対応したDirectX再頒布パッケージがあるのでそれをインストールすることができます。
ただそれらをインストールすること無しで XPから8まで、単一アプリケーションとしてサウンドを再生するには、実はDirectSoundを使用すると良さそうです(XPの標準状態でもDirectSoundは含まれていました)。

おそらくVista以降のDirectSoundはXAudio2より上位にレイヤーとしては位置付けられているようなので、
これを使うことでXAudio2に関係する依存関係を断ち切ってくれそうです。
ただし、DirectSoundは既にレガシーなAPIとなっているため、そのあたりが懸念事項でしょうか。
ただ互換性の点からOSから使用できない・削除されているわけではないため、XPから8まで一応使うことは出来るようです。

※ そのため単一アプリとして提供する際にはとても都合がよかったり。

DirectX9とXAudio2と。

D3DX関連のAPIもVS2012のWindows SDKに入っていないので、DirectX9+XAudio2という構成は VisualStudio 2012での開発にとってはなかなかの鬼門といえそうです。シェーダーのコンパイルはD3DXですし、XAudio2は今回のような問題があるし。

再頒布ランタイムをとりあえず強引にででもインストールさせるのであれば、DirectX SDK 2010 Juneを使って開発しておくでOKでしょう。
なるべくなら標準の状態で開発&配布したいと考えるなら、DirectX9やXAudio2を諦めて、OpenGLとDirectSoundを選択しておくと、余計なことを考えずともどこでも動く状態の物ができあがるように思います。

Windows Vista以降だけでよいというなら、WASAPI も選択肢に上がってくるかと思いますが、これは使うのが大変なので手軽にという点も考慮するなら、やはり情報も多いDirectSoundでお茶を濁しておくのが手っ取り早いでしょう。

参考元
XAudio2 Versions


Windows 8でXAudio2のトラブルに出遭う


VisualStudio 2012を使っていたら、Windows8でのXAudio2で問題に遭遇したのですが、
この件で、有名な吉野屋テンプレがうまく使えそうだと閃いたためちょっと貼ってみます。
ちゃんとした説明は次回に行いたいと思います。

では、どうぞ。

昨日、XAudio2 を使ったアプリを Windows 8 で動かしたんです。Windows 8。
そしたらなんかアプリが起動出来ないって言われるんです。

で、よく見たらヌルポでアクセス違反、とかのようなんです。
もうね、アホかと。馬鹿かと。

お前らな、XAudio2 引き如きで普段使わない Windows 8に来てんじゃねーよ、ボケが。
XAudio2 だよ、XAudio2。

なんかDirectX9とかもいるし。DirectX9 + XAudio2でWindows 8か。おめでてーな。
よーしパパ、プログラムをWindows 8対応しちゃうぞ、とか言ってるの。もう見てらんない。
お前らな、Windows SDK やるからその席空けろと。

Windows 8 対応ってのはな、もっと殺伐としてるべきなんだよ。
OS環境ごとにプログラムを用意しないで、
単一プログラムがそのまま動くか動かないか、そんな雰囲気がいいんじゃねーか。
女子供は、すっこんでろ。

で、やっと座れたかと思ったら、隣の奴が、WASAPI で、とか言ってるんです。
そこでまたぶち切れですよ。

あのな、WASAPI なんてきょうび流行んねーんだよ。ボケが。
得意げな顔して何が、WASAPI、だ。

お前は本当にWASAPIを使いたいのかと問いたい。問い詰めたい。小1時間問い詰めたい。
お前、WASAPI って言いたいだけちゃうんかと。

Windows 8通の俺から言わせてもらえば今、Windows 8での最新流行はやっぱり、
DirectSound、これだね。

素のDirectX9+DirectSound。これが通の頼み方。
DirectSoundってのは古くからあるDirectXのサウンド担当。そん代わり今やオーバーヘッドが多め。これ。

で、素のDirectX9(D3DXとかナシ)。これ最強。

しかしこれを頼むと次からマイクロソフトにマークされるという危険も伴う、諸刃の剣。
素人にはお薦め出来ない。
まあお前らド素人は、OpenGL + DirectSoundでも使ってなさいってこった。

※ 注意: OpenGL + DirectSound なら今や多くの環境でそのまま動くことでしょう。