Re: [Tracker] tracker-extract unable to read media files + aborts

[Ivan Frade <ivan frade gmail com>]

Hi Laurent,

2009/7/27 Laurent Aguerreche <laurent aguerreche free fr>

Hi!

I found the tracker-extract's logs fully populated by errors such as
"file not found" but only for media files.

I took a look at the tracker-extract-gstreamer.c file and found that it
tries to pass a URI to the "filesrc" plugin instead of a path to a file.
So "filesrc" needs to be replaced by "giosrc" or set the "location"
property with a path.

We have a bug open about that, including a patch.

http://bugzilla.gnome.org/show_bug.cgi?id=587849

It looks fine to me, but i dont know in detail the extractor code.
 

Note that I am unable to use the "tagreadbin" plugin on my Fedora 11
because it does not seem to be shipped. By the way, I am annoyed to see
this line in create_tagreadbin_pipeline() :
  g_warning ("Failed to convert filename to uri");
URI is already a filename/path!

 This looks like a trivial problem. The kind of things we want to polish before releasing 0.7.0. Thanks!
 

Now GStreamer is able to open a file and analyze it through the
"decodebin" plugin. Fine! But tracker-extract-gstreamer aborts (i.e. a
SIGABRT is emitted) when it tries to run some GStreamer's threads. After
some hours I found that tracker-extract stop to abort if I remove the
call to tracker_memory_setrlimits() in tracker-main.c... So I did it!

 We limit the amount of memory the extractor can use. We need that for small devices (e.g. Maemo) and having a limit is a sane protection against evil extractors.

I guess the amount of memory should be a compilation parameter so for a regular desktop you can use a bigger value.
 

What is the current state? Tracker-extract is able to extract data but
they are very poor. For a video, it is limited to the duration (but
sometimes it fails to get that!) and the audio codec (but the video
codec would be easy to add since GStreamer finds it, so why not add
it?).
Again I read the tracker-extract-gstreamer.c file and found that videos
dimensions are supposed to be read when the video playing has been
paused. Unfortunately, the pads that are returned at this time by the
callback dbin_dpad_cb() do not seem to contain any interesting
capabilities. But at this point, I have to admit that I am not a
GStreamer expert to understand this problem...

 I am not a gstreamer expert either. "Tagreadbin" is much (*much*) faster that decodebin, and the difference is big in an internet tablet. I dont know the status of that gstreamer component in upstream (if it is shipped in distributions). Depending on the situation we need to decide: depend on that component or fall back to decodebin if it is not present. Right now i dont have a solution, comments are welcome.
 

 Regards, and thank you very much for the feedback,

Ivan