[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.
Ingo
More information about the MPlayer-cvslog
mailing list