[gst-devel] tags and metadata

Thomas Vander Stichele thomas at apestaart.org
Tue Jan 20 09:27:06 CET 2004


Hi,

so this week I want to get started fixing media-info and
nautilus-media.  There are a lot of regressions due to the tag additions
and the streaminfo/metadata depreciation.

I am not 100% sure that the current framework allows us to fix these
MUSTFIX issue for GNOME 2.6

I'll start by explaining how the old system that was replaced by GstTag
used to work.

There were basically three kinds of "data about the data":
- metadata (for lack of a better term) was the data describing the
actual content of media streams.  This was for things like artist,
title, album, year, ... This data usually lives in the container format,
not in the encoded data, and hence is changeable without having to
modify the actual data stream.  This sort of data is generally detected
in demuxers/tag extractors.

- streaminfo was the data describing the technical parameters of the
ENCODED data.  This was for things like bitrate (average/nominal/...),
codec, encoder version, layer (for mpeg), ... The only way to change
this is to change the actual data stream by either transcoding, or (for
some codecs) using hacks like bitpeeling.  This sort of data is
generally detected in the decoder.  Some of this data might even be
variable through the stream.  Some of this data might also be used in
caps nego (for example, mad has the layer as a property, though on
negotiating it seems to always be set to 1 !)

- format was the data describing the technical parameters of the DECODED
data.  This is for things like channels, bit depth, sampling rate, ... 
The only way to change this is by resizing the decoded audio and
re-encoding (again, it is theoretically possible to hack in workarounds
that for example convert stereo to mono in the frequency domain).  This
sort of data is generally detected in the decoder, and available in
GStreamer as negotiated caps on the pads.

So, on with the questions.

The old "streaminfo" has been completely removed, with no mechanism to
signal it except for tags.  To this end I added this to vorbisfile.  It
works, but after thinking about it I'm not sure this is the right way to
do it.  I'm not sure what the intent was with this kind of information. 
Is GstTag the proper way to signal it ? The presence of GST_TAG_BITRATE
seems to suggest it was the intent.  My biggest problem with this is
that there is no way at all to distinguish between "metadata" and
"streaminfo".  Ie, the data about the song, and the data about the audio
data.  These get presented quite differently in applications.

The only thing I see us do at this point is to either extend Tag a
little so that the type of GstTag can be set, and the two types can be
distinguished; or, use and restore the old mechanism, which signalled
having STREAMINFO.  The streaminfo could in the past be gotten by
getting the pointer to the GstCaps.  We could either use GstCaps or
GstTag for actually transporting this to the app, I'm undecided on which
is best.

As for the format, since this is still available as caps on a pad, I'm
assuming we could keep using this.

I'd like to have people's thoughts on this, as I want to get this fixed
this week.  GNOME 2.6 isn't that far away anymore.

Thomas

Dave/Dina : future TV today ! - http://www.davedina.org/
<-*- thomas (dot) apestaart (dot) org -*->
Goodbye
I've finally arrived
<-*- thomas (at) apestaart (dot) org -*->
URGent, best radio on the net - 24/7 ! - http://urgent.fm/






More information about the gstreamer-devel mailing list