[gstreamer-bugs] [Bug 598533] Get stream topology of a bin/pipeline

[GStreamer (bugzilla.gnome.org)]

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

Edward Hervey <bilboed> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |
            Summary|[decodebin2] Post element   |Get stream topology of a
                   |message with the stream     |bin/pipeline
                   |topology on the bus         |

--- Comment #9 from Edward Hervey <bilboed at gmail.com> 2009-10-28 11:47:25 UTC ---
Right now, applications who want to know the following information about a URI
need to write a lot of code:
* How many streams does it have ?
* What kind of streams (audio/video/text/private/...) does it have ?
* What are the various properties of those streams (ex : for video, what's the
width/height/framerate/par/interlacing/native-colorspace/...)
* What's the container format (in GstCaps and not in mystical string tags
coming from somewhere) ?
* What are the codecs used in each stream (same comment as for containers) ? 
* What's the duration of the URI ?
* What are the tags used ?

In PiTiVi and some other gst-python-based applications, we have at least the
discoverer which helps a little bit, but it's not usable from non-python
applications.

All that information can be used for many different use-cases (ranging from
simple to more advanced):
* Desktop information (hover/right-click over the file to get the multimedia
info)
* Playback systems (in order to show a lot more information)
* Application doing decision making based on the type of streams available
and/or require the duration (tools using gnonlin that need to know which
streams are available and can use, and what the duration is)
* Trans-coding/trans-muxing so you can use the information to create the proper
encoding/muxing elements behind

Other side effects:
* Have a *unique* way of describing the container format and the codec formats
being used, since you get the *actual* caps and you can then use gstpbutils,
instead on relying on elements to provide a string (which they might not do, or
they might do differently, ...).
* If you have such a topology... you can then create a pipeline that can
encode/mux files that will end up being (closely) similar, by taking that
topology tree and reverting it (i.e. source becomes sink, demuxer becomes
muxer, ...).


Right now, there is only one thing which is non-trivial to get from the list at
the top of this comment, and that is the stream topology of a URI.

I thought that since decodebin2 is already constructing a consequent part of
the pipeline, we could just have it store that information and emit it as a
message.
The problem is:
* people are complaining about the uglyness of this
* GstStructure is a serious PITA to work with, and even more so when you start
having nested structures


So what I propose instead is a generic API to be able to get the stream
topology of a GstBin (and therefore a GstPipeline).
The idea is to end up with a tree-like structure/object that applications or
other libraries can then re-use to accomplish the goals stated at the top of
this comment.

I'd like to state that this can not be done for all pipelines, but only for
pipelines that have branching-out-only topologies, or mixing-in-topology (i.e.
pipelines like src ! demuxer ! many decoders !..., or many streams ! muxer !
sink). So any pipeline whose stream structure can be represented as a tree.
Trying to achieve this stream topology for any kind of pipeline would mean
creating a system that allows branching-then-mixing-back structures :(

Why STREAM topology (and not just topology) ?
* Because it would only contain the chain of identical caps, and where they
split-up/aggregate, but NOT the elements. If you want the topology of the
elements... you can just iterate the elements in a pipeline.

------
A proposed API could be the following:

struct GstStreamInformation {
  GstStreamType         streamtype;  // simple stream or container
  GstCaps              *caps;        // the caps of the stream
  GstStreamInformation *previous;    // The upstream stream (can be NULL)
  GstStreamInformation *next;        // The downstream stream (can be NULL)
};

struct GstStreamContainerInformation {
  GstStreamInformation  parent;
  GHashTable           *streams;     // the streams this container provides
                                     // or aggregates
                                     // key : unique key (can be pad name)
                                     // value: GstStreamInformation*
}

/**
 * gst_bin_get_topology:
 * @bin: a #GstBin
 * @topology: Will contain a pointer to the topology if successfull
 *
 * Gets the topology of the bin.
 * 
 * Returns: TRUE if the topology could be determined, else FALSE
 */
gboolean gst_bin_get_topology (GstBin * bin, GstStreamInformation **topology);
------

-- 
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.