[gst-devel] tags and metadata

Benjamin Otte in7y118 at public.uni-hamburg.de
Fri Jan 23 08:28:02 CET 2004


On Fri, 23 Jan 2004, Thomas Vander Stichele wrote:

> > I'm not against adding that, I'm against not defining it.
> > If we define that streaminfo is extracted from the stream and not via
> > metadata and that length is streaminfo, I will make id3tag never set the
> > length tag..
>
> length is something what I consider part of the decoded streaminfo - it
> is a property of the decoded audio.
> I am not sure though if it's something that would be reported through
> tags, since currently we do this through querying.
>
> As for the id3 length tag, I think it is a hack/workaround, but I'm not
> sure how GStreamer should handle it.  Ideally GStreamer would work well
> enough so that it's better to trust GStreamer to get length than id3.
> Note that in practice GStreamer does this pretty well.
>
In the mp3 case GStreamer is pretty ok, but not nearly as good as a
correct id3 tag. Especially in the vbr case.
What you fail to see here is that some other formats might use ID3 and
it might be a lot harder to get the length there without a correct tag.
Imagine a format where only decoding the whole file tells you the correct
length. tta maybe?

> Since you said you only want one length tag, that's a problem.
> Personally, I think the metadata (ie, editable/tagged) length should be
> called length-metadata or somesuch, and the length that can be
> calculated through gstreamer should be the default "length" tag.
> Alternatively, if the tag hashed not only on name, but on name/type
> somehow, that would be fine too.
>
Anybody that thinks that reporting multiple lengths is a good idea, please
raise your hand.
Apart from that, anything that is possible to report differently should
never be put into a tag, so a GStreamer calculated length is clearly wrong
there.

> What I'm getting at is, if I write an app, and I get the length tag
> twice (since GStreamer reports it once because it's in the id3 tag and
> once because it calculates it, in theory), I would like to prefer the
> one from the framework, not the tag, since the framework is supposed to
> be more correct.  So I need some way to distinguish between the two.
>
> If the framework doesn't allow me to distinguish them, then I'd prefer
> it would not give me the human-changeable one, ie the metadata.
>
> Does that make it more clear from my point of view ?
>
So how is an element supposed to handle the length tag? Should mad try to
correct the length tag? Should id3tag query to figure out the length when
it writes metadata? Should it not write at all? Or just write it when it's
set as a tag?

> Elements care about it since typically the way of reporting them is
> completely different.  As an example, metadata of vorbisfile is
> retrieved by using vorbistag, and the encoded and decoded streaminfo is
> retrieved by using (at this point) vorbisfile.  It will cause some
> restructuring of media-info since now I really need different pipelines
> for each type of info, while before one plugin signalled everything.
>
That's not true. An element should extract all the tags it can. So since
vorbisfile obviously knows about vorbistags, it should extract them. If it
doesn't oesn't, I'd consider this a bug.

> It seems to be similar for mp3, btw.  So it's pretty obvious to me that
> plugins detect these different kinds of info in different ways - exactly
> because metadata is data tagged onto the stream (mostly in the
> container), streaminfo of the encoded stream is encoded inside the
> bitstream (typically in headers), and streaminfo of the decoded stream
> are the caps properties of the raw decoded audio.
>
The differentiation you make here between streaminfo and metadata is
actually a differentiation between demuxer and decoder metadata most of
the time. You should keep in mind that there's no conceptual difference
between those inside GStreamer.
(For the sake of argument I'll not get into the argument of you not
getting the fact that there's only elements and not "decoders",
"encoders", "demuxers" and "muxers" from a core perspective. And yes,
GStreamer is the only framework that works that way.)

btw: The "streaminfo" part you're writing out is totally wrong anyway.
Both vorbis and mp3 are neither integer audio or something else. This is
just because you used some particular decoder that decodes it that way.
This is not a property of the file but of the pipelines you plug inside
media-info.

> Ok, so let me know which particular piece of encoded/decoded streaminfo
> you are unsure of and I'll clarify.  Afterwards I'll document everything
> in the manual.
>
Should an element care about the different flags when writing tags? How?


Benjamin





More information about the gstreamer-devel mailing list