[FFmpeg-devel] [PATCH] lavfi/gradfun: fix direct writing in buffer.

Clément Bœsch ubitux at gmail.com
Fri Dec 7 03:00:12 CET 2012


On Sun, Dec 02, 2012 at 03:57:52PM +0100, Nicolas George wrote:
> Le duodi 12 frimaire, an CCXXI, Clément Bœsch a écrit :
> > The (untested) code will now assume src = dst all the time, and we can
> > maybe do some more simplification. The min_perms is here to make sure that
> > a new buffer is allocated when the input is read-only (that was done
> > manually previously).
> > 
> > currently:
> >   if inbuf is RO:
> >     - filter requests a new write buffer
> >     - processing with src ≠ dst
> >   else if inbuf is RW:
> >     - processing with src = dst
> > 
> > after:
> >   if inbuf is RO:
> >     - lavfi requests a new write buffer so a new RW inbuf is passed
> >   - processing with src = dst
> > 
> > Does that make any sense?
> 
> It makes absolute sense, but it is missing the key information: benchmark.
> 
> Consider the hue filter (I did not check whether it is implemented as I will
> state, it is just an example): for planar formats, the U and V planes are
> completely rewritten while the Y plane is passed unchanged.
> 
> If you require WRITE permissions and it is missing, then lavfi will copy Y
> for us in the new buffer, as it should, but it will also copy the whole U
> and V planes, which is completely unnecessary.
> 
> The other way around has the opposite disadvantage: if we always allocate a
> new buffer, then the Y plane needs to be copied always, even if we could
> have reused it.
> 
> The current scheme uses the best of the two worlds: if we have write
> permissions, we use them to avoid copying Y; else, using a new blank buffer
> avoids copying U and V for nothing.
> 
> I have absolutely no idea whether this optimization makes any real
> difference or not. If it was for a new filter, I would not consider
> mandatory to implement it. But in this particular case it is already there,
> removing it without checking would be rather strange.
> 

Ah good point, I missed all of this, thanks for the explanations!

-- 
Clément B.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20121207/6599c835/attachment.asc>


More information about the ffmpeg-devel mailing list