[PATCH] mciqtz: Actually assign result to the output structure

[Joerg-Cyril.Hoehle at t-systems.com]

Hi,

Aric Stewart wrote:
>If you know about specifically quartz issues I am happy to start looking at them.

I find the following very specific:
Mciqtz is nothing but a pass-through to quartz' IVideoWindow_* IMediaSeeking_*
IMediaControl_ and IGraphBuilder_QueryInterface.
So using mciqtz is like using quartz directly.  The nice thing is:
every bug you find is a bug in Wine, since only Wine
source is involved, without third-party app.
That's why I find working with the MCI very rewarding.

The MCI shell is at
http://bugs.winehq.org/show_bug.cgi?id=20232#c10

Here are basic scenarios that do not work correctly now
-- in the following, replace foo.xyz with your choice of
 .wav (embedding linear pcm, adpcm and esp. mp3),
 .avi (with whatever RLL/iccvid/msvidc1/etc. video format),
      use .avi with and without audio tracks,
 .mp3 or
 .mpg audio/video (if you feel like stressing winegstreamer)
(even .wma if you feel like using codec outside Wine)
 You may even try .mid files, but perhaps that would use DirectMusic in native.

Open foo.xyz type mpegvideo alias q

Window q state show
Status q time format # optional, yields "frames" with .avi
Set q time format milliseconds # optional
Status q length
Set q time format frames # restore default for .avi
Status q length
Seek q to start
Play q notify # or alternatively
Play q from 0 notify
Play q from 5 to 10
Play q from 0 repeat notify # repeat flag not yet implemented
Status q position
Status q mode # should yield "stopped" or "playing"
Set q time format bytes # expect MCIERR_UNSUPPORTED_FUNCTION == refused
  # presumably, quartz does not work with bytes (or would mciqtz intercept that?)
Stop q
Close q

IIRC, Wine's DirectSoundRenderer would not stop and
regularly throw errors to the console.

I just noticed that "play X from 5 repeat" behaves differently
between native mciavi32 and mciqtz (xp).  Mciqtz repeats from 0
while mciavi repeats from 5.  Also their window refresh modes
are very different, mciqtz is mostly unresponsive while mciavi
refreshes even when not playing.  So it is not the case
that MS made mciavi and mciqtz equal.

Actually, I don't know where the default time format originates from.
A typical .avi yields "frames", using a .wav yields milliseconds.
So it is not a constant for mciqtz.

So I think there's plenty of room for improvement in quartz, and you need
not wade through obscure logs produced by binary-only apps.  And once
mciqtz/quartz behaviour becomes undistinguishable from native's as witnessed
by the MCI shell with "type mpegvideo", many bugzilla quartz items will
appear fixed automagically, I'm sure.

Thank you,
	Jörg Höhle