[gst-devel] tags

[Benjamin Otte]

On Sat, 27 Dec 2003, Thomas Vander Stichele wrote:

> We can still do pad_queries for that for now, right ?
>
Yes, sure.

> What is "it" in this sentence ?
>
The application/x-gst-tags mimetype.

> Let's keep the intended property that an unconnected sink pad just
> unrefs data.  Slightly less intensive than using a fakesink.  Otherwise,
> I agree.  Though it still seems to me that a specific tag extractor
> element that doesn't like at data makes sense in the case below.
>
You want to stop the pipeline when data arrives. You can't do that without
connecting a sink because the core unrefs the stuff for you before you
can check it. And you want to specify filtered caps. Which doesn't work
without a sink either.

> Well, which is why tag-only elements make sense to me.  They can decide
> quickly if the file being processed has tags, and it can be allowed to
> seek through the file to check if it has them or not.  In both actual
> work being done and how to use it, we should at least perform as well as
> dedicated tag libraries.  Ie, it's not really acceptable that we have to
> parse the whole stream to get some tag somewhere in the middle that has
> a welldefined location according to the format.
>
That's what I wanted, but it doesn't work. For a very simple reason: It
only works if one plugin can extract all the caps. In the case of ID3
encoded files, you either need a plugin that can handle flac, mp3 and all
other formats that may use ID3 tags or you're left without length
information for your file. In the case of flac there might be additional
metadata that is encoded as flac metadata and not as ID3 metadata.

Apart from that, Rhythmbox needs to figure out if the gien file contains
music. The question of wether or not it contains tags is not enough
anyway.

Benjamin


PS: I doubt you'll ever get as fast as dedicated tag libraries. GStreamer
is not a tag editing framework ;)