[gstreamer-bugs] [Bug 559250] New: segments need identifiers.

[GStreamer (bugzilla.gnome.org)]

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=559250

  GStreamer | gstreamer (core) | Ver: HEAD CVS
           Summary: segments need identifiers.
           Product: GStreamer
           Version: HEAD CVS
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gstreamer (core)
        AssignedTo: gstreamer-bugs at lists.sourceforge.net
        ReportedBy: wingo at pobox.com
         QAContact: gstreamer-bugs at lists.sourceforge.net
     GNOME version: Unspecified
   GNOME milestone: Unspecified


Let's imagine you have a pipeline on which you have performed a segment seek.
This pipeline has a queue in it after the demuxer, so the segment-done message
will be normally posted two seconds before the time the last video frame hits
the sinks.

Now, in your mind, start scrubbing this pipeline, performing flushing seeks. If
you seek to within the last two seconds of the segment, corresponding to the
length of the queue, a flushing seek will cause a segment-done message to be
emitted, asynchronously, as the demuxer fills up the queue but reaches the end
of the segment.

The problem comes in on the application side: it gets segment-done messages,
but does not know if they correspond to the *current* segment set by the last
flushing seek, or if it is just receiving stale segment-done messages from the
previous segment.

This is especially pernicious in the normal case in which you want to react to
segment-done messages, for example by performing a nonflushing rewind on the
pipeline. You might rewind in response to a stale segment-done message, when in
reality that message was already "invalidated" by your subsequent flushing
seek.

The solution to this is simple: have identifiers associated with segments, and
pass them along through the events and messages that deal with segments: the
SEEK and EOS events, and the SEGMENT_START, SEGMENT_DONE, and EOS messages.

The application can store the last segment identifier associated with the last
seek that it performed, and react only to segment-done messages corresponding
to the current segment.

I am not sure if GstBin can handle this for us directly; the synchronization
between the seeking thread, the streaming thread, and the thread handling the
messages (normally the seeking thread) is not particularly clear to me.

It would be ideal if the application only got non-stale segment-done messages,
but given the asynchronous queue in the top-level bus, it seems that a seek
would have to filter the queue of unpopped messages -- sounds a bit nasty. For
that reason my current proposal is to handle this in application logic instead,
although suggestions for GStreamer handling this would be ideal.

I'm filing the rationale first, and now will work on a patch. Comments most
appreciated.


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=559250.