mpg4c32.dll codec
Robert Ferraro
I use the mpg4c32.dll for codec for assembling bitmaps into MPEG4 AVI files.
This codec fails on multi-threaded applications running on computers with
hyper-thread enabled or multi-CPU machines.
The mpg4c32.dll version is 4.1.0.3920, dated May 11, 2001, 13:18:14.
Is there a more recent version, or another codec from Microsoft that can be
used in its place?
TIA,
Robert Ferraro.
Chris P. [MVP]
Yes, that codec is known not to work multi-threaded. Microsoft isn't
releasing any updates as they consider it obsolete and no longer support
it.
I think Alessandro once said that he got it to work buy running each
instance as a separate process. I would search the archives of this group
on google groups to be sure it was this codec being discussed at the time.
http://groups-beta.google.com/group/microsoft.public.win32.programmer
Robert Ferraro
of mpg4c32.dll (that apparently creates ASF files) and if so is it freely
downloadable from the Microsoft site?
TIA,
Robert.
"Chris P. [MVP]" <ms...@chrisnet.net> wrote in message
news:103g2440c7p9z$.6m5tdw0cf7jv$.dlg@40tude.net...
Alessandro Angeli [MVP::DigitalMedia]
> Chris, do you know if its possible to use the updated /
> replacement version of mpg4c32.dll (that apparently
> creates ASF files) and if so is it freely downloadable
> from the Microsoft site?
MS gave up on MPEG4 (be it MS or ISO) quite a long time ago
and updates are extremely unlikely. In the meantime however
many MPEG4 encoders were born, all implemented as VCM codecs
like the old MS encoders, so you should be able to make your
applications use a third-party codec easily. Those
third-party codecs, being newer, are even faster, supports
more advanced features, are ISO-compliant and produce better
results. You should look for DivX or XviD (both ISO-MPEG4
SP/ASP codecs) or a recent ffdshow aplha build (which
provides a VFW codec wrapper for encoding that supports many
formats, including ISO-MPEG4 SP/ASP and AVC)
--
// Alessandro Angeli
// MVP :: Digital Media
// a dot angeli at psynet dot net
Robert Ferraro
>>> ...you should be able to make your applications use a third-party codec
easily.
Maybe I don't know where to look, but I've had a problem finding something
as fast/faster than mpg4c32 that's free to use and distribute to customers
buying my application (I'm just not selling enough at this point to pay
royalties for a codec).
Can you suggest something specific that's comparable in quality and also
royalty-free to distribute?
TIA,
Robert Ferraro.
"Alessandro Angeli [MVP::DigitalMedia]" <nob...@nowhere.in.the.net> wrote in
message news:u8ZNmxCI...@TK2MSFTNGP09.phx.gbl...
Alessandro Angeli [MVP::DigitalMedia]
> Maybe I don't know where to look, but I've had a problem
> finding something as fast/faster than mpg4c32 that's free
> to use and distribute to customers buying my application
> (I'm just not selling enough at this point to pay
> royalties for a codec).
>
> Can you suggest something specific that's comparable in
> quality and also royalty-free to distribute?
In my experience, DivX, XviD and ffdshow/VfW are faster and
produce higher quality encodings. XviD and ffdshow are both
open source under the GNU GPL license, which lets you
redistribute them but has some restrictions. On the other
hand, IIRC, the mpg4c32.dll codec can not be redistributed
at all according to the accompanying EULA. With any
ISO-MPEG4 codec, you should also consider the terms of the
MPEG4 license and they may apply to the old MS-MPEG4 variant
as well, unless the codec vendor licensed the codec for you
(which is true for DivX, but not for XviD or ffdshow and I
don't think it's true for MP42 either, in case the license
applies to it).
http://www.mpegla.com/m4v/m4v-faq.cfm
> Chris mentioned that you were able to use mpg4c32.dll on
> multi-threaded applications by running each instance as a
> separate process.
>
> Can you give me an idea of how this is accomplished?
[CUT]
I don't know what post Chris was referring to, however I can
give you 2 suggestions:
1. (this may or may not work, it depends on whether the
codec's DLL uses shared resources or absolute memory
locations) for each instance of the codec you need, make a
temporary copy of the DLL with a different name then do
something like:
HDRVR hDriver
= OpenDriver(L"codec_001",NULL,0L);
HMODULE hModule
= GetDriverModuleHandle(hDriver);
DRIVERPROC fDiverProc
= (DRIVERPROC)GetProcAddress(hModule,"DriverProc");
ICInstall(*(DWORD*)"VIDC",*(DWORD*)"MP42",
(LPARAM)fDiverProc,NULL,ICINSTALL_FUNCTION);
HIC hCodec
=
ICOpen(*(DWORD*)"VIDC",*(DWORD*)"MP42",ICMODE_COMPRESS);
...
ICClose(hCodec);
ICRemove(*(DWORD*)"VIDC",*(DWORD*)"MP42",0);
CloseDriver(hDriver,0,0);
or use ICOpenFunction() instead of ICInstall()+ICOpen() (in
which case, ICRemove() is not needed).
2. (this should always work unless the DLL uses global
shared resources) Create a simple exe that does a single
compression and run as many instances as you need with
CreateProcess(). If you are compressing files, put all the
required code in this exe and pass the necessary parameters
on the command line. If you are compressing streams, read
and write the data through a stream connection (stdio, pipe
or stream socket) or a message-based connection (datagram
socket): the server side of the connection should be opened
by the main application before running the helper exe and
the parameters required to open the client side can be
passed in the command line. In any case, the result/error
can be returned as the process' exit code. As a bonus, if
you use named pipes or sockets, you can even create a
distributed application (over a network, stream sockets are
better while locally datagram sockets are more efficent and
easier to use). Of course, whatever the IPC mechanism you
use, this is a lot slower than having multiple instances of
the codec in the same process.
Robert Ferraro
>>> ...for each instance of the codec you need, make a temporary copy of the
DLL with a different name...
Does this apply when the one application (through various threads) is making
calls to the same codec? In other words, the same application starts many
threads that need the services of the codec...
>>> Create a simple exe that does a single compression and run as many
instances as you need with CreateProcess()...
In this case, it's one exec that's responsible for creating many
threads...does this logic still apply?
TIA,
Robert.
"Alessandro Angeli [MVP::DigitalMedia]" <nob...@nowhere.in.the.net> wrote in
message news:eBcztIQI...@TK2MSFTNGP10.phx.gbl...
Alessandro Angeli [MVP::DigitalMedia]
>> ...for each instance of the codec you need, make a
>> temporary copy of the DLL with a different name...
>
> Does this apply when the one application (through various
> threads) is making calls to the same codec? In other
> words, the same application starts many threads that need
> the services of the codec...
>
>> Create a simple exe that does a single compression and
>> run as many
> instances as you need with CreateProcess()...
>
> In this case, it's one exec that's responsible for
> creating many threads...does this logic still apply?
As far as I recall what was discussed about this codec
before, the problem is not really related to multi-threading
but to concurrent instances so you can not have more than 1
instance in the same process, whether they are used by the
same thread or by many. By instance I mean the handle
returned by ICOpen() or an equivalent usage.
Also, a single instance is not thread-safe (but this is
generally true for other codecs as well) so you need to
guarantee a serialized access to it by using it in a single
thread or protecting it with a mutex or any other thread
synchronization mechanism you like (this can not be
otherwise or you'll end up with a non-predictable output).
Even if you provide a thread-safe usage, this codec will
still not work properly when you open it more than once per
process (the number or threads is irrelevant) in which case
you must either create each instance in a separate process
(the helper exe of solution #2) or load multiple copies of
the codec (which requires to trick the DLL loader as in
solution #1).
A final note, if you use separate helper processes, you can
also usa a shared memory area as IPC mechanism, which is
most likely the most efficient solution (and you can
implement either a streaming or a messaging mechanism).
Robert Ferraro
>>> Also, a single instance is not thread-safe (but this is generally true
for other codecs as well) so you need to guarantee a serialized access to it
by using it in a single thread or protecting it with a mutex or any other
thread synchronization mechanism...
The application is serialized using critical sections. The interesting thing
is the invalid memory reads by mpg4c32 only happen when running the
application on multi-cpu and hyper-thread machines. On my Intel HP board, it
sometimes crashes after a few moments, and at other times browsing the
created files with Explorer triggers the error...
>>> ...you can also usa a shared memory area as IPC mechanism, which is most
likely the most efficient solution (and you can implement either a streaming
or a messaging mechanism)...
Alessandro, I'd like to understand this well enough to try and implement
it...<g> I have no idea how I would use shared memory in this situation...
Best regards,
Robert.
"Alessandro Angeli [MVP::DigitalMedia]" <nob...@nowhere.in.the.net> wrote in
message news:eEpgROpI...@TK2MSFTNGP14.phx.gbl...
Robert Ferraro
positive) results as soon as I'm done.
Best regards,
Robert Ferraro.
"Alessandro Angeli [MVP::DigitalMedia]" <nob...@nowhere.in.the.net> wrote in
message news:umsPIBy...@tk2msftngp13.phx.gbl...
| Robert Ferraro wrote:
|
| >> ...you can also usa a shared memory area as IPC
| >> mechanism, which is most
| >> likely the most efficient solution (and you can implement
| >> either a streaming or a messaging mechanism)...
| >
| > Alessandro, I'd like to understand this well enough to
| > try and implement it...<g> I have no idea how I would use
| > shared memory in this situation...
|
| Here you are a working sample on how to implement a
| message-based IPC mechanism using shared memory.