[gst-devel] tags

[Thomas Vander Stichele]

El sáb, 27-12-2003 a las 11:42, Benjamin Otte escribió:
> This is a writedown of my general thoughts. The issue is that current tag
> reading provides no way to get "length" and similar properties which
> aren't saved as tags but are part of the data out of the pipeline.

We can still do pad_queries for that for now, right ?

> I think we definitely want to support "unchangable" tags. But if we want
> to read them out we cannot use the current application/x-gst-tags
> mimetype, because that relies on the fact that one element (the one
> exporting x-gst-tags) provides these tags.
> I propose to drop it completely.

What is "it" in this sentence ?

> The correct solution for me seems to be plugging the complete pipeline as
> you'd plug it on playback since that's the only way you can be sure to get
> all the tags. (You want to replace the audiosink with a fake sink though

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.

>  -
> but keep the caps.) This even works without decoding - or with very little
> decoding - because tag parsing/event sending are supposed to happen before
> data passing. So if you just wait for the first data to arrive and stop
> the pipeline when that happens, you should be pretty much set.
> 
> This even tells you if the current file that you are testing is an audio
> file and if you should add it to your music library.
> Which brings us to the crux of the issue. If the current file your testing
> is not an audio file, spider might play back the whole file trying to plug
> it. Which needs a lot of time for big files...

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.

Thomas


Dave/Dina : future TV today ! - http://davedina.apestaart.org/
<-*- thomas (dot) apestaart (dot) org -*->
Welcome to Hits City, Jeff K - Population: you
<-*- thomas (at) apestaart (dot) org -*->
URGent, best radio on the net - 24/7 ! - http://urgent.fm/