PDA

View Full Version : What is new in DivX 6.8.3?


Leica
11th June 2008, 10:30
From 6.8.2? Any new features? Or just boring bug fixes?

neuron2
11th June 2008, 15:01
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
11th June 2008, 16:54
hasn't this version been out for a long time?

clsid
11th June 2008, 17:20
That's an old changelog, from 6.7.0 or 6.8.0 I think.

LoRd_MuldeR
11th June 2008, 18:11
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
11th June 2008, 21:10
One of the more significant fixes in this minor update was reported here (http://forum.doom9.org/showthread.php?p=1120829#post1120829) by dloneranger (http://forum.doom9.org/member.php?u=33034). 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
23rd June 2008, 03:15
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
23rd June 2008, 19:08
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
23rd June 2008, 19:34
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
23rd June 2008, 20:57
Leica, we're working on DivX 7. Project Rémoulade (http://forum.doom9.org/showthread.php?t=137786) 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
23rd June 2008, 21:08
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
23rd June 2008, 21:11
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
23rd June 2008, 22:42
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
24th June 2008, 02:06
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 :p 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
24th June 2008, 03:21
Or the full feature set of Level 5 :)

Brother John
24th June 2008, 18:20
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
25th June 2008, 04:16
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 :p 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.

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
25th June 2008, 08:39
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
25th June 2008, 10:35
DivX 7 will use the MKV container format!
Wow. Just... wow! :goodpost:

SeeMoreDigital
25th June 2008, 10:59
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

Brother John
25th June 2008, 17:15
Those of you now planning a street party do remember to send me an invitation ;)
OK. :D Tonight, Bayreuth (http://en.wikipedia.org/wiki/Bayreuth). Grilling and football: European Championship semi finals: Germany against Turkey. This country will go crazy later tonight: no matter how the match ends.

@SMD
Thx for the info. Will be interesting to keep an eye on this.

Ranguvar
26th June 2008, 03:09
Yes! Matroska for the win =) Thanks, DivX!!

BetaBoy
26th June 2008, 04:48
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 ;)

Yeah, let's not do that :)

\0/ I can talk about it now ;-) its good to hear that DivX has adopted Matroska (welcome aboard)... I will talk about more details on what is coming up for Matroska, especially as it relates to v2.0 and the Matroska Foundation later on (and not to go far OT).

delacroixp
26th June 2008, 14:02
Sorry if this is off topic, but
... is there any chance that DivX 7 will implement support for GPU encoding... certainly a great boost to HD encodes !

It's all good.


:):devil::D
Pascal

Ajax_Undone
27th June 2008, 05:25
Yes I would like to see this as well... I have 2 3870 x2 OC edition's and would love to see them help the CPU Out...

bond
27th June 2008, 20:01
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 ;)will divx use native avc mode or vfw compatbility mode in mkv?

madshi
27th June 2008, 21:19
DivX 7 will use the MKV container format!
Another big thumbs up from me!! :)

:thanks:

ChronoCross
28th June 2008, 05:48
All this hardware compatibility stuff seems an odd discussion to be having considering how much is defined by the H264 standard. Shouldn't you just be able to use the different levels to determine hardware compatibility rather than creating your own (which for the most part are very limited compression wise in ASP). That way every encoder can simply conform to the various levels rather than trying to meet a specific set that divx sets.

ChronoCross
28th June 2008, 05:49
will divx use native avc mode or vfw compatbility mode in mkv?

One would hope that vfw isn't even in their vocabulary when talking about AVC.

spyder
30th June 2008, 00:10
Maybe someone should point Sascha Segan of PC magazine at this thread. Someone needs to tell him DivX is entering the tentacle porn industry.

delacroixp
30th June 2008, 08:54
Maybe someone should point Sascha Segan of PC magazine at this thread.
Welcome back... nice to see MKV developers surfacing on Doom9.

It's all good !


:):devil::D
Pascal

DigitAl56K
30th June 2008, 21:02
... is there any chance that DivX 7 will implement support for GPU encoding... certainly a great boost to HD encodes !

Hi Pascal,

