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/code...codecs_10.html
http://www.compression.ru/video/code...4_2009_en.html
http://www.compression.ru/video/code.../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

[ChronoCross]

Originally Posted by LoRd_MuldeR

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

[Dyomich]

Originally Posted by 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.

[Dyomich]

Originally Posted by ChronoCross

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]

Originally Posted by 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

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

[ChronoCross]

Originally Posted by Dyomich

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]

Originally Posted by Dyomich

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)

[IgorC]

[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]

Originally Posted by Dyomich

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]

Originally Posted by 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].

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.

Originally Posted by Dyomich

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:

[Emulgator]

The flat parts are amazing, feeling calm.