[FFmpeg-devel] [PATCH] -fs parameter human friendly

Stefano Sabatini stefano.sabatini-lala
Thu Aug 21 15:30:07 CEST 2008

On date Wednesday 2008-08-20 19:15:25 -0400, The Wanderer encoded:
> Michael Niedermayer wrote:
> > On Tue, Aug 19, 2008 at 10:26:59PM -0400, The Wanderer wrote:
> > 
> >> Michael Niedermayer wrote:
> >>> what?
> >> 
> >> I would read this as meaning "if a value does not have the 'B'
> >> suffix, it is assumed to be expressed in bits; if it does have that
> >> suffix, it is assumed to be expressed in bytes". The current
> >> phrasing seems relatively clear to me (even in my current mildly
> >> bleary state of mind), although I would say "in which case" instead
> >> of "in this case".
> > 
> > its not a issue of grammer, its a issue of (av_)strtod parsing a
> > string and returning a double. Simply try to awnser if "3.141593" is
> > in bits or bytes according to this description. It simply makes no
> > sense, the number is not in bits nor in bytes. Nor does either of
> > them have any meaning here
> Point. I didn't actually consider that aspect, or read the code closely
> (just the comments). If I had, I would have been inclined to assume that
> any value received which had a non-integer portion would be an
> indication of a bad input string. Under this scenario, the use of
> av_strtod would be simply because of the absence of any other known
> existing-and-approved way of translating a (portion of a) string to a
> numeric value.
> >>> numer!? bits?
> >> 
> >> "number", obviously - and I interpret this as meaning that the
> >> return value will always be expressed in bits, no matter what units
> >> the input string used for its number.
> > 
> > double pi= av_strtod("3.1415927", NULL); is in units of bits?
> Either that or an error condition.
> Or at least you could interpret and define things that way - it could
> equally easily be exactly the kind of problem you're apparently
> considering it, in which case there's no point in my having spoken up in
> the first place.

Well we can also treat B as a multiplier like the other ones (M, Mi,
G, Gi, etc) with the only exception which it can be appended to the
other ones (MB, MiB, GB, etc).

So it makes sense to define for example:
3.1415927B = 3.1415927 * 8

although I practically can't see any example where this could make

Anyway I consider this patch frozen until when eval will be exported,
which is a precondition for this patch.

FFmpeg = Foolish and Forgiving MultiPurpose Evanescent Gospel

More information about the ffmpeg-devel mailing list