After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 768798 - audioclock: incorrect time handling for start_time > now after switching from system to audio clock
audioclock: incorrect time handling for start_time > now after switching from...
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
git master
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2016-07-14 09:43 UTC by Michael Olbrich
Modified: 2018-11-03 11:47 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Michael Olbrich 2016-07-14 09:43:52 UTC
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
Comment 1 Tim-Philipp Müller 2017-07-12 00:11:00 UTC
Sounds like it would happen with any audio sink, or is it pulsesink specific?
Comment 2 Tim-Philipp Müller 2017-07-12 00:11:21 UTC
Also sounds like it should be possible to make a unit test for it :)
Comment 3 GStreamer system administrator 2018-11-03 11:47:49 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/276.