[MPlayer-dev-eng] MNG support for MPlayer

[Stefan Schuermans]

Uoti Urpala wrote:
> On Mon, 2008-09-15 at 20:48 +0200, Stefan Schuermans wrote:
>> I've now found the "DEMUXER_CTRL_CORRECT_PTS" control call I've been 
>> missing so far and I think I was able to convert the MNG demuxer to 
>> dynamic framerate.
> 
> I'm not sure exactly what you expect it to do, but it's not strictly
> related to variable frame duration. I think it shouldn't affect behavior
> much in this case as there is no decoder delay (unless without it some
> brokenness in the old version happens to trigger).

Okay, so I misunderstood this one. I've taken another look at the GIF 
demuxer. This one works fine without this control code. However, when I 
take this control code out of the MNG demuxer, the MNG file is always 
played with the fixed framerate specified when creating the new video 
stream header.

I think the following code in the GIF demuxer is responsible for setting 
the frame times:
   dp->pts = ((float)priv->current_pts) / 100;
   dp->pos = stream_tell(demuxer->stream);
   ds_add_packet(demuxer->video, dp);
The pts member speicifies the time of the frame in seconds (measured 
from beginning), right?

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?

>>  But I've implemented a minimum framerate of 5 fps 
>> because output shows some odd behaviour if the framerate is much slower, 
>> e.g. when moving X11 output window.
> 
> This is a limitation elsewhere in MPlayer and you should not add such
> workarounds to individual demuxers. If a partial workaround is desired I
> think a two-line change in mplayer.c to limit the amount of time slept
> at once would be enough.

Okay, I understand. I removed this workaround from the MNG demuxer. 
However, now it is a little bit funny to use, e.g. when an MNG frame is 
20 seconds long and a seek is done. Nothing happens until the frame is 
over (e.g. for 15 seconds), then the seek is done. Is this intended 
behaviour, a known issue or another bug in my demuxer?

> A couple of random comments, I haven't read all of the diff:

Thanks, I've fixed those and the issues found by Diego Biurrun in the 
attached version of my patch.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: MPlayer-svn20080916d-mng.diff
Type: text/x-patch
Size: 21277 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20080916/ba3be611/attachment.bin>