The idea is that the current granularity is too small for bigger
coding structures, than can be 64x64 for both hevc and vp9. Instead,
the simplest way to describe the new type of progress is that of
a step function.
I bet the patchset will be far from consensual, and it's unlikely I'll
get it through in a shape that satisfies everyone. It's mostly a
proof of concept.
In the table below, 1T indicates the performance on one core, while
max means the default thread count. Furthermore, to benchmark the
modification, I also added some intrinsics (denoted by +idct). The
effect of the patchset is in the column +patch.
The configurations tested are:
1) HEAD on a 6-cores system
2) HEAD + intrinsics (~openhevc) on the same system
3) HEAD + intrinsics on a 2-cores system (with hyperthreading)
Finally, the numbers reported are the decoding times in seconds.
1T max +idct +patch
1: 26.2 9.5 7.2 6.2
2: 5.7 4.9
3: 13.2 6.5 6.3
Christophe Gisquet (4):
libavcodec: new API for frame threading by step
hevc: use new step progress API
hevc: actual benefits from new step threading API
hevc: use new step threading API for DBF-only cases
libavcodec/hevc.c | 19 +++++++------
libavcodec/hevc_filter.c | 26 ++++++++++++------
libavcodec/hevc_mvs.c | 4 +--
libavcodec/hevc_refs.c | 2 +-
libavcodec/pthread_frame.c | 68 ++++++++++++++++++++++++++++++++++++++++++++--
libavcodec/thread.h | 24 ++++++++++++++++
6 files changed, 121 insertions(+), 22 deletions(-)
--
1.9.2.msysgit.0
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
