[Bug 634407] decodebin2 should expose pads in a deterministic order

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=634407
  GStreamer | gst-plugins-base | unspecified

René Stadler <mail> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mail at renestadler.de

--- Comment #11 from René Stadler <mail at renestadler.de> 2011-12-13 00:29:32 UTC ---
I'm playing around with the following solution now:

Defining a new tag GST_TAG_STREAM_ID, of string type and "DECODED" flag (i.e.
not meta data, like the DURATION tag for example). The semantics shall be such
that the tag's value is modified by any element that splits up a stream into
different ones. So demuxers have to care, but not (the usual) decoders. tee
doesn't have to care (splits into identical copies), but deinterleave probably
should.

When a demuxer (or demuxer-like) element forwards the tag to a new branch, it
bases the new value for the tag on the upstream value by appending its own
specific stream id followed by a colon (:). This rule produces values as such:

  "1:", "1:2:", "184917:4374391004:1:9:"

The trailing colon has the benefit of reminding people that it's a string :)
but also allows you to quickly test that "1:2:" is a sub branch of "1:" by
comparing the prefix (otherwise, "1" could be confused with "11", so field
splitting would be required). Not sure if that could be useful to somebody
though.

The local id that an element appends per pad must be unique among all the pads
of course. It also has to be stable across multiple invocations in the same
process (so that you can match ids between runs of discoverer and decodebin).
Stability across the process boundary should not be required; the exact values
are subject to change between different versions of an element for example.

Elements can derive the id in a format specific way. For example in Ogg and
Matroska, there are serial numbers/track UIDs. In general, this means the ids'
lexical sort order does not necessarily match any kind of stream/track order in
the file. The first track could be "5:". Or "28904729847239842398472:".

Implementation wise, most of this can be encapsulated in some small helper
function(s) if sticky events are used. Some kind of tag_list_add_stream_id_uint
(list, sinkpad, my_local_id) perhaps (though should most likely not clutter up
the tag list namespace?). That function can query the upstream value through
gst_pad_get_sticky_event and do the magic to have the given uint value
represented. Other variants for uint64 and string should make sense, or maybe
just a single generic string variant where elements do the formatting on their
own.

This could also be done in 0.10 as well. However this means each demuxer has to
catch tag events to extract and store the upstream id. Also, I guess it is
harder for applications to extract per-stream tag events without sticky events,
so this is a lot less useful (right?).

Any opinions on the colon separator notation? One alternative would be to set
the tag multiple times, and then gst_tag_merge_strings_with_comma would produce
a single value to the application in the end.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.