[Bug 744572] New: flowcombiner regressions
GStreamer (GNOME Bugzilla)
bugzilla at gnome.org
Sun Feb 15 11:51:15 PST 2015
Bug ID: 744572
Summary: flowcombiner regressions
Version: git master
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
* 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
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
More information about the gstreamer-bugs