[Ffmpeg-devel] h264 playback performance

[Loren Merritt]

On Thu, 14 Sep 2006, Corey Hickey wrote:
> Andreas ?man wrote:
>> 
>> Now, during the summer my tv-provider did some trials with HDTV.
>> The video format used was CABAC-encoded h.264 in 720p @ 50Hz running
>> at approx 20Mbps.
>> 
>> Sadly, i discovered that my current machine (Pentium-M w/ 2Mb cache @
>> 1.8Ghz) decodes a frame in ~33ms in average (which obviously is too
>> slow). I know that the CABAC encoding is quite CPU hungry so it's
>> not very surprising.
>> 
>> I'm about to buy a new machine and I'm interested if anyone with
>> a "hot" CPU can try playing the clip I've uploaded and report back.
>
> I can't say for sure with such a short clip, but my system can almost handle 
> what you uploaded.
>
> $ mplayer SVT\ HD\ Teaser-ac3-chopped.ts
> Triggers the "your system is too slow" message.
>
> $ mplayer SVT\ HD\ Teaser-ac3-chopped.ts -lavdopts skiploopfilter=nonref
> A-V desync fluctuates but remains below 0.3 seconds at all times.

20mbit/s, and it's still not low enough qp to elminate deblocking?

>> Has there been any thoughts about making the h264-decoder
>> multithreaded? With the arrival of multi-core CPUs it would
>> seem like a wise thing to ponder.
>
> There's '-lavdopts threads=n'. I don't know how well it works, but it does 
> run multithreaded.

The only lavc codecs that implement it are mpeg1/2.

>> Can h264-slices be decoded independently ?
>>
>> Should one move the entropy-decoding to an individual thread
>> and push decoded macro-blocks between the threads?
>>
>> Any other ideas?

Possible multithreading modes:
* 3 threads: cabac, mc+dct, deblocking.
* Decode slices independently. Depends on the file having slices.
* Decode frames simultaneously but synchronized. Increases decoding delay.
* Decode frames independently. Depends on the file having non-referenced
B-frames, and increases decoding delay.
* Some combination of the above.

--Loren Merritt