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 <vitor1...@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. Having a filter needing to force the insertion of others will be possible in several other cases (padding, deinterlacing, resizing, etc).

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

-Vitor

_______________________________________________
FFmpeg-soc mailing list
FFmpeg-soc@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc

Reply via email to