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

[Michael Niedermayer]

On Mon, Dec 07, 2009 at 07:51:35PM +0100, Vitor Sessak wrote:
> 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. 

well, inserting a scale filter is nicer sure ...


> Having a 
> filter needing to force the insertion of others will be possible in several 
> other cases (padding, deinterlacing, resizing, etc).

i dont understand this sentance


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

iam not against a simple solution at first at all (the obvious one would be
to support just rgb+rgba or just yuv+yuva)


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The worst form of inequality is to try to make unequal things equal.
-- Aristotle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-soc/attachments/20091207/c95af89a/attachment.pgp>