MSU H.264 Codec Testing and DivX H.264

[Dyomich]

Dear doom9 community,

Moscow State University performs annual H.264 codec comparison as usual. And this year we have extended number of participants.

When we add codec in comparison we work with its developers to find optimal parameters and presets for encoding. Due to many user requests we have added DivX H.264 codec (DivX plus), but WE CAN NOT CONTACT ITS DEVELOPERS. We have written to support of DivX and other contacts, but do not have any answers.

We perform comparison and want to provide feedback about it to DivX, Inc.

Could you help us get contact with DivX H.264 developers?

Thank you!

P.S. You can find more information about our comparison here:
http://www.compression.ru/video/codec_comparison/call_for_codecs_10.html
http://www.compression.ru/video/codec_comparison/mpeg-4_avc_h264_2009_en.html
http://www.compression.ru/video/codec_comparison/index_en.html

Best regards,
Dr. Dmitriy Kulikov,
Head of Video Codec Testing team,
Graphics&Media Lab,
Moscow State University

[poisondeathray]

I think "DigitAl56K" works for DivX , perhaps you could PM him or use instant messaging. Contact info is in his profile

http://forum.doom9.org/member.php?u=21264

[LoRd_MuldeR]

Minimum 40 fps for "High Quality" preset

:eek:

[ChronoCross]

:eek:

Does that really surprise you? Their test has pretty much always been a joke IMO.

[Dyomich]

:eek:

For the test machine: this requirement is easily met by 2-pass x264 with preset "slow". So by our opinion it is quite normal requirement.

[Dyomich]

Does that really surprise you? Their test has pretty much always been a joke IMO.
Could you explain or argue your statement? What do you think is incorrect in MSU video codec comparisons?

[Dyomich]

I think "DigitAl56K" works for DivX , perhaps you could PM him or use instant messaging. Contact info is in his profile

http://forum.doom9.org/member.php?u=21264

Thank you - I will try to contact him as long report draft will be ready.

[ChronoCross]

Could you explain or argue your statement? What do you think is incorrect in MSU video codec comparisons?

Measuring quality in relation to speed of the codec isn't a very good qualitative measure and is completely dependent on the the power of the machine your using, the optimization of the code, etc. because if x264 can use 16 reference frames and get 40fps but DivX can only use 2 reference frames and still get 40fps then the quality will be skewed in the direction of x264.

Speed can be used in a test to chart the exact tradeoff of quality/speed rather than comparing it for absolute quality which is what your test is supposedly meant to measure.

[LoRd_MuldeR]

For the test machine: this requirement is easily met by 2-pass x264 with preset "slow". So by our opinion it is quite normal requirement.

If that's true (for both passes, not only for the fast first pass), then I'm surprised by the performance of those Core-i7's! And it's "only" the 920 you are using.

I get ~12-15 fps (less than the half speed) for 4CIF content with "slow" preset. That's on my Core2 Quad, which is running only very slightly slower (2,44 GHz -vs- 2,67 GHz) :o

[IgorC]

http://www.fcenter.ru/img/article/CPU/Linnfield_LGA1156/144493.png

[poisondeathray]

IgorC - perhaps adding background information to that graph would help .e.g source dimensions , encoding settings etc... otherwise the graph alone is less useful

[RunningSkittle]

Could you explain or argue your statement? What do you think is incorrect in MSU video codec comparisons?

High Quality encodes should not be dependent on speed?! Of course its interesting to see the speed, but to make such a high requirement kills the performance of x264. for example: No veryslow preset.
Making a floor fps requirement might be good though, 1fps is not very useful in most applications! Perhaps make it something more reasonable like 5-10fps.
it would also be interesting to see the speed/vs quality on fastest settings.

[Dark Shikari]

Oh come on, it's not unreasonable to require a speed threshold for each comparison.

I do agree that they overcompensated this year; the previous year had ridiculously low speed thresholds, so this year they made them an order of magnitude higher.

[Blue_MiSfit]

Indeed. I consider ~12fps (half realtime for 24p) to be quite usable for most scenarios.

High volume transcoding really does need high speeds though. 48 to 72fps is not unreasonable.

x264 can probably slaughter the competition at this threshold, but I'm always interested to see updated codec comparisons. I'll be doing my own comparison soon, between Rhozet Carbon Coder (Mainconcept) and x264 at 50mbps 1080p for mezzanine file purposes.

~MiSfit

[IgorC]

Or just add one preset more. Fast, Normal, High, Highest.

[DigitAl56K]

Hi Dmitriy,

By "DivX H.264 encoder" I assume you are referring to the beta released at DivX Labs last year. This was a sample application based on an older version of the SDK designed specifically to provide a DivX Plus HD-compliant reference in terms of bitstream constraints, HRD model and so forth. Although it serves as a fully functional and free encoder it is a feature constrained for-purpose application and doesn't represent the capabilities of the latest MainConcept encoder. Sorry if this hasn't been clearly communicated to you previously.

I had heard that you were in touch with our MainConcept team regarding their encoder. If I can help you further or if you need help contacting the MainConcept group you can write me directly at amayo (at) divxcorp [dotcom].

