GNOME Bugzilla – Bug 583030
[flvdemux] reset in pull mode doesn't work
Last modified: 2009-08-01 11:25:08 UTC
Please describe the problem: I am trying to reset the state of a filesrc linked to a flvdemuxer to reuse the flvdemuxer but i get the next message. The first file has 613698 bytes and the second file has 4546420 bytes. 0:00:24.791731770 6981 0x8a26748 WARN GST_SCHEDULING gstpad.c:4362:gst_pad_get_range:<filesrc0:src> getrange failed unexpected 0:00:24.791937104 6981 0x8a26748 WARN GST_SCHEDULING gstpad.c:4474:gst_pad_pull_range:<flvdemux0:sink> pullrange failed unexpected 0:00:24.791996748 6981 0x8a26748 WARN flvdemux gstflvdemux.c:318:gst_flv_demux_pull_range:<flvdemux0> failed when pulling 12 bytes from offset 4546420: unexpected Steps to reproduce: 1. Link a filesrc to a flvdemuxer. 2. Set them to PLAYING. 3. Reset them by setting to NULL and then to PLAYING. Actual results: Get the messages 0:00:24.791731770 6981 0x8a26748 WARN GST_SCHEDULING gstpad.c:4362:gst_pad_get_range:<filesrc0:src> getrange failed unexpected 0:00:24.791937104 6981 0x8a26748 WARN GST_SCHEDULING gstpad.c:4474:gst_pad_pull_range:<flvdemux0:sink> pullrange failed unexpected 0:00:24.791996748 6981 0x8a26748 WARN flvdemux gstflvdemux.c:318:gst_flv_demux_pull_range:<flvdemux0> failed when pulling 12 bytes from offset 4546420: unexpected Expected results: The second file plays from the beggining. Does this happen every time? Yes. Other information:
flvdemux is in -good now (in the current prerelease).
I can't reproduce this here. Could you attach sample code that reproduces this behaviour? I've tried playing a larger file after a smaller and the other way around, reusing the elements and setting the elements to NULL and READY between file changes.
Created attachment 135398 [details] Code that reproduces the bug It uses gstreamer.jni bindings, but is C equivalent.
Hm, unrelated to this bug, the API of those Java bindings doesn't look that nice. It's only static classes with the C API inside them. It's even required to do memory managment by hand by calling unref. Isn't it possible to create Java bindings that look like real Java (i.e. Pipeline pipeline = new Pipeline ("foo") and automatic memory managment by the garbage collector, ...)? Or is something like this the standard way of doing GObject-like bindings in Java? Your code itself looks quite weird though... this could be much simpler :) One thing I'd change would be to install a bus watch and handle EOS from there... the bus watch will be called from the main thread, not the streaming thread. The event probe isn't the correct solution IMHO. Another thing is, that you should a) add all elements to your pipeline and b) only set the state of the pipeline to NULL instead of setting the state of all elements to NULL. I think this could be one of the reasons why it doesn't work. In any case, my test code (C# but should be easy to understand) is at http://pastebin.ca/1435996 and this works just fine. And then you could simply use decodebin(2) for the video decoding part. Could you check if it works if you change your code like this?
I'm closing this as OBSOLETE, since my unit test works fine: commit 6227a6118e803561877b6a8ccbe023c6e53ec5e8 Author: Tim-Philipp Müller <tim.muller@collabora.co.uk> Date: Fri Jul 31 23:28:12 2009 +0100 check: add basic unit test for flvdemux In particular, test re-use of flvdemux in both pull and push mode (see #583030). If you still have problems, please provide a test program in C or python.