[Gstreamer-bugs] [Bug 123249] Changed - [PATCH] spider doesn't work with file size smaller than 150 Ko

[bugzilla-daemon at widget.gnome.org]

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=123249

Changed by rbultje at ronald.bitfreak.net.

--- shadow/123249	Sun Oct  5 13:12:21 2003
+++ shadow/123249.tmp.5491	Mon Oct  6 06:02:47 2003
@@ -76,6 +76,45 @@
 (gst_data_unref): assertion `GST_DATA_REFCOUNT_VALUE (data) > 0' failed
  
 
 but instead it doesn't play, and gives me a lot of
  GStreamer-WARNING **: pull on pad filesrc0:src but it is not active
 
+
+------- Additional Comments From rbultje at ronald.bitfreak.net  2003-10-06 06:02 -------
+This is starting to get really annoying...
+
+I've got the fix as far as not to hang the app. However, I cannot get
+spider to understand that it should *properly* EOS *some* elements
+inside it. I just don't understand spider well enough, I suppose.
+
+Issue is as follows: as soon as the typefinder in spider fetches EOS,
+it should typefind with the buffer it has and then push that buffer
+forward, followed by EOS. All this works. However, on EOS, spider
+calls gst_element_set_eos () on all its elements inside it (i.e.
+everything). This is wrong, imo, it should just set it on the first
+element in its own chain of elements.
+
+Anyway, even if I comment that whole part out and just push EOS to
+ident->src in the chainfunc of spider, weird stuff happens. I get
+warnings such as "(process:15180): GStreamer-WARNING **: pull on pad
+mad0:src but it is not active" and fail to understand why from this
+point on. The whole pipeline should be set to EOS, but that doesn't
+happen... This is weird, because I'm following the exact same path
+that a >150kB file would follow, and that still works. I'm really
+missing a point here...
+
+Apparently, I'm badly misunderstanding something here.
+
+What I *think* is going on: everything in spider is one thread, and
+with opt, that kills several things. It means that if I push my buffer
+inside spider and then push another, both will be queued internally
+and, when the loopfunc/chainfunc of spider returns, handled by the
+next element. *However*, spider has then already set EOS on those
+elements, which is why I don't want it to call gst_element_set_eos()
+on its children. But it does, somehow. This is proven by the fact that
+my fix works if I use the basic scheduler instead of the opt one
+(here, every element is its own thread).
+
+Anyway, this is complicated. I don't know how to fix it easily.
+
+Help! ;).