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 654830 - discoverer, uridecodebin, encodebin and multiple audio streams
discoverer, uridecodebin, encodebin and multiple audio streams
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
git master
Other Linux
: Normal enhancement
: 1.1.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2011-07-18 10:16 UTC by Christian Fredrik Kalager Schaller
Modified: 2012-11-20 13:58 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Christian Fredrik Kalager Schaller 2011-07-18 10:16:36 UTC
It is currently quite hard to work with files that have multiple streams of the same type using discoverer and uridecodebin and encodebin, as apart from the technical characteristics there seems to be no way of identified each stream. So especially when two streams are technically identical, ie. mp3 audio. It is a pain to deal with in a 100% safe way.

It would be nice if we could come up with a system where
discoverer could create some kind of unique identifier for each stream
it finds. That way when we am connecting uridecodebin to encodebin or
other elements I can look for the pad with that unique identifier and
connect that, would probably simplify writing applications to handle
this case a lot. If discoverer and uridecodebin where also able to
automatically attach any language information to each stream, based on
tag data etc. that would also be great.
Comment 1 Sebastian Dröge (slomo) 2011-07-18 10:18:08 UTC
This is related to bug #634407, which is about a deterministic pad exposing order for decodebin2.
Comment 2 Stefan Sauer (gstreamer, gtkdoc dev) 2011-07-18 15:35:05 UTC
Shall we keep the discussion to the existing bug?
Comment 3 Christian Fredrik Kalager Schaller 2011-07-18 15:41:25 UTC
ok, I will close this as a duplicate and then paste this bug text into that, as my request is not 'just' about being deterministic, but also about making the API a bit simpler

*** This bug has been marked as a duplicate of bug 634407 ***
Comment 4 Tim-Philipp Müller 2011-07-20 22:21:02 UTC
Well, it's not clear to me that these are the same bugs.

The other bug asks for decodebin behaving deterministically, this bug basically just requires that streams be identified in such a way that one can match identifiers/stream over multiple repeat runs. Not quite the same exactly.
Comment 5 Christian Fredrik Kalager Schaller 2011-07-20 23:03:57 UTC
True, I guess I don't need deterministic behaviour, although deterministic behaviour would let me identify the streams over repeat runs. Would fixing this issue be simpler than achieving detereministic behaviour?
Comment 6 Vincent Penquerc'h 2011-10-06 15:59:52 UTC
It should be a fair bit easier, as it only needs to have each demuxer attach (eg) the index each stream is encountered, or the stream serial number, etc, as (eg) a tag.

It doesn't help much for getting Totem to select the same audio track each time, though.
Comment 7 Christian Fredrik Kalager Schaller 2011-10-07 08:58:38 UTC
Vincent, but if we can come up with a deterministic stream naming system, wouldn't that also help Totem? Because if one can run discoverer and get back a set of stream names, names that can be used to attach to the streams provided by decodebin, then Totem could use that too?
Comment 8 Vincent Penquerc'h 2011-10-07 10:11:31 UTC
Only if you change Totem to use those.
Comment 9 Christian Fredrik Kalager Schaller 2011-12-02 11:20:17 UTC
Vincent are you still looking into this issue?
Comment 10 Vincent Penquerc'h 2011-12-02 12:20:18 UTC
Heh, I never started in the first place :)
Comment 11 Christian Fredrik Kalager Schaller 2012-11-06 10:28:03 UTC
With slomos newish stream identification code it would be great if support for it could be added to discoverer. Being able to identify streams with discoverer and then picking those streams when working later on with uridecodebin is what I need to be able to properly support multitrack audio in Transmageddon.
Comment 12 Sebastian Dröge (slomo) 2012-11-09 11:11:13 UTC
Agreed, support for this should be added to discoverer
Comment 13 Sebastian Dröge (slomo) 2012-11-20 13:58:41 UTC
commit 15ee41dfc9dd4d3dc80cc0a6d2f332aa59284ce2
Author: Sebastian Dröge <sebastian.droege@collabora.co.uk>
Date:   Tue Nov 20 14:56:45 2012 +0100

    discoverer: Add support for getting the stream-id
    
    https://bugzilla.gnome.org/show_bug.cgi?id=654830