DivX H.264 Encoder Beta 2

[DigitAl56K]

http://labs.divx.com/files/icon_tk_h264.pngIn 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 (http://labs.divx.com/node/11681) 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 (http://forum.doom9.org/showthread.php?p=1313721#post1313721) forum.

[Dark Shikari]

I'll try this encoder and add it to this test (http://x264dev.multimedia.cx/?p=102). 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]

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/gldmmqgznzm/x264-r1206-vs-DivX264-Beta2.7z
* Part 2: http://www.mediafire.com/file/zj2wjcmmid2/x264-r1206-vs-DivX264-Beta2.Part2.7z

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

[nakTT]

x264 r1206 -vs- DivX264 Beta-2:
http://www.mediafire.com/file/gldmmqgznzm/x264-r1206-vs-DivX264-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?p=1313912&postcount=15

[LoRd_MuldeR]

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...

[DigitAl56K]

Let's at least recognize these differences when we do comparisons, otherwise we're comparing apples to oranges and declaring oranges as the clear winner ;)

[Dark Shikari]

Let's at least recognize these differences when we do comparisons, otherwise we're comparing apples to oranges and declaring oranges as the clear winner ;)But everyone does know that oranges beat the hell out of apples. No contest.


(And an encoder without adaptive quantization at all is unlikely to hold much water in any comparison.)

[DigitAl56K]

(And an encoder without adaptive quantization at all is unlikely to hold much water in any comparison.)

Don't worry, we hear you ;)

[nakTT]

IMO it would be unfair to force restrictions on other encoders, just because yours does have these restrictions...
Can't agree more. For end user like me, we only care about the quality of the output file. We don't really care which encoder has what limitation.

Perhaps DivX could provide a nonrestrictive version of their encoder for a retest.

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

HD and CIF samples. Anime and Film included. Both encoders maxed out.
I have one noob curiosity here. I can see that for parkrun under DivX, we have "original framerate" 50 and "framerate" 25? I also can see that this has reduced its bitrate by about half?

[LoRd_MuldeR]

I have one noob curiosity here. I can see that for parkrun under DivX, we have "original framerate" 50 and "framerate" 25? I also can see that this has reduced its bitrate by about half?

DivX produces a "raw" H.264 stream. When I muxed it into MKV then MKVToolnix assumed 25 fps (and I didn't care), instead of the original 50 fps.

But that's just a meta information on the container level, the content itself isn't effected at all. Both were encoded from identical AVS file...

Let's at least recognize these differences when we do comparisons, otherwise we're comparing apples to oranges and declaring oranges as the clear winner ;)

Yeah, this explains why the DivX encoder currently may have "problems" in this scenario. But it doesn't make the entire test unfair.

(I used the highest quality settings of DivX encoder I could find. If you have any tips on how to tune the DivX encoder better for this scenario, I'd be happy to use them :))

[DigitAl56K]

For end user like me, we only care about the quality of the output file.

Stop to think that many more people who end up with your content probably also (maybe even primarily) care about being able to move it around all of their media devices reliably. If you are unwilling to make any sacrifice then others are destined to experience frustration getting your content to play on device xyz.

We've tried to make reasonable sacrifices based on all of the devices we expect to see while also enabling high quality encoding. A simple solution to improving quality is to raise the bitrate a little. Now you get high quality, good efficiency, and less frustration downstream.

Dark Shikari is correct that AQ will also help when it becomes available :)

[smok3]

random thoughts/questions;
a. can i use weird sar values? 345:122 (extended sar)
b. is there a list of standalones that will support interlaced encodes? wdtv tested? (just courious)
c. for bluray i would type? (just a quick example please)
d. nice page about piping from ffmpeg
http://labs.divx.com/node/11681
e. who will get the next cake?

[Atak_Snajpera]

can I ask somebody to send me this encoder. I have no patience for registration! Why do i have to register? Wouldn't be simpler to just make it available for everyone?

[DigitAl56K]

It is available to everyone, maybe this is a misunderstanding. The registration is not moderated and is instantaneous. As soon as you register and click the link in the article to join the apps group you will land on the download page. It takes 60 seconds tops.

[juGGaKNot]

why no support for custom fps ? 35/40 fps

[Atak_Snajpera]

Football 1280x720@50fps
x264
--pass 2 --bitrate 1024 --stats "job1.stats" --min-keyint 50 --keyint 500 --ref 3 --bframes 3
--b-adapt 1 --direct auto --subme 7 --aq-mode 1 --trellis 1 --partitions all --me umh
http://www.mediafire.com/file/mjodjho2nmz/x264.mkv

