GNOME Bugzilla – Bug 654830
discoverer, uridecodebin, encodebin and multiple audio streams
Last modified: 2012-11-20 13:58:41 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.
This is related to bug #634407, which is about a deterministic pad exposing order for decodebin2.
Shall we keep the discussion to the existing bug?
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 ***
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.
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?
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.
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?
Only if you change Totem to use those.
Vincent are you still looking into this issue?
Heh, I never started in the first place :)
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.
Agreed, support for this should be added to discoverer
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