GNOME Bugzilla – Bug 303962
decodebin/typefind can cause premature EOS events
Last modified: 2005-10-06 15:05:23 UTC
Version details: Not using GNOME Distribution/Version: MontaVista Linux If one runs "gst-launch filesrc location=myfile ! decodebin ! fakesink", and if the last typefinder calls gst_type_find_peek() such that the filesrc position is now at the end of a file, an EOS event is triggered before the typefinder element has a chance to reset the filesrc position. This causes the stream to end prematurely. To replicate this bug, compile and install the attached element "dummy". Remove any other existing typefinders (such as /lib/gstreamer-0.8/libgsttypefindfunctions.so) and run gst-register. Now run "gst-launch filesrc location=myfile ! decodebin ! fakesink --gst-debug=dummy:3". The dummy typefinder will associate "myfile" as type "application/x-dummy" and will load the dummy element. However, an EOS occurs before any data can be passed. As a control, comment out the line "gst_type_find_peek(tf, -1, 1);" from the dummy code and recompile the dummy element. Run the above gst-launch command again and note that dummy reports receiving all of "myfile" (via GST_INFO() messages). Note that this issue was found on an ARM port of GStreamer.
Created attachment 46380 [details] dummy filter testcase
A friend has verified this bug on Ubuntu Linux 4.10 on the x86 architecture running gstreamer 0.8.10 and gst-plugins 0.8.8.
Created attachment 47505 [details] [review] updated testcase Hi Mark, Your testcase does not work out of the box for various reasons: * it has no class that decodebin will handle (changed to Codec/Decoder/Video) * it has no rank (changed to PRIMARY) * decodebin plugs to raw (changed src template caps to video/x-raw-yuv) Also, it requires me to remove other typefind functions * set typefind rank to max + 1 Now, it works out of the box. I.e., I can add this to gst/typefind/, make it its own plugin, compile, run gst-register and run your pipeline gst-launch filesrc location=file.png ! decodebin ! filesink location=/tmp/file2.png to see what happens (I don't need a sandbox or anything). typefind will only handle this typefind function (see the logs), type will be found, it plugs the dummy element and filesink links to that. Also see the --gst-debug=typefind:5,decodebin:5,dummy:5 output. All fine so far. $ diff /tmp/file.png /tmp/file2.png $ In other words, all data from file.png was copied nicely to file2.png; no EOS issues or lack of data. Your test case is either invalid (becuase of the above), in which case something else is causing issues; or it is incomplete, in which case I'd hereby like to ask you to update my testcase until it fails. I'll set this bug to NEEDINFO until you've been able to update it.
This bug is fixed in the 0.9 series, with the addition of the getrange() api that typefind uses by default for typefinding. EOS is handled in a similar manner as the unix read(2) call. Closing as FIXED.