[FFmpeg-soc] [PATCH] updated! vf_overlay alpha patch and watermarking using PNG with alpha
Vitor Sessak
vitor1001 at gmail.com
Sun Dec 6 17:12:37 CET 2009
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.
> Because the whole overlay concept is very universal, there is no need for
> vf_logo or any other strange mockup. You can implement all the vf_logo
> functionality with overlay+scale. As a convenience, a mockup vf_logo could
> be built - which would just be a shortcut for automatically splitting and
> inserting vf_overlay in the right spot (just like scale or format filter is
> inserted automatically). This would mean the core code is still in
> vf_overlay and is easier to maintain in the long run.
I agree completely.
-Vitor
More information about the FFmpeg-soc
mailing list