Hi Laurent, 2009/7/27 Laurent Aguerreche <[email protected]>
> 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
_______________________________________________ tracker-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/tracker-list