Similar to the decoder we are working on the software implementation first. Of course there is always a chance in the future, but it's not something you'll see in 7.0.

Although GPU encoding could be fast (in fact a recent article from Anandtech (http://www.anandtech.com/video/showdoc.aspx?i=3339) show it is fast), I'm going to hold my breath until I see someone talk of the quality/efficiency that can be achieved. You'll notice that so far the details here range from light to non-existent :) CUDA though is definitely interesting, as is the AMD Stream Computing SDK.

will divx use native avc mode or vfw compatbility mode in mkv?

While we continue to develop elements of our spec we're trying to avoid going into details too early. I'll make sure to address your question as soon as I'm able to do so with confidence.

Shouldn't you just be able to use the different levels to determine hardware compatibility rather than creating your own (which for the most part are very limited compression wise in ASP).

Well, to begin I'd say that our compression in the ASP encoder was not very limited. If you compare it to an unrestricted encoder such as XVID on best settings you'll probably struggle to get more than 5-10% better efficiency for the same quality while the DivX profile-compliant version will have much better compatibility with devices. At the end of the day it's a balancing act. Personally, while I always strive for the highest quality I can get I really won't loose any sleep over 50MB of hard drive space, but recoding a video later just so that a friend can watch it on their DVD player is going to be a real pain.

Levels are one way to go, but then ASP also had levels. Levels work only if all manufacturers fully support everything in the same level equally well, and that doesn't always happen. There are ASP devices even today that still can't pass DivX Home Theater certification. What we actually did with ASP was to talk to many manufacturers to understand what all of their devices were capable of in terms of feature support, rate support and so forth, and then define a profile that we believed would bring interoperability across many of these devices without sacrificing efficiency too much. We're doing the same now for H.264 and we have had a lot of feedback that is very varied. The challenge is to bring this all together into a good solution not only for the manufacturers but for the community. Beyond the spec for the video bitstream we also need to ensure that every element of the format is specified and that conforming media will play reliably everywhere. It's neither a small nor easy task.

Maybe someone should point Sascha Segan of PC magazine at this thread. Someone needs to tell him DivX is entering the tentacle porn industry.

Sounds like a press release!

ChronoCross
30th June 2008, 21:26
Well, to begin I'd say that our compression in the ASP encoder was not very limited. If you compare it to an unrestricted encoder such as XVID on best settings you'll probably struggle to get more than 5-10% better efficiency for the same quality while the DivX profile-compliant version will have much better compatibility with devices. At the end of the day it's a balancing act. Personally, while I always strive for the highest quality I can get I really won't loose any sleep over 50MB of hard drive space, but recoding a video later just so that a friend can watch it on their DVD player is going to be a real pain.

Levels are one way to go, but then ASP also had levels. Levels work only if all manufacturers fully support everything in the same level equally well, and that doesn't always happen. There are ASP devices even today that still can't pass DivX Home Theater certification. What we actually did with ASP was to talk to many manufacturers to understand what all of their devices were capable of in terms of feature support, rate support and so forth, and then define a profile that we believed would bring interoperability across many of these devices without sacrificing efficiency too much. We're doing the same now for H.264 and we have had a lot of feedback that is very varied. The challenge is to bring this all together into a good solution not only for the manufacturers but for the community. Beyond the spec for the video bitstream we also need to ensure that every element of the format is specified and that conforming media will play reliably everywhere. It's neither a small nor easy task.



Well IMHO I think that saying that 50MB of space is plenty of space to waste for the same quality of video. I suppose if I look at it from your compatibility point with your profiles the quality is fine for that.

I however don't really buy into the argument that the levels can't be used. they are well defined on what one should expect out of each profile. A hardware manufacturer can't say the support x level if they really don't. So in reality it would be best to push fully compliant support across hardware manufacturers.

While this is definitely detrimental to DivX on the branding level as DivX compliant would simply be another word for AVC Levels Compliant I think it would be better off for AVC as a whole and accomplishes the same point of what Divx certification does.

that's the main difficulty with ASP is that there are so many different vendor specific profiles going around (Nero, Divx, Xvid (various)) that I personally see myself looking at a huge chart going.....so what plays what? Will my Nero files play on divx will my divx files play on nero. If everyone sticks to the standard I don't have to ask myself that question if I buy such a hardware device. We need to avoid it in AVC if at all possible.

At least that's how I feel about it. Not sure how many would agree with me but I think that fewer profiles is better.

DigitAl56K
30th June 2008, 22:03
At least that's how I feel about it. Not sure how many would agree with me but I think that fewer profiles is better.

Agreed, that's why we're trying to find a combination that works broadly. Can you pick a level right now and based on that alone know that your file will play well everywhere?

Dark Shikari
30th June 2008, 22:10
Agreed, that's why we're trying to find a combination that works broadly. Can you pick a level right now and based on that alone know that your file will play well everywhere?Level 4.1 High Profile; it'll play on all devices I care about.

Even DivX obviously can't get playback everywhere; unless you're willing to go for Restricted Baseline to satisfy iPods, of course, in which case you're completely crippling the format to the point of uselessness, which I'm pretty sure DivX won't do.

You have to draw the line somewhere, no matter who you are and what you're doing.

ChronoCross
30th June 2008, 22:23
Level 4.1 High Profile; it'll play on all devices I care about.

Even DivX obviously can't get playback everywhere; unless you're willing to go for Restricted Baseline to satisfy iPods, of course, in which case you're completely crippling the format to the point of uselessness, which I'm pretty sure DivX won't do.

You have to draw the line somewhere, no matter who you are and what you're doing.

perfect example of what i was talking about. Just picking and choosing random features to support is incredibly confusing. If it was like 4.1 high then you know exactly what can and cannot be enabled in the encoder.

For all these things XBOX 360, PS3, ipods, iphones, etc used levels it would be a much better place.

DigitAl56K
30th June 2008, 22:27
Level 4.1 High Profile; it'll play on all devices I care about.

It'll play on BluRay players.

SeeMoreDigital
30th June 2008, 22:31
It'll play on BluRay players.High@Level 4.1 is the maximum specified profile for both Blu-ray and HD-DVD....

Dark Shikari
30th June 2008, 22:37
It'll play on BluRay players.And most STBs and Xbox 360 and PS3 and all hardware-acceleration-supporting graphics cards and basically all standalone players...

I can't think of anything in the gap between "hardware player supporting HD material at Level 4.1" and "little device I can hold in my hand" (PSP, iPod, etc).

Brother John
30th June 2008, 22:38
As I understand it, the problem is that every manufacturer can just use the label »support for H.264 profile/level x/y« without any restriction. There are no procedures in place to ensure that such a device actually fully supports profile x and level y.

On the other hand you are only allowed to put a »DivX profile X« sticker onto your device if you’ve gone through the DivX certification process. So as a consumer the DivX profile label tells me exactly and (more important) reliably what the device is capable of.

Of course the full DivX profile specs should be freely available to everyone so that one can setup any encoder to produce compliant video. That might already be the case for current DivX profiles, I’ve never checked.

Manao
30th June 2008, 22:53
I can't think of anything in the gap between "hardware player supporting HD material at Level 4.1" and "little device I can hold in my hand" (PSP, iPod, etc).Apple TV. And at least one of the STB (netgem) I regularly use at work (it caps around 20mbits in 1080i30).

However, I agree to say that the need for third party levels for AVC is a lot less dire than it was for ASP. Two years ago, it would have been another story, but now the processing power is there, so it's not necessary anymore.

ChronoCross
30th June 2008, 23:44
The only problem I see with what you said Brother John is that other encoders aren't going to want to put "Certified to create DivX certified streams" in their products as that's free advertising and supporting the rule of law of the other company. Thereby creating a rift in the profiles as their companies adopt their own "standard profiles". It would be much better for them to just be able to say "Level 4.1 Compatible"

Inventive Software
1st July 2008, 00:03
If we're talking DivX Certification here for a second, my thought would be that SD could be 4.1 or 4.2 High Profile compliant, and HD could be 5.1 High Profile compliant, thus keeping a wide spread of the H.264 standard's features. In practice, only the image size/frame rate and number of macroblocks and max bitrate changes between 4.1/4.2 and 5.1, the difference in bitrate and macroblock terms is 5.1 has 4x the macroblocks per second of 4.1, and 5.1 High has a max bitrate 6x bigger than 4.1.

Dark Shikari
1st July 2008, 00:07
If we're talking DivX Certification here for a second, my thought would be that SD could be 4.1 or 4.2 High Profile compliant, and HD could be 5.1 High Profile compliant, thus keeping a wide spread of the H.264 standard's features. In practice, only the image size/frame rate and number of macroblocks and max bitrate changes between 4.1/4.2 and 5.1, the difference in bitrate and macroblock terms is 5.1 has 4x the macroblocks per second of 4.1, and 5.1 High has a max bitrate 6x bigger than 4.1.There's no way in hell you'll get anyone to support 5.1, primarily given the fact that for all intents and purposes (nearly) no hardware exists in the current world that even supports 5.1 completely.

Ranguvar
1st July 2008, 00:19
There's no way in hell you'll get anyone to support 5.1, primarily given the fact that for all intents and purposes (nearly) no hardware exists in the current world that even supports 5.1 completely.
It would be better to ask for 4.1 compatibility, but also ask that the players attempt to play videos even if they have higher levels. Nothing annoys me more than patching a 5.1 video to 4.1, and then it works perfectly. It's like, "Why didn't you just give it a shot at playing instead of running in fear from the big 5 1?"

Inventive Software
1st July 2008, 00:33
It would be better to ask for 4.1 compatibility, but also ask that the players attempt to play videos even if they have higher levels. Nothing annoys me more than patching a 5.1 video to 4.1, and then it works perfectly. It's like, "Why didn't you just give it a shot at playing instead of running in fear from the big 5 1?"

Your solution sounds the easiest, but I'm also surprised players don't do this. :D

DigitAl56K
1st July 2008, 00:41
The CE world is not as clear cut as you might imagine when it comes to H.264. There are many STBs that do not fully support High 4.1.

The only problem I see with what you said Brother John is that other encoders aren't going to want to put "Certified to create DivX certified streams" in their products

Why not? I could understand companies that compete for CE support taking some issue with it. Today I can count these companies on one hand with fingers to spare. Some of them don't even use H.264. I don't think any use the same container.

Which encoders are we talking about?

Brother John
1st July 2008, 00:53
As far as player manufacturers are concerned I guess most won’t have a problem with DivX certification. But for example Nero might not be too keen to let their encoder produce »DivX certified« video. ChronoCross is right, that would be free advertising for the competition. But an industry wide joint certification program might be too much to hope for.

ChronoCross
1st July 2008, 01:15
The CE world is not as clear cut as you might imagine when it comes to H.264. There are many STBs that do not fully support High 4.1.



Why not? I could understand companies that compete for CE support taking some issue with it. Today I can count these companies on one hand with fingers to spare. Some of them don't even use H.264. I don't think any use the same container.

Which encoders are we talking about?

I was talking exactly about those people. With all the infighting between CE devices causes tons of problems in the certified world. So why not use something that is already defined like Levels...

If AVC really wants to take off and have a decent market a universal non company specific standard must be used between encoders.

DigitAl56K
1st July 2008, 02:21
I was talking exactly about those people.

And you miss my point: This covers hardly any companies. In fact, are there any beside Nero (who output .MP4 files and have their own "Nero Digital" standard anyway)?

If AVC really wants to take off and have a decent market a universal non company specific standard must be used between encoders.

AVC in and of itself is not a media format. If "AVC" really wants to take off and have a decent market there needs to be a company to work with all of the manufacturers to promote a common standard. Look at DivX ASP format. We had this exact same discussion when DivX 5 was released.

Sharktooth
1st July 2008, 18:46
@Digital56K: is DNX considering to make also a divx CLI encoder?

bond
1st July 2008, 21:55
which advanced audio formats will the new divx avc certifications include? aac? vorbis? wma pro?

Inventive Software
2nd July 2008, 00:17
I'd ask if it's possible for Vorbis and AAC to get the look in on DivX Certified audio. Vorbis is not as common on standalones, and the Tremor fixed point decoder's been around for a long while. AAC could probably be the ideal multi-channel format, Vorbis the 2 channel format (although AAC is no slouch in this regard, there are different flavours that take different decoding requirements and more are being developed for different markets. Vorbis has not changed much), but they both have their own strengths and weaknesses. ;)

Sharktooth
2nd July 2008, 04:21
vorbis... mkv... dunno. i'd prefer a more "standard" compliant output.
mp4 is the natural container for AVC/AAC. why not use that combo?
MKV and vorbis are 2 outstanding techs and would be great to have them as a second choice though. however IMHO AVC/AAC in MP4 is the way to go.

Dark Shikari
2nd July 2008, 04:34
vorbis... mkv... dunno. i'd prefer a more "standard" compliant output.
mp4 is the natural container for AVC/AAC. why not use that combo?
MKV and vorbis are 2 outstanding techs and would be great to have them as a second choice though. however IMHO AVC/AAC in MP4 is the way to go.Probably because if they use MP4 they lose a potential way to distinguish themselves from the competition ;)

GodofaGap
2nd July 2008, 07:04
Or it could just possibly be that they wanted support for AC3 and perhaps some other non-native mp4 formats.

BetaBoy
2nd July 2008, 09:14
... or any of a dozen+ other formats. IMHO (and without me going into details) using Matroska allows DivX a greater range of flexability without having to confirm to limited container possibilities. DivX has always been about pushing new ideas/concepts/projects (even though they have been quite this past year), this is no different.

SeeMoreDigital
2nd July 2008, 10:13
Given that every digital surround sound amplifier offers onboard multi-channel AC3 decoding (and not AAC), AC3 is a must for any container.

Much as I like multi-channel AAC-LC and HE audio, I am happy that the MPEG-4 spec is at last being amended to officially accommodate AC3 (and EAC3) audio streams.

Daiz
16th July 2008, 22:01
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 ;)

