GNOME Bugzilla – Bug 680087
flvdemux: seek in push mode makes it start from beginning
Last modified: 2018-11-03 14:47:06 UTC
I am using Fedora 17, GStreamer 0.10.36 and Good plugins 0.10.31-6. When trying to seek FLV file via HTTP, get following error from flvdemux: "failed to find an index, seeking back to beginning". To reproduce, please open any GStreamer player with GST_DEBUG=flvdemux:3 and open FLV file located in HTTP server.
This issue still exists in git master (1.x). Can be reproduced with e.g.: gst-launch-1.0 playbin uri=http://www.olearygoss.co.uk/videos/Coronation-Road.flv video-sink='navseek ! xvimagesink' and arrow-right. It might just be because there's no index, in which case it should just refuse to seek and continue, however.
So, index is always needed to perform seeking?
That seems like a limitation, note that seeks works within the downloaded portion if using: gst-launch-1.0 playbin uri=http://www.olearygoss.co.uk/videos/Coronation-Road.flv video-sink='navseek ! xvimagesink' flags=video+audio+download Or if it's on-disk. Does this HTTP server support GET range ?
It does not operate in push mode then though, but in pull mode.
Also, I said it *might* be because, I didn't actually investigate, something else might be going on entirely :)
1. If HTTP server does not support GET ranges, we will have another error. 2. We will still get this issue, even if server supports ranges. 3. There is no difference - where we want to seek, in downloaded portion or no. We in push mode.
Also, in terms of GStreamer, how Youtube operates? In pull mode?
(In reply to comment #7) > Also, in terms of GStreamer, how Youtube operates? In pull mode? This decision is not GStreamer related, but if I was to use GStreamer in a Flash player, I'd used pull for HTTP streaming, and push for RTMP (as seeking is handled on server side IIRC), finally embeded streams are not encapsulated so it's a non-issue. Normal Youtube app should not use FLV streams but M4V/MP4 instead.
Hi, We have noticed that for non compliant FLV files i.e. not carrying metadata tag information (index and other useful information) which when played with http results into seeking from the 0th offset position. That's why the desired seek position is not set in this use-case.The approach followed by original native demuxer is to seek back to 0th position in case of non compliant (without index+metadata) while streaming from http. The behaviour is due to non compliant FLV file. The attached patch has modified the behaviour for this specific use-case (http+stream without metadata/index table). Now while in http if seek is issued for older offset (for which playback has already happened), then based on index it comes in effect. And if the desired seek position is very far in positive direction then it waits until it reaches desired position. I think it's an extra feature being provided for non compliant streams and that's too for http. Kindly review the patch and share your observations, Best Regards, Nitin
Created attachment 255793 [details] [review] http_flv_seek_patch
Isn't this a duplicate of bug #674790 ?
Hi Edward, Yes it looks like similar. So the same patch should be able to address it. Looking forward to feedback on patch. Now it doesn't seek to position 0 for push mode http. Regards Nitin
Review of attachment 255793 [details] [review]: Overall I'm not entirely convinced by this patch. If you have a long (say 1 hour) flv ... and you seek to almost the end you'd have to wait for everything to be downloaded, even if the remote server supports range queries. It would make a lot more sense to add scanning as mentionned in bug #674790 . Also this patch seems to remove some pre-existing behaviour. Has this been checked in all other scenarios (pull/push and with/without index) ? ::: gst/flv/gstflvdemux.c @@ +1947,2 @@ + /* parse tag data */ + if (demux->seek_state == FLV_SEEK_STATE_PARSE_TAG_DATA) { seek_state should be initialized in the right location before it can be used. In _demux_cleanup() for example ? @@ +2613,3 @@ } + /* ST rewrite this piece of code to converge the pull mode and push mode seek */ References to private bugtrackers are of no use for people who can't access it. Instead explain what the problem is and why it needs to be fixed this way. @@ -2591,3 @@ demux->seek_event = gst_event_ref (event); - - /* set the building_index flag so that only one thread can setup the Where has this code gone ? ::: gst/flv/gstflvdemux.h @@ +67,2 @@ /* <private> */ + Don't include empty changes.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/issues/67.