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 <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.
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
signature.asc
Description: Digital signature
_______________________________________________ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc