What additional metadata would be useful here and for which sort of application?

I'd personally rather this was implemented in a separate plugin that'd depend on GStreamer, rather than making grilo's core libraries (which are now responsible for doing GFile -> GrlMedia with metadata) depend on GStreamer.

I think it could implemented on filesystem conditionally. So downstream could enable gstreamer or not depending if they want this extended capability.

How is that better than a separate plugin?

Conditional support in a library like this is a recipe for more problems when bugs are reported.

This new plugin is mostly like the Filesystem one, except it provides more information thanks to the use of GStreamer.

So probably any new feature we add to Filesystem would be great to have it in this new one.

I don't know, maybe I think this extra information is really useful, that distros will package it instead of our current filesystem plugin. If so, I don't see why we do not want to include that extended plugin instead of current Filesystem one.

And even in this case, there could be some use case where gstreamer is not required/available, so that's why the conditional compilation proposal.

Anyway, other approach is do what do you suggest, and just move the new plugin to our core set if it is really very used.

(In reply to comment #4)
> This new plugin is mostly like the Filesystem one, except it provides more
> information thanks to the use of GStreamer.

No, not really. You'd only implement resolve in the GStreamer plugin. The tracker plugin also exports a whole lot of metadata gathered using GStreamer.

The plugin could gather things like:
- bitrate
- duration
- framerate
- width, height
- orientation

Based on a URI being provided in the GrlMedia element.

Thanks for taking the time to report this.
This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find.

*** This bug has been marked as a duplicate of bug 749458 ***