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] > > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > No snowflake in an avalanche ever feels responsible. -- Voltaire > _______________________________________________ > 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". _______________________________________________ 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".