[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