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

Andrew, Aric, Maarten,

I'm pleased to see that patches to quartz and mciqtz keep flowing in.

For the last years, I've wondered whether I should open a sort of generic bug
that mciqtz/quartz still is a mostly broken MCI device, missing many basic
functions.  Every time I try it out using my MCI shell, it has improved a little bit,
but it's still in a very bad shape overall. Alas, I've never written a significant
mciavi testsuite. That could be used to check mciqtz too.

For instance, basic commands like the following are either partially implemented
or completely missing:
open xyz.avi type mpegvideo alias q notify
status q length
status q time format notify
seek q to 0
set q time format xyz
play q from 50 to 500 notify
status q position
window q state show
seek q to end

Furthermore, mciqtz should be able to access other files, e.g. play .wav and even IIRC .mid files.
open sound.wav type mpegvideo alias w notify
status w time format
play w from 4
status w length
status w position
In theory, one could use the mciwave testsuite, add type mpegvideo
to every open, and it should mostly pass.

Even without "type mpegvideo", using mciqtz to open an .mpg file with audio and/or video
yields many fixme lines and has issues, e.g. IIRC it doesn't manage to stop!

close all

Often, the missing bits are in quartz or associated dlls, not mciqtz.
Every time I look at quartz code, I'm lost among lots of methods that do
nothing but delegate to other methods. Typical OO :-(

A quartz working well would allow to close bug #19496. See comment #13.
I believe msvfw should always delegate to one of mciavi or mciqtz.
But currently, mciqtz+quartz is in too bad shape to switch msvfw.

I'd be happy to see mciqtz work at least as well as most other mci drivers.
Please keep sending patches!

Thank you,
 Jörg Höhle

[Aric Stewart]

Hi Jörg,

Thanks for the e-mail.  I will admit that I am completely ignorant about 
mci and mciqtz.  However I am becoming more and more skilled at quartz. 
Right now I am mostly knowledgeable about the filters and filter chain. 
  I will start looking at our filter graph stuff soon, but there is 
still a lot for me to do with cleaning up and improving our filters.

If you know about specifically quartz issues I am happy to start looking 
at them.

-aric

On 12/03/21 10:13, [e-mail] wrote:
> Andrew, Aric, Maarten,
>
> I'm pleased to see that patches to quartz and mciqtz keep flowing in.
>
> For the last years, I've wondered whether I should open a sort of generic bug
> that mciqtz/quartz still is a mostly broken MCI device, missing many basic
> functions.  Every time I try it out using my MCI shell, it has improved a little bit,
> but it's still in a very bad shape overall. Alas, I've never written a significant
> mciavi testsuite. That could be used to check mciqtz too.
>
> For instance, basic commands like the following are either partially implemented
> or completely missing:
> open xyz.avi type mpegvideo alias q notify
> status q length
> status q time format notify
> seek q to 0
> set q time format xyz
> play q from 50 to 500 notify
> status q position
> window q state show
> seek q to end
>
> Furthermore, mciqtz should be able to access other files, e.g. play .wav and even IIRC .mid files.
> open sound.wav type mpegvideo alias w notify
> status w time format
> play w from 4
> status w length
> status w position
> In theory, one could use the mciwave testsuite, add type mpegvideo
> to every open, and it should mostly pass.
>
> Even without "type mpegvideo", using mciqtz to open an .mpg file with audio and/or video
> yields many fixme lines and has issues, e.g. IIRC it doesn't manage to stop!
>
> close all
>
> Often, the missing bits are in quartz or associated dlls, not mciqtz.
> Every time I look at quartz code, I'm lost among lots of methods that do
> nothing but delegate to other methods. Typical OO :-(
>
> A quartz working well would allow to close bug #19496. See comment #13.
> I believe msvfw should always delegate to one of mciavi or mciqtz.
> But currently, mciqtz+quartz is in too bad shape to switch msvfw.
>
> I'd be happy to see mciqtz work at least as well as most other mci drivers.
> Please keep sending patches!
>
> Thank you,
>   Jörg Höhle

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

[Aric Stewart]

Hi Joerg,

Cool, but what I could use is concrete test cases with reported failures.

Could you give me some example scripts, maybe with accompanying media 
files, with the issues pointed out.

You could give me where the expected behavior does not match the 
existing behavior.

clear tests and procedures like that will allow me to really focus in on 
what is going wrong.

thanks!
-aric

On 12/03/23 13:18, [e-mail] wrote:
> 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