[FFmpeg-devel] [PATCH 3/3] avcodec/utils: Optimize ff_color_frame()

[Michael Niedermayer]

On Mon, Dec 24, 2018 at 05:44:26PM +0100, Paul B Mahol wrote:
> On 12/24/18, Michael Niedermayer <michael at niedermayer.cc> wrote:
> > Fixes: Timeout
> > Fixes:
> > 10709/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_H264_fuzzer-5630617975259136
> >
> > Found-by: continuous fuzzing process
> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer <michael at niedermayer.cc>
> > ---
> >  libavcodec/utils.c | 9 +++++++--
> >  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> Ugly, set first row and use memcpy for rest of rows.

That would increase the load on the data cache
memcpy has to read the line each time and write it each time
otherwise the code just writes the line.
This should become especially noticable if something else accesses
the data cache like a 2nd core/thread
with just a single thread mempcpy is faster than this simple method
a slightly more complex implementation beats memcpy even single thread
though (at least in my quick test here)

of course if people prefer memcpy() (because its simpler) i can do that
what is preferred ?
code as in the patch ?
memcpy ?

even more messy but slightly beating memcpy ?
(i have to actually clean this up and retest as it does a aliasing violation
 if people want this one)
 
and of course there are more options like with asm to implement that

memcpy:
    5585847 decicycles in A,       4 runs,      0 skips

ugly:
    5696222 decicycles in A,       4 runs,      0 skips

ugly and messy:
    5527612 decicycles in A,       4 runs,      0 skips

original:
    14953532 decicycles in A,       4 runs,      0 skips

tested with: fate-suite//h264/SonyXAVC_LongGOP_green_pixelation_early_Frames.MXF

thanks


[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Does the universe only have a finite lifespan? No, its going to go on
forever, its just that you wont like living in it. -- Hiranya Peiri
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20181224/f74a581a/attachment.sig>