[FFmpeg-devel] [PATCH 3/6] lavc: deprecate -ab as part of FF_API_OLD_AVOPTIONS.

[Ronald S. Bultje]

On Fri, Aug 28, 2015 at 6:03 PM, Michael Niedermayer <michael at niedermayer.cc
> wrote:

> On Fri, Aug 28, 2015 at 05:23:44PM -0400, Ronald S. Bultje wrote:
> > Hi,
> >
> > On Fri, Aug 28, 2015 at 5:15 PM, Michael Niedermayer
> <michael at niedermayer.cc
> > > wrote:
> >
> > > On Fri, Aug 28, 2015 at 03:02:47PM -0400, Ronald S. Bultje wrote:
> > > > Hi,
> > > >
> > > > On Mon, Aug 17, 2015 at 9:56 PM, Michael Niedermayer
> > > <michael at niedermayer.cc
> > > > > wrote:
> > > >
> > > > > On Mon, Aug 17, 2015 at 01:38:19PM -0400, Ronald S. Bultje wrote:
> > > > > > Hi,
> > > > > >
> > > > > > On Mon, Aug 17, 2015 at 1:12 PM, Michael Niedermayer
> > > > > <michael at niedermayer.cc
> > > > > > > wrote:
> > > > > >
> > > > > > > On Mon, Aug 17, 2015 at 11:52:16AM -0400, Ronald S. Bultje
> wrote:
> > > > > > > > ---
> > > > > > > >  libavcodec/options_table.h | 2 ++
> > > > > > > >  1 file changed, 2 insertions(+)
> > > > > > >
> > > > > > > googling for
> > > > > > > ffmpeg "-ab"
> > > > > > > has 332.000 matches
> > > > > > >
> > > > > > > ffmpeg "-b:a"
> > > > > > > has 64.100 matches
> > > > > > >
> > > > > > > this patch is simply a bad idea
> > > > > >
> > > > > >
> > > > > > So, there's a few practical problems here. A) if we remove
> flag/mask
> > > from
> > > > > > the set_defaults calls (other patch in this set), the audio is
> also
> > > used
> > > > > > for the video ones (since we ignore media type), and thus we use
> > > (after
> > > > > > FF_API_OLD_AVOPTIONS is 0) the audio bitrate as default for video
> > > also.
> > > > > > That's bad, and causes some fate failures. We can workaround
> that by
> > > > > > inverting the ordering of these two, but then, the general one
> > > _always_
> > > > > > (even before FF_API_OLD_AVOPTIONS=0) takes precedence over the
> audio
> > > one,
> > > > > > so all fate results without explicit bitrate change from ab=128k
> to
> > > > > > ab=200k. (I'm working around that by making each fate test set
> > > bitrate
> > > > > > explicit where relevant.)
> > > > > >
> > > > >
> > > > > > Alternate suggestion: I don't mind if -ab gets a workaround in
> > > ffmpeg.c,
> > > > > > but I'd like to remove it from the libav* code.
> > > > >
> > > > > ffserver seems to have "ab" hardcoded in
> > > > > ffserver_config.c
> > > > > this will need some change too, i dont know the code so i dont know
> > > > > what needs to be done / if a simple change to "b" is sufficient
> > > > > it seems to work with "b" better than with "ab" though after
> > > > > FF_API_OLD_AVOPTIONS=0)
> > > >
> > > >
> > > > This is done now, so are you now OK with this?
> > >
> > > if people want to remove it and it doesnt break anything, yes
> > >
> > > ill add a workaround to ffmpeg.c so this doesnt break command
> > > lines which depend on the default audio bitrate
> >
> >
> > There's other ways to accomplish that. For example, we could add two "b"
> > entries in the AVOptions, one for video, one for audio (I don't think
> this
> > makes sense for other media types?), and assign a default value to each.
> > That still prevents the duplication in ffm header, but keeps
> media-specific
> > defaults. Maybe there's other ways also...
>
> two "b" entries break fate, i did not investigate why


My guess is that ffm header gets two "b" entries per stream instead of one.
We can probably fix that by using mediatype flags/masks when serializing
the ffm header options. That would still break fate, but in a sensible way
(right now it has two audio bitrate entries, it should only have one).

Ronald