Single threaded H.264 decoding performance

[Blue_MiSfit]

[EDIT] This was all updated quite a bit. The interesting graph I came up with a few hours later has been added to this OP just to grab eyes :)
Consider my thoughts in this OP somewhat misguided...

tl;dr - ffmpeg-mt is faster (for these sources anyway) than CoreAVC or DivX H.264!


http://imgur.com/8PJRS.png

Hey folks,

So we all know that CoreAVC is a great place to start if you're looking for FAST H.264 decoding on Windows. That's all well and good.

However, I recently realized I'd made the assumption that it would be very fast in all scenarios. As my numbers below show, this is not the case!

All tests were performed on a 2.4 GHz Intel Q6600 quad-core CPU running Windows 7 x64. Benchmarks were made using avs2avi. DSS2 provided DirectShow interaction. All sources were of identical content, and were 1080p24.

Source 1 - ~50mbps x264 encode, "fastdecode" tune (no CABAC, B-Frames, or Deblocking)
CoreAVC - 103.7 fps
FFMS2 - 31.5 fps
Fake CoreAVC "single threaded" ~ 25.93 fps

Source 2 - ~50mbps x264 encode, no CABAC or B-Frames, but has deblocking
CoreAVC - 86.9 fps
FFMS2 - 27.6 fps
Fake CoreAVC "single threaded" ~ 21.73 fps

Source 3 - ~50mbps x264 encode, with CABAC, B-frames, and deblocking
CoreAVC - 56.6 fps
FFMS2 - 13.7 fps
Fake CoreAVC "single threaded" ~ 14.2 fps

My conclusion? In typical scenarios for this community, CoreAVC or similar high performance multi-threaded decoders are the way to go.

However, in MY CASE :D, things are a little different. I usually work with H.264 sources that have no B-Frames, and use CAVLC instead of CABAC. Both of these sacrifices are made to facilitate real-time capture, which is a huge ugly animal all on its own!

Given my typical sources, and the fact that I'm doing a LOT of transcoding at once (anywhere from 3-6 1080p encodes on a system at once, depending on how many cores I have), FFMS2, single threaded, seems like it will actually give me better throughput - provided it never bottlenecks x264!

Sure, the numbers are always higher with CoreAVC, but the numbers are always with it eating up almost 100% of my CPU! That's fine for playback, but for high volume transcoding, I want the most efficient decoder for my type of files, correct?

I THINK I'm seeing this correctly. What do you guys think?

The best possible solution is to do all the decoding on a couple GPUs, but that's another story.

Derek

[Blue_MiSfit]

Some more numbers, this time with timeCodec.exe. They're higher overall, but I assume that's because it avoids AviSynth etc. The advantage is, I can restrict CPU affinity reliably this way :)

Also, since FFMS2 isn't available in this framework, I'm just using libavcodec from ffdshow-tryouts rev 3463 (may 29 2010)

Source 1 (--tune fastdecode, zerolatency)
CoreAVC (4 threads) - 126.3
libavcodec (1 thread) - 35.9
CoreAVC (1 thread) - 34

Source 2 (--no-cabac, --tune zerolatency)
CoreAVC (4 threads) - 101.4
libavcodec (1 thread) - 30.4
CoreAVC (1 thread) - 27.7

Source 3 (all on)
CoreAVC (4 threads) - 62.5
libavcodec (1 thread) - 17.6
CoreAVC (1 thread) - 16.5

Interesting. The trend is basically the same, though the differences here are less pronounced (less than 10% in most cases).

Interestingly, good old MPEG-2 at 80mbps, with typical GOP structure decodes at ~44fps single threaded with FFMS2, which is almost 2x faster than DGDecode ;)

Derek

[clsid]

ffdshow also has multi-threading capability if you select ffmpeg-mt as H.264 decoder.

[Blue_MiSfit]

Indeed. In my testing it's always been slower than CoreAVC, but it's worth a look!

Derek

[Blue_MiSfit]

Here's more results, this time using ffmpeg-mt (and including the CoreAVC results for reference

Source 1 (--tune fastdecode, zerolatency)
ffmpeg-mt (1 thread) - 35.5 fps
ffmpeg-mt (4 threads) - 130.4 fps
CoreAVC (1 thread) - 34 fps
CoreAVC (4 threads) - 126.3 fps

Source 2 (--no-cabac, --tune zerolatency)
ffmpeg-mt (1 thread) - 28 fps
ffmpeg-mt (4 threads) - 110.4 fps
CoreAVC (1 thread) - 27.7 fps
CoreAVC (4 threads) - 101.4 fps

