Skip to content

audioclock: incorrect time handling for start_time > now after switching from system to audio clock

Submitted by Michael Olbrich @mol

Link to original bug (#768798)

Description

When playing this stream[1], the following happens:

  • The stream starts with video only, so the system clock is used
  • The program in the ts stream changes to add audio
  • buffering triggers state changes
  • the pipeline switches to the clock provided by the new audio sink

The last step causes the problem: If the audio sink is a pulsesink, then 'now' starts at zero and the new base_time would be negative:

pipeline gstpipeline.c:469:gst_pipeline_change_state:<playbin> start_time=0:00:00.075684100, now=0:00:00.000000000, base_time 5124095:34:33.633867516

I'm not sure if such a wrap around is valid, however immediately afterwards comes this:
pulse pulsesink.c:1528:gst_pulseringbuffer_commit:<pulsesink1> need to write 1024 samples at offset 7083549724284064

These samples won't be played for a long time, so once the buffer is full, the pipeline stalls.

I have no idea which component needs to be fixed here.

I can work around this issue by adding an extra offset in GstAudioClock to avoid the issue entirely but I'm not sure if this is correct either.

[1] http://filmrommet.no/film/playlist.m3u8?id=12450%20TR=1%20type=m3u8