MPEG-4 AVC/H.264 decoder comparison

[Fraeon Lux]

Shame.. I'd (And I imagine quite a lot of people) love to see a multithreaded decoder that could take advantage of my dual core processor. Until then, CoreAVC is doing a magnificent job at decoding even 1080p video.

Isn't CoreAVC Pro capable of using your dual core processors? Or is that just marketing BS they profess on their home page?

[Dark Shikari]

Isn't CoreAVC Pro capable of using your dual core processors?Yes, CoreAVC has frame-level parallelism.

[Sagekilla]

When was frame level parallelism added? I guess that explains why I can decode 1080p without a problem.

[foxyshadis]

Between the first public release and the next non-public beta release, before 1.0. Or if you mean ffdshow, the patch for cabac parallelism was applied a week or two ago, but it's not full decoding threading.

[iwod]

Any update to the decoder comparison?

Would be nice to see how everything new stack up including new libav and corecodec.

[shita]

I'm looking for some H.264 Decoder Open Source.
Can you help me some address ?
Thanks so much.

[_xxl]

http://ffmpeg.mplayerhq.hu/
http://forum.doom9.org/showthread.php?t=120465

[iwod]

Does anyone know of any site where they have information on which part of the decoding in H.264 takes how many percentage of time.

Example, Like during the decoding pipeline, How many % of time is used to decode CABAC ?

[Dark Shikari]

Does anyone know of any site where they have information on which part of the decoding in H.264 takes how many percentage of time.

