DivX 6.6 released

[crnagora]

Well, that was fast...couple of days after the Intel Penryn-Showdown 6.6 is already released. Good work DivX guys.

http://www.divx.com/divx/windows/

The changelog:

- Up to 12% faster decoding for smoother playback
- Over 10% faster encoding in “Insane” mode
- Up to 7% better compression for HD capture in "Fastest" mode
and
- Experimental support for SSE4 on new Intel Penryn CPUs (Like anyone has one of them except a couple of developers and Intel guys :rolleyes: ) :

http://img390.imageshack.us/img390/8587/66timingchartfx4.gif

Well, more speed for everybody :thanks: .

If DigitAl56k surfs around:

1. Any other changes ? Quality-wise ?

2. Enhance the damn I-Blocks...what does this option do ? I suppose "Enhance Textures" (till DivX 6.4) and this "Enhance I-Blocks" is the same thing. But what is it exactly ? Its under the psychovisual stuff so I think it is some psychovisual stuff too ( :stupid: )

3. A response to this thread would be cool to stop rumors or false assumptions : http://forum.doom9.org/showthread.php?t=125321

Cheers.

[Romario]

I am dissapointed, too quick release, too quick.

And nothing is really new, except experimental SSE4 support.

[Kurtnoise]

Still no support for Vista (according to the disclaimer) ? Does anyone have already tested this codec on the new OS ?

[falcon2000eg]

Still no support for Vista (according to the disclaimer) ? Does anyone have already tested this codec on the new OS ?
yes,no problem on vista ultimate.But I'm only using the codec not the encoder.

[DigitAl56K]

1. Any other changes ? Quality-wise ?


It depends how you want to look at things :) Better compression (e.g. in Fastest mode) means better quality. Insane mode being faster means better quality in less time.

But yes, there are other quality improvements. We tweaked the motion search a little and this resulted in most modes being up to 2% more efficient when encoding HD material.


2. Enhance the damn I-Blocks...what does this option do ? I suppose "Enhance Textures" (till DivX 6.4) and this "Enhance I-Blocks" is the same thing.But what is it exactly ?

Intrablocks are coded more accurately. In action scenes (e.g. explosions) this reduces the appearance of blocks. It also makes the picture quality better for all keyframes. Usually I find that keyframes tend to look slightly more blocky and are "smoothed" slightly due to motion compensation by the next two reference frames. This is generally a good trade-off against bitspend. However, for certain types of content, e.g. music videos, which have a lot of cut scenes, flashes, and so forth, it's sometimes nicer to accept a higher bitrate in order to improve intrablocks.

This is an option I use on a case by case basis as necessary - depending on how many I frames (or more generally I blocks) you're going to have the additional data spend, or increase in average quantizer (for average bitrate modes), may significant.


3. A response to this thread would be cool to stop rumors or false assumptions : http://forum.doom9.org/showthread.php?t=125321

Cheers.

I saw this thread a few days ago, and although this particular issue is outside of my area of expertise I did send off e-mails to various folks internally who should be able to comment (actually I see theKid already posted a short reply).

@Romario: We made it faster and improved the compression! Okay, we didn't add any new check boxes this time around - but we're running out of space in the GUI!

Does anyone have already tested this codec on the new OS ?

We're not calling it Vista compatible quite yet, but to the best of my knowledge the key codec components (VFW codec, DShow decoder) should work on Vista just fine (32-bit version).

We're updating all of our software right now, I'll keep you posted.

[bond]

We're not calling it Vista compatible quite yet, but to the best of my knowledge the key codec components (VFW codec, DShow decoder) should work on Vista just fine (32-bit version).hm, i have read somewhere that vista doesnt support vfw anymore!? it seems thats propably not true

[clsid]

Vista doesn't show VFW/ACM stuff anymore in the device manager. But I think it still supports such codecs.

[falcon2000eg]

i'm using vista ultimate 32-bit .just did small encoding test using virtualdub 1.7 and it works fine.

[crnagora]

