[FFmpeg-devel] Once again: Multithreaded H.264 decoding with ffmpeg?

[Siegmar Buss]

> This has been discussed several times, please check the archives.

I beg your pardon for my insufficient research. I used G**gle quite a 
lot, but the only post I found was the slice-based thing. In the mean 
time I also found the information about the frame-based parallelization 
(summer of code).

> There is definitively room for 50% decode speed improvement in
> ffmpeg's h264 decoder but it would take some work. CUDA et al have
> been discussed in the past (again see archives) but the kist of it is
> that while very fast, the latency can be quite significant so you

Thanks for the latency point. I didn't take latency into account at all.

> The best way would be to compile with oprofile support under linux and
> measure it yourself.

I will do that! In the mean time I have done some _very simple_ speed 
tests with the current svn version, yielding this distribution:

1. Parsing, bitstream handling   43.8 %
2. Apply motion prediction       29.2 %
3. Apply intra-frame prediction   1.7 %
4. Residual-Decoding              5.7 %
5. Deblocking                    19.5 %

Please use these numbers with caution. I just measured the speed while 
uncommenting several parts of hl_decode_mb_internal without 
understanding the code completely. :-)

> I haven't looked at that myself, but it seems like something that
> could be done but I think the biggest single gain would be
> implementing frame-level parallelisation.

You are right! The intra-frame-parallelization approach would leave the 
parsing process unparallelized, limiting the speed gain. Frame-level 
parallelization does not have this limitation.

I'm looking forward to the results of the frame level parallelization 
approach!

Thanks,
   Siegmar