Very seriously awesome news.

Now how about ASS for subtitles :D?

DigitAl56K
17th July 2008, 00:59
Now how about ASS for subtitles :D?

Thanks for the offer but that's really not necessary, you can watch subtitles for free O.O

Ranguvar
17th July 2008, 01:59
Thanks for the offer but that's really not necessary, you can watch subtitles for free O.O
X.X

Err, I think he meant Advanced SubStation Alpha support... :p

ChronoCross
17th July 2008, 02:18
Thanks for the offer but that's really not necessary, you can watch subtitles for free O.O

lol I wonder if that was actually joke or if you forgot that "ASS" is a subtitle format.

http://en.wikipedia.org/wiki/Advanced_SubStation_Alpha#Advanced_SubStation_Alpha

ha Ranguvar beat me...

DigitAl56K
17th July 2008, 04:00
Yes, I was just kidding! You may now commence throwing rotten tomatoes ;)

ChronoCross
17th July 2008, 04:23
/me throws a rotten tomato.

delacroixp
17th July 2008, 18:15
Rotten Tomatoes (http://www.rottentomatoes.com/)

It's all good !


:):devil::D
Pascal

Ranguvar
18th July 2008, 06:02
Now, the real question is, was that just a joke - or a clever way to dodge the question? ;) :p

Wolfman
1st August 2008, 05:27
There can only be three levels. Its gods way. Most people can count to 10, but really can only mentally grasp the numbers one two and three. Its around in nature everywhere the three leaf clover, the tri-maran, the Holy trinity and even the three Amigos. And pizzas, small medium and large?

Divx certification worked.. But who ever used the divx hd ? So maybe you only really need two..

And whatever you do, you have to get the software tools out there for (ordinary) people.. where's the software to make .divx files from existing .avi files? I mean cutting edge is good, but you only get a good cut with a thick blade, too many companies chase the new and leave existing customers in the dust....

delacroixp
1st August 2008, 14:08
Divx certification worked.. But who ever used the divx hd ? So maybe you only really need two..

Perhaps the HD revolution has only started.

I would certainly like to see the more common use of 576p on the internet ... H264/X264 makes that ever more possible !
The use of original 24 FPS on Film material is only a bonus.

It's all good.


:):devil::D
Pascal