[FFmpeg-devel] [PATCH] lavc/mjpegdec: hint next marker position in ff_mjpeg_find_marker

[Matthieu Bouron]

On Sat, Jan 28, 2017 at 02:25:34AM +0100, Michael Niedermayer wrote:
> On Fri, Jan 27, 2017 at 09:47:18AM +0100, Matthieu Bouron wrote:
> > On Fri, Jan 27, 2017 at 02:30:40AM +0100, Michael Niedermayer wrote:
> > > On Thu, Jan 26, 2017 at 05:47:51PM +0100, Matthieu Bouron wrote:
> > > > Speeds up next marker search when a SOS marker is found.
> > > > 
> > > > ff_mjpeg_find_marker goes from 54% to 30% under perf record ffmpeg -i
> > > > sample_2992x4000.jpg
> > > > ---
> > > >  libavcodec/mjpegdec.c | 31 +++++++++++++++++++++++++------
> > > >  libavcodec/mjpegdec.h |  2 +-
> > > >  libavcodec/mxpegdec.c |  5 +++--
> > > >  3 files changed, 29 insertions(+), 9 deletions(-)
> > > 
> > > this breaks decoding multiple jpeg files
> > > for example tickets//856/nint.jpg
> > 
> > New patch attached fixing the issue.
> > 
> > [...]
> 
> >  mjpegdec.c |   31 +++++++++++++++++++++++++------
> >  mjpegdec.h |    2 +-
> >  mxpegdec.c |    5 +++--
> >  3 files changed, 29 insertions(+), 9 deletions(-)
> > 6ba49d73c189b197bdc1a983e26ccd49713c617c  0001-lavc-mjpegdec-hint-next-marker-position-in-ff_mjpeg_.patch
> > From ebef63ebdc75872d52529d5b74b6d05254d4c0fd Mon Sep 17 00:00:00 2001
> > From: Matthieu Bouron <matthieu.bouron at gmail.com>
> > Date: Thu, 26 Jan 2017 15:17:36 +0100
> > Subject: [PATCH] lavc/mjpegdec: hint next marker position in
> >  ff_mjpeg_find_marker
> > 
> > Speeds up next marker search when a SOS marker is found.
> > 
> > ff_mjpeg_find_marker goes from 54% to 30% under perf record ffmpeg -i
> > sample_2992x4000.jpg
> 
> the patch seems to work but
> why is the "buf_ptr += (get_bits_count(&s->gb) + 7) / 8;" not
> already skiping all that what the buf_hint does ?
> is the difference the unescaping ?
> maybe the buf_hint stuff can be simplified by adjusting buf_ptr instead
> ?

I've just realized that the SOS marker handling does not consume any byte
from the GetBitContext *only* when the frame is being discard (which
happens in avformat_find_stream_info).

So I guess a better solution would be to consume all the bytes from the
GetBitContext while this marker is skipped and let the code already in
place handle that.
However, the buf_ptr won't directly be at the next marker position since
the sos data is unescaped. With the sample I use there is a difference of
13774 bytes (thus iterations in find_marker) to find the next marker. It
reduces the function (according to perf) from 5,4% to 4.8% while the frame
is being decoded (ffmpeg -i sample_2999x4000.jpeg -f null -) but it seems
the performance gain is too little versus the code that the patch
introduces and the decoder will benefits more from having aarch64 simd
code for the various idct functions (something that i plan to do in the
upcoming days).

I'll send a new patch soon.

Matthieu

[...]