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 336951 - Playlist support for gstreamer
Playlist support for gstreamer
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other All
: Normal enhancement
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on: 540890
Blocks: 318309 346262 346840 346948
 
 
Reported: 2006-04-02 18:42 UTC by Lutz Mueller
Modified: 2013-07-17 10:29 UTC
See Also:
GNOME target: ---
GNOME version: Unversioned Enhancement


Attachments
Patch that adds playlist support to Gstreamer (3.40 KB, patch)
2006-04-02 18:49 UTC, Lutz Mueller
none Details | Review
Playlist support for gstcddabasesrc (10.72 KB, patch)
2006-04-02 18:56 UTC, Lutz Mueller
rejected Details | Review
Patch to illustrate the playlist support (19.49 KB, patch)
2006-04-02 18:59 UTC, Lutz Mueller
none Details | Review
Screenshot of the patched seek test application (13.78 KB, image/png)
2006-04-02 19:06 UTC, Lutz Mueller
  Details
Patch to add "playlist" support to gst-launch (3.85 KB, patch)
2006-06-30 06:37 UTC, Lutz Mueller
rejected Details | Review

Description Lutz Mueller 2006-04-02 18:42:18 UTC
Gstreamer currently has no support for playlists.
Comment 1 Lutz Mueller 2006-04-02 18:49:38 UTC
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.
Comment 2 Lutz Mueller 2006-04-02 18:56:10 UTC
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.
Comment 3 Lutz Mueller 2006-04-02 18:59:29 UTC
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.
Comment 4 Lutz Mueller 2006-04-02 19:06:40 UTC
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).
Comment 5 Tim-Philipp Müller 2006-04-02 20:38:28 UTC
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).
Comment 6 Thomas Vander Stichele 2006-04-03 08:51:48 UTC
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.
Comment 7 Tim-Philipp Müller 2006-04-03 10:04:47 UTC
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.
Comment 8 Lutz Mueller 2006-04-03 17:35:39 UTC
(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.
Comment 9 Lutz Mueller 2006-06-30 06:37:38 UTC
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.
Comment 10 Bastien Nocera 2007-05-02 11:49:26 UTC
I posted a comment at bug 346840 comment 11. I'm not sure this is a good idea at all...
Comment 11 Edward Hervey 2009-01-29 09:29:58 UTC
Isn't this supported by the indexing support in cddabasesrc ??
Comment 12 Tobias Mueller 2009-08-11 12:30:48 UTC
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.
Comment 13 Tim-Philipp Müller 2009-08-11 13:00:58 UTC
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.
Comment 14 Sebastian Dröge (slomo) 2011-05-17 08:40:38 UTC
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
Comment 15 Edward Hervey 2013-07-17 10:01:24 UTC
Now that the TOC support is in, should this be closed ?
Comment 16 Tim-Philipp Müller 2013-07-17 10:28:28 UTC
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).
Comment 17 Sebastian Dröge (slomo) 2013-07-17 10:29:08 UTC
I think so, even if this bug is not about playlists but instead about what GstTOC solves :)