[MPlayer-dev-eng] MNG support for MPlayer

Stefan Schuermans stefan at blinkenarea.org
Tue Sep 16 23:55:47 CEST 2008


Reimar Döffinger wrote:
> On Tue, Sep 16, 2008 at 09:36:42PM +0200, Stefan Schuermans wrote:
>> I'm using the same code in the MNG demuxer now, but it does not work. Can 
>> somebody give me a tip regarding this or point me to the correct place in 
>> the documentation, please?
> 
> There is a hack in libmpdemux/video.c, around line 562 for gif and
> matroska demuxers.

Thank you, that helped me a lot.
I think it's a litle bit odd that one has to put the end time of the 
current frame in the pts member od the demuxer packet to make the frames 
last for the correct durations, but it works now.

I'm not sure what's better now: Adding the MNG demuxer to video.c or 
re-adding the DEMUXER_CTRL_CORRECT_PTS conrol code to demux_mng.c. Both 
solutions seem to work.
What's your preference?

> Note that the gcc-specific __attribute__ stuff without ifdefs etc. is
> not acceptable, if in any way possible the code should compile with any
> compiler that implements C99 (preferably it should also work with C89,
> but that is not important).

I saw this somewhere in the source (e.g. in vidix/ivtv_vid.c), so I 
assumed this was okay to get rid of the warnings about unused 
parameters. I can simply remove the attribute stuff, or construct 
something with #ifdef. What's the MPlayer way of dealing with unused 
parameters?

> Does libmng indeed require that you set the refresh callback even if it
> is of no use for us (and the same for alloc and free, [...])?

Yes, it's needed. The error MNG_NOCALLBACK is reported from the first 
function doing real work if it has not been set.
The alloc and free can be switched to internal memory management by a 
(libmng) compile time define MNG_INTERNAL_MEMMNGMT. However, this does 
not seem to be set in standard libmng packages. (Even if this is set, 
mng_initialize() still takes the two parameters for alloc and free, but 
seems to ignore them. So nothing should break if the libmng package is 
compiled with this option set.)

> Is the seeking feature actually useful for you? It seems like a lot of
> code for something that is likely to not work too well.

Seeking works (not reacting to input until next frame seems to be an 
issue elsewhere in MPlayer). Removing the seeking feature would reduce 
code size only by about 40 lines. I'd like to leave this in, because it 
is quite useful when working with long MNG animations and trying to only 
look at certain parts.

Regards,
Stefan




More information about the MPlayer-dev-eng mailing list