[FFmpeg-devel] [PATCH] libopenjpegdec: add pix fmt gbrp (9-14 bit)
Paul B Mahol
onemda at gmail.com
Thu Jan 31 15:40:34 CET 2013
On 1/31/13, Michael Bradshaw <mjbshaw at gmail.com> wrote:
> 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
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.
> 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?).
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
More information about the ffmpeg-devel