On 04/02/14 13:59, Anton Khirnov wrote:
> From: Luca Barbato <[email protected]>
>
> Currently ff_interleave_packet_per_dts() waits until it gets a frame for
> each stream before outputting packets in interleaved order.
>
> Sparse streams (i.e. streams with much fewer packets than the other
> streams, like subtitles or audio with DTX) tend to add up latency and in
> specific cases end up allocating a large amount of memory.
>
> Emit the top packet from the packet_buffer if it has a time delta
> larger than a specified threshold.
>
> Original report of the issue and initial proposed solution by
> [email protected].
>
> Bug-id: 31
> Signed-off-by: Anton Khirnov <[email protected]>
> ---
> doc/APIchanges | 4 ++++
> libavformat/avformat.h | 18 ++++++++++++++++++
> libavformat/mux.c | 35 +++++++++++++++++++++++++++++++++--
> libavformat/options_table.h | 1 +
> libavformat/version.h | 4 ++--
> 5 files changed, 58 insertions(+), 4 deletions(-)
>
> diff --git a/doc/APIchanges b/doc/APIchanges
> index e4bd6d8..a64962b 100644
> --- a/doc/APIchanges
> +++ b/doc/APIchanges
> @@ -13,6 +13,10 @@ libavutil: 2013-12-xx
>
> API changes, most recent first:
>
> +2014-02-xx - xxxxxxx - lavf 55.11.0 - avformat.h
> + Add AVFormatContext.sparse_stream_threshold for controlling the detection
> of
> + sparse streams.
> +
> 2014-01-xx - xxxxxxx - lavc 55.32.1 - avcodec.h
> Edges are not required anymore on video buffers allocated by get_buffer2()
> (i.e. as if the CODEC_FLAG_EMU_EDGE flag was always on). Deprecate
> diff --git a/libavformat/avformat.h b/libavformat/avformat.h
> index 00380d7..fddce00 100644
> --- a/libavformat/avformat.h
> +++ b/libavformat/avformat.h
> @@ -1002,6 +1002,24 @@ typedef struct AVFormatContext {
> */
> int debug;
> #define FF_FDEBUG_TS 0x0001
> +
> + /**
> + * The threshold (in microseconds) for detecting sparse streams when
> + * interleaving -- muxing only.
> + *
> + * To ensure all the streams are interleaved correctly,
> + * av_interleaved_write_frame() will wait until it has at least one
> packet
> + * for each stream before actually writing any packets to the output
> file.
> + * When some streams are "sparse" (i.e. there are large gaps between
> + * successive packets), this can result in excessive buffering.
^ drop it.
The rest looks fine.
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel