DIVX 5.1 and "Q" [Archive]

zulu

29th August 2003, 20:31

Originally posted by MfA
Their hardware partners already have AVI parsers, tweaking AVI seems the best strategy for them.

For the tim being.. They're working on their own container, actually.
The article says that "Q" will be their own standard including their own container, their audio codec and non-mpeg4-compilant video.
Yeah, maybe someone should point them to matroska (anyway,i guess someone has done that already ;)).

MfA

29th August 2003, 20:37

The article suggests the container format will be a tweak of AVI.

zulu

29th August 2003, 20:40

:) you're right. seems i missed that part..

EDIT:
Darn, the paragraph i missed also says that it won't be "their" audio codec but a licensed one, possibly vorbis or AAC.

MfA

29th August 2003, 20:50

The part about the non standard video seems to still be speculation on the part of Heise BTW (the rest seems to be quotes).

SeeMoreDigital

29th August 2003, 20:51

On the 11 July Darrius "Junto" Thompson. Director R&D at DivX wrote this...

Yes, it seems everytime we think we've reached the limits of improving video quality within the boundaries of MP4 someone on the team comes up with a great idea that has the potential for making improvements that are worth our efforts. At the same time we know there are limits and we constantly think we are close and then someone on the team proves this thought wrong. However, we know that other algorithms can be developed that would enable us to take an even larger leap than "might" be available within MP4 whether the idea\algorithm is proprietary or based off of newer standards and we are working on these everyday, so at no time are we confining ourselves just to MP4, we have to see what will give us the best jump in quality along with performance and keep in mind what the average configuration of a video PC user is and then also correlate that with hardware. To make a long story short, you can expect that we are looking at many new ideas not within MP4 as our goal is not to be MP4 but to be DivX...high quality\useability across software and hardware. Also I'm not sure I've ever mentioned this publically but our goal was never to be MP4 our goal was always quality\performance\scalability. We then looked in a toolbox to see what we thought were the best video tools to build on top of and it happened that the tools we believed would give us the best video quality also happened to be part of MP4 and this is how the MP4 route was chosen by DivX. It was not....let's be MP4. It was, "How do we create quality".

Hope that satisfies your curiosity Good things to come in the future and as we're doing now you'll see these ideas early in the lifecycle at divxlabs and of course we'll get feedback from everyone here as well, and now that we've done this once we've learned quite a bit from our mistakes which will hopefully make the experience and resulting technology much better this 2nd time around

Darrius "Junto" Thompson
Director R&D DivX

This might answer a few questions... Or raise a few more!

Cheers

zulu

29th August 2003, 20:54

@MfA:
Yes, but some time ago DXN themself mentioned that they'll break the mpeg4 standard in DivX6.0 (it was on cebit IIRC).

Edit:
SeeMoreDigital was faster :)

SeeMoreDigital

29th August 2003, 21:13

Personally, I think DivX dropped the ball when they abandoned the MP4 container and concentrated their efforts purely on the AVI container.

Although the 'video' element is ofcouse the most important aspect of DivX's work. Dropping the MP4 container left end users at a disadvantage. No AAC audio, no surround sound, subs, chapters etc.

When it comes to audio, the competition has totally overtaken DivX!

And I think this is a great shame!

Cheers

MfA

29th August 2003, 21:28

Originally posted by zulu
@MfA:
Yes, but some time ago DXN themself mentioned that they'll break the mpeg4 standard in DivX6.0 (it was on cebit IIRC).

Not exactly, look it up.

IMO they wont do it, everything is patented (just possibly not by a valid patent). Without the clout of a standards body (or m$) such a high profile commercial product based on a proprietary format would make them a prime target. MPEG-4 and H.264 patent pools only get part of their validity from the patents in the pool, the group standing behind it with all its resources and lawyers with an interest in keeping the standard strong and with an uncontested patent pool are just as important.

temporance

29th August 2003, 22:47

> When it comes to audio, the competition has totally overtaken DivX!

What? That's like saying "when it comes to pizzas, the competition has totally overtaken MacDonalds". DivX is part of a puzzle. There's nothing to stop you muxing AAC audio with DivX video and you've got state of the art!

