[FFmpeg-devel] [PATCH] parseutils: add support for ms and us suffix for AV_OPT_TYPE_DURATION

Aurelien Jacobs aurel at gnuage.org
Sat Mar 3 17:55:20 EET 2018


On Fri, Mar 02, 2018 at 11:28:29PM +0100, Hendrik Leppkes wrote:
> On Fri, Mar 2, 2018 at 11:19 PM, Aurelien Jacobs <aurel at gnuage.org> wrote:
> > On Fri, Mar 02, 2018 at 10:02:58PM +0000, Rostislav Pehlivanov wrote:
> >> On 2 March 2018 at 21:57, Aurelien Jacobs <aurel at gnuage.org> wrote:
> >>
> >> > On Fri, Mar 02, 2018 at 09:39:48PM +0100, Michael Niedermayer wrote:
> >> > > On Thu, Mar 01, 2018 at 09:41:20PM +0100, Aurelien Jacobs wrote:
> >> > > > supported suffixes are:
> >> > > > - s: seconds (default when no suffix specified)
> >> > > > - m or ms: milliseconds
> >> > > > - u or us: microseconds
> >> > > > ---
> >> > > >  libavutil/parseutils.c | 15 +++++++++++++--
> >> > > >  1 file changed, 13 insertions(+), 2 deletions(-)
> >> > >
> >> > > can some of this and the si_prefixes related code in eval.c be
> >> > > factored ?
> >> >
> >> > I've had a look at this, but this would increase code complexity
> >> > in both eval.c and parseutils.c with no advantage, so I deceided not to.
> >> > Anyway, 'u' and 'm' SI prefix are the only ones that make any sense for
> >> > AV_OPT_TYPE_DURATION and supporting more prefix than those "thanks" to
> >> > common code, might add confusion for end user.
> >> >
> >> > BTW, while looking at si_prefixes, I noticed that both 'k' and 'K' are
> >> > supported for meaning "kilo", which is wrong in the SI. Only 'k' is
> >> > a prefix for "kilo", 'K' is a unit for "Kelvin".
> >> > Not sure if there is actually a good reason for having 'K', if it is
> >> > needed for backward compatibility, or if it should be removed...
> >> >
> >> > > either way this LGTM
> >> >
> >> > Great. Applied.
> >>
> >> I think that was a bit premature, I really think "m" should be for minutes
> >> while "ms" should be for milliseconds.
> >
> > What you (or I) think is not relevant here. We are simply implementing
> > an internationnal standard that define precisely what those letters mean
> > so that people all around the world can communicate without ambiguity.
> >
> 
> Why is it not relevant what we think?

Because what is relevant is what the majority of users will understand
the best, whatever their language, culture or education is.

> Who said this has to follow strict SI rules?

Nobody said this, but the fact the SI rules are already used in other
parts of ffmpeg and that nobody suggested any other widely accepted
rules is already a good start.
The fact that SI rules is by far the most widely used unit and prefix
system around the world, and that it is unambiguously defined, makes
it a strong contender I think.

> It should use postfixes which are the most logical and intuitive,

Provided that you can strictly define "logical" and "intuitive" in a
worldwide context...

> when someone reads "5m" he is the most likely to assume minutes, not
> milliseconds.

Not sure what makes you able to know what everybody is gonna assume ?
Personnaly when I read "5m" out of context, I read 5 meters.
With ffmpeg, when I first set SBC delay, I used 0.005 but right after
this I tried 5m by analogy with -b:a 128k where we only use the SI
prefix without unit (ie. we don't write -b:a 128kb/s).


More information about the ffmpeg-devel mailing list