After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 346840 - GStreamer cannot handle buffers of type text/uri-list
GStreamer cannot handle buffers of type text/uri-list
Status: RESOLVED DUPLICATE of bug 776613
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other Linux
: Normal enhancement
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on: 336951
Blocks:
 
 
Reported: 2006-07-07 06:25 UTC by Lutz Mueller
Modified: 2018-05-01 09:19 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Makefile.am (267 bytes, text/plain)
2006-07-07 06:25 UTC, Lutz Mueller
Details
gsturilist.c (1.18 KB, text/plain)
2006-07-07 06:26 UTC, Lutz Mueller
Details
gsturilistdec.h (1.38 KB, text/plain)
2006-07-07 06:26 UTC, Lutz Mueller
Details
gsturilistdec.c (3.63 KB, text/plain)
2006-07-07 06:34 UTC, Lutz Mueller
Details
gsturilistdec.c (3.73 KB, text/plain)
2006-12-20 21:02 UTC, Lutz Mueller
Details
gsturilistdec.c (3.70 KB, text/plain)
2006-12-20 21:05 UTC, Lutz Mueller
Details
gsturilistdec.c (3.99 KB, text/plain)
2006-12-22 20:09 UTC, Lutz Mueller
Details

Description Lutz Mueller 2006-07-07 06:25:14 UTC
Although GStreamer recognizes (and even posts -> id3demux) buffers of type text/uri-list, there is no element that can handle them.
Comment 1 Lutz Mueller 2006-07-07 06:25:54 UTC
Created attachment 68523 [details]
Makefile.am
Comment 2 Lutz Mueller 2006-07-07 06:26:14 UTC
Created attachment 68524 [details]
gsturilist.c
Comment 3 Lutz Mueller 2006-07-07 06:26:46 UTC
Created attachment 68525 [details]
gsturilistdec.h
Comment 4 Lutz Mueller 2006-07-07 06:34:17 UTC
Created attachment 68526 [details]
gsturilistdec.c

This is a small plugin that handles buffers of type "text/uri-list" (i.e. ram-files). It is just a bin that creates an element for each URI.

Related bug reports:
#346262: Bin that adds a pad for each file in a given directory
#336951: Playlist support for GStreamer (stream/pad selection)
Comment 5 Tim-Philipp Müller 2006-07-10 10:18:19 UTC
I don't really see how creating a bin with one source element for each URI makes sense in the usual usage context. Typically you'd want playlist streams/URIs tried one after another, not all the same time. I am not really convinced this is the right way to add 'playlist support', but maybe that's just me.

(I don't think creating an element where you can switch between the URIs in a playlist with a property makes much more sense either right now. We need to find a decent abstraction/mechanism for applications to handle this stuff both ways first IMHO).

Comment 6 Lutz Mueller 2006-07-10 16:16:31 UTC
I agree that we need to find a solution to #336951 (playlist support).

But this element "just works fine" for https://www.tagesschau.de. Adding it now improves user experience with GStreamer and doesn't impact the API. The same applies to #346948 (application/smil).
Comment 7 Lutz Mueller 2006-12-20 21:02:46 UTC
Created attachment 78713 [details]
gsturilistdec.c

NULL-terminate strings before passing them to g_strsplit.
Comment 8 Lutz Mueller 2006-12-20 21:05:50 UTC
Created attachment 78714 [details]
gsturilistdec.c

... and now without g_message...
Comment 9 Lutz Mueller 2006-12-22 20:09:34 UTC
Created attachment 78809 [details]
gsturilistdec.c

Temporarily set state to READY when adding pads in order to suppress a warning because of flushing pads being added to playing elements.
Comment 10 Wim Taymans 2007-05-02 09:35:40 UTC
This could be done like with chanined oggs:

 - add 1 pad with data of first stream
 - when stream finishes (EOS), remove pad (there is some discussion about what to
   do first; send EOS + remove the pad, remove + send EOS, ...)
 - add pad of next stream
 - ...
 - send EOS when out of streams

Comment 11 Bastien Nocera 2007-05-02 11:48:34 UTC
(In reply to comment #6)
> I agree that we need to find a solution to #336951 (playlist support).
> 
> But this element "just works fine" for https://www.tagesschau.de. Adding it now
> improves user experience with GStreamer and doesn't impact the API. The same
> applies to #346948 (application/smil).

This seems like a work-around for an application problem. Totem already has a (LGPL) playlist parser that should be able to do the job. Building the playlist handling directly in GStreamer sounds like it would create more problems than it would solve.

Totem supports M3U, RAM (uri-lists), directories, block devices, iso images, cue files, Google Video Pointers, desktop files, PLS, quicktime (rtsptext/smiltext/medialink), SMIL, ASF, ASX, and XSPF.

I hope you're not planning on implementing all those by hand in GStreamer...
Comment 12 Wim Taymans 2007-08-16 13:38:56 UTC
I see playlist support a little different:

There are some parser elements in gstreamer to typefind and parse the playlist. For each entry a new message is posted. The application builds a list of playable streams from the messages and starts playing them.

This would be at the lowest level, you could build something around this to start playback automatically... dunno, just some idea.
Comment 13 Jan Schmidt 2016-04-14 15:41:18 UTC
I think we should just acknowledge that we're never going to implement this and close as WONTFIX
Comment 14 Tim-Philipp Müller 2016-04-14 15:48:01 UTC
I think we will implement support for playlists at some point, but it's a bigger issue and non-trivial. I don't think we want to just post URIs as messages but perhaps something more structured.

I don't think we necessarily need to keep this bug open though, and I can't see these patches landing in this form.
Comment 15 Edward Hervey 2018-05-01 09:19:39 UTC

*** This bug has been marked as a duplicate of bug 776613 ***