alexnoe

29th August 2003, 23:10

@Hobojobo:
I'm writing my own matroska code, and do not use a single line of libembl or libmatroska, so I know how complex matroska reading is, compared to AVI reading.
I would not really want to have to implement hardware matroska reading, with all the obscure things you can create an then call it a 'matroska' file....hardware support will require some really strict conventions (such as >don't split the track information data into 17 parts and place it somewhere between some clusters'<).

@All:
You won't believe what they are going to hack into AVI :)

Joe Fenton

30th August 2003, 02:48

Actually, the real reason DivX is moving to a non-MPG4 format is that they are tired of all the other codecs (XviD, FFMPG, etc) making streams that play on their decoders. DivX can't compare to XviD in encoding quality, but it has damn good decoding. I always set my XviD encodes to the DivX fourCC for best playback. Many others do too. Nearly every MPG4 compliant encoder has an option to output in "DivX" format. By moving to a proprietary format, they hope to force people to either use their encoders once more, or give up on using their decoders for playback.

kl33per

30th August 2003, 04:43

DivX can't compare to XviD in encoding quality
Great, another XviD fan. Not that I've got anything against anyone who works on or uses XviD, but I think these kind of statements are completely unjustified. You can't just say one codec is better than the other in every situation. Recent DivX beta's have been outdoing XviD yet I believe XviD still beats DivX when encoding anime. And before the guys from the new A/V formats forum come along, I know WMV9-VCM and RM9-EHQ beat both of them pretty consistantly.

30th August 2003, 16:09

Originally posted by kl33per
Great, another XviD fan. Not that I've got anything against anyone who works on or uses XviD, but I think these kind of statements are completely unjustified. You can't just say one codec is better than the other in every situation. Recent DivX beta's have been outdoing XviD yet I believe XviD still beats DivX when encoding anime. And before the guys from the new A/V formats forum come along, I know WMV9-VCM and RM9-EHQ beat both of them pretty consistantly.

I always explain it like this.
1) DivX is blurry.
2) A blurry picture will get a higher PSNR value than a sharp (slightly artifacted) picture.
3) Conclusion from 1 and 2: DivX has a PSNR advantage over XviD.
4) XviD has a higher PSNR than DivX, despite the PSNR advantage DivX has.

digitize

30th August 2003, 16:54

Yes, I like mf am an xvid fan. But you have to realize the xvid devels do not just say "We are better than Divx" without backing it up. Cruncher constantly does tests on builds, comparing psnr, compression, encoding time, and things like that.

SeeMoreDigital

30th August 2003, 18:26

Pleases, please, please, do not to turn this thead into yet another XviD versus DivX debate.

I am personally very interested to learn about any future DivX proposals and policy changes that may be happening soon.

I would like to hope that any future DivX codec developments will stay rooted to Mpeg4 and hopefully include the use of the MP4 container. As this would provide far greater flexibility for those of us who have hardware players.

It seems likely, to me, that more and more chip manufacturers will be producing 'combined' Mpeg1,2 and 4 chipsets (aka Sigma and ESS) for 'stand alone' players. I also think it's likely that Windows Media will soon be incorporated within these chipsets too!

Oh, and I would be most grateful if sombody could provide a translation for Hobojobo link.

Cheers

CruNcher

30th August 2003, 22:36

@all

this remembers me of a song it goes like this
Que Sera Sera whatever will be will be the futures not ours to see... ;)

SeeMoreDigital

30th August 2003, 23:23

Originally posted by CruNcher
@all

this remembers me of a song it goes like this
Que Sera Sera whatever will be will be the futures not ours to see... ;) CruNcher... You Are Mad!

But that's OK I still love you. In a none gay way ofcourse!

Cheers and goodnight.

ChristianHJW

31st August 2003, 08:12

Originally posted by alexnoe I'm writing my own matroska code, and do not use a single line of libembl or libmatroska, so I know how complex matroska reading is, compared to AVI reading.
I would not really want to have to implement hardware matroska reading, with all the obscure things you can create an then call it a 'matroska' file....hardware support will require some really strict conventions (such as >don't split the track information data into 17 parts and place it somewhere between some clusters'<).

