[FFmpeg-devel] [PATCH] avformat: Allow forcing use of AVParsers

Ronald S. Bultje rsbultje at gmail.com
Tue Sep 6 03:03:55 EEST 2016


Hi,

On Mon, Sep 5, 2016 at 6:52 AM, Paul B Mahol <onemda at gmail.com> wrote:

> On 9/5/16, Ronald S. Bultje <rsbultje at gmail.com> wrote:
> > Hi,
> >
> > On Sep 5, 2016 12:05 PM, "Michael Niedermayer" <michael at niedermayer.cc>
> > wrote:
> >>
> >> On Mon, Sep 05, 2016 at 05:25:14AM -0400, Ronald S. Bultje wrote:
> >> > Hi,
> >> >
> >> > On Sep 5, 2016 11:18 AM, "Michael Niedermayer" <michael at niedermayer.cc
> >
> >> > wrote:
> >> > >
> >> > > TODO: version bump, docs
> >> > >
> >> > > Signed-off-by: Michael Niedermayer <michael at niedermayer.cc>
> >> > > ---
> >> > >  libavformat/avformat.h      | 8 ++++++++
> >> > >  libavformat/options_table.h | 1 +
> >> > >  libavformat/utils.c         | 3 +++
> >> > >  3 files changed, 12 insertions(+)
> >> > >
> >> > > diff --git a/libavformat/avformat.h b/libavformat/avformat.h
> >> > > index 3ee7051..33b921a 100644
> >> > > --- a/libavformat/avformat.h
> >> > > +++ b/libavformat/avformat.h
> >> > > @@ -1886,6 +1886,14 @@ typedef struct AVFormatContext {
> >> > >       * - decoding: set by user through AVOptions (NO direct access)
> >> > >       */
> >> > >      char *protocol_blacklist;
> >> > > +
> >> > > +    /**
> >> > > +     * Force parsing.
> >> > > +     * - encoding: unused
> >> > > +     * - decoding: set by user through AVOptions (NO direct access)
> >> > > +     */
> >> > > +    int force_parsing;
> >> > > +
> >> > >  } AVFormatContext;
> >> > >
> >> > >  int av_format_get_probe_score(const AVFormatContext *s);
> >> > > diff --git a/libavformat/options_table.h
> b/libavformat/options_table.h
> >> > > index 3b74d1b..359796c 100644
> >> > > --- a/libavformat/options_table.h
> >> > > +++ b/libavformat/options_table.h
> >> > > @@ -103,6 +103,7 @@ static const AVOption avformat_options[] = {
> >> > >  {"format_whitelist", "List of demuxers that are allowed to be
> used",
> >> > OFFSET(format_whitelist), AV_OPT_TYPE_STRING, { .str = NULL },
> >  CHAR_MIN,
> >> > CHAR_MAX, D },
> >> > >  {"protocol_whitelist", "List of protocols that are allowed to be
> > used",
> >> > OFFSET(protocol_whitelist), AV_OPT_TYPE_STRING, { .str = NULL },
> >  CHAR_MIN,
> >> > CHAR_MAX, D },
> >> > >  {"protocol_blacklist", "List of protocols that are not allowed to
> be
> >> > used", OFFSET(protocol_blacklist), AV_OPT_TYPE_STRING, { .str = NULL
> },
> >> > CHAR_MIN, CHAR_MAX, D },
> >> > > +{"forceparsing", "force use of AVParsers", OFFSET(force_parsing),
> >> > AV_OPT_TYPE_INT, { .i64 = -1 },  -1, AVSTREAM_PARSE_FULL_ONCE, D },
> >> > >  {NULL},
> >> > >  };
> >> >
> >> > Why int?
> >>
> >> what else ?
> >> a flag doesnt work as AVStreamParseType has more than 1 value
> >
> > An enum would be nice.
> >
> >> > At vdd, we discussed parsers, maybe we should sync on that because I
> >> > believe it makes this unnecessary.
> >>
> >> not sure i understand what you suggest ?
> >
> > Anton expressed interest in merging parsers and bitstream filters. I
> > believe they are (other than semantically) identical in goal, and the
> > semantic difference is sometimes violated already. If you think of them
> as
> > bitstream filters, we could merge their functionality with auto-insertion
> > of BSF. It was proposed that we could go one step further and do parsing
> > not in the demuxer step (av_read_frame), but before the decoder (which
> is a
> > change) and in the muxer (which we already do). Auto-insertion mechanisms
> > would be shared and this would lead to interesting new features that
> > someone demuxing a mpeg system stream or vp9/divx-with-packed-b-frames
> > using external tools (which don't split/reframe) but using avcodec
> decoders
> > would still see it work. On the other hand, people using lavf to demux
> such
> > streams would not need to merge (divx/vp9) before muxing, making that
> > process more efficient (using lavf) or less buggy (using non-lavf
> muxers).
>
> Are you telling that using non-lavf muxers is less buggy?


No.

Just that people are using it like that (sometimes).

Ronald


More information about the ffmpeg-devel mailing list