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

[Michael Niedermayer]

On Mon, Sep 05, 2016 at 06:17:02AM -0400, Ronald S. Bultje 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.

enums are not guranteed to be stored in a specific data type
2 enums could be stored in different data types, one could be int16
one uint32 one int64
that makes using enums with AVOption difficult. (which is why i
used an int)


> 
> > > 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).

Parsers extract all kinds on information like keyframe flags, frame
types and reorder timestamps and so on.
bitstream filters did at least previously not do anything like that

so they are a bit different. But if someone wants to implement or
merge this iam sure happy and this patch can be dropped.

Though that redesign suggested is probably orders of magnitude more
work than the simple patch i wrote here.
Has it been considered if all the advantages and disadvantages
of the old design vs. the new one (+bugfixing and potential merge bugs)
make it worth the work ?

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

Good people do not need laws to tell them to act responsibly, while bad
people will find a way around the laws. -- Plato
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20160905/b21fa276/attachment.sig>