[FFmpeg-devel] Once again: Multithreaded H.264 decoding with ffmpeg?
Mon Jun 2 19:53:52 CEST 2008
> 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
More information about the ffmpeg-devel