[FFmpeg-soc] vf_overlay with transparancy

[Vitor Sessak]

zeger at customsoft.nl wrote:
> Vitor Sessak wrote: 
>> A patch to add alpha handling to vf_overlay.c has been posted to
>> ffmpeg-devel (search for the thread "Support alphablending in the 
>> overlay filter"). The add_alpha filter has also been posted to 
>> ffmpeg-devel, see vf_alpha.patch in thread "[RFC] Alpha support"
> 
> After adding the vf_overlay blend patch as suggested I wrote an
> updated vf_alpha filter since I needed Y based transparency and did 
> not like the YUV -> RGB -> YUV conversions.
> 
> I ran into a slight problem when combining the vf_alpha filter with
> vf_scale; div by zero. I am not sure how to fix this other than 
> patching vf_alpha. 
> 
> I've been using the following filter chain to test the overlay with 
> alpha and scaling combination:
> 
>  input ----------------------> deltapts0 --> overlay --> output
>                                                ^
>  movie --> alpha --> scale --> deltapts1 ------|
> 
> Zeger Knops 


> +    for(i = 0; i < h; i ++) {
> +       alpha->values[POV_y] = i;
> +       i_sub = i >> alpha->hsub;
> +        for(j = 0; j < link->w; j ++)
> +        {

Inconsistent braces placement

> +           j_sub = j >> alpha->hsub;
> +
> +           outrow_0[j]     = inrow_0[j];
> +            outrow_1[j_sub] = inrow_1[j_sub];

Funny indentation

> +           //TODO rgb conversion if user is using rgb in alpha function
> +            alpha->values[POV_cyuv] = (outrow_0[j]<<16) + (outrow_1[j_sub]<<8) + outrow_2[j_sub];
> +            alpharow[j] = ff_parse_eval(alpha->value, alpha->values, alpha);

If you are using ff_parse_eval() here, this filter have no advantage 
comparing to vf_applyfn. In the other hand, if you accept only YUVA420 
as input and if you call ff_parse_eval() at most once per frame, this 
filter can be _much_ faster (and no memcpy(), just modifying the buffer, 
see vf_drawbox).

-Vitor