Correct, the flexibility of matroska is extremely hard to support on current generation hardware devices, thats for sure, but its not going to happen anytime soon, so thats not really a limitation either.

All current matroska muxers do create files that definitely COULD be supported on today's hardware units just fine, if any company had plans to do so, and a 'normal' codec was used. The bigger problem here for those companies was then how to sell and promote MKV hardware support to their customers, as writing simply 'supporting matroska container' could lead to severe compatibility problems and, as a result of this, unhappy customers. For this reason we are going to define our 'matroska hardware profiles', and also launch some tools to check existing files for compliance, but please understand this is not on the top of our priority list right now.

@All: You won't believe what they are going to hack into AVI :)

ph3344RRR !!! :scared: :scared: ......

Sagittaire

31st August 2003, 10:55

Originally posted by mf
I always explain it like this.
1) DivX is blurry.
2) A blurry picture will get a higher PSNR value than a sharp (slightly artifacted) picture.
3) Conclusion from 1 and 2: DivX has a PSNR advantage over XviD.
4) XviD has a higher PSNR than DivX, despite the PSNR advantage DivX has.

1) No, DivX with bitrate Modulation "slow motion" isn't blury
2) No, Blur decrease PSNR
blur 0.1: 54.5353 dB
blur 0.2: 50.1381 dB
blur 0.3: 47.4559 dB
blur 1.0: 39.6771 dB
3) No
4) No, The Kaukura is the best iso-MPEG4 (very better than XviD Devapi3 and better XviD Devapi4)

SeeMoreDigital

31st August 2003, 11:17

I must admit it sure would be nice to play Mpeg4 video files complete with 6 channel surround sound audio via my Xcard.

I understand that if you're willing to view your encodes on a PC (or a PC with TV out) it's technically possible include all sorts of wild things with the aid of matroska.

I suppose at the end of the day the ultimate goal would be to put a DVD in one drive, a blank CD-R in another, launch some kind of 'David Blaine' type application and.... "presto changeo"... you end up with an a compressed copy of the original DVD, complete with chapter search, subtitles and 6 channel audio!

Well that's my dream anyway but then ofcourse us hardware junkies will then require the necessary firmware in our players to spin such discs. And that's why we need clever coders like alot of you guys here on the forum!

As many of you know I like my Sigma Xcard. And now it's been paired with the Jove player GUI (instead of Sigma's awful Xmedia player) the card has become an extremely versatile piece of kit.

So.... I don't suppose there's anybody out there who's ready, willing and able to create their own version of Xcard and/or Kiss player drivers and application software. So we don't have to install anything from Sigma or Kiss at all!

@All: You won't believe what they are going to hack into AVI Please tell us more!

Cheers

CruNcher

31st August 2003, 12:06

2) No, Blur decrease PSNR

not allways as mf said a more artifacted (sharper) picture will get a lower psnr then the same slightly blurred one

4) No, The Kaukura is the best iso-MPEG4 (very better than XviD Devapi3 and better XviD Devapi4)

Sagittaire sure it is better but slower then XviD to get the same
quality or extreme slow to get a better one 3x slower

but something offtopic:

why does people start buying this Sigma and Divx Certified players ?
my sugestion, wait till next year when the first "Real" DSPs with the full feature set arrive or better by an Xbox. Those test version players are not developed yet to give the customer that what he wants.

MfA

31st August 2003, 13:54

DivX sold their soul when it gave players with Sigma chipsets their blessing. If they dont even feel they have the clout to get real advanced simple players out there how the hell would they get hardware players to provide support for a proprietary protocol?

Microsoft I can see pulling it off, DivX ... dont think so. The only way I see a new format gain support without the kind of corporate backing Microsoft can provide is through Open Source and popular support, ala Vorbis.

sysKin

31st August 2003, 14:54

Originally posted by Sagittaire
[B]1) No, DivX with bitrate Modulation "slow motion" isn't bluryEvery codec will look better at low motion if you boost bitrate for low motion. H263 quantization type is more blurry, there's no way to fix this without sacrificing something else (or implementing mpeg quant to divx, of course).
2) No, Blur decrease PSNR
blur 0.1: 54.5353 dB
blur 0.2: 50.1381 dB
blur 0.3: 47.4559 dB
blur 1.0: 39.6771 dBWhat is that? What codec was used, and how did you modulate its sharpness?
I sure hope you didn't test filtered image vs. original???

