On Fri, Aug 07, 2015 at 10:21:14AM -0400, Ronald S. Bultje wrote:
> Hi,
>
> On Fri, Aug 7, 2015 at 6:43 AM, Michael Niedermayer <mich...@niedermayer.cc>
> wrote:
>
> > On Thu, Aug 06, 2015 at 10:24:52PM -0400, Ronald S. Bultje wrote:
> > > Hi,
> > >
> > > On Thu, Aug 6, 2015 at 4:27 PM, Michael Niedermayer <michae...@gmx.at>
> > > wrote:
> > >
> > > > From: Michael Niedermayer <mich...@niedermayer.cc>
> > > >
> > > > Fixes Ticket4746
> > > >
> > > > TODO: implement packed formats and subsampled formats
> > > >
> > > > Signed-off-by: Michael Niedermayer <mich...@niedermayer.cc>
> > > > ---
> > > > doc/scaler.texi | 13 ++++++
> > > > libswscale/Makefile | 3 +-
> > > > libswscale/alphablend.c | 55 +++++++++++++++++++++++
> > > > libswscale/options.c | 3 ++
> > > > libswscale/swscale_internal.h | 12 +++++
> > > > libswscale/utils.c | 97
> > > > +++++++++++++++++++++++++++++++++++++++++
> > > > 6 files changed, 182 insertions(+), 1 deletion(-)
> > > > create mode 100644 libswscale/alphablend.c
> > > >
> > > > diff --git a/doc/scaler.texi b/doc/scaler.texi
> > > > index 23d6393..4c55334 100644
> > > > --- a/doc/scaler.texi
> > > > +++ b/doc/scaler.texi
> > > > @@ -122,6 +122,19 @@ a_dither).
> > > >
> > > > @end table
> > > >
> > > > +@item alphablend
> > > > +Set the alpha blending to use when the input has alpha but the output
> > > > does not.
> > > > +Default value is @samp{black}.
> > > > +
> > > > +@table @samp
> > > > +@item black
> > > > +Blend onto black
> > > > +
> > > > +@item none
> > > > +No blending
> > > > +
> > > > +@end table
> > > > +
> > > > @end table
> > >
> > >
> > > I must admit I'm not a fan of having just two values for something like
> > > this. It seems to me you want 2 options, "blendmode", being "none" or
> > > "background" (or a float/alpha between 1.0/0.0), and the actual
> > background
> > > color (black, white, blue, r=a,g=b,c=d). "black" vs. "none" seems like a
> > > future compat nightmare. Is it that hard to implement a proper rgb/yuv
> > > value solution?
> >
> > The color value convertion support is in drawutils which is in
> > libavfilter. also drawutils lacks support for >8bit formats
> > so to get arbitrary color support with a clean non duplicated
> > implementation it would require moving drawutils
> > or the color related code from it to libavutil and extending it to
> > support all pixel formats. Unless iam missing something
> >
> > Also i wanted to implement support for a checkerboard background
> > (which some applications use as default and it shows what
> > is transparent much better than black would)
> >
> > So i would suggest that we implement ATM a "none" + "solidcolor" or
> > "background" or what name is preferred
> > and ill add a black/white checkerboard mode later and once drawutils
> > exist in libavutil we can then easily add a "blendcolor" AVOption
> > to specify the exact color
> >
> > If noone objects then ill work on that (except drawutils moving and
> > extending)
>
>
> Sounds ok.ok, updated patch(set) applied [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Into a blind darkness they enter who follow after the Ignorance, they as if into a greater darkness enter who devote themselves to the Knowledge alone. -- Isha Upanishad
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
