On Mon, 20 Jan 2014, 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 max_delay.
Original report of the issue and initial proposed solution by
[email protected].
Bug-id: 31
Signed-off-by: Anton Khirnov <[email protected]>
---
A revival of a patch from 2 years back.
I've recently encountered this problem again and it's pretty annoying and should
be fixed one way or another.
One thing I'd especially welcome comments about is the use of max_delay for
controlling this behavior. Currently, it's set to -1 (disabled) by default, but
avconv explicitly overrides that to 0.7 sec.
I think sparse stream detection should be enable by default for all callers, not
just avconv. So we could either change the default for max_delay (though that is
also used by some muxers, so it might affect them in undesired way) or use a
new fields for controlling this.
Or maybe someone else has other suggestions?
Indeed - I like the idea in generaly, but 0.7 sec is way too short for
this, there are normal (non-sparse) streams that aren't properly
interleaved by amounts of the same order of magnitude as 0.7 s which the
normal interleaving IMO should be able to handle.
As for what field to use - max_delay is also used by some muxers to
control how much data is buffered up before sending (e.g. for audio
protocols in RTP, this decides how much data can be buffered up into one
packet - if dealing with some sort of realtime setup like voip, one
definitely wants to keep this at something much lower like 0.1-0.2 seconds
or so).
A separate field might be the clearest option, like
max_interleave_difference or so. It's not all fun to add more fields all
the time, but the max_delay field has got too many different overloaded
interpretations already.
// Martin
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
