[gstreamer-bugs] [Bug 564749] tagreadbin + GstTagReader interface

[GStreamer (bugzilla.gnome.org)]

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

--- Comment #23 from Tim-Philipp Müller <t.i.m at zen.co.uk> 2010-03-31 11:46:18 UTC ---
Quick update: a few comments and what's left to do:

 - First off: tagreadbin vs. gst-discoverer:
   both do sort of similar things, and even use a similar
   approach to how they do it, but they are targetted at
   different use cases: gst-discoverer tries to get the
   full picture, with full reliability, for transmuxing/coding
   purposes; it will usually plug decoders. Tagreadbin
   on the other hand tries to get just the metadata as
   fast as possible. It aims to work without decoders at
   all, so that metadata can be extracted whether the
   appropriate codecs are installed or not. Both
   approaches could be combined, but I don't think this
   is desirable or useful at this point. We should proceed
   with both separately, optimise them for their respective
   use cases and then look at combining them at a later
   point (or 0.11). There's quite a bit of potential for, err,
   synergy though, see the interface discussion below.

 - left to do: oggdemux needs to extract tags from the
   stream headers (or vorbisparse/theorparse etc. need
   to implement the interface, but I think oggdemux
   should just extract the tags - that makes it behave
   more like a normal container, and it shouldn't be hard
   to do since the stream stuff is already in place now
   after the recent changes in oggdemux). Fairly minor
   task.

 - I'm not 100% happy with the GstTagReader interface
   yet. As a reminder, it serves two purposes:

      a) to configure elements into tag reading mode or
          tag skipping mode, so they can avoid expensive
          operations that aren't needed (like index parsing,
          for example). decodebin2 and uridecodebin
          implement this interface and will proxy the
          settings to children they plug. tagreadbin is a
          top-level pipeline that internally uses a
          uridecodebin that is configured in tag reading
          mode. This aspect is less important now that the
          major demuxers (avidemux, qtdemux) have been
          optimised for fast start-up, but see below for how
          this can still be useful.

      b) to selectively plug parsers or other elements that
          are deemed suitable for tagreading purposes, but
          that usually wouldn't be plugged for playback, for
          whatever reason (not needed, messes up sync,
          not trusted/tested enough yet). The registry
          stores the interfaces an element implements, and
          tagreadbin will (via decodebin2) prioritise a tagreader
          element over any decoder/other element during the
          autoplug-select process.

    One of the problems we have in GStreamer in general
    when reading metadata is that the application has no
    idea how reliable the various bits of information are, nor
    has it got a way to tell the plugins what it cares about
    or not. This means it's hard for an application to get a
    good/reliable duration reading or bitrate estimation for
    VBR files, for example, if it cares about such things. This
    is also a problem that gst-discoverer and its users face,
    if I'm not mistaken. The tagreader interface doesn't solve
    that (yet), but I think it could go in that general
    direction, ie. a way for an app to configure plugins what
    they care about and what not, a bit like an ACCURATE flag
    for duration estimation or bitrate estimation, for example
    (there's also the DONTCARE case of course).

    In any case, I'm currently leaning towards separating
    the two above-mentioned functions of the tagreader
    interface, so that it could be a more general
    GstMetaDataAndOrTagExtractionModeConfigurationInterface
    kind of thing (I'm sure we can think of something more
    snappy). Elements (e.g. parsers) could then implement
    this if they want to, without that affecting their
    autoplug-or-not status in tagreadbin. I believe this
    might also be useful for gst-discoverer.

    The autoplug aspect could then be handled either by an
    entry in the elementfactory klass (Tagreader or somesuch)
    or a separate interface.

    Should we go that way (more generic interface + separate
    shibboleth for tagreadbin), we don't need to decide on
    all the API now, just the name of the interface and how
    to set the element into tag-reading/skipping mode,
    although even that we don't absolutely *need*, we could
    just go ahead with just the autoplug klass marker and
    not do the interface for now.

    Having said all this, the current implementation seems
    fine too, and the estimation/reliability problems that
    I mentioned above could be handled entirely client side
    e.g. by additional query API like a _query_duration_full()
    that would also return the reliability or somesuch, then
    the caller can decide to continue parsing until it gets
    a better estimate based on that.


Thoughts? Favoured approaches?

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