[Bug 768798] New: incorrect time handling for start_time > now after selecting a new clock

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=768798

            Bug ID: 768798
           Summary: incorrect time handling for start_time > now after
                    selecting a new clock
    Classification: Platform
           Product: GStreamer
           Version: git master
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: don't know
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: m.olbrich at pengutronix.de
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

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

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.