DivX264
-br 1024 -aqo 2 -npass 2 -sf "Sample.dat"
http://www.mediafire.com/file/dfhmmon4ziy/divx264.mkv
Encoding time on Q6600@3Ghz
x264 - 2min (fast first pass)
DivX264 - 3min (slow first pass)

Highly optimized x264 with AQ+PsyRD+MBtree is light years ahead of rest :)

[Dark Shikari]

Why not just use presets instead of spamming some enormously long commandline?

[Atak_Snajpera]

Why not just use presets instead of spamming some enormously long commandline?
presets do not tell anything about settings used during encoding. Besides I don't use presets. Is this my fault that this forum cannot automatically warp text in CODE?

[Dark Shikari]

presets do not tell anything about settings used during encoding. Besides I don't use presets. Is this my fault that this forum cannot automatically warp text in CODE?I don't think it's fair for x264 to use bizarre commandlines that don't make sense from a speed-quality perspective, and I don't think it's fair for DivX to use long custom commandlines for x264 while DivX only has a single option to adjust speed-vs-quality.

[Atak_Snajpera]

happy now ? :)

[Yoshiyuki Blade]

A lot of those options are redundant since they're x264's defaults anyway :) I think a cleaner command line would look something like:

--pass 2 --bitrate 1024 --stats "job1.stats" --min-keyint 50 --keyint 500 --direct auto --partitions all --me umh

[DigitAl56K]

@Atak_Snajpera But still you are encoding with a much larger max IDR interval when you use x264. Can you link me to the source file?

[DigitAl56K]

random thoughts/questions;
a. can i use weird sar values? 345:122 (extended sar)
b. is there a list of standalones that will support interlaced encodes? wdtv tested? (just courious)
c. for bluray i would type? (just a quick example please)
d. nice page about piping from ffmpeg
http://labs.divx.com/node/11681
e. who will get the next cake?

Hey smok3, good questions.

a. For progressive content you can use any non-extended SAR, extended SAR is restricted because we want to ensure that all devices are able to scale reliably. This ought to cover most use cases, or introduce only a very small error/pre-adjustment. I'll update the DivX Labs article to include that information.

b. Any device that is certified DivX Plus HD will support the interlaced resolutions listed in the DivX Labs article.

c. The idea is not to encode for Blu-Ray, the idea is to encode for any device which will in future have a DivX Plus HD logo on it. That will include Blu-Ray devices, set-top boxes, digital TVs, consoles, PMPs, etc. This is why some of the encoder features are constrained, because we want content to be portable and work reliably everywhere.

d. Thanks :)

e. And who is bringing the beer?

[Atak_Snajpera]

@Atak_Snajpera But still you are encoding with a much larger max IDR interval when you use x264. Can you link me to the source file?
If your encoder does not allow larger values so that is your problem. I have simple rule. min keyint = fps , max keyint = fps*10.
http://x264.nl/h.264.samples/force.php?file=./premiere-paff.ts

[Brother John]

x264: »Here’s some rope to hang yourself with.«
DivX: »Get away from that rope!«
Myself, I’m feeling suicidal. ;)

DigitAl56K, could you shed some light on why DivX decided device-safe defaults wouldn’t be enough and hard restrictions are required? I mean, this is the CLI encoder that’s aimed at expert users anyway, isn’t ist? It seems to me those people will just not use DivX AVC at all if the rope is too short.

[Dark Shikari]

You are all being unfair to DivX; it is reasonable for them to place some restrictions on their encoder, given that they do intend to play these on standalone devices.

So, I did a real, fair test with both encoders under the same restrictions. Hopefully this ends this pointless, stupid debate over whether it's fair to compare codecs with two different keyframe intervals or whatever other BS.

