OS/2, eCS & ArcaOS - Technical > Multimedia

How do I change this default behaviour?

<< < (2/4) > >>

Dariusz Piatkowski:
Hi Pete!


--- Quote from: Pete on November 28, 2021, 07:29:18 am ---...The cwmm MediaFolder help file - usually at [BootDrive]:\MMOS2\MEDIAFLD\DOC\mediafldr.inf provides an answer if using smplayer or vlc. See the section Hidden Features, Replace AVI Player as an example. Not sure if it can be tweaked to use mplayer without a frontend though...
--- End quote ---

Ahh, so these are the Chris W's MM classes I think, which I do not have installed on my machine, so that option is not currently available. Not to say I won't pursue it, just that it's not the setup I have deployed at the moment.

Dariusz Piatkowski:
Hi mauro,

--- Quote from: mauro on November 28, 2021, 02:01:57 pm ---Hi Dariusz, I had simply changed the default application for opening my media files using Assoedit (see images).

--- End quote ---

Yeah, I thought that doing this should take precedence over anything else, but in my case that is not the outcome. I suspect it is because of the MM file classes, but that's a standard OS/2 MM install and I figured basically everyone else out there would be impacted by this, unless I have of course installed something else in the past that I have simply forgotten about since then!

Lars:
The MM classes do make an attempt to define some "default" behaviour when you double click a file for the file type/file extension they are responsible for. I have not looked at the MM classes but I'd expect that they just do a MCI_PLAY command on the MM device that is associated with that file type/extension as a default. The CW MM classes might have implemented a smarter approach (looks like it).
Anyway, the "default" MM device for some given file type/file extension is defined through MMPM2.INI. And unfortunately, that "device" has to be an MCI device which essentially boils down to being a DLL with a defined entry point and command support. Certainly not any arbitrary EXE file. It would be possible to "wrap" invocation of an EXE file as a MCI device but this has to be implemented...

Dariusz Piatkowski:
Hi Lars,


--- Quote from: Lars on November 29, 2021, 10:44:13 am ---...Anyway, the "default" MM device for some given file type/file extension is defined through MMPM2.INI. And unfortunately, that "device" has to be an MCI device which essentially boils down to being a DLL with a defined entry point and command support. Certainly not any arbitrary EXE file. It would be possible to "wrap" invocation of an EXE file as a MCI device but this has to be implemented...

--- End quote ---

OK, good pointer. I found the following sections in MMPM2.INI file:


--- Code: ---...
[IBMDIGVIDPLAYER01]
 VERSIONNUMBER=1.2
 PRODUCTINFO=Software Motion Video
 MCDDRIVER=SVMC
 MCDTABLE=MDM
 RESOURCENAME=VIDEO PLAYER01
 DEVICEFLAG=1
 DEVICETYPE=12
 SHARETYPE=3
 RESOURCEUNITS=10
 RESOURCECLASSES=2,10,1
 CONNECTORS=1,3,,1
 EXTNAMES=5,AVI,FLC,FLI,MOV,QT
 EATYPES=Digital Video
 ALIASNAME=DigitalVideo Player
...
[IBMMPEGPLAYER01]
 VERSIONNUMBER=1.2
 PRODUCTINFO=OpenMPEG Video
 MCDDRIVER=DVMC
 MCDTABLE=MDM
 RESOURCENAME=OpenMPEG01
 DEVICEFLAG=1
 DEVICETYPE=12
 SHARETYPE=3
 RESOURCEUNITS=10
 RESOURCECLASSES=2,10,1
 CONNECTORS=1,3,,1
 EXTNAMES=7,MPG,VBS,DAT,M2P,CDI,M2T,M1T
 ALIASNAME=OpenMPEG Video 2
...

--- End code ---

...therefore, the 'Digitalvideo' definition (see below section) clearly points to the above 'Software Motion Video' and 'OpenMPEG Video' as the providers of that playback functionality (at least as best as I can interpret this).

