What is new in DivX 6.8.3?

[Leica]

From 6.8.2? Any new features? Or just boring bug fixes?

[neuron2]

From divx.com:

Up to 50% faster decoding on multi-core computers for better HD playback

New custom matrices that allow better fine tuning of the encoder for specific content types

Compress digital video 5 to 10 times more than MPEG-2/DVD format and hundreds of times over raw digital video

Encode high-definition (HD) video at resolutions up to 1080p

Play DivX videos on almost any 3rd party software media player

Achieve the perfect balance between visual quality and performance with six carefully optimized encoding modes

Enjoy maximized performance for all multithreaded processors (Intel Core Duo and Core 2 Duo, AMD Athlon 64 X2 and Athlon 64 FX)

Reduce grain and low-light noise (common with DV cameras) without significantly degrading the video with the automated noise reduction feature

[ron spencer]

hasn't this version been out for a long time?

[clsid]

That's an old changelog, from 6.7.0 or 6.8.0 I think.

[LoRd_MuldeR]

Well, the Readme says:

| 1. Introduction
+=========================-

   Welcome to DivX Codec 6.8.3
   
   Mostly fixing some issues to further improve your
   experience.  Check out what's new in this version below.

   Please give us any feedback you have about this release
   via the DivX Labs website:

     http://labs.divx.com

     - The DivX Team


| 2. New In This Version
+=========================-

   Fixes:

     * Fixed encoder to prevent artifacts when outputting interlaced content

     * Multithreading fixes and improvement

     * Minor GUI fixes and cosmetic changes

[DigitAl56K]

One of the more significant fixes in this minor update was reported here by dloneranger. In summary there was a problem with part of the multithreading implementation, variations of the symptoms including playback stuttering or stalling, high CPU use for Explorer while building thumbnails, and similar performance issues affecting both DirectShow and VfW applications. The problem was uncommon, but worth fixing for those experiencing it.

[Leica]

Sorry if this is off topic, but WHEN will we get DiVX 7???

Divx 6.x has been out for "Donkey's Ears" ! ! !

So please just tell me when DivX 7 is coming, otherwise I will just learn x264 and use that for all my encoding, something which I do a LOT!

[Ranguvar]

At risk of getting flamed, I advise you to check out x264. It can destroy pretty much any other H.264 codec out there. DivX is going to have a very steep uphill battle if they want to rival x264.

[Dark Shikari]

Originally Posted by Ranguvar

At risk of getting flamed, I advise you to check out x264. It can destroy pretty much any other H.264 codec out there. DivX is going to have a very steep uphill battle if they want to rival x264.

Quite true, given that x264 wipes the floor with many of the top commercial encoders (even enterprise-grade ones, let alone the cheaper ones). If DivX can even get close to x264, that also means its beating many others such as Scientific Atlanta and Mainconcept, companies with far more experience (and possibly more money, too) than DivX.

If it happens at all, it will likely take DivX quite a while to become competitive if only because they're starting so late.

Of course, I think they'd be better off giving up on such a futile endeavor, using x264 instead, and sticking what they've always done best--standardizing hardware devices to play videos.

[DigitAl56K]

Leica, we're working on DivX 7. Project Rémoulade is part of this effort.

I also agree with Ranguvar and Dark Shikari, you should definitely look at x264! It is a very good encoder and you can use the streams it creates with the DivX H.264 Decoder betas. DivX ASP (4,5,6) still has it's place - it's extraordinarily fast to encode these days even on high quality settings, playback requirements are extremely light, and it's supported by hundreds of millions of devices - even low powered devices like mobile phones (check out the LG Secret and the Viewty).

