[Vmaid-devel] Re: Native Codec について。

Back to archive index

ryoma ryoma****@users*****
2005年 11月 25日 (金) 20:45:05 JST


こんばんわ。ryoma です。
# 登録してあるアドレスしか受け付けてくれないのでしたね…。


> 1)NATIVE_CODECは不要
> ...

了解しました。


> 2)DriverProc
>  Windowsのcodecの仕様を踏襲する形でVideo maidのNativeなcodecを
> 実装するのはマズイと思います。
>  DriverProcはlParam1とlParam2がポインタになることがありますが、
> そういう仕様は問題があると私は思います。DriverProcという1つの関数を
> エクスポートしてmsgで使い分けるのではなく、Nativeのcodecでは
> 機能に対応した各々の関数を用意した方が良いと思います。
>  Win32ならばlParam1にポインタを設定できるけど、環境によっては
> ポインタがLONG(32ビット)よりも大きい場合もありえると思います。

サンプルコードではアドホックに long を使っていますが、私が参考にした 
MSDN の文書が古いのかもしれません。
以下のように書かれてまして、long にした次第でした。

LONG DriverProc(
  DWORD dwDriverId, 
  HDRVR hdrvr, 
  UINT msg, 
  LONG lParam1, 
  LONG lParam2
);

huffyuv の DriverProc は以下の様になってますね…。
こちらが新しい書き方なのでしょうか。

LRESULT PASCAL
DriverProc(DWORD dwDriverID, HDRVR hDriver, UINT uiMessage,
           LPARAM lParam1, LPARAM lParam2);

この場合、問題は起きないはずです。
以下、MinGW のヘッダより。

/* basetsd.h */
#define __int64 long long
#if defined(_WIN64)
typedef __int64 LONG_PTR, *PLONG_PTR;
#else
typedef  long LONG_PTR, *PLONG_PTR;
#endif

/* windef.h */
typedef LONG_PTR LPARAM;
typedef LONG_PTR LRESULT;

ポインタが 32 ビットより大きい場合と言えば、主に 64 ビットになると思う
のですが、UNIX 系?の 64 ビット環境では、大体は long は 64 ビットにな
ると思います。最終的な判断は採用しているデータモデルに依存するのでしょ
うから、結局なんとも言えませんが…、あまり心配ないかと。
# よく調べてませんが、LP64 で検索すれば、ちらほらと。


> 3)Nativeのcodecの読み込み方法
>  Profileは廃止予定です。ProfileからNativeのcodecを読み込むのではなく、
> どこかのディレクトリを検索するような方法にしたいと考えています。

了解しました。


>  Win32エミュレーションの方はdllloaderを破棄して新たにw32loaderを作り、
> それでOpenDriverなどの関数を実装する予定です。それによりicm.cの
> ソースレベルではOSがWindowsの時と、w32loaderによるエミュレーションの
> 差がなくなるようにします。
>  codecの登録は例えば.w32loaderみたいなファイルに
> [registry]
> HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Drivers32\VIDC.hfyu=huffyuv2.dll
> という記述をしておくことにします。そしてそれをRegOpenKeyExで開いて
> 値を取得するみたいな...

現状のコードでは、エミュレーションとネイティブで同時に同じコーデックは
使えないので、何か考えます。
# そのうち、Win64 の事も考えないといけなくなるのかな…。


>  パッチの方法はWindowsのcodecを少ない労力で移植するには適していると思います。
> 私が考えている方法だと、移植の手間は多くなると思います。

0からコーデックを書く場合であれば良いのですが、やはり、移植するとなる
と、「少ない労力」に傾いてしまいます。(^^


>  あとhuffyuvですが、Nativeのcodecを実装するときには、私も始めに
> huffyuv 2.1.1を作る予定でした。huffyuvは現在、誰も開発を行っていないようです。
> ゆえに我々でhuffyuvの後継を宣言して、Windows版も含めて開発を行うことを
> 考えています。

Huffyuv 0.2.5 patch なんて物もあるようですが、とりあえず huffyuv 2.1.1 
から始めることにしました。
# とりあえず完成したと言うことで、手を付ける必要がないのか、開発を放棄
# したのか、どちらなんでしょうかね…。

-- 
  ryoma <ryoma****@users*****>



Vmaid-devel メーリングリストの案内
Back to archive index