[Dyomich]

Hi Dmitriy,

By "DivX H.264 encoder" I assume you are referring to the beta released at DivX Labs last year. This was a sample application based on an older version of the SDK designed specifically to provide a DivX Plus HD-compliant reference in terms of bitstream constraints, HRD model and so forth. Although it serves as a fully functional and free encoder it is a feature constrained for-purpose application and doesn't represent the capabilities of the latest MainConcept encoder. Sorry if this hasn't been clearly communicated to you previously.

I had heard that you were in touch with our MainConcept team regarding their encoder. If I can help you further or if you need help contacting the MainConcept group you can write me directly at amayo (at) divxcorp [dotcom].

Hello!
Thank you for answer!

Yes, we are using beta from DivX Labs.
About MainConcept - we have a contact with developers and testing newest MainConcept encoder.
And due to the fact that DivX H.264 encoder is present as separate encoder comparing to MainConcept we test it too.

Next year we plan to make a new use-case - only for encoders with РВК model. So we look forward to include your encoder (DivX Plus) in next comparison.

Also I have a question - what e-mail address can we use to contact DivX developers this time and next year? Yours?

[DigitAl56K]

Dmitriy,

Send me an e-mail so that I have your address and we can talk further.


Also I have a question - what e-mail address can we use to contact DivX developers this time and next year? Yours?

I hope so! ;)

[bob0r]

Dyomich, i have prepared this graph for you:
http://x264.nl/graph.jpg

[Emulgator]

The flat parts are amazing, feeling calm.

[dstln]

Encoding times certainly do matter but wow :P

I personally think it would make much more sense to have the "normal" requirement as realtime and then adjust "high speed" and "high quality" semi arbitrarily from there as you see fit. Either way it's too late now since the rules are already set and process in place, but yeah. Maybe next year.

[Dyomich]

Encoding times certainly do matter but wow :P

I personally think it would make much more sense to have the "normal" requirement as realtime and then adjust "high speed" and "high quality" semi arbitrarily from there as you see fit. Either way it's too late now since the rules are already set and process in place, but yeah. Maybe next year.

Real-time requirements differ too much for different PC configurations. It is main problem of this requirement. During previous comaprisons some developers told us that our PCs too slow or too fast for some requirements.

[Biggiesized]

Indeed. I consider ~12fps (half realtime for 24p) to be quite usable for most scenarios.
12 FPS is twice realtime. 48 FPS would be half real-time. (This is measured in terms of length of encoding. If you encoded 24p content at 12 FPS, it would take twice as long as if you encoded it at 24 FPS, which is realtime.)

Personally, I think 5 times real-time should be the minimum threshold. (That's roughly 5 FPS).

[AnonCrow]

12 FPS is twice realtime. 48 FPS would be half real-time. (This is measured in terms of length of encoding.
<nitpick> FPS is a unit of speed , not a unit of time. </>

[G_M_C]

Dyomich, i have prepared this graph for you:
http://x264.nl/graph.jpg

The flat parts are amazing, feeling calm.

I lol'ed :D

An explination on what the graph represents might be usefull. But hey, people seem to love their graphs ;)

[Dyomich]

Dear codec professionals!
We have finished H.264 Video Codecs Comparison report prepearing.
We have tested:

DivX H.264
Elecard H.264
Intel® MediaSDK AVC/H.264
MainConcept H.264
Microsoft Expression Encoder
Theora
x264
XviD (MPEG-4 ASP codec)

You can read it here http://compression.ru/video/codec_comparison/h264_2010/

[julius666]

Dear codec professionals!
We have finished H.264 Video Codecs Comparison report prepearing.
We have tested:

DivX H.264
Elecard H.264
Intel® MediaSDK AVC/H.264
MainConcept H.264
Microsoft Expression Encoder
Theora
x264
XviD (MPEG-4 ASP codec)

You can read it here http://compression.ru/video/codec_comparison/h264_2010/

On the Speed/Quality tradeoff charts, normal preset's chart is missing for me.

[Dyomich]

On the Speed/Quality tradeoff charts, normal preset's chart is missing for me.

Thank you for remark!
Try to refresh your browser window.

[julius666]

Thank you for remark!
Try to refresh your browser window.

Thx, it works now.
Of course x264 is winner in those cases too :cool:

[creamyhorror]

Good to see this comprehensive codec evaluation again. I see MainConcept narrowly beat x264 on HDTV Normal preset. I wonder why? A particular type of material that MainConcept performs better on?

[Dark Shikari]

Good to see this comprehensive codec evaluation again. I see MainConcept narrowly beat x264 on HDTV Normal preset. I wonder why? A particular type of material that MainConcept performs better on?Make sure to check the individual tests; it's quite possible for a single test to shift all the results in one direction if the results are dramatic enough.

[Bordo32]

Blue_MiSfit, just curious if you have done a few codecs comparison as you have mentioned earlier:

"I'll be doing my own comparison soon, between Rhozet Carbon Coder (Mainconcept) and x264 at 50mbps 1080p for mezzanine file purposes."