GNOME Bugzilla – Bug 776613
Playlist Support
Last modified: 2018-11-03 12:38:51 UTC
This is useful to support remote playlists and other formats than a simple URI/filename list. totem-plparser is rather small and doesn't do much more than the name suggests.
Created attachment 342614 [details] [review] gst-play: Implement playlist parsing optionally via totem-plparser
Shoudn't we instead try to absorb totem-pl-parser into GStreamer somehow?
Yes, we should see bug #478564. I'd rather not have an external dep for gst-play, even if optional.
totem-pl-parser as is has some (optional) external dependencies for e.g. downloading playlists. It would have to be changed a bit to use GStreamer infrastructure for that (libgsturidownloader? :) ). CC'ing Bastien in case he has any thoughts about that.
Is that part needed? (Haven't looked at all yet) I was hoping to get rid of uridownloader and move it into adaptivedemux directly, it's not great API, I don't think we can move that to -base (not to mention that soup is in -good).
If you point totem to http://whatever.com/something.pls, then you need that, yes. I think that's one of the main use cases here, many Internet radios give you a remote playlist.
(In reply to Olivier Crête from comment #2) > Shoudn't we instead try to absorb totem-pl-parser into GStreamer somehow? I'm not sure that the code would be of the expected quality: it has loads of special-cases, might download huge files without a second thought, and some of the parsers might not be as robust as they should be. It also provides 2 additional features. A prober which doesn't do any parsing but can detect whether something might be a playlist (was used in the totem browser plugin), and detect whether specific URLs might point to video websites (using quvi or an external helper via youtube-dl). (In reply to Sebastian Dröge (slomo) from comment #4) > totem-pl-parser as is has some (optional) external dependencies for e.g. > downloading playlists. The dependencies are: - libsoup, hard requirement for downloading from HTTP(s) - libxml, hard dependency but could be made optional, for parsing certain types of playlist, also has a home-grown "this is utterly broken but looks like XML" parser - gmime, optional dep, used for parsing dates in various formats, used for the RSS and Atom parsers - quvi, optional dep, for detecting "video sites", so parsing a video site will point you to the actual video stream - libarchive, used in totem-disc, to detect whether an ISO image is a video DVD, or VCD, etc. - libgcrypt, to parse AMZ files. I might remove that. shared-mime-info is a hard unlisted dependency. totem-pl-parser is one of the reasons I became shared-mime-info maintainer: https://git.gnome.org//browse/totem-pl-parser/tree/plparse/totem-pl-parser.c#n191 > It would have to be changed a bit to use GStreamer > infrastructure for that (libgsturidownloader? :) ). I'd be fine moving some parts of that code to GStreamer, and I would even be happy to help integrate more parsers once the scaffolding is done. But totem-pl-parser probably needs to carry on working, it has functionality that you probably wouldn't want in GStreamer. Ideally, you'd move the playlist parsing (and saving?) code to GStreamer, and I'd use inside the totem-pl-parser API. Bonus points if the parsers with optional deps can be built as plugins, reimplemented in other more secure languages, or sandboxed. Let me know if you have any questions.
Renaming this to be the generic "(How) should we add playlist support to GStreamer" and marking all other playlist related ones as duplicates of this.
*** Bug 346262 has been marked as a duplicate of this bug. ***
*** Bug 346840 has been marked as a duplicate of this bug. ***
*** Bug 478564 has been marked as a duplicate of this bug. ***
*** Bug 346948 has been marked as a duplicate of this bug. ***
*** Bug 588269 has been marked as a duplicate of this bug. ***
-- 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/gstreamer/issues/213.