[FFmpeg-devel] [PATCH]Improved message for bitrate tolerance too small

[Michael Niedermayer]

On Fri, Feb 01, 2008 at 04:02:42PM +0100, Michel Bardiaux wrote:
> Michael Niedermayer wrote:
> > On Fri, Feb 01, 2008 at 11:01:17AM +0100, Michel Bardiaux wrote:
> >> Michael Niedermayer wrote:
> >>> On Thu, Jan 31, 2008 at 04:26:57PM +0100, Michel Bardiaux wrote:
> >>>>> Note that if someone could explain *why* tol must be > bitrate/fps...
> >>>>> Cheers,
> >>>> Ping?
> >>> IIRC the test is a heuristic, thus the minimum the patch would print isnt much
> >>> better than 2* of that or 0.5* of it. Values that small cause problems.
> >>> So i dont want to make it easy to select the smallest value, because that
> >>> is almost certainly too small.
> >>>
> >> Does that mean you forbid the patch? Because as things stand, we have an 
> >> error condition that can be understood only by looking in the code, talk 
> >> about obfuscated behaviour...
> > 
> > No, your patch obfuscates the code, making the user belive that there would
> > be a minimum which would be ok and below which was not.
> 
> Uh? Basic users are not supposed to see the code. My patch might 
> obfuscate the doc, but not the code. On the contrary, it makes explicit 
> what the code does. That's scruitability, not obfuscation.
> 
> Non-expert users have no alternative to trying higher and higher 
> tolerance values until the error message goes away. Which is exactly 
> equivalent to using the value suggested by my patch. 

As ive already said the minimum is not a good choice. Thus the user has
no need to know or search for it. If he does he is doin something wrong.
The check is just there to catch really non functional values. Its like
a warning sign in the center of a mine field, that is you absolutely never
want to be anywhere close to it.


> Expert users will 
> never see the message.
> 
> > 
> > 
> >> Besides I have another issues with the current code: It is 
> >> mathematically very dubious since it compares a bitrate*timebase with a 
> >> bitrate!
> > 
> > This is not true, as the tolerance is not in bit/sec.
> 
> Not according to ffmpeg-doc.texi ca. line 388.

then the doc is wrong

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

it is not once nor twice but times without number that the same ideas make
their appearance in the world. -- Aristotle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080201/8a5df428/attachment.pgp>