It's easy to blur picture and gain PSNR in mpeg-4, I proved that almost a year ago. Everyone was happy when I *decreased* psnr by more than 0.1dB, because picture was sharper and looked better.
Simple answer is that psnr is not a good quality measure.

Radek

SeeMoreDigital

31st August 2003, 15:12

Originally posted by CruNcher
...why does people start buying this Sigma and Divx Certified players ?
my sugestion, wait till next year when the first "Real" DSPs with the full feature set arrive or better by an Xbox. Those test version players are not developed yet to give the customer that what he wants. Well, the reason why I/we (the business) purchased Xcards was because we needed our 'hire out media PC's' to be able to playback raw Mpeg1 and Mpeg2 files in hardware and display the images onto large TV monitors, projectors etc.

The Xcards replaced our Hollywood+ cards. At first we did'nt pay much attention to it's Mpeg4 capabilities but more and more people kept asking us about DivX and XviD so we decided to give Mpeg4 a go along with all the other serious compression codecs.

I don't take the view that DivX sold there soul to Sigma. Sure they've provided some technical information and 'certification' but technically Sigma's chipset could play just about any Mpeg4 file, provided it's running with the correct firmware. So I suppose on that basis, anybody with correct know-how could write firmware to make the chipset work with their own version of Mpeg4 (within reason).

At the end of the day somebody had to start somewhere. And in my opinion, you have to admire both Sigma and DivX, as they got the ball rolling. For me, it's a refreshing change to see the likes of RealMedia and Microsoft playing catch-up for their slice of the market!

Mpeg4 video may well end up not being 'the best of the bunch'. But neither is Mp3, neither is VHS (against betamax). But that fact has'nt stopped them ending up in everybodies homes!

MfA

31st August 2003, 15:24

Originally posted by SeeMoreDigital
Sure they've provided some technical information and 'certification' but technically Sigma's chipset could play just about any Mpeg4 file

It can play just about any MPEG file which uses half-pel motion compensation and DCT coding ... which is not just about any MPEG4 file.

It was a MPEG1/2 chip, it was extensible to MPEG-4 simple profile ... and there is where it stopped. If it had been designed as a MPEG-4 chip it wouldnt have this half ass not just simple not quite advanced simple feature set.

SeeMoreDigital

31st August 2003, 16:31

Originally posted by MfA
It can play just about any MPEG file which uses half-pel motion compensation and DCT coding ... which is not just about any MPEG4 file. Okay. The Sigma chipset on the Xcard has it's limitations. Sigma's new chips have been designed to do a better job. And now we have other manufacturers making Mpeg4 chips, there's no doubt in my mind that the technology will get better and better.

As I type this I'm watching an 700MB DivX encode of DareDevil in RGB on my 42" plasma monitor. Dispite the fact it's a 'low bitrate' encode it's very watchable. And I did'nt even have to get out of my chair, to switch on my PC monitor. I don't even have to fiddle about with my keyboard or mouse to access the file. It was all done via a simple to use 'remote control'.

This ease of use has been available to all Sigma/Jove player users for over two years now. You can't say that about the competition!

Cheers

TheXung

31st August 2003, 19:51

Do you realize the difference in processing power needed to decode a real advanced simple profile stream versus only what the sigma chip is capable of? Just try it, see how much processing power a pirated rip takes and then see how much a rip with q-pel, GMC, and multiple b-frames takes up. The real load comes from q-pel, you're motion compensating 4 times as much data as half-pixel. Really, the sigma sounds like a hacked up mpeg2 chip.

SeeMoreDigital

31st August 2003, 20:10

Originally posted by TheXung
Do you realize the difference in processing power needed to decode a real advanced simple profile stream versus only what the sigma chip is capable of? Just try it, see how much processing power a pirated rip takes and then see how much a rip with q-pel, GMC, and multiple b-frames takes up. The real load comes from q-pel, you're motion compensating 4 times as much data as half-pixel. Really, the sigma sounds like a hacked up mpeg2 chip. If this is the case with using full Qpel. Then it's really not use the effort encoding with it. That said, such use would better be impemented via a hardware decoder/player rather than a software decoder/player.

