[Gstreamer-bugs] [Bug 116185] Changed - [DESIGN] should decoders work when src pad is disconnected?

bugzilla-daemon at widget.gnome.org bugzilla-daemon at widget.gnome.org
Wed Feb 18 18:33:20 PST 2004


Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

http://bugzilla.gnome.org/show_bug.cgi?id=116185

Changed by ds at schleef.org.

--- shadow/116185	Thu Jul 24 03:02:18 2003
+++ shadow/116185.tmp.18204	Wed Feb 18 21:33:20 2004
@@ -1,26 +1,26 @@
 Bug#: 116185
 Product: GStreamer
 Version: 0.6.x CVS
 OS: Linux
 OS Details: RH80
-Status: NEW   
-Resolution: 
+Status: RESOLVED   
+Resolution: NOTABUG
 Severity: normal
 Priority: Normal
 Component: gst-plugins
-AssignedTo: thomas at urgent.rug.ac.be                            
-ReportedBy: thomas at urgent.rug.ac.be               
+AssignedTo: thomas at apestaart.org                            
+ReportedBy: thomas at apestaart.org               
 QAContact: gstreamer-maint at bugzilla.gnome.org
 TargetMilestone: HEAD
 URL: 
 Summary: [DESIGN] should decoders work when src pad is disconnected?
 
 it should check for usability of pads
 
-------- Additional Comments From thomas at urgent.rug.ac.be  2003-06-28 10:16 -------
+------- Additional Comments From thomas at apestaart.org  2003-06-28 10:16 -------
 Created an attachment (id=17855)
 flacdec patch
 
 
 ------- Additional Comments From rbultje at ronald.bitfreak.net  2003-06-29 05:08 -------
 if (!GST_PAD_IS_USABLE) gst_element_error(); or so?
@@ -32,13 +32,13 @@
 I mean, what's the use of an unconnected pad in this case? The
 pipeline still won't do a thing. So?...
 
 GST_PAD_IS_USABLE() is only useful for multi-pad elements such as
 avidemux, mpegdemux etc.
 
-------- Additional Comments From thomas at urgent.rug.ac.be  2003-06-29 08:53 -------
+------- Additional Comments From thomas at apestaart.org  2003-06-29 08:53 -------
 this was discussed a long time ago, check mad and vorbisfile.
 
 The point is that not connecting the src pad allows you to do very
 fast querying of media properties, without actually decoding to the
 raw format.
 
@@ -46,13 +46,13 @@
 lot of sense, and no, it isn't a gst_element_error at all, in fact all
 other plugins need to be fixed in similar ways.
 
 ------- Additional Comments From rbultje at ronald.bitfreak.net  2003-06-29 10:05 -------
 I missed the whole discussion then... Use fakesink.
 
-------- Additional Comments From thomas at urgent.rug.ac.be  2003-06-29 11:34 -------
+------- Additional Comments From thomas at apestaart.org  2003-06-29 11:34 -------
 no, you really did miss the discussion :)
 
 It's already decided that it should work with the decoder not
 connected,  this patch is a matter of implementing that for flacdec,
 just as it has been implemented for mad and vorbisfile.
 
@@ -64,13 +64,13 @@
 
 ------- Additional Comments From rbultje at ronald.bitfreak.net  2003-06-29 11:40 -------
 I don't like this... Ohwell, if you want to do this work, go ahead.
 
 I rest my point that it's just plain ugly.
 
-------- Additional Comments From thomas at urgent.rug.ac.be  2003-06-29 11:56 -------
+------- Additional Comments From thomas at apestaart.org  2003-06-29 11:56 -------
 huh ? what the hell is ugly about it ? it's incredibly clean instead
 of ugly.  You don't connect the decoder's src pad if you have no
 intent of using the decoded data, period.
 
 How else are you supposed to query 1000+ songs for properties quickly ?
 
@@ -105,6 +105,15 @@
 If you want a FLAC metadata extraction plugin, write one. That should 
 be reasonably easy and would offer the great benefit of having the 
 possibility of implementing a subclass that does metadata editing.
 
 btw: both mad and vorbisfile decode the data but discard it when they 
 are unconnected if I'm not mistaken.
+
+------- Additional Comments From ds at schleef.org  2004-02-18 21:33 -------
+I'm closing this, since the current behavior seems acceptable, and
+it's too late to change for 0.8.  If it's really a problem, it will
+come up again.
+
+The current behavior is "drop buffers pushed to unlinked pads".  Note
+that there is a small problem with this -- unlinked pads are not
+negotiated.




More information about the Gstreamer-bugs mailing list