[cairo] [Pixman] Planar YUV support

[Siarhei Siamashka]

On Fri, Feb 25, 2011 at 11:18 PM, Andrea Canciani <ranma42 at gmail.com> wrote:
> On Fri, Feb 25, 2011 at 2:00 PM, Siarhei Siamashka
> <siarhei.siamashka at gmail.com> wrote:
>> I'm cautiously interested in getting planar YUV format support added to
>> pixman/cairo for the purpose of implementing some kind of reasonably
>> well performing software fallback solution for html5 video in browsers
>> when hardware acceleration is either impossible or too difficult to use.
>> And this looks like a much smaller scale task than your work because:
>> 1. Just read-only support for planar YUV format is enough
>> 2. Image quality is less important than performance, so that the precise
>> filtering details or chroma siting can be just ignored
>> 3. Probably just only SD color matrix (Rec.  601) would be enough for the start
>>
>> The only missing thing in pixman API right now is the ability to wrap the
>> output of video decoder (3 buffers corresponding to the color planes) into
>> pixman_image_t for using it as source image in compositing operations.
>
> I would suggest the creation of a new opaque pixman type, pixman_format_t,
> that represents the format of a bits image with more flexibility than
> the existing
> pixman_format_code_t.
>
> To represent the existing formats (and many more, for example the x1a7r8g8b8
> format from https://bugs.freedesktop.org/show_bug.cgi?id=33741) a structure
> with the following fields would be sufficient:
>  - bpp bits per pixel
>  - n_components number of components
>  - for each component:
>   - shift the offset
>   - bits the number of bits of the component

I think that this is an interesting topic, but unfortunately it moves
the discussion a bit away from the problem which I would like to
solve. And the problem in fact is that there is just a single
important planar YUV format, which is not handled well enough by
pixman:
    http://www.fourcc.org/yuv.php#YV12
And IYUV and I420 are mostly the same if pixman API would allow some
flexibility to specify color planes as individual buffer pointers.

I'm not a big fan of "let's make this totally universal and future
proof" approach if only a very small fraction of this functionality is
going to be actually used. Moreover, I suspect that trying to be too
general was responsible for slowing down the original "Planar YUV
support" plan.

Surely an alternative solution for html5 video fallbacks is to do
YUV->RGB conversion of video frames outside of cairo/pixman, and only
let cairo/pixman handle the RGB data. The only real problem with this
solution is that such multi pass data processing is somewhat slower.
We are speaking about at least tens of percents of performance here.
And pixman support for native single pass YUV->RGB conversion combined
with scaling could help.

-- 
Best regards,
Siarhei Siamashka