Source 3 (all on)
ffmpeg-mt (1 thread) - 17.3 fps
ffmpeg-mt (4 threads) - 66.2 fps
CoreAVC (1 thread) - 16.5 fps
CoreAVC (4 threads) - 62.5 fps

WOW. I was NOT expecting that! ffmpeg-mt is faster than CoreAVC in all cases for my usual files! It looks like the ffmpeg devs have been working hard :D

I'll make a pretty little graph to illustrate, and maybe put in DivX H.264 as well, I don't have DiAVC and don't feel like spending $10 right now... :)

http://imgur.com/8PJRS.png

Derek

[kieranrk]

Have you tried DiAVC?

[Blue_MiSfit]

I don't have DiAVC and don't feel like spending $10 right now...

Derek

[Underground78]

I don't have DiAVC and don't feel like spending $10 right now... :)

I thought a trial version was available but I may be mistaken.

[Dark Shikari]

Performance may depend heavily on the source material -- e.g. whether the bitrate is high or low, etc.

[sneaker_ger]

I thought a trial version was available but I may be mistaken.

The current trial seems to be expired, but schweinsz gladly distributes trials on request.

[Blue_MiSfit]

Indeed. The bitrate was very high in my case, usually around 60mbps (1080p24)

Derek

[Dark Shikari]

Indeed. The bitrate was very high in my case, usually around 60mbps (1080p24)

DerekTry a much lower bitrate sample. At that bitrate, you're benching the CABAC decoder.

[Blue_MiSfit]

Hence why 2/3 of my tests have CABAC disabled ;)

[Dark Shikari]

Hence why 2/3 of my tests have CABAC disabled ;)Then you're benching the CAVLC decoder ;)

[Blue_MiSfit]

Fair enough.

Still, I'm trying to determine the optimal way to decode high bitrate H.264 for high volume transcode. In my mind, this means the decoder that gives the best per-thread performance. Is that logical?

This seems like a valid test, no?

As I said, MPEG-2 decodes very quickly as well :devil:

Derek

[STaRGaZeR]

If you feel like it, it'll be really nice to have a comparison chart with more samples, with a complete description of the used settings. That way we'll see where each decoder shines or fails :)

[iwod]

Um... So we come to the conclusion that FFmpeg - Mt is fastest.

No loner a reason to use CoreAVC, Divx, or Diva decoder?

[Blue_MiSfit]

Well, for these (unusual) test cases anyway. I haven't bothered to do anything with standard BluRay streams or typical 4-15mbps backup type streams.

Derek

[CeeJay.dk]

@Dark Shikari : You wrote on your blog about some new deblocking optimization you made to x264. Could this optimization to an encoder deblocker be applied to a decoder deblocker , like the one in FFmpeg ?
Have it already been applied - Is that why the new FFmpeg 0.6 release decodes h264 faster ?

[Dark Shikari]

@Dark Shikari : You wrote on your blog about some new deblocking optimization you made to x264. Could this optimization to an encoder deblocker be applied to a decoder deblocker , like the one in FFmpeg ?
Have it already been applied - Is that why the new FFmpeg 0.6 release decodes h264 faster ?It could be, and no, it hasn't been. It would help a lot more in a decoder than in an encoder, in fact.

I haven't done it because the second stage of the process -- "fix things up if the neighbors are different for deblocking than for normal decoding -- is rather hard when you have to consider all possible options (PAFF, MBAFF, etc, etc).

[schweinsz]

Indeed. The bitrate was very high in my case, usually around 60mbps (1080p24)

Derek
The DiAVC has a very good CABAC decoding engine. If you are interested in it, I can provide a trial version to you.

[LoRd_MuldeR]

The DiAVC has a very good CABAC decoding engine. If you are interested in it, I can provide a trial version to you.

Could you put up a new "Trial" edition of DiAVC for everybody? I'd like to give it a try in DVBViewer, now that I have a DVB-S2 card.

The current trial available for download on your homepage says "Expires on May 20, 2010" :(

[CeeJay.dk]

It could be, and no, it hasn't been. It would help a lot more in a decoder than in an encoder, in fact.

I haven't done it because the second stage of the process -- "fix things up if the neighbors are different for deblocking than for normal decoding -- is rather hard when you have to consider all possible options (PAFF, MBAFF, etc, etc).

Maybe you could drop a hint about it to the FFmpeg developers or some of the other videolan developers , and see if anyone would be willing to do it?
I think unfourtunatly it is too late for this summer of code.

Once in FFmpeg it would benefit all the FFmpeg based projects so I think a lot of people would love to see it implemented.