[FFmpeg-devel] [PATCH v2 2/2] avcodec/v210dec: add the frame and slice threading support

[Limin Wang]

On Sat, Sep 21, 2019 at 11:04:27PM +0200, Michael Niedermayer wrote:
> On Sat, Sep 21, 2019 at 07:45:58AM +0800, Limin Wang wrote:
> > On Fri, Sep 20, 2019 at 07:57:10PM +0200, Michael Niedermayer wrote:
> > > On Fri, Sep 06, 2019 at 11:28:29PM +0800, lance.lmwang at gmail.com wrote:
> > > > From: Limin Wang <lance.lmwang at gmail.com>
> > > > 
> > > > The multithread is avoid one core cpu is full with other filter like scale etc.
> > > > About the performance, the gain is very small, below is my testing for
> > > > performance.
> > > > In order to avoid the disk bottleneck, I'll use stream_loop mode for 10 frame
> > > > only.
> > > > 
> > > > ./ffmpeg -y -i ~/Movies/4k_Rec709_ProResHQ.mov -c:v v210 -f rawvideo -frames 10
> > > > ~/Movies/1.v210
> > > > 
> > > > master:
> > > > ./ffmpeg -threads 1 -s 4096x3072 -stream_loop 100 -i ~/Movies/1.v210 -benchmark
> > > > -f null -
> > > > frame= 1010 fps= 42 q=-0.0 Lsize=N/A time=00:00:40.40 bitrate=N/A speed=1.69x
> > > > video:529kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing
> > > > overhead: unknown
> > > > bench: utime=10.082s stime=13.784s rtime=23.889s
> > > > bench: maxrss=147836928kB
> > > > 
> > > > patch applied:
> > > > ./ffmpeg -threads 4 -thread_type frame+slice  -s 4096x3072 -stream_loop 100 -i
> > > > ~/Movies/1.v210 -benchmark -f null -
> > > > 
> > > > frame= 1010 fps= 55 q=-0.0 Lsize=N/A time=00:00:40.40 bitrate=N/A speed=2.22x
> > > > video:529kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing
> > > > overhead: unknown
> > > > bench: utime=11.407s stime=17.258s rtime=18.279s
> > > > bench: maxrss=442884096kB
> > > > 
> > > > Signed-off-by: Limin Wang <lance.lmwang at gmail.com>
> > > > ---
> > > >  libavcodec/v210dec.c | 135 +++++++++++++++++++++++++++++++++------------------
> > > >  libavcodec/v210dec.h |   1 +
> > > >  2 files changed, 88 insertions(+), 48 deletions(-)
> > > > 
> > > > diff --git a/libavcodec/v210dec.c b/libavcodec/v210dec.c
> > > > index 6ce18aa..2cdb99e 100644
> > > > --- a/libavcodec/v210dec.c
> > > > +++ b/libavcodec/v210dec.c
> > > > @@ -28,6 +28,7 @@
> > > >  #include "libavutil/internal.h"
> > > >  #include "libavutil/mem.h"
> > > >  #include "libavutil/intreadwrite.h"
> > > > +#include "thread.h"
> > > >  
> > > >  #define READ_PIXELS(a, b, c)         \
> > > >      do {                             \
> > > > @@ -37,6 +38,13 @@
> > > >          *c++ = (val >> 20) & 0x3FF;  \
> > > >      } while (0)
> > > >  
> > > > +#define MAX_SLICES 32
> > > > +typedef struct ThreadData {
> > > > +    AVFrame *frame;
> > > > +    uint8_t *buf;
> > > > +    int stride;
> > > > +} ThreadData;
> > > > +
> > > >  static void v210_planar_unpack_c(const uint32_t *src, uint16_t *y, uint16_t *u, uint16_t *v, int width)
> > > >  {
> > > >      uint32_t val;
> > > > @@ -67,58 +75,32 @@ static av_cold int decode_init(AVCodecContext *avctx)
> > > >      s->aligned_input = 0;
> > > >      ff_v210dec_init(s);
> > > >  
> > > > +    s->slice_count = av_clip(avctx->thread_count, 1, MAX_SLICES);
> > > 
> > > why is there a MAX_SLICES ?
> > 
> > It's limit the slice thread count, if it's not OK, I can use MAX_AUTO_THREADS for max.
> 
> why is a limit needed here ?
> where does avctx->thread_count get a bad value ?

No other limit, only thread_count need great than 0, by my testing, I'll be auto thread even
using -threads 0, so it's OK to remove it.

> 
> This feels a bit arbitrary to limit it to 32 (or any number)
> will that be still correct in 10 years ? if not then this is
> not a good way to limit it
> 
> thx
> 
> [...]
> 
> -- 
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> 
> The misfortune of the wise is better than the prosperity of the fool.
> -- Epicurus



> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".