On Tue, Mar 3, 2015 at 9:49 PM, Michael Bradshaw <mjbs...@gmail.com> wrote:
> That seems like the least intrusive fix, and the logic looks right to me. I
> don't know if 8-bit per component XYZ will ever be supported in ffmpeg, but
> if so then deciding between rgb24 and xyz8 will need a different method. The
> mixing of AV_PIX_FMT_* enums and *_PIXEL_FORMATS macros looks
> tedious/fragile.
>
> I'd say the above patch is okay. Alternatively, something like the following
> could be done, I think:
>
> +static const enum AVPixelFormat libopenjpeg_j2k_all_pix_fmts[] = {
> RGB_PIXEL_FORMATS, GRAY_PIXEL_FORMATS, YUV_PIXEL_FORMATS,
> XYZ_PIXEL_FORMATS
> };
The problem is that this order does not work like you think it does.
Due to the way libopenjpeg_matches_pix_fmt is imlemented
XYZ_PIXEL_FORMATS will never match because rgb48 will always match
first (for both rgb48 and xyz12 pixels). The split was done for
precisely this reason or else it would not work correctly.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
