Re: Gstreamer filter

[Christopher James Lahey <clahey ximian com>]

Le mercredi 10 novembre 2004 à 02:07 +0000, Adam Lofts a écrit : 
> On Tue, 2004-11-09 at 15:54 -0500, Christopher James Lahey wrote:
> > So, this looks mostly okay.  I've noticed that gst-sharp requires
> > gstreamer 0.8.7.  Is this a hard requirement?
> 
> I think that the tagging interface changed between gstreamer 0.6-0.8, so
> even if gst-sharp did build with < 0.8.7 the filter wouldn't work.

Fair enough.

> > The main issue that I see is the mime type handling.  It looks like
> > you're attempting to create filters and then letting them be garbage
> > collected to detect mime types.  However, this happens every time the
> > filter gets created, which means every time a file is going to be
> > filtered.
> > 
> 
> Fair enough - here's a new version.

Excellent.

> > I haven't reviewed the code to do the actual reading of the tags, as I
> > don't know the gstreamer stuff very well.  I assume this is correct
> > since you've tested it and it presumably works.  My only concern in this
> > code would be the possibility that it reads to the end of the file, even
> > if the tags are at the beginning (and doesn't skip to the end if the
> > tags are always at the end.)  Is this the case?  And if so, is it
> > possible to avoid this?
> > 
> 
> The code will read data from the file, until the first chunk of data is
> decoded or an error in the pipeline is thrown. i.e. Under no situation
> will an entire media file be decoded - hopefully all the individual
> decoder elements will skip in the file stream rather than read it all if
> tags are at the end.
> 
> Rhythmbox extracts tags in this way - i hope it's fairly efficient.

Sounds perfect.

> > Other than those two issues, the code looks fine.  If you fix the cache
> > thing and test it, I'd be willing to commit this.
> 
> Great.

I'll commit now.

> You will probably have noticed the long list of possible tags at the end
> of the file. Which tags should be indexed by the filter? Does beagle
> care about the bitrate of a stream?
> 
> Finally, (i forgot about this in my first post) the gstreamer name for
> the title of a song is "title" and so is indexed as "fixme:title",
> FilterMusic.cs calls the title "fixme:song". Title seems to make more
> sense to me, can we not standardise on the gstreamer tag names? [ title
> does seem more accurate than song ]

Well, I agree that title is better, but I don't think it matters.  As
we're using the fixme: namespace, I don't think it matters at all.

Thanks,
    Chris