Source: Premiere HD football, 1280x720 (I'll upload the lossless source if anyone asks).
Output files: Mediafire download (http://www.mediafire.com/?0t4ako0jyd5)
Methodology for frame chosen: I picked a random frame which was a P-frame in both encodes, in order to avoid comparing P to B or something equally unfair. Both P-frames were a significant distance from the previous I-frame, to avoid bias from higher quality propagating from the previous I-frame.

DivX settings:

for pass in 1 2;do -aqo 2 -npass $pass -pyramid -bf 3 -br 2000 -i input.avs -o DivX.h264;done
Total time: 7 minutes, 36 seconds.

x264 settings:

for pass in 1 2;do time x264 --preset veryslow input.avs -o x264.h264 --bitrate 2000 --keyint 100 --level 4.0 --pass $pass --bframes 3;done
Total time: 6 minutes, 55 seconds.

DivX:

http://img198.imageshack.us/img198/40/divx.png

x264:

http://img14.imageshack.us/img14/7379/x264.png

Same test at 1 megabit instead of 2 (output files (http://www.mediafire.com/?rfyzcyzgdjf)):

DivX:

http://img34.imageshack.us/img34/2233/divx2.png

x264:

http://img14.imageshack.us/img14/711/x2642.png

Game, set, match, DivX. The 1 megabit x264 beats the 2 megabit Divx.

[microchip8]

x264 one looks a lot better to me :D it seems the DivX one blurred too much

[Guest]

Levels and/or colors are different!

[Dark Shikari]

Levels and/or colors are different!How is that even possible? I inputted from the same Avisynth script and took both of the output images using Elecard Streameye. If there's a level difference, it's a bug in DivX, not in my test.

Edit: I just checked, both output files have the exact same levels, what are you talking about?

(or are you saying that the levels are different from the source, but the same between the two output files?)

[Guest]

Oops, never mind. It was caused by different positioning and thus viewing angle on my large LCD display.

[DigitAl56K]

I'd like to focus the conversation for a moment on what we're really trying to achieve with the DivX Plus HD encoder. To begin, I'll start by saying that we love the x264 project and the dedication of the community in developing solutions that improve the future of digital media. We're not trying to replace x264 or even to compete against it. I've said that many times over but it bears repeating since this always seems to be the immediate reaction whenever we release an encoder ;)

What we're trying to do is support content creation in a way in which media isn't just accessible to the person who encoded it on a desktop computer but also to hundreds or even thousands of non-technical end users who are ultimately likely to want to move the content off to their TV or mobile device in some way or another. This means that we have to recognize two goals: Good efficiency, but also very high compatibility.

It's easy to take the view that the best possible way to encode a video is to enable all of the best settings to achieve the greatest efficiency possible but sometimes there are other considerations to make. For example, Dark Shikari is familiar with tuning x264 for real-time encoding: You want to use the best possible settings but you also need to guarantee that the encoder will not fall behind while encoding multiple channels simultaneously. In short, you have to make some trade-offs and find the right balance to meet your goals. Our biggest goal is to help drive interoperability - to ask people to stop and consider the bigger picture. For example, "Do I want this file to push a PS3 to its limit, or do I want everyone to be able to watch this on any device without worry?" If your file looks looks perfect on the desktop but you take it to your friends place and it stutters periodically because you haven't used a VBV their player can handle are they going to be impressed with your work? If you have to advise some of your friends to spend 2 hours re-encoding for their specific device won't they find that frustrating? ;)

The DivX Plus HD H.264 encoder is designed to focus on making the trade-offs that we believe to be necessary to ensure a good experience on a very wide range of devices. For example, elsewhere in this forum there is discussion on how Blu-Ray devices are tested to support up to 3 bframes, and how files marked as level 4.1 may not be compatible with all Blu-Ray devices due to x264's current slicing implementation. We've even seen content marked as level 4.1 because people believe it will play better on a PS3 even though the PS3 plays level 4.0 content and the data rates in these files rarely tread into 4.1 territory. In reality, all that has happened is that compatibility with 4.0-capable devices has been reduced.

It's worth remembering that the encoder is in beta and its feature set, performance and quality are improving over time. For example, this encoder does not yet use the latest available core (although it was updated from the last beta), we're still tuning the -aqo modes, and features like adaptive quantization aren't included yet. But we're making it freely available to support creating content compatible with all future DivX Plus HD devices, and if you prefer you can already do the same with x264, so although it's interesting to compare encoders that's somewhat of a side-issue.

@Brother John: Some restrictions in the CLI encoder, like IDR interval, could potentially be relaxed to recommended defaults.

@neuron2: What is the viewing angle when you're nose-to-screen? ;)

[InsulinJunkie]

Oops, never mind. It was caused by different positioning and thus viewing angle on my large LCD display.

A TN screen strikes again! :)

[I should confess that I was reading this on my Samsung 26" monitor that's a TN screen, and I thought the same thing about colors on first glance as you did, until I scrolled and realized the cause]

[Zachs]

But why reinvent the wheel when you could take x264 and contribute to it such that it will have a mode (or modes) that is DivX Plus HD device compatible?

[DigitAl56K]

But why reinvent the wheel when you could take x264 and contribute to it such that it will have a mode (or modes) that is DivX Plus HD device compatible?

I would love to see modes in x264! :) I saw that performance presets are being added, if device presets/modes will also be supported this would be fantastic.

[Dark Shikari]

I would love to see modes in x264! :) I saw that performance presets are being added, if device presets/modes will also be supported this would be fantastic.Support in x264 already exists for DivX modes; you could trivially write a 10-line patch to add it as an option and release x264 instead of wasting time on an encoder that's under half the efficiency of x264.

But no, you have to validate your purchase of Mainconcept ;)