[Bug 564749] tagreadbin + GstTagReader interface

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Sun Sep 23 12:26:26 PDT 2012


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

--- Comment #30 from Tim-Philipp Müller <t.i.m at zen.co.uk> 2012-09-23 19:26:23 UTC ---
I don't know why it got linked from the LWN article, I'm pretty sure I didn't
mention it in my talk, and the context was also not quite right (it was
developed for Nokia ages ago, and not for any MeeGo IVI stuff, though of course
I'm happy if they find it useful).

It's still current in the sense that tag-reading is still not as good as it can
be, and tagreadbin's approach is better and faster for most cases than what
discoverer does currently. There are other open issues which neither tagreadbin
nor discoverer solve.

However, for the time being discoverer is the only game in town and I don't
expect this to change anytime soon, there are more interesting things to do. It
shouldn't be too hard to teach discoverer the approach tagreadbin uses (e.g.
don't plug decoders unless absolutely needed), all the groundwork for that has
been done (oggdemux, plugging parsers, etc.). Tagreadbin is also much smarter
about tag aggregation (stream tags vs. global/demuxer tags), but that's
something that should be much easier in 1.0 now that we make those explicit.

The main issue on the metadata front is reliability of the duration (and/or
bitrate) estimates, IMHO, so a metadata reader can know whether to stop or
whether to wait a bit longer for a better estimte, in cases where the duration
can't be determined in a reliable way from the headers and/or index.

So anyway, nothing to see here, move along :)

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


More information about the gstreamer-bugs mailing list