[gstreamer-bugs] [Bug 628021] New: [baseaudiosink] position reporting not increasing

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=628021
  GStreamer | gstreamer (core) | git

           Summary: [baseaudiosink] position reporting not increasing
    Classification: Desktop
           Product: GStreamer
           Version: git
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gstreamer (core)
        AssignedTo: gstreamer-bugs at lists.sourceforge.net
        ReportedBy: mnauw at users.sourceforge.net
         QAContact: gstreamer-bugs at lists.sourceforge.net
      GNOME target: ---
     GNOME version: ---


... 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
- ... ?

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.