mciavi should be rewritten using the AVIFile interface

Hi,

MSDN documents (and I verified) that the MCIAVI allows to access an
open AVIFile object via the special name @NN...NN (decimal address).
Conversely,
open @-1024 type avivideo alias a
crashes native at address ffffc000 -- except on w95 (KB140750).

This makes it likely that MCIAVI internally uses the AVIFile API
(it might also pull the MMIO file handle out of the AVIFile structure).

Furthermore, other parameters that the MCI exports, e.g.
MCI_ANIM_*_SPEED, map to what the AVIFile objects provide and is not
present in MMIO handling, reinforcing the hypothesis that the MCIAVI
uses the AVIFile API.

Hence mciavi.c should be rewritten to use the AVIFile API.  I hope
that doing so will prevent a skew that I've observed with some apps,
where sound and video rendering do not match after a few seconds.

Any volunteers?
Any excellent sample code using AVIFile to render both video and audio?

Regards,
 Jörg Höhle

[Dmitry Timoshkov]

 wrote:
> Hence mciavi.c should be rewritten to use the AVIFile API.  I hope
> that doing so will prevent a skew that I've observed with some apps,
> where sound and video rendering do not match after a few seconds.

It would be better to find and fix an actual bug instead of introducing
a bunch of new ones with the rewrite. Same with mciseq.

[Maarten Lankhorst]

Hi Joerg,

2010/11/17  :
> Hi,
>
> MSDN documents (and I verified) that the MCIAVI allows to access an
> open AVIFile object via the special name @NN...NN (decimal address).
> Conversely,
> open @-1024 type avivideo alias a
> crashes native at address ffffc000 -- except on w95 (KB140750).
>
> This makes it likely that MCIAVI internally uses the AVIFile API
> (it might also pull the MMIO file handle out of the AVIFile structure).
>
> Furthermore, other parameters that the MCI exports, e.g.
> MCI_ANIM_*_SPEED, map to what the AVIFile objects provide and is not
> present in MMIO handling, reinforcing the hypothesis that the MCIAVI
> uses the AVIFile API.
>
> Hence mciavi.c should be rewritten to use the AVIFile API.  I hope
> that doing so will prevent a skew that I've observed with some apps,
> where sound and video rendering do not match after a few seconds.

Just symlink mciqtz32.dll.so to mciavi32.dll.so ?

Cheers,
Maarten