Re: [Tracker] MP4 Extractor

["Florent Viard" <fviard lacie com>]

Hi,

I agree with you for not having that kind of extractor enabled by default and let the distribution choose. But, that isn't opposed with having it in the master repository. It shouldn't need a lot of maintenance and you know where to find me if some maintenance is still needed. Even if I disappear: this is not a library and there always stay the gstreamer backend, so you could easily remove it later.

It is impossible for me to create an external repository. For your extractor, I never heard about it, and so I don't find this really relevant to have a lot of extractors dispatched around the internet. It would be as if all the codecs of gstreamer or ffmpeg were dispatched on different repositories. The diversity of extractors are a key point for an indexer I think.
I also think that all the possible third parties extractors should be available with the core of tracker-extract/ even if tagged as third party and only compiled on demand.

No?

Florent Viard
Software Development Engineer
........................................
fviard lacie com
www.lacie.com

Le 07/04/2010 15:06, Ivan Frade a écrit :

Hi!

On Tue, Apr 6, 2010 at 3:02 PM, Florent Viard <fviard lacie com> wrote:

Hi,

I don't think that having a mp4 extractor conflict with having the tracker-extract-gstreamer module. For me the mp4 one is specific where there is always the gstreamer one as fallback for all audio / video not having an extractor (or by disabling the mp4 extractor for people preferring the meta datas extracted the mp4 extractor).
For me having the more extractors possible is the best even if I agree that it shouldn't be a priority to develop new ones. (I developed this one as it was needed by us as we don't have gstreamer on the device and require the faster indexation time with the lower cpu and memory usage. And for this, launching gstreamer wasn't the best solution :p

 The problem comes if we integrate it in the current master, and then we need to maintain it ;)

 A good solution can be to create your own project for that extractor. I did that for the OGG extractor for maemo:
http://gitorious.org/tracker-vorbis-extractor

 The is the distribution who choose what plugins to include (instead of making them compilation options in tracker).
  

FYI the beginning of the extractor looks "byte by byte" as it skip the file header but for the meta tag parsing it is not dependent of the byte position, so there shouldn't be problems in the future I think :) Moreover, I think that the meta tags system of mp4 is cleaner/simpler than one for mp3 and so there isn't a lot of different versions like for mp3. So i think that this code is not complex as is the one for mp3.

With "byte by byte" i meant the low level parsing  compared with gstreamer. The code doesn't look specially ugly :)
 

By the way, did you started looking at the nmm:ontology? because I had a look at how the ontologies are made and it looks easy :) So, I could try to submit a patch regarding my previous ontology change proposal even if it certainly will take me some days.

Not yet, not sure i can do it soon. Patches are welcome, but please take the comments in that thread into account.

Regards,

Ivan

This e-mail and any attachment are confidential and intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient, please telephone or email the sender and delete this message and any attachment from your system. Unauthorized publication, use, dissemination, forwarding, printing or copying of this e-mail and its associated attachments is strictly prohibited.