[MPlayer-cvslog] r33448 - trunk/gui/mplayer/gui_common.c

Ingo Brückl ib at wupperonline.de
Tue May 10 20:58:08 CEST 2011

Reimar Döffinger wrote on Tue, 10 May 2011 18:38:13 +0200:

> On Tue, May 10, 2011 at 12:59:18PM +0200, Ingo Brückl wrote:
>> Reimar Döffinger wrote on Mon, 9 May 2011 20:33:28 +0200:
>> > On 9 May 2011, at 13:17, ib <subversion at mplayerhq.hu> wrote:
>> >> Author: ib
>> >> Date: Mon May  9 13:17:43 2011
>> >> New Revision: 33448
>> >>
>> >> Log:
>> >> Check for reasonable time values.
>> >>
>> >> Some A/V files don't provide reasonable time information in which case
>> >> the GUI produces a junk dlabel, so set values to zero.
>> > A sample would be a good idea. Also using FFMAX should simplify the code.
>> What exactly do you mean by sample? I have a captured 500 MB wmv live
>> stream, returning a time length of 1844674407365.95508.

> Yes, but why is that so?

That's beyond my knowledge. If I can assist anyhow by preferably not
uploading this huge file...

> This seems likely to be a demuxer bug and it would be a good idea to fix
> that bug and not _only_ "sweep it under the rug".

I certainly have no idea what during the capturing happens. Doesn't all come
from the server that way, so it is its fault?

>> Rather than r33448, I'd like to fix it with the attached patch (revising
>> my suggested [PATCH] Check for reasonable time length), because this patch
>> would solve OSD problems as well as GUI problems, and I could revert
>> r33448.

> I don't particularly like limiting a double value to a int-based one, but
> it might be the best solution.

All the calculated stuff seems to be integer as well.

> Though considering the use-cases INT_MAX would be better than INT32_MAX

Well, 68 years time length seemed enough to me, but people's lifetime
is increasing. ;-) UINT32_MAX is just as well.


More information about the MPlayer-cvslog mailing list