[gst-devel] I420 + alpha

[Greg Wright]

If you are interested we have been using a YCrCbA format for a several
years now. It is exactly what you describe, I420 plus an alpha plane.

video/include/ciddefs.h

#define CID_I420        0   /* planar YCrCb 4:2:0 format (CCIR)     */
#define CID_YV12        1   /* planar YVU 4:2:0 (ATI)               */
#define CID_YVU9        2   /* planar YVU 16:2:0 (Intel,ATI)        */
#define CID_YUY2        3   /* packed YVU 4:2:2 (ATI,S3,etc.)       */
#define CID_UYVY        4   /* yet another packed 4:2:2 (3Dfx)      */
[snip]
#define CID_ARGB32      11  /* RGB32 with Alpha Channel.            */
#define CID_YUVA        12  /* planar YCrCbA 4:2:0                  */

defined as:

#define BI_YUVA         MAKEFOURCC('Y','U','V','A') /* planar YVU 420 plus alpha plane */

I guess I didn't pick the best name for it.

We also have hand optimized x86 assembly for doing alpha blending
with it and a variety of formats.

%define _I420andYUVAtoI420_MMX        I420andYUVAtoI420_MMX
%define _I420andYUVAtoYV12_MMX        I420andYUVAtoYV12_MMX
%define _I420andYUVAtoYUY2_MMX        I420andYUVAtoYUY2_MMX
%define _I420andYUVAtoUYVY_MMX        I420andYUVAtoUYVY_MMX

We also have C versions off all these as well.

The code can be found on the Helix Community web site:

    https://helixcommunity.org/projects/video/

Not sure how the licensing will work for you though.

--greg.




Jan Schmidt wrote:
> On Thu, 2005-03-17 at 13:19 +0100, Benjamin Otte wrote:
> 
>>On Wed, 16 Mar 2005, Gergely Nagy wrote:
>>
>>
>>>In our application, we have an I420 format source, which I need to
>>>modifiy (blend stuff on it), and pass it to theoraenc, which wants I420.
>>>
>>>Right now, I need to convert the whole thing to AYUV, and then back.
>>>This results in significantly more resource usage and it takes a lot of
>>>time.
>>>
>>>To solve this, I'd like to have a new format, which is essentially I420
>>>with a full-size alpha plane appended (appended, because then it is easy
>>>to strip, or simply ignore).
>>>
>>>This way, I could make our application able to work without any kind of
>>>expensive colorspace conversions, and could use the same buffer the
>>>first element in the pipeline gave me. In my experience, this makes the
>>>whole thing significantly faster.
>>>
>>>Question is, how should I call this new format? I thought of A420, but
>>>people here might have better ideas.
>>>
>>
>>stupid question:
>>Does a format that does this already exist somewhere?
>>It sounds like a reasonable format to have to me and if it were already
>>existing somewhere we could just use that name.
>>
>>Although converting from I420 to AYUV and back shouldn't really be that
>>performance-reducing, or is it?
>>
> 
> 
> (720*576*1.5 + 720*576*4) * 30.0 = 65.25MB/s memory bandwidth. Even on
> my Athlon 2000, that's about 10% of the memory bandwidth for each
> conversion.
> 
> Caching isn't going to help much, because even 1 frame is too big, so
> even on a fast machine, you don't want to do too many of them in any
> pipeline.
> 
> J.