GNOME Bugzilla – Bug 598915
qtdemux: propagate jpeg2000 header data in image/x-j2c
Last modified: 2009-10-20 15:23:40 UTC
Created attachment 145779 [details] [review] patch implementing these image/x-j2c fields in qtdemux JPEG2000 inside ISO containers, called MJPEG2000 sometimes, with a normal file extension of .mj2 -- yes. The deal is that when we demux out a J2K stream, what qtdemux pushes is just the raw codestream. The codestream contains information about the number of components and their sizes, but we need more information than that to accurately present the data. Some of this information is in the colr atom, currently exported as a "fourcc" field in the caps. That's cool. But we also need component ordering -- is it RGB, or BGRA, or whatever. This information is in the "component mapping" and "channel definition" atoms. The attached patch pushes out the contents of these atoms in a fairly raw format, as a list of integers under the "component-mappings" and "channel-definitions" caps fields. It's probably the least lossy way to do that. These fields will not be present if the file has the default mapping for the colorspace with no alpha channels, which is to say RGB in that order for RGB caps, or YUV in that order for YUV, or the single greyscale channel for greyscale.
Review of attachment 145779 [details] [review]: When you put the cmap into the caps, it seems that we might lose the cmp field when MTYP is "palette mapping", no?
The same applies to cref.
(In reply to comment #1) > Review of attachment 145779 [details] [review]: > > When you put the cmap into the caps, it seems that we might lose the cmp field > when MTYP is "palette mapping", no? Indeed you are right. It seems to fully support palette mapping we'd also need a palette map caps ingest as well -- but since palette mapping is much more complicated, I'm going to punt on it for now. But we can include the info in the caps. The best way to do so would be with separate elements or something, but I'm just going to pack it in that int. The high bits will be 0 only if the component is mapped directly.(In reply to comment #2) > The same applies to cref. Not sure what you refer to here. Thanks for the review, going to commit the patch, my first to GStreamer in a long time! ;-)