Cheers

CruNcher

31st August 2003, 20:56

@SeeMoreDigital

My XboX has no problems playing back full Qpel+GMC encodes and i never expierenced any stutter or high motion problems as standalone users do regulary and i can use Mp4 + AAC as for what it was once made up for :) Mpeg4 doesn't belong into AVI and sure no mp3 too,
but as Sigma and DXN where to "money hungry" and knew the cost to produce high quality chips would be to high, they put out this lower versions to gain that resources to produce better more advanced chips. It will be funny to see people complaining that their not be able to playback, in maybe some months or let it even be a year, those rips they bought the players for and you can surely forget to play any other types for example your new camcorder videos made with a iso aware Mpeg4 Camcorder on such players without doing some heavy "get it out of the standard over to the fake standard" conversion type of thing. Thats why i would wait before doing such a investment sure a DivX Mpeg4 Player is cheaper then a XboX but you get alot more from a XboX then from such a DivX Mpeg4 Player you can play virtualy anything and have a gui with Xbmp that any Standalone user would dream off.

SeeMoreDigital

31st August 2003, 21:31

Hi CruNcher,

Thanks for your reply.

I'll be the first to admit I don't know very much about this device (I don't play games) but I am interested in the boxes technology. I think it's fantastic that the XboX, which is afterall an Microsoft product, can spin Mpeg4 CD-R's. Surely it can't do this 'straight out of the box'. There must be some firmware trickery involved!

I would like to know a little more please. Can it play DivX and XviD (.avi) files. Or do they have to be Mpeg4 files with an .mp4 file extension? Can it play WMV9 files with either an .avi or .wmv file extension?

For me, my biggest problem with getting several of these players in the office would be... none of my employees would get any work done!

Cheers

Sigmatador

1st September 2003, 18:18

>>quote:
>>-------------------------------------------------------------------->>------------
>>2) No, Blur decrease PSNR
>>blur 0.1: 54.5353 dB
>>blur 0.2: 50.1381 dB
>>blur 0.3: 47.4559 dB
>>blur 1.0: 39.6771 dB
>>-------------------------------------------------------------------->>------------
>>
>>What is that? What codec was used, and how did you modulate its >>sharpness?
>>I sure hope you didn't test filtered image vs. original???

mouahahah *rofl* i'm sure he did it XD Sagittaire is the PSNR'masta :D

Sagittaire

1st September 2003, 18:58

You say "PSNR can't detect blur" or "PSNR for DivX is better than XviD because DivX encode with blur". I make this test ...

You say PSNR can't detect blur, block, ect ... but no demonstration ...

You say test PSNR is not a good test thus I use the VQM, SSIM, JDN ... which are tests psychovisuels and which often confirm tests PSNR and visual impression ...

You said PSNR are not a good test but all the developper of codecs use PSNR for test comparing ...

http://www.on2.com/pdf/vp6_white_paper.pdf
http://labs.divx.com/archives/000007.html

Perhaps be you better experts than the developers of codecs and specialists of the image processing ... ?!!

You should thus develop your own codec to make us share your knowledge ...

Source

source=Mpeg2Source("D:\Mes dossiers\B.A\Les deux tours\azerty.d2v")
source=Crop(source,24,88,-24,-72)
source=LanczosResize(source,640,272)
return source

Test with blur 0.3

source=Mpeg2Source("D:\Mes dossiers\B.A\Les deux tours\azerty.d2v")
source=Crop(source,24,88,-24,-72)
source=LanczosResize(source,640,272)
source=Blur(source,0.3,0.3)
return source

PSNR test

# --> Video Opening <--

source=AviSource("D:\Mes dossiers\B.A\Les deux tours\source.avs")
source=ConvertToYV12(source)

video=AviSource("D:\Mes dossiers\B.A\Les deux tours\test.avs")
video=ConvertToYV12(video)

# --> PSNR analysis <--
CompareYV12(video,source,"","test-Bilinear.txt")