@Dark Shikari: I think when it comes to encoders options are always nice. x264 is a very feature rich and capable encoder. DivX may release an encoder that is more specifically designed to work around hardware compatibility, as you mention, with perhaps easier configuration (we're still working out the details). I would like to make sure x264 can produce streams compliant to our profiles, and hopefully having more than one encoder will drive each to improve upon the other. Certainly we aren't going to release an encoder for the purposes of competing with x264, if anything my "dream" outcome is that DivX brings to the table a standard that is interoperable across a very wide range of devices, just as we did for ASP, and that we give you guys any help or tools you might need to take advantage of that platform (admittedly, we could have done better on this front in past). End-users ideally have the option of using their preferred encoder, whichever that is, in many applications.

Side: DivX acquired MainConcept last year. The DivX H.264 codec will leverage work from both teams.

Of course, now we are quite far off-topic. Apologies to the moderators! Since the original topic was answered already hopefully you don't mind too much.

[LoRd_MuldeR]

Which interface will the upcoming DivX H.264 encoder use? I doubt it will use VfW, as DivX 6 (and previous) used to do until now. Also you say that you are targeting for easy configuration, which excludes a CLI encoder. IMHO the remaining options are: A library to be licensed and used by other video editing/encoding applications or a "standalone" DivX encoding application...

[Dark Shikari]

Originally Posted by LoRd_MuldeR

Which interface will the upcoming DivX H.264 encoder use? I doubt it will use VfW, as DivX 6 (and previous) used to do until now. Also you say that you are targeting for easy configuration, which excludes a CLI encoder. IMHO the remaining options are: A library to be licensed and used by other video editing/encoding applications or a "standalone" DivX encoding application...

Well the smart thing to do would be to make it an x264 GUI, since it would save them the millions of dollars of developing their own encoder and be quite a bit faster to boot.

[DigitAl56K]

Originally Posted by LoRd_MuldeR

Which interface will the upcoming DivX H.264 encoder use? I doubt it will use VfW, as DivX 6 (and previous) used to do until now. Also you say that you are targeting for easy configuration, which excludes a CLI encoder. IMHO the remaining options are: A library to be licensed and used by other video editing/encoding applications or a "standalone" DivX encoding application...

There will be a CLI encoder. There are many ways to achieve an easier configuration, though. For example, it's unlikely that we'll expose everything x264's --longhelp does. We may enable profile-conformance options by default so that it's harder to go wrong, and so forth. It's likely that there will also be licensed applications and a DivX encoding application, although these things are further out and I don't have all the details just yet.

Pre-release versions of the encoder will become available as part of Project Rémoulade. You'll have plenty of time to try them and give your feedback

[Ranguvar]

I eagerly await DivX 7, because the way I benefited from DivX 4+ was the much improved number of standalones playing ASP content. I just ask that DivX 7 certified devices need to support high profile, and attempt to play level 4.1 content, even if it stutters Oh, and 5 reference frames, too And while I'm wishing, how about the MKV container, AAC 5.1, Vorbis, and b-pyramid xD

[Inventive Software]

Or the full feature set of Level 5

[Brother John]

DivX adopting Matroska as the container really would be fantastic. Maybe it's not that unlikely since MP4 does have severe limitations especially with audio – as long as you don't want to mess with private stream kludges. It might be necessary to restrict possible formats via profiles, but with Matroska the base for extensions would already be in place, and in a well defined way without the danger of incompatible competing implementations. A real horror scenario would be stuff like incompatible DivX-AC3-MP4 and Nero-AC3-MP4.

[DigitAl56K]

Originally Posted by Ranguvar

I eagerly await DivX 7, because the way I benefited from DivX 4+ was the much improved number of standalones playing ASP content.

Yes, like the current generation what we want to achieve is a standard that brings interoperability to many classes of devices, everything ranging from mobile phones and PMPs right through to digital video cameras, set-top boxes, Blu-Ray players and connected devices. Media should be transportable with minimal effort and you should be able to know that your files are going to play well wherever you take them.

I just ask that DivX 7 certified devices need to support high profile, and attempt to play level 4.1 content, even if it stutters Oh, and 5 reference frames, too And while I'm wishing, how about the MKV container, AAC 5.1, Vorbis, and b-pyramid xD

Some nice suggestions Keep them in mind because I'll be starting a more in-depth discussion of DivX 7 in the near future. It's important to remember that what brought compatibility across many devices for DivX 5 and 6 was balancing certain bitstream properties so that we allowed for efficient coding with a standard that many devices could work to adhere to. Nothing prevents manufacturers from going above and beyond if they choose to - it happens today. What is important is that there is some known baseline that is consistently implemented and thoroughly tested so that you know if you adhere to it during content creation your file is going to play reliably on any certified device.

If you think back seven or eight years DivX was really the first company to try to find a standard that was designed around bridging the gap between high quality video on the Internet and the general consumer in the CE space. To do this we had to constrain certain properties of the encoder and there was a lot of pushback from many people who wanted an unconstrained MPEG-4 ASP format. I think that now there is a clear precedent that shows what can be achieved if we can find a good compromise. That's not to say, of course, that there isn't value in a fully-capable H.264 encoder such as x264. What is important is applying the right settings for the intended purpose, and as I mentioned previously my personal ideal outcome would be that we help enable that for x264 and applications that use it also.

Originally Posted by Brother John

DivX adopting Matroska as the container really would be fantastic.

DivX 7 will use the MKV container format! That's right, you heard it here first: our new format does not use AVI! Those of you now planning a street party do remember to send me an invitation

A real horror scenario would be stuff like incompatible DivX-AC3-MP4 and Nero-AC3-MP4.

Yeah, let's not do that

[mdoubledragon]

That why I like Divx. They are a company with a vision. First of all they wont give up on ASP and keep improving it release after release. Then they have also embraced AVC and did the right thing by coming to Doom9 to get real professional opinion from gurus of the field. And now they are shifting the container to the most loved one, Matroska. One word; Respect.

[GodofaGap]

Originally Posted by DigitAl56K

DivX 7 will use the MKV container format!

Wow. Just... wow!

[SeeMoreDigital]

Originally Posted by Brother John

DivX adopting Matroska as the container really would be fantastic. Maybe it's not that unlikely since MP4 does have severe limitations especially with audio – as long as you don't want to mess with private stream kludges.

Actually that's all about to change... The official specs for placing AC3 (and E-AC3) audio streams within the .MP4 container are due to be released this summer

Edit: As Bond previously wrote it forms part of: Annex F to the AC3 standard ETSI_TS_102_366