[FFmpeg-devel] [PATCH] yuv pixel formats support in openjpeg decoder + 10bit support

[Jean First]

On Thu Nov 17 2011 17:59:23 GMT+0100 (CET), Alex Zhukov wrote:
> ping

sorry - I was wating for samples from Dave.

>
> On Sat, Nov 12, 2011 at 3:39 AM, Alex Zhukov<zhukov.alex at gmail.com>  wrote:
>> re code cleanups: see the new patch
>> re curly braces: i'd keep them to make further patches less in size
>>
>> re rgb48, needs a little bit of context
>> there is no field in j2k (i know of) that tells you what color space
>> is used. i am guessing even if there was one people would rarely use
>> it.
>> so most of the code in check_image_attributes() is guesswork that
>> basically does the following:
>> - if component sizes are not the same its more likely to be YUV (ratio 1/2)
>> - if component sizes ARE the same and precision of component is 8 bit its RGB24

ok with me.
As reference: The j2k files contain pure image data and only j2p files 
contain image data and metadata (ISO/IEC CD15444-1 Annex 1 ).
So with pure j2k files we don't know what color space ("cdef") nor what 
color profile ("colr") the file uses.

>> what do we do with higher precisions is, imho, a matter of taste,
>> 16bpp equal component size j2k can either be YUV444P16 or RGB48.
>>
>> returning PIX_FMT_YUV444P16 i made an assumption that it is more
>> likely to be YUV444P16, mostly because i encounter such files more
>> often.
>> tell me if you have a different experience.

I can live with that.
[...]

> +    switch (compRatio) {
> +        case 0111111: goto libopenjpeg_yuv444_rgb;
> +        case 0112121: goto libopenjpeg_yuv422;
> +        case 0112222: goto libopenjpeg_yuv420;
> +        default: return PIX_FMT_RGB24;
> +    }

coding style (here and below), as in 
http://www.kernel.org/doc/Documentation/CodingStyle :

switch (compRatio) {
case 0111111: goto libopenjpeg_yuv444_rgb;
case 0112121: goto libopenjpeg_yuv422;
case 0112222: goto libopenjpeg_yuv420;
default: return PIX_FMT_RGB24;
}

[...]

the rest is fine if testet.
Jean