Example, Like during the decoding pipeline, How many % of time is used to decode CABAC ?Outdated (http://akuvian.org/src/x264/ffh264_oprofile.txt), but still somewhat accurate. MC cost is lower now.

It also depends heavily on bitrate; CABAC decoding cost, for example, is linearly proportional to bitrate.

[Caroliano]

Another one, also probably outdated, but in an form easier to understand for dummies: http://forum.doom9.org/showthread.php?t=99131

[Dark Shikari]

Another one, also probably outdated, but in an form easier to understand for dummies: http://forum.doom9.org/showthread.php?t=99131A lot of that seems really misleading--you can't enable p4x4 without p8x8 for example, so his p4x4 was actually a test with p8x8 off period.

[Mr VacBob]

CABAC is much faster in libavcodec with the assembly/CMOV reader enabled, which is newer than either of those profiles. I'm not sure if ffdshow uses it or not, but it might not.

[schweinsz]

When was frame level parallelism added? I guess that explains why I can decode 1080p without a problem.
frame level parallelism is useless if all frames are referenced.

[Dark Shikari]

frame level parallelism is useless if all frames are referenced.Incorrect.

[schweinsz]

Incorrect.
Could you explain it? If the current-decoding frame is referenced by the next-decode frame always, is frame-level parallelism useless?

[Dark Shikari]

Could you explain it? If the current-decoding frame is referenced by the next-decode frame always, is frame-level parallelism useless?sliceless threads (http://akuvian.org/src/x264/sliceless_threads.txt)

[P.J]

Please test Cyberlink H.264 Decoder and integrated ATI/NVIDIA DxVA decoder !

[refulgentis]

what happened to multithreaded decoding in ffmpeg for H.264? I haven't seen any mention of it in commits or the developers list for the past couple months, but it looks like astrange has been steadily making commits to the ffmpeg-soc repository

[Cyber-Mav]

new divx h264 decoder is now considered to be the fastest software based decoder for h264 content. it is around 5-7% faster than coreavc.

[nm]

Though CoreAVC is faster on old CPUs with slow/no SSE2 units.

[BetaBoy]

new divx h264 decoder is now considered to be the fastest software based decoder for h264 content. it is around 5-7% faster than coreavc.

Cyber-Mav... you know better... Post facts not opinions..... we have already discussed this on D9 that the DivX decoder is ONLY faster when utilizing instructions sets for certain CPU's. Otherwise CoreAVC is still the fastest. Go to both the CoreAVC and DivX threads if you want more details.

[Cyber-Mav]

yea i forgot to mention that. the tests i saw were done on a e8400 so it has sse4 which could have helped out divx.

[RonaldoSan]

I wanted to compare CoreAVC to the build-in decoder in Windows 7, to see which is best used for encoding (quality).

Exact same 1001 frames and x264 settings (crf18, faster preset, film tune).

CoreAVC Graph

http://i25.tinypic.com/33m1y88.jpg

CoreAVC Encode

avis [info]: 1920x1080 @ 23.98 fps (1001 frames)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2
x264 [info]: profile High, level 4.1
mp4 [info]: initial delay 104271 (scale 2500000)
x264 [info]: frame I:8 Avg QP:14.40 size:251091
x264 [info]: frame P:257 Avg QP:19.28 size: 69794
x264 [info]: frame B:736 Avg QP:20.05 size: 42684
x264 [info]: consecutive B-frames: 0.6% 1.2% 1.5% 96.7%
x264 [info]: mb I I16..4: 21.4% 43.8% 34.8%
x264 [info]: mb P I16..4: 0.6% 2.9% 1.2% P16..4: 33.2% 19.2% 14.7% 0.0% 0.0% skip:28.1%
x264 [info]: mb B I16..4: 6.4% 12.3% 0.5% B16..8: 18.5% 1.6% 1.2% direct:16.1% skip:43.3% L0:39.3% L1:29.1% BI:31.6%
x264 [info]: 8x8 transform intra:62.9% inter:45.0%
x264 [info]: coded y,uvDC,uvAC intra:81.9% 90.8% 53.6% inter:28.8% 34.9% 4.3%
x264 [info]: ref P L0 66.2% 19.5% 14.2%
x264 [info]: ref B L0 79.8% 20.2%
x264 [info]: kb/s:9841.6

encoded 1001 frames, 12.60 fps, 9842.43 kb/s

Windows 7 Graph

http://i27.tinypic.com/2uel1qc.jpg

Windows 7 Encode

avis [info]: 1920x1080 @ 23.98 fps (1001 frames)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2
x264 [info]: profile High, level 4.1
mp4 [info]: initial delay 104271 (scale 2500000)
x264 [info]: frame I:8 Avg QP:14.40 size:257389
x264 [info]: frame P:257 Avg QP:19.30 size: 71213
x264 [info]: frame B:736 Avg QP:20.08 size: 43335
x264 [info]: consecutive B-frames: 0.6% 1.2% 1.5% 96.7%
x264 [info]: mb I I16..4: 22.6% 45.2% 32.1%
x264 [info]: mb P I16..4: 0.6% 3.1% 1.3% P16..4: 33.4% 19.4% 14.8% 0.0% 0.0% skip:27.3%
x264 [info]: mb B I16..4: 6.5% 12.4% 0.5% B16..8: 18.8% 1.6% 1.3% direct:16.3% skip:42.7% L0:39.3% L1:29.2% BI:31.5%
x264 [info]: 8x8 transform intra:62.9% inter:45.0%
x264 [info]: coded y,uvDC,uvAC intra:82.1% 90.8% 54.0% inter:29.2% 35.4% 4.4%
x264 [info]: ref P L0 66.4% 19.5% 14.1%
x264 [info]: ref B L0 79.9% 20.1%
x264 [info]: kb/s:10013.0

encoded 1001 frames, 12.00 fps, 10013.75 kb/s

x264 uses more bitrate for the Windows 7 encode, so would it be fair to conclude that it decodes with superior detail?

[Dark Shikari]

All H.264 decoders give identical output.

[RonaldoSan]

All H.264 decoders give identical output.
Okay, but would it not be possible for the decoders to give a different output if filters are applied or levels are changed?

Either way, unless I made a mistake, the Microsoft decoder would be slightly preferable given the slightly higher bitrate?

[Dark Shikari]

Okay, but would it not be possible for the decoders to give a different output if filters are applied or levels are changed?

Either way, unless I made a mistakeSince all decoders must give identical output, you clearly must have made a mistake.

[RonaldoSan]

Since all decoders must give identical output, you clearly must have made a mistake.
Okay. Thank you for your help.

[BetaBoy]

Wow and a Thank you!

[Cyber-Mav]

Cyber-Mav... you know better... Post facts not opinions..... we have already discussed this on D9 that the DivX decoder is ONLY faster when utilizing instructions sets for certain CPU's. Otherwise CoreAVC is still the fastest. Go to both the CoreAVC and DivX threads if you want more details.

new version of divx seems to be even more faster now for me and it also has 64bit support. dixv runs faster for me on my q9550 cpu when decoding 1080p h264 content. i will test later on the new version of divx and see if its any quicker on my laptop. i have a feeling that this new divx is gonna be quicker on my dothan processor too.

[dimitrik]

All H.264 decoders give identical output.

Jumping in late with a question here. As I understand it, since all decoders give bit identical output, they must all be equal in "image quality" (however that is defined) but may differ in efficiency i.e. resource usage, speed etc.

My questions stems from the fact that when I experimented with ffdshow using libavcodec and ffmpeg-mt, I noticed that ffmpeg-mt gave slightly inferior image quality to libavcodec (certainly there was a visible difference).

The difference was not huge but it was too clear to be a subjective impression. This was about 3-4 months ago, so obviously ffdshow has changed several versions since, so it may no longer be the case.

Did you ever experience anything similar in your tests, or are you aware of some difference that may explain this? Could it be that ffmpeg-mt, being experimental is not fully compliant and hence does not give bit identical output?

[Dark Shikari]

Jumping in late with a question here. As I understand it, since all decoders give bit identical output, they must all be equal in "image quality" (however that is defined) but may differ in efficiency i.e. resource usage, speed etc.

My questions stems from the fact that when I experimented with ffdshow using libavcodec and ffmpeg-mt, I noticed that ffmpeg-mt gave slightly inferior image quality to libavcodec (certainly there was a visible difference).

The difference was not huge but it was too clear to be a subjective impression. This was about 3-4 months ago, so obviously ffdshow has changed several versions since, so it may no longer be the case.

Did you ever experience anything similar in your tests, or are you aware of some difference that may explain this? Could it be that ffmpeg-mt, being experimental is not fully compliant and hence does not give bit identical output?ffmpeg-mt is libavcodec. If there was a bug that resulted in non-compliance, it would generally be rather obvious (e.g. tons of blocking).

[dimitrik]

ffmpeg-mt is libavcodec. If there was a bug that resulted in non-compliance, it would generally be rather obvious (e.g. tons of blocking).

OK, pardon my ignorance here, but ffdshow allows me to choose using either libavcodec or ffmpeg-mt, meaning they cannot be the same.

In fact the difference is CPU use, and IIRC, this difference in image output I noticed (which was definitely not bad as tons of blocking, but was clear enough to the naked eye, mostly grainyness I think).

I suspect when you say they are the same you mean they are the same codec, differently implemented, but from a user perspective, you can choose one or the other and from what I saw the difference in picture reproduction was clear. I'm not keen to re-install the old version to try it again though:p

[JEEB]

OK, pardon my ignorance here, but ffdshow allows me to choose using either libavcodec or ffmpeg-mt, meaning they cannot be the same.

Same codebase is used, just that "ffmpeg-mt" means multithreaded decoding, which means that not only one of your cores gets used in decoding.

Also, using ffmpeg-mt here on several things (Kovensky's mplayer builds and CCCP's ffdshow), but still have yet to have seen any "grainyness".

[nm]

I suspect when you say they are the same you mean they are the same codec, differently implemented, but from a user perspective, you can choose one or the other and from what I saw the difference in picture reproduction was clear. I'm not keen to re-install the old version to try it again though:p
I don't use ffdshow, but can't you switch between "ffmpeg-mt" and libavcodec on the fly?

Anyway, you'll need to post screenshots and a sample video that exhibits this to make us believe. I suspect that you had in-loop deblocking disabled or you used different post-processing filters if there really was such a difference.

[dimitrik]

I don't use ffdshow, but can't you switch between "ffmpeg-mt" and libavcodec on the fly?

Anyway, you'll need to post screenshots and a sample video that exhibits this to make us believe. I suspect that you had in-loop deblocking disabled or you used different post-processing filters if there really was such a difference.

You can't switch deocders on the fly, you have to unload and reload the filters, i.e. terminate and restart the application.

I did some tests this week and I found no difference in image quality. I'm pretty sure when I tested them las time I did not use postprocessing filters. It it possible that I had inloop deblocking enabled but it would have been the same for both decoders.
I can't explain it except to say that it was several versions ago and that I would swear there was a visible difference. Since its no longer the case though, it's a moot point. Call me crazy, I don't mind:)


Same codebase is used, just that "ffmpeg-mt" means multithreaded decoding, which means that not only one of your cores gets used in decoding.

Also, using ffmpeg-mt here on several things (Kovensky's mplayer builds and CCCP's ffdshow), but still have yet to have seen any "grainyness".

You can set ffdshow to run several decoding threads from "decoder options" so it uses all the cores. Not quite as evenly balanced as with ffmpeg-mt but the difference is actualy pretty small in terms of multicore decoding.

Slightly OT, but for anyone interested in the difference in performance, using libavcodec with 4 decoding threads on my brief test, tended to load one core slightly more than the mt decoder (I left ffdshow configured for 4 threads).
The difference was about 10% i.e. 3 cores had ~35% CPU use, while one had ~45%. With the mt, they all had about ~40%.

It made no visible difference, except when I created an unusually heavy load: upscaling 720p to 1080p with lanzocs, RGB32 coversion, postprocessing enabled with fast spp deblocking. With the x64 version of libavcodec, there was video delay on an Intel Quad 2.26GHz while ffmpeg-mt was fine. The x86 decoders had no problem either way.

So from now on I'm using ffmpeg-mt on my HTPC.

[nurbs]

It it possible that I had inloop deblocking enabled but it would have been the same for both decoders.
You should never disable inloop deblocking in the decoder. That can get very ugly (http://forum.doom9.org/showthread.php?p=1184258#post1184258).

[nm]

You can set ffdshow to run several decoding threads from "decoder options" so it uses all the cores. Not quite as evenly balanced as with ffmpeg-mt but the difference is actualy pretty small in terms of multicore decoding.
The difference can be large depending on the decoded stream and number of CPU cores. Libavcodec's slice-based parallelization doesn't work on H.264 streams that only have one slice.

[dimitrik]

That's useful info, thank you both.

[tal.aloni]

ffmpeg-mt is libavcodec. If there was a bug that resulted in non-compliance, it would generally be rather obvious (e.g. tons of blocking).

just to clear dimitrik's name:
there was such a bug with one of the old ffmpeg-mt releases, it has been fixed long time ago.

[dimitrik]

Hey, thanks. See? I was innocent all along your honor!

[xv]

Hi,
also this thread is sticky, it´s information is completly outdated. It would be nice if the comparison in the first post could be updated, new fields added (yuv 4:2:2, 4:4:4 decoding, 9/10 Bit..., old lossless supported, new lossless supported) and new decoders added (CoreAVC, DiAVC, Microsoft, DivX, Nvidia VPx)
Thanks

[CeeJay.dk]

Blue_misfit did some testing back in July last year and found that ffmpeg-mt is the fastest decoder now (http://forum.doom9.org/showthread.php?t=155441).

I did my own tests back then, as I needed to find a way to get two old P4 2.0 and 2.2 ghz systems to play 720P and 1080P, and came to the same conclusion.
ffmpeg-mt was the fastest decoder for me for most files but on a few CoreAVC seemed slightly faster.

On my cpu limited systems though, the fastest (usable) option was to use VLC and setting "Skip H.264 in-loop deblocking filter" to Non-key.
This was always faster than CoreAVCs "Deblocking : Skip when safe" option.
Of course the fastest option was to disable all deblocking, but that absolutely destroys the quality, and is unwatchable, so I chose VLC and skipping the deblocking of the Non-key frames, as I couldn't really tell the difference in quality between that and deblocking all the frames.

[crouserali]

Hello to every one
I need help in finding the new developments made to the H.264, can any onehelp me?
and what is the referance software used for such development?
best regards.

pleas send me an email to:
mohammed.ali.82@gmail.com

[PCU]

Where I can find the latest comparison?