[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
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, Joerg-Cyril.Hoehle(a)t-systems.com 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
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, Joerg-Cyril.Hoehle(a)t-systems.com 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
participants (2)
-
Aric Stewart -
Joerg-Cyril.Hoehle＠t-systems.com