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

Baptiste Coudurier baptiste.coudurier at gmail.com
Wed May 12 01:05:41 CEST 2010


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.

Libswscale should be pretty fast at doing this.

-- 
Baptiste COUDURIER
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer                                  http://www.ffmpeg.org


More information about the FFmpeg-soc mailing list