[Bug 709224] audio/videodecoder: Not returning GST_FLOW_EOS when after segment

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=709224
  GStreamer | gst-plugins-base | git

--- Comment #34 from Tim-Philipp Müller <t.i.m at zen.co.uk> 2013-11-01 23:05:36 UTC ---
Generally looks fine to me (thanks for reworking this!), but I still have a
nagging feeling that it could be even better.

Some random comments:

 - in the commit message: GstFlowReturnCombiner -> GstFlowCombiner

 - FLOW_FLUSH aggregation should be documented in docs chunk too

 - gst_flow_combiner_update_flow_return() - quite long, how about
   just _add_flow() or _combine_flow()?

 - gst_flow_combiner_get_flow_return(): do we really need to iterate over
   all pads every time? Can't we store the last aggregated flow return and
   combine that with the new one in most cases?

 - all this hashtable stuff irks me a little, even if it's just an internal
   implementation detail.

 - wonder if it shouldn't go into gstpad.c as GstPadFlowCombiner, then we
   could just use the GstPad private struct and store the last flow there ;)
   (or we could do that anyway via some internal helper funcs if we wanted to)

 - another idea: I think most elements (esp. demuxers) have a derived pad or
   pad-related stream structure which they operate on, so they could store
   some kind of GstFlowCombinerPadID in there as well. You could hand those
   out when the demuxer/element does _add_pad(), and it could just be a
   counter or whatever (just typedef it to guintptr then it can be anything
   in future), then you don't need the hashtable and can just do pads[i]
   inside the flow combiner, etc.

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