DivX H.264 Encoder Beta 2

[DigitAl56K]

In response to your feedback after our Beta 1 release we've been working on the DivX command-line H.264 encoder, and in the first of several updates we are introducing several popularly requested features. These include a target quality mode, support for flagging sample aspect ratio, and support for input via stdin.

Visit DivX Labs to get the download and find more information about Beta 2.

Complementing this encoder, we're also jointly releasing a beta AAC encoder today, check out the thread in the Audio Encoding forum.

[Dark Shikari]

I'll try this encoder and add it to this test. Thanks!

Edit: or I would, if it didn't give me "access denied" when going to your link...

[DigitAl56K]

No access for you!

Okay okay, try again

[Dark Shikari]

Originally Posted by DigitAl56K

No access for you!

Okay okay, try again

Works great now! Thanks. Unfortunately now I realize I can't really do a fair test, because the keyframe interval range is only 1-4 seconds, while the test requires 10 seconds, and given the low motion, that'd probably hurt the results pretty badly.

(any plans to allow longer keyframe intervals?)

Edit: Nevermind, by changing the framerate to 60fps and encoding at 625kbps instead of 250kbps, I can cheat the keyframe interval up to 10 seconds

[Dark Shikari]

Potential bug (in commandline parsing?). Output file is all I-frames:

Summary information:
Number of coded frames 5000
Total encoding time 159531 ms
Average time per frame 31.906 ms
Average speed achieved 31.3 fps
Average bitrate 1819514.21 kbit/sec @ 60.000 Hz

Commandline:

$ /c/Program\ Files/DivX/DivX\ H.264\ Codec\ CLI/bin/DivX264.exe -i maikaze.avs -aqo 2 -I -pyramid -bf 3 -br 625 -npass 1 -o divx.mp4

I notice that I messed up the commandline ("-I" with no arguments), but instead of erroring out, it chose a keyframe interval of zero?

[DigitAl56K]

Dark Shikari,

I was just thinking the same thing. The maximum IDR interval is limited to 4 seconds because we wanted to improve seeking for consumer electronics devices and through experimental testing our team found that this was a reasonable trade-off to make in terms of the impact on overall efficiency and navigation experience, so our encoder adheres to this recommendation.

P.S. Excellent! New bugs to log already

[Dark Shikari]

And another bug (matches the previous report as well):

818365.54 kbit/sec @ 60.000 Hz

the output bitrate is off by exactly a factor of 1000, apparently. The output file itself is correct, of course.

[Dark Shikari]

And another bug: even at 60fps, -I 4 sets the keyframe interval to 96, which is actually 1.5 seconds, not 4 seconds.

[Chengbin]

Also, 60.000 Hz?? Shouldn't it be fps?

[DigitAl56K]

Thanks Dark Shikari, these all sound like issues with the parser, I'll file issues on all of them.

Chengbin: I think hz and fps are reasonably interchangeable in this context.

[Dark Shikari]

Also, remind your asm coders that pshuflw/punpcklqdq is faster than pshuflw/pshufd when splatting a value across a register

[shon3i]

What encoder is behind AAC? or you made from scratch?

[DigitAl56K]

shon3i: The core comes from MainConcept who are now also part of DivX. The command-line version was jointly developed.

Let's try to keep the AAC encoder questions on the AAC encoder thread, otherwise the conversation gets hard to follow

[LoRd_MuldeR]

x264 r1206 -vs- DivX264 Beta-2:
* Part 1: http://www.mediafire.com/file/gldmmq...vX264-Beta2.7z
* Part 2: http://www.mediafire.com/file/zj2wjc...Beta2.Part2.7z

HD and CIF samples. Anime and Film included. Both encoders configures for maximum quality (but no "placebo" settings).

[nakTT]

Originally Posted by LoRd_MuldeR

x264 r1206 -vs- DivX264 Beta-2:
http://www.mediafire.com/file/gldmmq...vX264-Beta2.7z

HD and CIF samples. Both encoders maxed out.

Great. Downloading as we speak. Can't wait to see how far ahead of the curve x264 is compared to DivX Beta 2. Or should I say how close the DivX Beta 2 to x264.

[bob0r]

LOL @ DiVX:
x264 r1206 -vs- DivX264 Beta-2

cif_samples.divx.mkv, the red wall = one big brick, LOL!

[stax76]

@DigitAl56K

StaxRip is now destributed as big package including all used software. Applications with license that don't permit this will simply not be supported at all! Does your new encoders permit this and how big is the compressed file size of your cmdl tools?

[DigitAl56K]

LoRd_MuldeR: x264 with settings maxed out is using very different settings than divx264 with settings maxed out. I would expect to see differences, it's not a very fair comparison.

For example, as Dark Shikari pointed out divx264 is using max IDR interval of 4 seconds to improve navigation on CE devices, whereas you have 20 seconds. You haven't set any vbv parameters, we also limit refs by level 4 requirements and consecutive b-frames to 3 for broad device compatibility whereas you have used 8 (this version of the encoder is expecting to work mainly with HD btw, not CIF material). If you test x264 without similar constraints then of course you are likely to get a better result, potentially at the expense of some device interoperability later. Keep in mind that we always look to find an balance between efficiency and interoperability.

stax76: Interesting. I'll grab the latest StaxRip and take a look today. I'll see what I can work out The size of our tools compressed of course varies by compressor. 7-Zip will compress the AAC and H.264 encoders to about 528kb total using zip-compatible deflate.

[LoRd_MuldeR]

Added more samples:
http://forum.doom9.org/showpost.php?...2&postcount=15

[LoRd_MuldeR]

Originally Posted by DigitAl56K

LoRd_MuldeR: x264 with settings maxed out is using very different settings than divx264 with settings maxed out. I would expect to see differences, it's not a very fair comparison.

For example, as Dark Shikari pointed out divx264 is using max IDR interval of 4 seconds to improve navigation on CE devices, whereas you have 20 seconds. You haven't set any vbv parameters, we also limit refs by level 4 requirements and consecutive b-frames to 3 for broad device compatibility whereas you have used 8 (this version of the encoder is expecting to work mainly with HD btw, not CIF material). If you test x264 without similar constraints then of course you are likely to get a better result, potentially at the expense of some device interoperability later. Keep in mind that we always look to find an balance between efficiency and interoperability.

stax76: Interesting. I'll grab the latest StaxRip and take a look today. I'll see what I can work out The size of our tools compressed of course varies by compressor. 7-Zip will compress the AAC and H.264 encoders to about 528kb total using zip-compatible deflate.

Well, this was a test with "high quality" (but not "placebo") settings. That's what I actually use every day

If your encoder has hardcoded limitations that can't be bypassed, there is nothing I can do. But it's certainly not "unfair", because you could offer more (and less restrictive) options.

IMO it would be unfair to force restrictions on other encoders - restrictions I don't have normally - just because yours does have these restrictions...