From: GStreamer (bugzilla.gnome.org) <bug...@bu...> - 2007-09-14 11:32:47
|
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. |