blur 0.1: 54.5353 dB
blur 0.2: 50.1381 dB
blur 0.3: 47.4559 dB
blur 1.0: 39.6771 dB

Tommy Carrot

1st September 2003, 19:08

I think he wanted to say a blurry encode with less artifacts will have more psnr than a sharper encode with blocks and noise (which perceptually may seems to be better).

Comparing a blurred avs script to the original is ofcourse a stupid thing, but i suppose not that was the idea.

TheXung

1st September 2003, 19:45

Originally posted by Sagittaire
Perhaps be you better experts than the developers of codecs and specialists of the image processing ... ?!!

You should thus develop your own codec to make us share your knowledge ...

Uh, this is sysKin you're talking about . . . .

Just because someone is doing this as a hobbie does not make them less qualified than someone in industry. Not that I know the backgrounds of the xvid developers, but remember, most research is conducted by graduates; graduates for the most part are not working in industry.

1st September 2003, 20:08

You really aren't getting the point ehh Sagittaire?
If you want to test blurry against sharp, try this:

Source: normal sharp filtering

Test 1: Encode with XviD h.263 at a target bitrate of, say, 896kbit/s
Test 2: Encode with XviD MPEG at the same target bitrate, using the same source.

Do a subjective comparison (MPEG will probably look nicer), and then do a PSNR test. Ta-daaa.

Oh, btw, test this on a nice detailed DVD source, not anime or some smooth video.

Sagittaire

1st September 2003, 22:18

@ mf

The best matrix of quatisation for the PSNR is H263 not MPEG (better than the MPEG and the custom matrix)...

For the SSIM, VQM, JDN best are the HVS matrix not MPEG ...

But the variations are weak (~0.1 dB for PSNR) between matrix ...

For XviD the only version which can fight with DivX Kaukura with PSNR, SSIM, VQM and visual is XviD Devapi4 ...

XviD Koepi 24/06/03 is really worse ... if you had tested you would know it. DivX Kaukura and XviD Devapi4 are very similar with an advantage for DivX in the encodings with low compressibility (better for blocking) ...

Sigmatador

1st September 2003, 22:23

what a funny guy :D

@Sagit:
>"You say test PSNR is not a good"
>>yes PSNR sux, here's the demonstration:
http://www.cns.nyu.edu/~zwang/files/research/quality_index/demo_lena.html

>"all the developper of codecs use PSNR for test comparing "
>>Well, maybe for the same reason I use it, it's much faster than any other metrics.
It could be usefull to develop ONE codec, not to compare many ones.
And exactly we need a motion ponderate psychovisual metrics to do that (very usefull to avoid "slow motion cheat" with an average metric)

>"Perhaps be you better experts than the developers of codecs "
>>Don't be so annoying :devil: Syskin IS a codec developper, and much an expert than you. (well, who wrote VHQ ? and who "copy" it to slow their codec ^^ )

>"...
blur 0.1: 54.5353 dB
blur 0.2: 50.1381 dB
blur 0.3: 47.4559 dB
blur 1.0: 39.6771 dB
..."
>>OMG! incredible results! who could have expected that? every encoder here should thank you.
...
mouarf your PSNR tests become increasingly stupid *rofl*
Sagittaire did you know that converttoyv12().convertoyuy2().converttorgb24().converttorgb32().convertbacktoyv12() lower the PSNR, i think it could help you :D

really, what a funny guy :D

Sigmatador

1st September 2003, 22:34

@Syskin
can you make a PSNR build which rox every codec at *Average" PSNR for Sagittaire, i think you need 5-10minutes to do that ^^

..funny :D ...

Sagittaire

1st September 2003, 22:34

Salut Sigma

VP6 developpers use PSNR for comparing WMV9 and VP6
http://www.on2.com/pdf/vp6_white_paper.pdf

No very similar codec I think ... ;-)

superdump

1st September 2003, 23:06

well there are some criticisms we could make about their method of testing, but they are likely to use whatever comparison that is fairly well known or easily explainable which shows that their codec is 'better'. That's just business. If you're really onto a good codec and the test is a proven one then you'll win more custom for your product because those with the knowledge can't fault your product so easily.