[FFmpeg-devel] Copyplane filter

Stefano Sabatini stefano.sabatini-lala at poste.it
Thu Aug 25 15:34:51 CEST 2011


On date Thursday 2011-08-25 08:07:37 +0100, Gavin Kinsey encoded:
> On Thursday 25 August 2011 01:00:05 Stefano Sabatini wrote:
[...]
> > > +            if (!cp->skipplane[c])  {
> > > +                av_read_image_line(cp->line,
> > > +                                   (const uint8_t **)inpic->data,
> > > +                                   inpic->linesize,
> > > +                                   cp->pix_desc,
> > > +                                   0, i, c, w1, 0);
> > > +                av_write_image_line(cp->line,
> > > +                                    outpic->data,
> > > +                                    outpic->linesize,
> > > +                                    cp->pix_desc,
> > > +                                    0, i, c, w1);
> > > +            }
> > 
> > Look, since you don't need generic support a simple memcpy should be
> > more efficient.
> 
> A memcpy per line or is just one per plane safe?

memcpy per plane is not always safe, in case linesize != width.

You can use libavutil/imgutils.h:av_image_copy_plane (note: it could
be optimized for doing a single memcpy when dst_linesize ==
src_linesize == bytewidth).

> > Also note that this filter job can be done in a much more general way
> > using an eval filter, e.g.:
> > 
> > evalrgb=a=r
> > 
> > Check the applyfn filter in the archive, also you could consider using
> > the mp=geq filter (not sure it supports alpha).
> 
> I looked at the existing filters, didn't think to look for ones that haven't 
> been applied, or the mplayer ones.  I'll take a look, since even if I don't 
> use one now it may be useful in future, or for reference.
> 
> > On the other hand the eval filter would be much slower (an expression
> > is evaluated for each pixel component), so maybe the copyplane idea is
> > acceptable.
> 
> Performance is an issue, since our apps often run multiple streams in 
> parallel.  I'll do some tests and see what the performance difference is for 
> our typical workloads.  But to be honest now I've gone to the effort of 
> writing it I'll probably just stick with copyplane.  :-)

A benchmark would be welcome, but I'm not in general opposed to the
copyplane approach.
-- 
FFmpeg = Fanciful & Fostering Most Practical Encoding/decoding God


More information about the ffmpeg-devel mailing list