[Bug 744572] New: flowcombiner regressions

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=744572

            Bug ID: 744572
           Summary: flowcombiner regressions
    Classification: Platform
           Product: GStreamer
           Version: git master
                OS: Linux
            Status: NEW
          Severity: major
          Priority: Normal
         Component: gstreamer (core)
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: mnauw at users.sourceforge.net
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

With the introduction of GstFlowCombiner as a helper and so used in lots of
demuxers, quite some of them had a last_flow removed in pad/stream struct data.
 However, so it seems, without replacing all steps and the whole logic that was
involved on these stored GstFlowReturn.  The following has been specifically
seen with avidemux, but other demuxers are potentially affected as well.

The problem is that segment seek is pretty broken as follows:
* segment seek occurs
* data loop advances streams
* if a stream reaches past the end-of-segment (minding keyframe), then this is
internally tracked by returning a GST_FLOW_EOS (but no data is pushed
downstream).  So this EOS is passed to GstFlowCombiner but not stored in the
pad ABI last_flowret (which still registers OK).  So the combined GstFlowReturn
determined by GstFlowCombiner never turns EOS (and loop eventually stops at end
way past segment or a downstream decoder has seen enough and returns EOS).
* so we finally made it past this segment somehow, then a next segment-seek
happens
* last_flow used to be reset at seek time, but the pad ABI last_flowret is
never reset.  So some streams may still assume EOS is reached, and internal
book-keeping is confused (in this case, no data sent for such stream and things
go wrong).

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.