[Bug 665390] New: [pipeline] conflicting element base_time

[GStreamer (bugzilla.gnome.org)]

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

           Summary: [pipeline] conflicting element base_time
    Classification: Platform
           Product: GStreamer
           Version: git
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gstreamer (core)
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: mnauw at users.sourceforge.net
         QAContact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---


Created an attachment (id=202596)
 View: https://bugzilla.gnome.org/attachment.cgi?id=202596
 Review: https://bugzilla.gnome.org/review?bug=665390&attachment=202596

pipeline: only have a top-level pipeline do pipeline time management

Consider a (unusual case of a) pipeline within a pipeline, going ASYNC to
PLAYING (due to e.g. a live src).

Then the top-level pipeline will set up a base_time (to be distributed),
however the contained pipeline will do the same, so we end up distributing that
one's base_time to all elements.  When the pipeline has prerolled and is then
finally going to PLAYING (all the way), the top-level will have it (original)
base_time distributed again.

So, elements end up with conflicting/changing base_time (without intermittent
state change), and afaik this should not happen (and is at least Not Nice).

Problem stems from the ASYNC_DONE state change handling explicitly checking for
a top-level pipeline/bin, whereas the time (etc) manipulation in GstPipeline
happens unconditionally.

Simple patch attached makes the latter also conditional (though not sure if it
needs something more subtle there).

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