Log in

View Full Version : H264 Decoder With more than 16 threads


vanden
10th November 2015, 09:59
Hello,

I tried with LAV (MPC HC 1.7.9) and CoreAVC 3.0.1 but all are limited to 16 threads ...
Does H264 Decoder With more than 16 threads exist ?

EDIT :
Yet CoreAVC is assumed Multicore ready (Unlimited CPU Cores) ...
http://www.corecodec.com/products/coreavc

Asmodian
12th November 2015, 20:25
What is the resolution of the video you are playing? There is a limit to how parallel H.264 can be decoded.

Here is a good explanation of the issue though I do not believe any current decoders use the 3D wave strategy described in the paper, using macroblock-level parallelism instead.
Parallel Scalability of H.264 (http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.119.957&rep=rep1&type=pdf)

Groucho2004
12th November 2015, 20:42
I'm curious why you would need such a high decoding speed (assuming that this why you are looking for more decoding threads).

LoRd_MuldeR
14th November 2015, 17:03
Actually I think most H.264 software decoders process multiple frames in parallel, probably in addition to slice-level parallelism.

It means that they don't decode just the "next" frame, but they decode multiple frames "ahead" - in parallel. But there are dependencies between the frames, i.e. a "reference" frame must be decoded before any frames that refer to it. Or, more specifically, you can only decode those parts of a frame for which all reference data is already available. So, at a certain point, it probably just doesn't make sense to use even more threads, i.e decode even more frames in parallel.

benwaggoner
15th November 2015, 22:09
Actually I think most H.264 software decoders process multiple frames in parallel, probably in addition to slice-level parallelism.

It means that they don't decode just the "next" frame, but they decode multiple frames "ahead" - in parallel. But there are dependencies between the frames, i.e. a "reference" frame must be decoded before any frames that refer to it. Or, more specifically, you can only decode those parts of a frame for which all reference data is already available. So, at a certain point, it probably just doesn't make sense to use even more threads, i.e decode even more frames in parallel.
With H.264 and WPP used, you can get one thread of parallelism per 64 pixels of height of the video. This basically replaces the slice-based parallelism of H.264, which no one used outside of Blu-ray since it had a pretty big negative impact on quality.

Parallel decoding at the frame level can be done with a lot of forward buffering (which can be an issue on memory constrained devices), and for non-reference b-frames. Of course, non-ref b-frames are generally pretty easy to decode in the first place since they don't have that many bytes for entropy decode, have little or no intra blocks, and otherwise do less than other frame types.

LoRd_MuldeR
15th November 2015, 23:03
With H.264 and WPP used, you can get one thread of parallelism per 64 pixels of height of the video. This basically replaces the slice-based parallelism of H.264, which no one used outside of Blu-ray since it had a pretty big negative impact on quality.

Are you referring to H.264/AVC or H.265/HEVC here? This thread has been about H.264/AVC decoders, so far.

I think that WPP parallelization (https://sites.google.com/site/hevcwppp/) has been announced as one of the "new" features in H.265/HEVC. I also think that some changes to CABAC that were done in H.265/HEVC exist specifically to make WPP possible.

Could WPP be used with H.264/AVC already? And if so, do software decoders, like FFmpge/lavc or CoreAVC actually implement it?

benwaggoner
15th November 2015, 23:21
Are you referring to H.264/AVC or H.265/HEVC here? This thread has been about H.264/AVC decoders, so far.

I think that WPP parallelization (https://sites.google.com/site/hevcwppp/) has been announced as one of the "new" features in H.265/HEVC. I also think that some changes to CABAC that were done in H.265/HEVC exist specifically to make WPP possible.

Could WPP be used with H.264/AVC already? And if so, do software decoders, like FFmpge/lavc or CoreAVC actually implement it?
No, I just forgot which forum I was in :).

Parallelism in H.264 decode can come from slices, forward buffering, and parallel decoding of frames for which the reference frames have already been decoded. CABAC can also take place in its own thread, and other aspects of decoding a single frame could be done in parallel.

That said, I have a hard time imagining a single-slice decode efficiently using even 16 threads, let alone more, unless it is doing a crazy amount of forward buffering, and has a lot of latency in startup and random access. How much decode parallelism is possible will depend a lot on how the stream is encoded. Using slices and not using reference B-frames would probably help a lot, at the cost of encoding efficiency.

HEVC had a lot of good design work to make parallelism in single-frame decode work a lot better, like in what orders filters apply, and particularly in WPP.

vanden
20th November 2015, 13:47
What is the resolution of the video you are playing?

It's a x264 2160p 50fps 72mbs (http://infonetservices02.chez.com/NoiseRed-50fps-72mbs.mkv)

On my old system (Mac Pro 2008 / Win7x64 / 2xXeon E5462 2.8GHz / 8 Cores / AMD HD6850) there is a little loss of synchronization (the framerate drops below 50fps) at the end of the scene with ducks... And CPU @ 98-100% :
http://infonetservices02.chez.com/MacLAV.png
But with my new (HP DL580 G5 / Win2012R2 / 4xXeon E7450 2.4Ghz/ 24 Cores / Nvidia GTX650Ti) it's also limit (Sometimes it's ok but other times there is synchronization loss), and the processor does not exceed 40% .... :
http://infonetservices02.chez.com/LAV.png
With limit MPCHC @ 18 cores :
http://infonetservices02.chez.com/LAV-18.png
With limit MPCHC @ 16 cores :
http://infonetservices02.chez.com/LAV-16.png
DXVACheker 3.14.0 / LAV 0.68.1
LavX64 DecBench CPU : Fps 29/69.6/75 Cpu 30/42/54
LavX86 DecBench CPU : Fps 28/69.5/76 Cpu 12/43/56
LavX64 DecBench DXVA : Fps 37/41.8/46 Ve 100

LavX64 PlayBench CPU (resize to 1080p) : 0/51.2/56 Cpu 11/31/41
LavX86 PlayBench CPU (resize to 1080p) : 0/51.4/56 Cpu 11/32/43


Or another (worst) H264 2160p 60fps 8mbs (max 35.1mbs) : BigBunny2160p-60fps (http://distribution.bbb3d.renderfarming.net/video/mp4/bbb_sunflower_2160p_60fps_normal.mp4)

On MacPro 60fps (perfect) CPU @ 58% :
http://infonetservices02.chez.com/MacBBBLAV.png
On DL580 env 55 fps (complet loss of synchronization) CPU @ 30-40% ... :
http://infonetservices02.chez.com/BBBLAV.png
DXVACheker 3.14.0 / LAV 0.68.1
LavX64 DecBench CPU : Fps 37/74.8/83 Cpu 10/23/36
LavX64 DecBench DXVA : Fps 18/34.3/51 Ve 100

LavX64 PlayBench CPU (resize to 1080p) : Fps 3/54.3/60 Cpu 4/18/26



What encoder and parameters (h264 or h265) to maximize multithreaded when decoding ?

vanden
25th November 2015, 13:36
No ideas ?

What encoder/parameters (h264 or h265) to maximize multithreaded when decoding ?