On Sun, 24 Aug 2014 14:47:45 +0300 (EEST), =?ISO-8859-15?Q?Martin_Storsj=F6?= <[email protected]> wrote: > On Wed, 20 Aug 2014, Anton Khirnov wrote: > > > It allows to configure how long will avformat_find_stream_info() wait > > to get the first timestamp. > > --- > > doc/APIchanges | 3 +++ > > libavformat/avformat.h | 6 ++++++ > > libavformat/options_table.h | 1 + > > libavformat/utils.c | 1 + > > libavformat/version.h | 2 +- > > 5 files changed, 12 insertions(+), 1 deletion(-) > > Looks sensible enough to me. > > > > > diff --git a/doc/APIchanges b/doc/APIchanges > > index 6d1f061..1281667 100644 > > --- a/doc/APIchanges > > +++ b/doc/APIchanges > > @@ -13,6 +13,9 @@ libavutil: 2014-08-09 > > > > API changes, most recent first: > > > > +2014-08-xx - xxxxxxx - lavf 56.02.0 - avformat.h > > + Add AVFormatContext.max_ts_probe. > > + > > 2014-08-xx - xxxxxxx - lavu 54.03.0 - mem.h > > Add av_strndup(). > > > > diff --git a/libavformat/avformat.h b/libavformat/avformat.h > > index 5b29145..923b282 100644 > > --- a/libavformat/avformat.h > > +++ b/libavformat/avformat.h > > @@ -1192,6 +1192,12 @@ typedef struct AVFormatContext { > > int event_flags; > > #define AVFMT_EVENT_FLAG_METADATA_UPDATED 0x0001 ///< The call resulted in > > updated metadata. > > > > + /** > > + * Maximum number of packets to read while waiting for the first > > timestamp. > > + * Decoding only. > > + */ > > + int max_ts_probe; > > + > > /***************************************************************** > > * All fields below this line are not part of the public API. They > > * may not be used outside of libavformat and can be changed and > > diff --git a/libavformat/options_table.h b/libavformat/options_table.h > > index ac052c8..b09bdda 100644 > > --- a/libavformat/options_table.h > > +++ b/libavformat/options_table.h > > @@ -65,6 +65,7 @@ static const AVOption avformat_options[] = { > > {"strict", "strictly conform to all the things in the spec no matter what > > the consequences", 0, AV_OPT_TYPE_CONST, {.i64 = FF_COMPLIANCE_STRICT }, > > INT_MIN, INT_MAX, D|E, "strict"}, > > {"normal", NULL, 0, AV_OPT_TYPE_CONST, {.i64 = FF_COMPLIANCE_NORMAL }, > > INT_MIN, INT_MAX, D|E, "strict"}, > > {"experimental", "allow non-standardized experimental variants", 0, > > AV_OPT_TYPE_CONST, {.i64 = FF_COMPLIANCE_EXPERIMENTAL }, INT_MIN, INT_MAX, > > D|E, "strict"}, > > +{"max_ts_probe", "maximum number of packets to read while waiting for the > > first timestamp", OFFSET(max_ts_probe), AV_OPT_TYPE_INT, { .i64 = 10 }, 0, > > INT_MAX, D }, > > {NULL}, > > }; > > Would e.g. 50 be a better default here, or is that "too long" for actual > streams? 10 at least feels a little on the low side, perhaps 20 if 50 is > too much. (For the cases where one reallly cares about latency and startup > time, one shouldn't be using find_stream_info in the first place - or then > one can lower the thresholds.) >
Hmm. When I was picking the default value, I was mainly thinking about video streams, where 10 frames should be plenty enough to tell you whether you'll ever see any timestamps. But now that you mention this, I suppose it might be too few for tiny audio frames. If you think 50 is a good default, I can use that. -- Anton Khirnov _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