Intrablocks are coded more accurately. In action scenes (e.g. explosions) this reduces the appearance of blocks. It also makes the picture quality better for all keyframes. Usually I find that keyframes tend to look slightly more blocky and are "smoothed" slightly due to motion compensation by the next two reference frames. This is generally a good trade-off against bitspend. However, for certain types of content, e.g. music videos, which have a lot of cut scenes, flashes, and so forth, it's sometimes nicer to accept a higher bitrate in order to improve intrablocks.

This is an option I use on a case by case basis as necessary - depending on how many I frames (or more generally I blocks) you're going to have the additional data spend, or increase in average quantizer (for average bitrate modes), may significant.


So this is a tradeoff ? Quality of the Keyframes/Intrablocks will be better but therefor the quality of the p-frames will be lowered ? Correct ?

You guys really should think about updating the old DivX Guide for the new options and codec-settings.

[DigitAl56K]

So this is a tradeoff ? Quality of the Keyframes/Intrablocks will be better but therefor the quality of the p-frames will be lowered ? Correct ?

Correct, for modes that target an average bitrate. For quantizer-based modes this simply means larger file sizes.

You guys really should think about updating the old DivX Guide for the new options and codec-settings.

SeaBass (our customer service guru, which is just one of his many talents) is actually going to be doing that real soon!

[DigitAl56K]

DivX 6.6.1 has been released

I'll post a news announcement shortly and assemble a version history. We've been working like crazy on it and I wanted to get it live before the weekend :)

You can download our full bundle from DivX.com (http://download.divx.com/divx/DivXInstaller.exe), or get just a patch for the codec (http://download.divx.com/divx/autoupdate/codec/PatchInstaller.exe
).

More later :)

[crnagora]

DivX 6.6.1 has been released

I'll post a news announcement shortly and assemble a version history. We've been working like crazy on it and I wanted to get it live before the weekend :)

More later :)

:thanks:

And also thanks for the previous answers DigitAl56K.

Hm...interesting:

DivX 6.6 Package-Download ~ 14,1 MB

DivX 6.6.1 Package-Download ~ 20,6 MB

So over 6 MB increase in size of the bundle. Must be a hell of a changelog ;) :p .

Speaking of hell: Will we see a DivX 6.6.6 in near future ? :devil:

Cheers and thanks for the updates.

EDIT:
Sorry...I edited my post for better understanding ;). It was about the download-size of the divx-bundle (Not of a encoded clip).

[DigitAl56K]

:thanks:

So over 6 MB increase in size. Must be a hell of a changelog ;) :p .


Settings? (e.g. CLI string for first and second pass, input width/height/framerate/format), and application/build number?

[crnagora]

Settings? (e.g. CLI string for first and second pass, input width/height/framerate/format), and application/build number?

:confused: Uhm...i was talking about the Download-Size of the DivX-Bundle (And comparing how it increased from 6.6 to 6.6.1). So the CLI string should be: http://download.divx.com/divx/DivXInstaller.exe :)

The codec works fine...so it was not a bug-report or whatever about the codec...just curiosity about the 30% increase in Size of the DivX-Bundle.

Sorry for the misunderstanding.

[DigitAl56K]

Ahhh, why not to get out of bed and proceed directly to Doom9! I just spent the past half an hour running test encodings! Thanks man :P ;)

Anyway, the increase in file size is because the bundle is 30% better!

.. okay okay :) As you may know, if you haven't got Firefox installed we may offer it to you during installation. In past we have always then gone on to download it as necessary but the experience is not so good - for example what if your machine needs a restart at the end of installation but we're supposed to be doing a download? So we're experimenting with bundling in the installer to see how that works out. Most of us are on fast connections these days and the difference between 14Mb and 20Mb for an installer is a bit of a non-issue, especially for people downloading high-quality video. We think.

I don't particularly want to have pages of discussion of that in this thread because it's a little off-topic, but that's the answer.

[fight2win]

is this vista compatible? when is new dr. divx coming?

[DigitAl56K]

is this vista compatible?

See above :)

When is new dr. divx coming?

Dr DivX is an open source project - the new version is coming whenever someone contributes the code to update it!

