[FFmpeg-soc] [PATCH] updated! vf_overlay alpha patch and watermarking using PNG with alpha

[Vitor Sessak]

Michael Niedermayer wrote:
> On Sun, Dec 06, 2009 at 05:12:37PM +0100, Vitor Sessak wrote:
>> Hi and sorry for the delay.
>>
>> Artur Bodera wrote:
>>> On Tue, Dec 1, 2009 at 12:50 AM, Vitor Sessak <vitor1001 at gmail.com> wrote:
>>>> While I normally oppose making non-committed code more complex, I think
>>>> this feature is so often requested that it is worth the extra work in the
>>>> future. Stefano, Michael, any strong opinion about this?
>>>>
>>> I think the vf_overlay should be modified altogether. Although
>>> mathematically alpha-blending is more expensive than opaque pixel
>>> replacement, I think that it should be automatically decided by analyzing
>>> the overlay format.
>>> So the alpha-blending should be a "built-in" functionality (not a 
>>> switchable
>>> parameter) and should be implicitly functional with any overlay 
>>> stream/image
>>> that has alpha channel (i.e. rgba). If there is no alpha channel, then 
>>> pixel
>>> overriding would be used. This makes much more sense.
>> I agree that this would be nice, but there is no way to make it work with 
>> the current format negotiation in libavfilter. For example, there is no way 
>> to have a filter that accepts either "input: rgb, output rgba" or "input: 
>> yuv, output: yuva", so I suggest you just do as your present patch for the 
>> time been.
> 
> an overlay filter that supports 
> rgb -> rgb              yuv -> yuv
>     ^           OR          ^
>   rgba                     yuva
> 
> cant be done, but you can do:
> 
> rgb -> rgb              yuv -> yuv
>     ^           OR          ^
> yuva||rgba              yuva||rgba
> 
> this might end up requireing rgb<->yuv converting the thing to be overlaid
> in the overlay filter (its just a call to the swscaler ...)

I thought about this idea, but what I don't like is doing calls to 
swscale instead of just having the vf_overlay inserting an scaler 
filter. Having a filter needing to force the insertion of others will be 
possible in several other cases (padding, deinterlacing, resizing, etc).

That's why I thought that having at a first time a simpler solution is 
better (instead of delaying too much the svn inclusion).

-Vitor