GNOME Bugzilla – Bug 346840
GStreamer cannot handle buffers of type text/uri-list
Last modified: 2018-05-01 09:19:39 UTC
Although GStreamer recognizes (and even posts -> id3demux) buffers of type text/uri-list, there is no element that can handle them.
Created attachment 68523 [details] Makefile.am
Created attachment 68524 [details] gsturilist.c
Created attachment 68525 [details] gsturilistdec.h
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)
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).
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).
Created attachment 78713 [details] gsturilistdec.c NULL-terminate strings before passing them to g_strsplit.
Created attachment 78714 [details] gsturilistdec.c ... and now without g_message...
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.
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
(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...
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.
I think we should just acknowledge that we're never going to implement this and close as WONTFIX
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.
*** This bug has been marked as a duplicate of bug 776613 ***