debugging a/v-sync issues, possibly inter*-element related
osm-lists at mazdermind.de
Wed Jun 3 04:40:28 PDT 2015
On 03.06.2015 02:45, Nicolas Dufresne wrote:
> Le Tuesday 02 June 2015 à 15:30 +0200, Peter Körner a écrit :
>> My guess is, that there may be a truncation error or sth. the like in
>> the inter* elements, but I may be wrong here. I'm happy to accept
>> Ideas on how to debug this further.
> The inter sink/src element are use to split your stream into multiple
> pipeline. This means, split your stream over multiple clocks, hence not
> synchronization is happening.
I chose that design with inter-Elements so that when a source dies
(someone pulls a plug, for example), the mixer- and output-pipelines
keep running. inter*src fills the gap with black/silence in this case.
Is there another design that would achieve this?
> If you want synchronized playback, keep
> everything in the same pipeline, or considering using a shared clock.
I was under the impression that they would share the same
Nevertheless I created a global Gst.SystemClock and shared them across
all pipelines. I set start_time to CLOCK_TIME_NONE and base_time to a
common value fetched from the clock upon startup, following the example
The result is identical: the audio starts 10ms early on the output,
drifts to beeing equal and drifts on to 30ms late over ~30 minutes playback.
I tested with this example which is self contained, in that it does only
use gstreamer elements to reproduce the issue:
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 473 bytes
Desc: OpenPGP digital signature
More information about the gstreamer-devel