Edward Hervey f4ba43b15d multiqueue: Add a pad property to "group" streams ... When syncing by running time, multiqueue will throttle unlinked streams based on a global "high-time" and the pending "next_time" of a stream. The idea is that we don't want unlinked streams to be "behind" the global running time of linked streams, so that if/when they get linked (like when switching tracks) decoding/playback can resume from the same position as the other streams. The problem is that it assumes elements downstream will have a more or less equal buffering/latency ... which isn't the case for streams of different type. Video decoders tend to have higher latency (and therefore consume more from upstream to output a given decoded frame) compared to audio ones, resulting in the computed "high_time" being at the position of the video stream, much further than the audio streams. This means the unlinked audio streams end up being quite a bit after the linked audio streams, resulting in gaps when switching streams. In order to mitigate this issue, this patch adds a new "group-id" pad property which allows users to "group" streams together. Calculating the high-time will now be done not only globally, but also per group. This ensures that within a given group unlinked streams will be throttled by that group's high-time instead. This fixes gaps when switching downstream elements (like switching audio tracks).		2016-06-30 14:45:10 +02:00
..
elements	multiqueue: Add a pad property to "group" streams	2016-06-30 14:45:10 +02:00
tracers	tracers: leaks: some micro-optimisations	2016-06-03 14:03:25 +01:00
Makefile.am	tracer: initial prototype for the tracing subsystem	2015-10-05 20:59:39 +02:00