[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 #33 from Thiago Sousa Santos <thiago.sousa.santos at collabora.co.uk> 2013-11-01 22:37:23 UTC ---
I ported tee over and decided to check if performance would be the same. For 2
pads it was the same, but then I tried with 5 pads and the difference was of
about 60s to process 10M buffers.

The pipeline was "fakesrc ! tee ! [queue ! fakesink] * 5"

I used 'time' for measuring it.

I know 10M is too much, even for a 60fps video it would take a 2 day long clip
for going over 10M frames (if my math is correct). In any way, I would prefer
to look for an alternative for a compatible performance.

The issue is that for every GST_FLOW_OK it will iterate over the pads and check
the combination, while most demuxers and tee won't do that as they assume all
other pads are _OK while they are demuxing/looping. They only go over all pads
in NOT_LINKED/EOS cases. I think it makes sense for GstFlowCombiner to do the
same.

Once a _ERROR is received it returns immediately (might store or not this error
for the pad) and then if the user decides to proceed and gets an _OK it would
return _OK. The user decided to ignore the _ERROR, so I think it is ok not to
store this GstFlowReturn and move on.

If we decide to store the _ERROR, then the user must explicitly set a new
flow-return if it decides to move on, this is also ok for me.

Any opinions? Am I being too picky with performance?


Another idea is to have counters for the different flow-returns and
increment/decrement as the returns from the pads change. This way we have
constant combination time, regardless of the number of pads. It adds a little
overhead when setting the flow returns, but this is also constant.

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