[gstreamer-bugs] [Bug 486659] xmp/exif metadata handling

[GStreamer (bugzilla.gnome.org)]

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=486659

  GStreamer | gst-plugins-bad | Ver: git

Edward Hervey changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bilboed at gmail.com
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1




------- Comment #20 from Edward Hervey  2009-03-11 21:29 UTC -------
We really need 'proper' support for exif/xmp at least.

The problem with the current metadata implementation and based on the last
comments and discussion on IRC is that the metadata(de)mux elements are trying
to do something which other elements can do (much better) and are failing
abysmally at that.

It would be better to provide a convenience library to give the exif/xmp blobs
to and get back tags/structures (and vice-versa) and leave to existing elements
that know how to parse/mux those blobs in a given format handle that.

Ex : add it to jpegdec/jpegenc.

It would then be also much more trivial to make (if needed) parsers for
specific formats.

Ex : within the jpeg plugin, you could share the code from gstjpeg{enc|dec} and
make a jpegparse element which can extract/insert those tags without having to
encode/decode anything.


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=486659.