On Mon, Sep 05, 2016 at 06:17:02AM -0400, Ronald S. Bultje wrote:
> Hi,
>
> On Sep 5, 2016 12:05 PM, "Michael Niedermayer" <mich...@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" <mich...@niedermayer.cc>
> > > wrote:
> > > >
> > > > TODO: version bump, docs
> > > >
> > > > Signed-off-by: Michael Niedermayer <mich...@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
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
