[gst-devel] tags and metadata

[Thomas Vander Stichele]

> I also assume that you don't really use nautilus at all.  But
> > you're not a GNOME person anyway, you're a GStreamer person.
> >
> Ah, I'm a GStreamer person. That must be the reason why I'm a Gnome
> foundation member then ;)

It's not a matter of carrying the badge.  It's a matter of realizing
what it takes.  So, do you run nautilus ? Have you run the apps in GNOME
using GStreamer ?

> Uhm no, it's not my problem if Gnome apps work.

If you're a library on which GNOME depends, and apps use it in GNOME,
then it is a matter of policy for the library to make sure the apps can
keep their functionality, and help them do it, and not the other way
around.  If we cannot provide that we will get kicked out of GNOME
pretty quickly.  I'm not sure about you, but I wouldn't like to see that
happen.

>  If Gnome devs think their
> apps don't work with 0.8, they should say so.

Oh they're about to, don't you worry.  My only concern is that I have
nothing to prove them wrong when they do.  Since, when they'll tell me
that seeking is broken, they can't play files in nautilus, and it
doesn't play many formats at all, I'll have to agree, sadly.

>  I just said I'd make
> GStreamer 0.8 ready for Gnome 2.6 and would like people to include it in
> Gnome. And then the Gnome people that decide what goes in Gnome decided
> that they wanted it in. I didn't decide it all, just like you said.

They decided they wanted it in because we as a team proposed they should
use 0.8 for 2.6.  That implicated we make sure that we do not
feature-regress for the apps already in GNOME 2.4.  You assume since it
doesn't get said explicitly it's not true, but since you haven't been a
GNOME person long enough you probably don't know what it means to
propose a module/library for GNOME.  Which is fine, but you cannot
assume that the rules do not hold up for us as a project because some of
us didn't know about the rules.

So all I'm saying is - if you started the push for 0.8 in GNOME 2.6
(which I thought was great on your part), but today you realize you
didn't realize back then it means we have to make sure we don't
feature-regress and fix if we do, then it's time to take the
consequences.

But let's not play the game of "nobody told me what it meant".

> > Its maintainer asked you *repeatedly* for your plans with the tagging
> > stuff, waiting for you to come up with something for a long time.
> >
> And I always explained it, I even added support for multiple entries per
> tag because of your input.

Sure thing.  All I'm saying is that in the planning/design stages, I
didn't have much of a chance to offer input.  So it's not really fair to
complain that I haven't looked at it much when it's only been around for
looking at since two months.  We all know how compilable/runnable
gstreamer has been for the last three months to last month.


> The only thing that doesn't work is the artificial differentiation between
> "streaminfo" and "metadata". I explained to you why it doesn't work.
> So the thing you call a regression, I call a bug. :)

Whatever you call it, if there's no way to differentiate it for the
purposes of nautilus-media, GNOME people call it a regression.

By the way, there is nothing artificial about the distinction at all. 
Metadata are tags describing the music/audio irrespective of the actual
physical format : title, artist, album ... Streaminfo describes the
specific format of the audio encoding, irrespective of the actual audio
content: codec used, bitrate, ... And format describes the specific
format of the decoded audio.

They are very much completely different and the lines where I separate
them are very unambiguous IMO.


> > The ONLY thing that matters today and that I care about is how I can fix
> > stuff so that it works again.  I want to figure out what you intended to
> > do with the functionality that was already in GStreamer in 0.6.  I want
> > to figure out how you think it should be done so that nautilus-media can
> > work again.  I'm willing to code up whatever is necessary for it.
> >
> Just don't differentiate between writable and non-writable metadata
> anymore as that is not possible beyond guessing as I explained in my last
> mail.

It sure still is.  It'll NEVER be possible to change the bitrate of an
encoded file without transcoding it, peeling, or otherwise changing the
actual encoded content.  It'll be, in many cases, very possible to
change artist, title, and so on (I'm sure you know, since rhythmbox
asked us to make this possible for more than a year).  The cases where
it's not possible are the expected cases like "the file is on a cdrom"
(duh) or "it's DRM-protected".

Quoting examples like DRM'd files is a very bad way to make your point
:) 

Also, the simple fact that filewise this information is in completely
different locations, and codewise there are different locations where
this is extracted, should make my point for itself.

Anyways, again - we need to get stuff fixed for GNOME 2.6.
I, as an app developer, who used to have streaminfo and metadata
separated, now ask you how I can get them separated again.  If you
can't, then I, as a GStreamer developer, will extend the tag system so I
can get it.  But I'd prefer working on something together that pleases
us both, otherwise in the next cycle I just have to replace your stuff
with our old stuff, and then you can do the reverse again, and we lose a
lot of time :)

I'm interested in getting it done now.  There are people who want
GStreamer out of GNOME and I'm not one of them.

Thomas


Dave/Dina : future TV today ! - http://www.davedina.org/
<-*- thomas (dot) apestaart (dot) org -*->
Mag je buiten
Kom je spelen
Jij mag winnen
Daar kan ik tegen
<-*- thomas (at) apestaart (dot) org -*->
URGent, best radio on the net - 24/7 ! - http://urgent.fm/