GNOME Bugzilla – Bug 336951
Playlist support for gstreamer
Last modified: 2013-07-17 10:29:08 UTC
Gstreamer currently has no support for playlists.
Created attachment 62620 [details] [review] Patch that adds playlist support to Gstreamer This patch adds playlist support to Gstreamer by adding two functions (gst_query_[get,set]_stream) and GST_FORMAT_STREAMS. Basically, you query the number of substreams ("tracks" on a CD) using gst_query_new_duration (GST_FORMAT_STREAMS). Seeking is done accordingly. If you would like to query the duration of the current substream ("track") instead of the duration of the whole stream ("CD"), you need to call gst_query_set_stream (query, substream_number). Patch for gstcddabasesrc to follow separately.
Created attachment 62623 [details] [review] Playlist support for gstcddabasesrc This patch adds playlist support to gstcddabasesrc. GST_FORMAT_TRACKS is replaced by GST_FORMAT_STREAMS. Position and duration is reported for just the track if the query is for a substream only.
Created attachment 62624 [details] [review] Patch to illustrate the playlist support This patch adds a second scale to the existing one for the current substream. The scale above will display the position in the whole stream, the scale below the position in the current substream (i.e. "track"). In addition, you can select the format for querying and seeking. Screenshot to follow.
Created attachment 62625 [details] Screenshot of the patched seek test application This screenshot was taken while running the program seek as follows: ./seek 15 "cdiocddasrc mode=1 ! alsasink" In above scale you see that GStreamer is currently streaming substream (track) 8. The scale below shows the current position in the substream (track).
We can't remove support for the 'track' format from cddabasesrc within the 0.10 series, that's API/ABI breakage (haven't looked at the whole thing yet, just wanted to point this out).
also, I would not use the word "stream". A lot of formats have both the notion of "streams to be played at the same time" (ie. audio + video + subtitles for one track) and "streams to be played one after another" (ie. different chapters in a DVD). The first type is called concurrently multiplexed, the second type is called sequentially multiplexed.
One problem with using queries for this is that it's hard to cascade queries. It may be enough to make your tardec/tardemux work for now, but what if in 6 months someone else comes along who's got a .tar file within a .tar archive ...? (admittedly pure crack, but then some people would have said that some time ago about supporting .tar in GStreamer as well ;)) Also, what about the case where a substream has further substreams? Why should one only be able to select, say, a DVD title via your method, but not also the chapter or angle? Finally, I'm not sure if stream/track/file selection is really the same as 'playlist support'. I don't really know whether it's desirable or makes sense to use the same API for both or not, but I'm fairly sure that you need a bit more for full 'playlist support' than what you propose (for use in playbin, for example). I think a better solution for the time being would be to add a GstWhateverSelection interface and make elements implement that. Elements could post information like filenames via tags on the bus to announce them (we'd probably need a few new tags for that, but for the time being elements could register custom tags of their own). The interface has the advantage that you can cascade elements that implement it (like tardec ! tardec). Also, you might be able to support multiple formats with it, although it might become messy if formats are contingent on other formats (like chapter/angle is on dvd title). I am not really convinced that dvd title selection and cd source title selection needs to be handled via that new interface as well, but that's just me.
(1) Cascading: It is possible to cascade queries. You already (should) do that for each element where bytes_in != bytes_out if you query for GST_FORMAT_BYTES. I am currently working on the tar-in-tar example. (2) Word: I am open for suggestions. "streams", "substreams", "tracks", "chapters", "sections"... Concurrently multiplexed: For these, we have demuxers (with multiple pads). Sequentially multiplexed: This is what I am working on. (3) Hierarchy: Tim, you are right. With my patch, one would know that there are 5 streams. There would be no way of quering the hierarchy (1.1, 1.2, 2.1, 2.2, 2.3). Let me think about it. (4) Interface versus GstQuery: The reason for GstQuery is that you used this approach in cdiocddasrc. My patch is a generalization. I'll think about the interface version.
Created attachment 68206 [details] [review] Patch to add "playlist" support to gst-launch Here's a new approach: Create 1 pad for each stream/track/file/... I've tested it with #346262 (dirsrc): (1) Listing available streams: lutz@lutz:~$ gst-launch-0.10 --list-streams dirsrc location=yy name=dirsrc dirsrc. ! decodebin ! audioconvert ! alsasink dirsrc. ! decodebin ! audioconvert ! alsasink Setting pipeline to PAUSED ... Pipeline is PREROLLING ... Pipeline is PREROLLED ... Available sinks: 1: alsasink1 (of type GstAlsaSink) 2: alsasink0 (of type GstAlsaSink) Setting pipeline to NULL ... FREEING pipeline ... (2) Selecting one stream: lutz@lutz:~$ gst-launch-0.10 --select-streams=alsasink0 dirsrc location=yy name=dirsrc dirsrc. ! decodebin ! audioconvert ! alsasink dirsrc. ! decodebin ! audioconvert ! alsasink Setting pipeline to PAUSED ... Pipeline is PREROLLING ... Pipeline is PREROLLED ... Setting selected element to PLAYING ... (...) This approach could be useful for the TAR plugin (#303975) and could be used to replace the custom GST_FORMAT_TRACKS in the gstcddabasesrc.
I posted a comment at bug 346840 comment 11. I'm not sure this is a good idea at all...
Isn't this supported by the indexing support in cddabasesrc ??
I'm not sure what to make out of this bug. Is playlist support generally accepted as an issue worth implementing? If so, please set to new. If not, please close as WONTFIX. If not know, please raise a discussion on gst-devel to decide that.
Undecided for now, so setting to NEW. Playlist support in general is accepted yes, and there are existing bugs for various aspects of this already. It would probably be good to try and refine the scope of this bug a bit more, and how it relates to the other open (API) bugs.
I'll add a dependency on bug #540890 for this, I still think that as part of full playlist support we want some kind of TOC/stream-selection interface. Partial playlist support can still be done before that, e.g. by doing something like the hls demuxer, which essentially is a playlist demuxer, or by passing parsed playlist as a message to applications... but for it to be really useful we need an interface to control playlist playback from inside GStreamer
Now that the TOC support is in, should this be closed ?
Yes, let's close it. TOC support covers some of it, and there's another bug for playlists somewhere ("move totem playlist parser to gstreamer" or similar).
I think so, even if this bug is not about playlists but instead about what GstTOC solves :)