GNOME Bugzilla – Bug 676542
[jpegdec] JPEG decoder doesn't expose EXIF tags, XAP tags, or comments
Last modified: 2013-08-21 19:18:12 UTC
The JPEG decoder doesn't expose EXIF tags, XAP tags, or comments. This can be trivially fixed by adopting the relevant code from jpegparse. Patch underway.
Is this fixed by bug #676302 or do you still plan to attach a patch?
I understand now that this needs a separate patch to actually expose these tags.
This is not fixed by bug #676302. Implementing the patch is still on my list.
Created attachment 219472 [details] [review] jpegdec: Parse EXIF and XAP tags (for git master)
Created attachment 219473 [details] [review] jpegdec: Parse EXIF and XAP tags (for 0.10 branch)
Bit undecided whether this should be done in the decoder in 0.11. It's the fastest way to make it work at the moment of course, but generally we've moved metadata extraction from decoders to parsers. I'd like to see a new jpegparse element written on top of GstBaseParse and using the API from bug #673925, which can then also do the metadata extraction.
The jpegparse already extracts these tags. I don't know if this task has be done by the decoder.
(In reply to comment #6) > Bit undecided whether this should be done in the decoder in 0.11. It's the > fastest way to make it work at the moment of course, but generally we've moved > metadata extraction from decoders to parsers. I'd like to see a new jpegparse > element written on top of GstBaseParse and using the API from bug #673925, > which can then also do the metadata extraction. No I am a bit surprised since I got told to try exactly this (extracting the tags in jpegparse) to avoid all the unforeseeable side effects from messing with element priorities. Goal of this patch is to enable GstDiscoverer for JPEG images.
Anyway, Tim: Can you outline your proposal more in detail, and maybe also estimate effort? I honestly don't know JPEG or GStreamer well enough for doing a serious estimation myself right now, but with a better idea on what has to be done, I can ask for budget.
How about applying this fix for now, and doing the proper solution later?
0.10 is closed for new features now (see announcement on gstreamer-announce/devel mailing list), esp. in 'critical' code paths, and for 0.11 I strongly prefer the 'proper' solution. If we add it to jpegdec now we need to support it until the end of time, and we'll end up extracting the same metadata twice. I'm trying to get some traction on the jpeg parsing API and parser though.
This should be fixed by using jpegparse.