On Tue, Mar 3, 2015 at 3:04 AM, Vilius Grigaliūnas < vilius.grigaliu...@gmail.com> wrote:
> On Tue, Mar 3, 2015 at 11:40 AM, Carl Eugen Hoyos <ceho...@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). _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel