[gstreamer-bugs] [Bug 354590] New: gnomevfssrc fails with radio streams

[GStreamer (bugzilla.gnome.org)]

Do not reply to this via email (we are currently unable to handle email
responses and they get discarded).  You can add comments to this bug at
http://bugzilla.gnome.org/show_bug.cgi?id=354590
 GStreamer | gst-plugins-base | Ver: HEAD CVS

           Summary: gnomevfssrc fails with radio streams
           Product: GStreamer
           Version: HEAD CVS
          Platform: Other
        OS/Version: All
            Status: UNCONFIRMED
          Severity: blocker
          Priority: Normal
         Component: gst-plugins-base
        AssignedTo: gstreamer-bugs at lists.sourceforge.net
        ReportedBy: micxer at micxer.de
         QAContact: gstreamer-bugs at lists.sourceforge.net
     GNOME version: Unspecified
   GNOME milestone: Unspecified


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.


-- 
Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.