[FFmpeg-devel] [PATCH] libopenjpegdec: add pix fmt gbrp (9-14 bit)
mjbshaw at gmail.com
Thu Jan 31 16:08:51 CET 2013
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
> > 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
> > 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
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.
More information about the ffmpeg-devel