[FFmpeg-devel] [PATCH] libopenjpegdec: add pix fmt gbrp (9-14 bit)

[Michael Bradshaw]

On Thu, Jan 31, 2013 at 7:40 AM, Paul B Mahol <onemda at gmail.com> wrote:

> On 1/31/13, Michael Bradshaw <mjbshaw at gmail.com> wrote:
> > Should RGB support be taken out of the decoder? Or should GBRP just take
> > higher priority when looking for a pixel format (and still support RGB
> with
> > that hacked deinterleaving you hate so much)? Also, for j2ks with an
>
> I just think that approach is slow. openjpeg expect data
> in planes and using planar rgb is more natural because you just
> call memcpy instead of bunch of loops and shifts.
>

I agree it's not optimal. I'm just wondering where (or if) we draw the line
on what's the decoder's (or encoder's) responsibility.


> > unknown pixel format, we have to guess the pixel format. GBRP10, for
> > example, would match an unknown 3-component 10bpc pixel format just as
> well
> > as YUVP10. Should YUV be given higher priority than GBRP if the pixel
> > format is 9-14 bits, but GBRP have higher priority for 8 and 16 bits (I
> > feel like rgb is more common in the 8 and 16 bit cases while yuv is more
> > common in the 9-14 bit cases, but I don't have proof of this)?
>
> Well warning should be printed if format is guessed and option to
> pick color space should be available to the user (isn't this already
> done?).


The user can pick a color space, yes, but currently no warning is printed
if the format is guessed. That would be a good idea though.