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 628021 - [baseaudiosink] position reporting not increasing
[baseaudiosink] position reporting not increasing
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other Linux
: Normal normal
: 0.10.36
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2010-08-26 10:00 UTC by Mark Nauwelaerts
Modified: 2011-07-11 09:16 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
basesink: try harder to arrange increasing position reporting (2.26 KB, patch)
2011-07-04 11:46 UTC, Mark Nauwelaerts
committed Details | Review

Description Mark Nauwelaerts 2010-08-26 10:00:09 UTC
... specifically around PLAYING transition (in normal forward playback).

Consider a typical audiosink based on basesink with a larger ringbuffer, e.g. pulsesink.  Let a seek be performed, then the following occurs at (base)sink:
- FLUSH_STOP arrives
- newsegment arrives
- some data arrives, preroll occurs, waits for playing
- state change to playing occurs
- (audio) data is rendered.  However, a typical audiosink bypasses basesink clock syncing, so this data will be rendered immediately (into ringbuffer).
In particular, current_sstart will increase along.
- as long as state change to PLAYING is not yet completed, position is (partially) based on the above, and as such will "shoot forward"
- state change to PLAYING is completed; position reporting now uses clock, and may as such be "smaller" than latest position reported above

As for what to do about it (?):
- never mind about it, only minor "jitter"
- report position in PAUSED only based on segment time:
if no syncing occurs, current_sstart may not be meaningful, and if syncing occurs, current_sstart should not be (much) different from segment time anyway
- track whether syncing actually occurs, and disregard current_sstart if not
- ... ?
Comment 1 Wim Taymans 2010-08-26 13:36:09 UTC
How about setting a flag in the state change function when going to PLAYING and change this:

  if (GST_STATE (basesink) != GST_STATE_PLAYING ||
      GST_STATE_PENDING (basesink) != GST_STATE_VOID_PENDING)
    goto in_pause;

to check the flag instead. While the sink is going to PLAYING, I would guess that we can already start using the clock safely.
Comment 2 Tim-Philipp Müller 2010-10-08 16:56:59 UTC
Anything we can do about this before the upcoming release?
Comment 3 Mark Nauwelaerts 2011-07-04 11:46:03 UTC
Created attachment 191225 [details] [review]
basesink: try harder to arrange increasing position reporting

Should fix this using some flag as suggested above to avoid the in_paused approach when querying position during transition to PLAYING.
Comment 4 Sebastian Dröge (slomo) 2011-07-10 17:30:59 UTC
Comment on attachment 191225 [details] [review]
basesink: try harder to arrange increasing position reporting

Looks good to me
Comment 5 Mark Nauwelaerts 2011-07-11 09:16:33 UTC
commit c8b92755781b652862d7d2a15cfe5860ed8fe2a5
Author: Mark Nauwelaerts <mark.nauwelaerts@collabora.co.uk>
Date:   Mon Jul 4 12:58:54 2011 +0200

    basesink: try harder to arrange increasing position reporting
    
    ... rather than having a momentary decreasing one while transitioning
    to PLAYING.
    
    Fixes #628021.