On Sun, Oct 13, 2019 at 06:45:16AM +0800, Limin Wang wrote:
> On Sat, Oct 12, 2019 at 11:46:58PM +0200, Michael Niedermayer wrote:
> > On Sat, Oct 12, 2019 at 06:58:21PM +0800, lance.lmw...@gmail.com wrote:
> > > From: Limin Wang <lance.lmw...@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.lmw...@gmail.com>
> > > ---
> > >  libavcodec/v210dec.c | 132 +++++++++++++++++++++++++++----------------
> > >  libavcodec/v210dec.h |   1 +
> > >  2 files changed, 85 insertions(+), 48 deletions(-)
> > > 
> > > diff --git a/libavcodec/v210dec.c b/libavcodec/v210dec.c
> > > index 5a33d8c089..c3ef8051e6 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,12 @@
> > >          *c++ = (val >> 20) & 0x3FF;  \
> > >      } while (0)
> > >  
> > > +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;
> > > @@ -64,21 +71,87 @@ static av_cold int decode_init(AVCodecContext *avctx)
> > >      avctx->pix_fmt             = AV_PIX_FMT_YUV422P10;
> > >      avctx->bits_per_raw_sample = 10;
> > >  
> > > +    s->thread_count  = av_clip(avctx->thread_count, 1, avctx->height/4);
> > >      s->aligned_input = 0;
> > >      ff_v210dec_init(s);
> > >  
> > >      return 0;
> > >  }
> > >  
> > > +static int v210_decode_slice(AVCodecContext *avctx, void *arg, int 
> > > jobnr, int threadnr)
> > > +{
> > > +    V210DecContext *s = avctx->priv_data;
> > > +    int h, w;
> > > +    ThreadData *td = arg;
> > > +    AVFrame *frame = td->frame;
> > > +    int stride = td->stride;
> > > +    int slice_h = avctx->height / s->thread_count;
> > > +    int slice_m = avctx->height % s->thread_count;
> > > +    int slice_start = jobnr * slice_h;
> > 
> > this is still not correct
> > the height of a slice is not the same for all slices if the frame height
> > is not divisible by the number of slices
> Yes, so the last slice is processed different by the following code. I have 
> tested with
> different thread number to verify the fate-v210 result. 
> 
> make fate-v210 SAMPLES=../fate-suite thread_type=frame+slice threads=[1-7]

What the code should do is split the frame evenly not
have many small slices and a really large last one

a really large last slice would need much longer to be processed making
the work distribution uneven

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you fake or manipulate statistics in a paper in physics you will never
get a job again.
If you fake or manipulate statistics in a paper in medicin you will get
a job for life at the pharma industry.

Attachment: signature.asc
Description: PGP signature

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Reply via email to