GNOME Bugzilla – Bug 354590
allow seeking in gnomevfs (HTTP) streams
Last modified: 2008-02-18 22:49:57 UTC
To enable seeking in files offered by a UPnP AV server, the parameter GNOME_VFS_OPEN_RANDOM was introduced for the open mode in gnomevfssrc.c:792. Afterwards, seeking in mp3 files was working fine, but if you try to play webstreams, the opening fails because seeking is not available in webstreams. For testing you can use the following pipeline: gst-launch-0.10 gnomevfssrc location=http://shoutcast.accuradio.com:8006/ ! icydemux ! mad ! alsasink For solving this issue, it is needed to check seekability of the source and if that fails to try again without seeking. An even better way would be the following: The gnomevfssrc gets a new parameter (e.g. seek=0/1) and it tries to open the given URI according to the value. The advantage of this would be to enable a UPnP client to ask explicitly for seeking capability of the server so that it receives an error if this isn't supported. A webradio client could skip the request for seeking since it doesn't need any seeking capabilities. For backwards compatibility the gnomevfssrc has to use the mode describe in the previous paragraph when the seek parameter is not present. Can we maybe reuse the iradio-mode? Any comments? Otherwise I would implement it like this and attach a patch for it.
Created attachment 72304 [details] [review] try both modes
Can confirm that gnomevfssrc is pretty badly broken in trunk, and that this patch seems to make it work better. However, with this patch we still have a severe regression from previous versions: connecting to an http server (that doesn't support random access to the resource) now does TWO connections to the server. This is presumably a limitation of gnomevfs, but it might be possible to work around it. I'd suggest backing out the RANDOM-mode patch for this release, and working on getting that to function properly for the next release.
Created attachment 72319 [details] [review] patch to remove the random flag This patch removes the RANDOM flag that was incorrectly introduced with http://webcvs.freedesktop.org/gstreamer/gst-plugins-base/ext/gnomevfs/gstgnomevfssrc.c?r1=1.90&r2=1.91
Note that with the original proposed patch, #331690 will probably be reintroduced (inability to play last.fm streams), for a concrete example. So, I think Wim's patch is better at this point; we can introduce new functionality in the next release, along with a property to control it.
commited to CVS, closing
proposal for adding ability to open in random mode as a new feature
Created attachment 76696 [details] [review] readd optional random access mode + gobject poperty to activate
Please see this thread on the gnome-vfs mailing list: http://mail.gnome.org/archives/gnome-vfs-list/2006-November/msg00006.html Apart the GNOME_VFS_OPEN_RANDOM is also used to hint the underlying file system about the use case: http://mail.gnome.org/archives/gnome-vfs-list/2006-November/msg00007.html
(2nd patch was committed on Sep 7 2006, updating the status so i do not see this one when searching for patches with accepted-commit_after_freeze status)
Created attachment 91228 [details] [review] update patch to not blacklist http, when random-access=true
Created attachment 91674 [details] [review] update patch to not blacklist http, when random-access=true changes to *.h was missing
The introduction of the "random access" parameter is handy, but does it allow for the corner case when the availability of random access is determined by the server's response (the Accept-Ranges header) and we just have to accommodate with or without it? Will the source fail to open if random-access=1 and random access is reported unavailable? If so, can we introduce something akin to random-access=try? (The might call adding something like GNOME_VFS_TRY_OPEN_RANDOM to GnomeVFS.) P.S. Please change the subject to "allow seeking in gnomevfs sources (HTTP)"
Ok, so this is fixed now in gnome-vfs as it actually is a gnome-vfs bug :) While the docs say that one doesn't get seeking when GNOME_VFS_OPEN_RANDOM is not given no module other than http did this in the past but instead allowed seeking always. And then the http module failed to open an URI with _OPEN_RANDOM if the server does not support seeking while instead it should just fail on seeks then. This revision fixes it: http://svn.gnome.org/viewvc/gnome-vfs?view=revision&revision=5446 No changes to gnomevfssrc are necessary at all :)