On Tue, Dec 1, 2009 at 12:50 AM, Vitor Sessak <[email protected]> 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.
This would also help keep the code clean!
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.
Arthur.
--
__
/.)\ +48 695 600 936
\(./ [email protected]
_______________________________________________
FFmpeg-soc mailing list
[email protected]
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
