On Sun, 24 Aug 2014, Anton Khirnov wrote:
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.
Even for video, a slightly higher number might be beneficial - many rtmp servers serve the full previous GOP when connecting to a live stream, to allow instant playback instead of waiting for the next keyframe. (They ues a bit of timestamp trickery to do this; they send these packets with DTS=0, but PTS set to negative values, so the decoded sequence of PTS ends up like -300, -200, -100, 0, and then onwards, from the point that the connection was made.) None of that really applies in this case I guess, but the amount of "uncommon" data at the start can be on the order of magnitude of a full GOP.
Before this option exists it behaves as if it was set to infinity, so therefore leaving it slightly higher has less risk of breaking anything we didn't think about.
// Martin _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
