[FFmpeg-devel] [PATCH 2/2] acvodec/lipopenjpeg: Improve XYZ color space detection

[Michael Bradshaw]

On Tue, Mar 3, 2015 at 3:04 AM, Vilius Grigaliūnas <
vilius.grigaliunas at gmail.com> wrote:

> On Tue, Mar 3, 2015 at 11:40 AM, Carl Eugen Hoyos <cehoyos at ag.or.at>
> wrote:
> > Doesn't this break rgb48 images?
>
> No, it does not break rgb48. They are not affected by this change. Due
> to the way libopenjpeg_matches_pix_fmt is implemented, rgb48 can match
> xyz12, but xyz12 can not match rgb48. So the order of formats matter,
> it should be in increasing depth. With the previous format order xyz12
> was never checked, because rgb48 would have been incorrectly selected
> first.
>
> This line is the reason for this:
> 106: desc->comp[2].depth_minus1 + 1 >= image->comps[2].prec
>
> Since 16 >= 12, rgb48 matches and xyz12 is not even considered. I do
> not know, why >= is used here instead of ==, but I do not want to
> change too much.
>

>= was used because some images can have a weird bit depth. For example,
you can make a rgb image with 9 bits per component. ffmpeg doesn't support
rgb27 (only rgb24/rgb48). So >= was used so we can decode "weird" bit
depths and stuff them into a frame without losing precision (so an rgb27
would get stuffed in an rgb48 frame).