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

[Michael Bradshaw]

On Thu, Jan 24, 2013 at 5:12 AM, Paul B Mahol <onemda at gmail.com> wrote:

> On 1/24/13, Carl Eugen Hoyos <cehoyos at ag.or.at> wrote:
> > Paul B Mahol <onemda <at> gmail.com> writes:
> >
> >> Did you ever notice that RGB48 case is pure hack
> >> because you manully deinterleave/planarize RGB48.
> >
> > (Apart from the fact that as you know there is no
> > complete planar GBR support making the discussion
> > not really helpful:)
> > Wasn't that implemented before non-8 bit GBR
> > code was added or do I miss something?
> >
> >> Obviously you do not care for performance.
> >
> > When I last tested libopenjpeg, it was a magnitude
> > slower than our native codec, so I don't understand
> > how a performance argument for this wrapper is
> > relevant.
>
> If time spent in wrapper can be made smaller
> it is better.
>
> Yes, GBRP case can take priority over RGB case once
> GBRP gets output in swscale. Currently it is still possible to output
> both via user request.


I don't have time to modify this patch right now, but I'd like to ask what
your thoughts are about this now that swscale does support GBRP so I can
better modify this patch when I do have time.

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
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)?

Thanks,

Michael