[gstreamer-bugs] [Bug 476514] [queue] Doesn't forward EOS event in all cases

[GStreamer (bugzilla.gnome.org)]

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=476514

  GStreamer | gstreamer (core) | Ver: HEAD CVS




------- Comment #15 from Tim-Philipp Müller  2007-09-14 11:32 UTC -------
> Instead, I think wavparse should feel free to ignore any further data it
> receives once it has seen what it thinks is the end of the file, but it should
> definitely not take it upon itself to return UNEXPECTED - it should just pass
> the EOS downstream, and let that shut the pipeline down.

Definitely?  While your suggestion would work of course, I think it would be
unnecessarily limiting in terms of what can be done in future.

I wonder if it might not even be bad from a design point of view, making it
impossible for elements in the pipeline to decide when streaming should stop,
putting this burden onto the application, with all that entails (like shutting
down source first to make it send EOS, then wait for the EOS message before
shutting down the rest of the pipeline etc.).

And what if you have a source that provides data forever? (Not so much an issue
for wavparse, but in general).

I think we should allow for elements in the pipeline to return FLOW_UNEXPECTED
(or a new flow return, don't really care) to signal upstream that processing
should stop now.


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=476514.