[olnima]

Beside all the posts about increased filesizes and things it would be nice to get a little changelog from 6.6 to 6.6.1

:thanks:

Olnima

[Romario]

Changelog for 6.61? I can't find it nowhere.

[DigitAl56K]

Sorry guys, after four or five weeks solid in the office I took the weekend off! I know, I'm a slacker... ;)

New:
Experimental search dropdown box is now enabled for CPUs with SSE2

Note: It is not possible to compare this search method with the normal operation of DivX Codec 6.6 or prior. The experimental search does additional work and therefore is naturally slower. We’re enabling it so that comparisons between the Penryn using SSE4 and older processors using the equivalent SSE2 routine are possible.

Fixed:
The VFW decoder did not render frames for certain bitstreams when post-processing was disabled
Fixed decoding b-frames for clips with data partitioning
Fixed a small motion compensation error in b-frames when using quarter pixel estimation
Fixed a VLD issue that could cause blocks to appear in the decoded picture
Fixed bitrate resetting to default when changing from Fast 1st pass to Nth pass rate-control mode
Changed default VBV initial occupancy to 100%
Workaround for later versions of VirtualDub and derivatives where additional frames were being written to the multipass log file in Fast 1st pass mode
Fixed handling of forced aspect ratio in DirectShow decoder

[olnima]

Thanks Digit...

Olnima

[weaver4]

How does 6.6 work with the tools that are out there right now like: avi.net, autogk, mpeg mediator, video studio, vdub, vdubmod, FUW and such?

It does not seem to work well with Dr. Divx.

[DigitAl56K]

It does not seem to work well with Dr. Divx.

This is simply because Dr DivX doesn't recognize the new DLL version. Like I say, Dr DivX 2 is open source - it will work just as soon as someone contributes the appropriate patch. There are many people on this forum with the capability to update Dr DivX! This is one of the main virtues of open source, no? :)

[weaver4]

I completely understand the reasons that you went the way you went for Dr DivX. But Linux and Mac portability is a difficult thing to accomplish. I have not heard a word about ever achieving Linux capability now. And in the Mac World most people use H264 and when they use Divx or Xvid they use Quicktime, VisualHub or Handbrake.

So what you are left with is a program that really only runs on Windows but was written in C++ using wxWidgets. Not a very attractive environment to recruit developers to.

[d00kl1]

But Linux and Mac portability is a difficult thing to accomplish.


We have accomplished it since the Dr. runs on OS X too. It is only difficult to accomplish if the wrong decisions are made at the inception of the project and not designed to be ultimately deployed on OS X.

The libraries that the Dr. uses for it's functionality are all portable and with an acceptable open source license.

We don't foist an extra runtime on the user to allow them to run this portable application.


I have not heard a word about ever achieving Linux capability now.


The idea was to move towards Linux after the OS X port was complete. With the lack of development help, this effort isn't progressing.


And in the Mac World most people use H264 and when they use Divx or Xvid they use Quicktime, VisualHub or Handbrake.


The same argument could be said for MS Windows users where there are more choices and there are umpteen other applications other than the Dr. that provide similar feature set.

The overall goal for the project is easy DivX media creation on every desktop platform with the application having the same feature set on all 3. The OS X and Linux platforms shouldn't be treated as second class citizens. There are users for DivX production and consumption on all 3, MS Windows is the majority but that doesn't mean the OS X and Linux user base is trivial and non-influential.

[weaver4]

My only point was that MS has 93% market share in OS. Mac has 5% market share, but most people on a Mac would use Quicktime anyway; or H264. Linux has 2% market share, but DivX does not run on it as of yet.

So my point was that probably 96-98% of the time Dr. Divx would be running on Windows. And, if you wrote the project for Windows only it would of taken considerably less effort. If you wrote it in Windows .Net I could of helped.

[DigitAl56K]

Build 6.6.1.4 is now live. It has three changes:


Fix: Feedback window is no longer automatically enabled after a Fast 1st Pass
Fix: Encoder was crashing on 8 core systems
New: Up to 8 threads are enabled