GNOME Bugzilla – Bug 503616
Let metadataparse extract image dimensions
Last modified: 2009-07-29 14:26:02 UTC
bug 486659 comment 17: Apart from emitting tags, it would also be useful to let an image metadata parser change the caps. Specifically, width and height are always present. A use case for this is multiplexing of motion JPEG. The source of the JPEG data may not provide width and height properties in the caps, but multiplexers like avimux and matroskamux demand these properties on their source pads: souphttpsrc location="http://webcam/mjpeg" do-timestamp=true ! multipartdemux ! metadataparse ! matroskamux ! filesink location="webcam.mkv"
Created attachment 100960 [details] [review] Patch to extract JPEG size. (preliminary) Extract dimensions from JPEG image and add them to source caps.
One would probably want this done a bit cleaner and more generic, with PNG support, but this is a working prototype.
Created attachment 100963 [details] [review] Patch to extract JPEG size. Extract dimensions from JPEG image and add them to source caps. This is a bit cleaner and actually reconfigures the src caps, and only when they've changed.
Created attachment 102114 [details] [review] Patch to extract JPEG size. Extract dimensions from JPEG image and add them to source pad caps. I must have screwed something up when cleaning up the previous patch, as it doesn't actually compile. The patch is now updated to the current CVS HEAD, after the parse->demux change.
Created attachment 102115 [details] [review] Patch to extract JPEG size. Extract dimensions from JPEG image and add them to source pad caps. Remove already fixed compiler warning fix.
Some comments on this: - doesn't apply to latest CVS anymore, for example caps setting is done in metadatademux - seems to be very JPEG-centric. Might need some refactoring to be easily applicable to other formats too without making META_DATA_IMG_HEIGHT implement different logic for each format.
Wouter, are you going to update the patch?
(In reply to comment #7) > Wouter, are you going to update the patch? No. Perhaps this problem has been adequately addressed by the new jpegparse element, see bug 583098?
No but it could and that would probably be a better place :) Good point