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

[Vitor Sessak]

Baptiste Coudurier wrote:
> On 12/06/2009 08:12 AM, 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.
> 
> How much harm does doing yuv -> yuva or rgb -> rgba in all cases ?
> To my knowledge it would only be a matter of adding one component and 
> memset it to 0xff.

This wouldn't do much harm, but there is no way of asking for such kind 
of inputs in lavfi (i.e., either "rgb,rgba" or "yuv,yuva"). And changing 
lavfi to accept such constraints would probably make colospace 
negotiation a NP problem.

-Vitor