Further on, the following is defined in the 'Drivers' section:


--- Code: ---[Drivers]
 Digitalvideo=IBMDIGVIDPLAYER01,IBMMPEGPLAYER01
 Speaker=SPEAKER
 Headphone=HEADPHONE
 Microphone=MICROPHONE
 Filter=IBMFILTER01,IBMFILTER02,IBMFILTER03
 CDaudio=IBMCDAUDIO01
 Waveaudio=UNIAUDWAVE01
 Ampmix=UNIAUDAMPMIX01,UNIFMAMPMIX01
 Sequencer=UNIAUDFM01

--- End code ---

Therefore, the IBMDIGVIDPLAYER01 & IBMMPEGPLAYER01 are the pertinent sections, where the 'MCDDRIVER=' field in both cases appears to point to a matching DLL file in the \MMOS2\DLL path.

Beyond this, the contents of MMPMMMIO.INI spell out the actual installed & registered details.

I am fairly certain that both of these are part of the default OS/2 MM install though, so I suppose one could try the official un-install process, although I'm worried that would remove far too much of that multimedia functionality.

Based on the feedback you provided I went looking through 'Multimedia Subsystem Programming Guide' (part of the OS/2 Toolkit), and under the 'Installation Requirements' one will find 'Installing an I/O Procedure' section. Of course that will simply update the MMPMMMIO.INI file, but it still needs the DLL itself that would allow a re-mapping of various file extensions to a user-defined program.

Taking the example of the AVI IOProc from above, so the SVMC.DLL file, I find the following procedures being exported:


--- Code: ---Procedures Exported by Ordinal:
    0 @#IBM:14.075#@
    1 mciDriverEntry

--- End code ---

Therefore, I'm curious if one was to:
1) build such a DLL that would re-map the call to a mplayer.exe (or a user defined EXE for that matter), would it be sufficient to define in that DLL the matching mciDriverEntry procedure?

2) once that procedure is created, would it simply call the EXE from there?

I feel like the above is a terrible oversimplification, but heck, that's all I know at the moment! LOL

Lars:
You are mixing up MCD drivers (see "MMPM2.INI") and MMIO procedures (see "MMPMMMIO.INI").

MCD drivers are for actually playing/recording audio/video content, MMIO procedures are for converting file formats (say from ADPCM to PCM) so that they become playable by MCD drivers (which only know a limited number of file formats to play, for audio this is almost exclusively: PCM) or transform to a standard format on record.

I would need to look at what commands an MCD driver needs to support but there must be something like OPEN , LOAD and also PLAY. And I seem to remember that either on OPEN , LOAD or PLAY, the MCI driver gets passed a filename or an "hmmio" which is a handle to an already opened audio/video "file" (where "file" can also mean data in memory). Search for "MCI_OPEN", "MCI_LOAD" and "MCI_PLAY" ...

Then, simply spoken, you'd just start the app with that filename (if it is a real file, otherwise you would need to create a temporary file ...). Then, in order to deal with concurrent calls, you need to deal with device IDs and possibly serializing access to that "MCD device" (maybe that replay app can only play one file at a time ...).

And then, in order to easily support multiple different replay apps, it would likely be a good idea to make that configurable via either some INI file or via some settings page in the "Multimedia Object" or some such. There are a few other functions that are mandatory to support (but won't need to do much for the envisaged use case).

And yes, the entry point of such an MCD driver (DLL) always is "mciDriverEntry".

Have a look at this, I think that's a good explanation of somebody who knows:
http://mireality.co.uk/writing/technology/os2-multimedia-chapter/media-control-interface/

By the way: MCD drivers are added via a CARDINFO.DLL resource DLL. It's some work to write one but it's not extremely difficult (maybe there also exists some script approach but I don't know). An example has been the "Timidity MCD" which essentially wrapped the Timidity SW so that you could play MIDI files with a double click.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version