Time for a new codec comparison? [Archive]

SeeMoreDigital

7th September 2003, 11:12

Originally posted by iwod
And i am really interested to See how Divx 5.1 and Xvid 1.0 perform at ~550Kbps ( some people say Divx 5.1 has some improvement at this range bitrage ) Personally I have not found anything to suggested that DivX 5.1 creates better looking low bitrate encodes than previous DivX versions.

As it's virtually impossible for me to read every DivX post/thread could you provide a link please so I can catch up please?

Originally posted by iwod
opps.... i forgot that divx has a auto pp...... so measuring the resouces with that wouldn't be useful.... Again, personally I don't think automatic 'post-processing' is not too much of a problem, at the moment. Afterall the WMV9 player includes this function (and can only be disabled using a registry hack). Maybe the RV9 player includes PP but nobodies found out about it yet!

Eitherway, at least with DivX you can control the level of PP. But once again, having such control makes it even harder to compare the quality of one codec's encodes against anothers!

What would be interesting to know a little more about is.... If you play your older DivX 5.0.5 encodes in the new 2.5 player. Do they look better than with the old 2.1 player? I suspect they do!

And if they do. This may explain why some users report seeing better looking low bitrate encodes that with DivX 5.0.5.

In my opinion, in the future there will be alot more attention levied toward post processing tools than now. If you try and imagine a post processing tool as being a form of decoder in it own right. It's easy to understand why post processing tools are useful.

To use an analogy. If you listen to an Mp3pro file using a player that is not Mp3pro compatible (ie does not have an Mp3pro post processor) although you can hear the audio it sounds crap!

You will all have to come up with your own conclusions as to where 'post processing' could lead us all..... spooky!

Cheers

DigitAl56K

7th September 2003, 11:48

1) A PP issue is under investigation (which would cause problems with test results)

2) Gej is on vacation in the short term :)

Sagittaire

7th September 2003, 13:54

Amen ... ;-)

PSNR, SSIM, VQM, JDN and visual test with PP and without PP (deblocking and deringing):

- XviD 1.0
- DivX 5.10
- WMV9
- RV9 EHQ
- DivX 3 with ffvfw 3 pass

Test with 570, 715, 950 and 1150 Kbps ...

Soulhunter

7th September 2003, 18:06

Test with 570, 715, 950 and 1150 Kbps ...
No higher bitrates -> 1500/2000/2500... ??? :D

Bye

Assault

7th September 2003, 18:12

Perhaps we should test 1500 but not higher because at those bitrates it's hard to spot differences between the codecs.

Assault

SeeMoreDigital

7th September 2003, 18:40

Originally posted by Assault
Perhaps we should test 1500 but not higher because at those bitrates it's hard to spot differences between the codecs.

Assault I very much agree. Above 1500kbps it does get difficult to spot the differences between the codecs.

And lets not forget, the main reason why such codecs (DivX, XviD, Mpeg4, WMV9 and RV9 etc) exist in the first place, is because they are supposed to deliver high quality video (and audio) at low bitrates!

Cheers

Soulhunter

7th September 2003, 19:02

Perhaps we should test 1500 but not higher because at those bitrates it's hard to spot differences between the codecs.
Ok, agree with that...

But AFAIK this PSNR test is made to spot out the smallest differences... ;)

Just thought its possible that one codec maybe sucks more than an other at lower bitrates, but profits at higher bitrates...

Thats one thing I ever thought about DivX5/XviD...

At lower bitrates both are "near" the same...

DivX = less blocks / less details
XviD = more blocks / more details

So its a personal choice, what you prefeer... (no blocks/more dtails)

But at higher bitrate (3CD encodes) XviD really starts to profit...

Because at this bitrate BOTH files have no "real visible" blocks, but XviD looks still more detailed

DivX = no blocks / less details
XviD = no blocks / more details

So I think a additional high bitrate test would be nice to see all advantages of a codec...

Bye

temporance

7th September 2003, 19:35

Originally posted by Sagittaire
Amen ... ;-)

PSNR, SSIM, VQM, JDN and visual test with PP and without PP (deblocking and deringing):

Test with 570, 715, 950 and 1150 Kbps ... Agree, but... this time, leave the choice of resolution to the person doing each encoding. (Anamorphic allowed) It's fairer - for example, xvid @ 640x400 might look better than @ 720x400. Viewing conditions are full screen.

SeeMoreDigital

7th September 2003, 19:55

Originally posted by temporance
Agree, but... this time, leave the choice of resolution to the person doing each encoding. (Anamorphic allowed) It's fairer - for example, xvid @ 640x400 might look better than @ 720x400. Viewing conditions are full screen. 'Anamorphic allowed' thank goodness for that!

In my opinion, all the test encodes should be done at 720x480/576. If we used this method everybodies encodes would be easier to compare.

Once 'the winner' has been established. It would stand to reason that they would look slightly better using smaller image pixel frame sizes/less pixels!

However, I don't hold out much agreement for this suggestion!

Cheers

Assault

7th September 2003, 21:13

@ Soulhunter

Hmm....perhaps we should really test very high bitrates too because:

Originally posted by Soulhunter
But at higher bitrate (3CD encodes) XviD really starts to profit...
we don't know if XviD or DivX is better for VERY high bitrates. There's the possibility that one of the codecs maxes out before the other.

Assault

Doom9

8th September 2003, 08:45

during a recent mbti evaluation I learned that I'm the guy to go to when you want somebody to look at an idea realistically (meaner people would say if you want your ideas destroyed by hard and cold facts).
4 different bitrates, 3 movies, 2 resolutions (cropped, full res) = 4^3^2 = 24 source comparisons. Let's assume a 10 minute clip and it takes you at least twice as long for a visual comparison, so 24x20 = 8 hours of visual comparison in the best case. Anyone who's ever done a reasonable visual comparison will hate it, trust me on that. And 8+ hours of pure hate... /me runs away screaming.
Then there are 12 sources to be encoded. I very much doubt that any of the programmers could be hassled into encoding movies for other people. Plus, they have been providing the settings they regard as optimal for a source, and with those settings anybody can reproduce the results (note that this is exactly how my last codec comparison was done).
downloadable sources: bandwidth and copyright. Forget about reasonably long sources due to copyright reasons, and bandwitdh constraints will also limit the allowable bitrates. The clips offered by c't along with their latest test were short and low bitrate.

Then we have the different measuring schemes. I wonder how many of you could even explain what PSNR is (no offense if you don't know, it is a very complicated concept indeed), but what good is a measurement if you cannot understand what the results mean? JND is commercial, you won't just get those tools for free, so who's willing to pay for a commercial image evaluation package? Plus, you can read the c't test to know how JDN will rate codecs. Blocks = bad, smoothed even without details = good. You don't need an expensive package to tell you that, you can just use your own eyes.

And let's now forget how the best comparison is done: by yourself. Since you won't get long high quality samples anyway, you might as well encode the source yourself.

(Anamorphic allowed) doesn't make any sense. Why? Because you can encode anamorphically using any codec and have the player do aspect ratio correction. If a codec specific container natively supports AR flags is of no significance, because a generic purpose container can offer that feature to any player. In the end all you have is a higher bits/pixel value for a given playback resolution. Of course you can do that, but you could've done that ever since players with AR correction were available but almost nobody ever made use of that.

Sorry to be a killjoy but I had a good laugh at this thread because I know about the possible problems behind those suggestions and doing everything suggested in this thread would take one guy definitely way more than a month even if he's working on it full-time. It is therefore unrealistic. You want companies to provide samples and measurements? Maybe they even will, but can you trust those? From personal experience I know that statistics can be used to "prove" completely opposite things so I tend to distrust any comparisons that have not been performed by an entity that I consider being neutral.

temporance

8th September 2003, 09:45

Originally posted by Doom9
Plus, they have been providing the settings they regard as optimal for a source, and with those settings anybody can reproduce the results (note that this is exactly how my last codec comparison was done).
downloadable sources: bandwidth and copyright. Forget about reasonably long sources due to copyright reasons, and bandwitdh constraints will also limit the allowable bitrates. The clips offered by c't along with their latest test were short and low bitrate.Thanks for your comments doom9, as our wise old codec comparateur!

Just an idea (and it's something I don't know too much about): what about using a p2p network to host the encoded versions? It doesn't make the copyright and bandwidth problems go away, but it decentralizes them.

Then we have the different measuring schemes. I wonder how many of you could even explain what PSNR is (no offense if you don't know, it is a very complicated concept indeed), but what good is a measurement if you cannot understand what the results mean? JND is commercial, you won't just get those tools for free, so who's willing to pay for a commercial image evaluation package?I for one am more than happy to forget about "objective" measurements. Can we consider instead some subjective measurements, e.g.
* noise (inc blocking/ringing),
* softness,
* image stability,
* clarity,
and rate each of these in the range 0 to 5 (0=makes video unwatchable, 5=not a problem).

(Anamorphic allowed) doesn't make any sense. Why? Because you can encode anamorphically using any codec and have the player do aspect ratio correction.Well, the fact that you can encode anamorphically using any codec is a positive reason for allowing it. I'm all for allowing anything that can make an encode look better, including free choice of resolution. I remember reading a long time ago about some research that showed that square pixels are actually not the best use of bandwidth. IIRC, the optimum was something around 1.8:1 PAR. Further, in MPEG-4, the motion vector space that can be represented by a given f_code is square. However natural motion in most TV/movie content falls more into a horizontal ellipsoid distribution (there's usually more horizontal motion than vertical). So, there's some good backing to the theory that it's possible that an anamorphic encode is better than one done with square pixels.

Sorry to be a killjoy but I had a good laugh at this thread because I know about the possible problems behind those suggestions and doing everything suggested in this thread would take one guy definitely way more than a month even if he's working on it full-time. It is therefore unrealistic. You want companies to provide samples and measurements? Maybe they even will, but can you trust those? From personal experience I know that statistics can be used to "prove" completely opposite things so I tend to distrust any comparisons that have not been performed by an entity that I consider being neutral. Your comments (and laughes) are well received. If we forget all objective measurements, then companies could not use clever statistics to make their product look better. But if we say to these companies, "what can you do with this clip at this bitrate?", there can be no cheating in what they come back with.

SeeMoreDigital

8th September 2003, 10:13

Hi Doom9, nice to see you on the thread.

I'm moved to say that while I agree with some of your points you have managed to take some the fun out of thread now!

However, there is one fact you have overlooked, you are an NTSC user.

Now I know I can't speak for anybody else but I find that it's quite a bit easier to make NTSC DVD rips look better than PAL rips. Especially when you crop and resize!

In your recent 'codec shoot-out' test both your movie sources (Matrix and Saving Private Ryan) are NTSC. I wonder then, if you would conduct your second batch of tests using the same movies but this time using PAL DVD sources.

And as for the 'anamorphic' quip (which I know you know I would have responded to!) I don't agree! Just compare the anamorphic encodes from the same PAL and NTSC movie, at the same bitrate using any codec and it becomes very clear, very quickly, that NTSC users have an easier time!

Cheers

Doom9

8th September 2003, 10:14

Just an idea (and it's something I don't know too much about): what about using a p2p network to host the encoded versions? It doesn't make the copyright and bandwidth problems go away, but it decentralizes them.
Well.. imagine me feeding those clips into a p2p network. I know the MPAA doesn't particularly like me, but uploading copyrighted content is against the law even in my country so they'd finally have a clear cut reason to try and shut me down. Thus, I'd never upload anything to a p2p service. For the same reasons, code makers cannot publish arbitrary sample clips.
But if we say to these companies, "what can you do with this clip at this bitrate?", there can be no cheating in what they come back with.Unless you get the source (which faces the problem mentioned above) there's no way for you to verify the results and that's the main problem. You can easily reproduce the results I get in my codec comparisons.. you have downloadable codecs, the codec settings, precise description of the source, but as soon as you can't get the source or the evaluation applications things become tricky because you cannot verify them.
I wonder then, if you would conduct your second batch of tests using the same movies but this time using PAL DVD sources.
we're talking about 3 weeks worth of work without any apparent benefit I can see (and without any financial compensation for my efforts). That about tells you how much I'm inclined to do it. I don't even have those movies in a PAL version (but I do live in a PAL country). It is very easy to ask for a test, but extremely hard and time consuming to conduct something that stands up to even the most basic scrutiny. Why would NTSC movies be easier to encode? I read your signature.. but obviously comparing fullscreen rips is not fair because PAL uses so many more pixels. But if you crop, you end up with the same number of pixels to encode. Do you have any mathematical background to prove your claim that PAL movies are harder to encode than NTSC ones?

cordraconis

8th September 2003, 10:17

Originally posted by temporance
Thanks for your comments doom9, as our wise old codec comparateur!

Just an idea (and it's something I don't know too much about): what about using a p2p network to host the encoded versions? It doesn't make the copyright and bandwidth problems go away, but it decentralizes them.

Well, since I'm busy right now redoing exams (Thx Junto ... :D Kidding!), I don't have time to go deeply into this discussion.

But I think (of we would make Doom9's test-encodes public via P2P), it would be a good idea to use Trailers and previews as source, since (as far as I know) they are public anyway. The difficulty would be to decide which ones to use, because of the numerous scenes and "hard cuts" etc ... giving a high keyframe ratio.

And to test the different (settings of each) codec(s), the number of degrees of freedom should be as low as possible, meaning that all the common settings (like resolution, bitrate/size, keyframe interval, Qpel, etc ...) should be the same for all codecs, so the uniqueness of the features (or the different implementations thereof), can make the difference.
(and yes, I thought about it for 5 minutes, so if it doesn't make any sence ... :rolleyes: )

Anyway, Doom9 is right about all the possibilities and the time it will take to compare them, so IMHO that's why we should fix the common settings.

And now back to study. (Bl***y Cristallography ...:mad: )

Edit: OK, Doom9 typed faster ... :D

Doom9

8th September 2003, 10:40

But I think (of we would make Doom9's test-encodes public via P2P), it would be a good idea to use Trailers and previews as source, since (as far as I know) they are public anyway. The difficulty would be to decide which ones to use, because of the numerous scenes and "hard cuts" etc ... giving a high keyframe ratio.
That idea has been brought up a couple of times. However, I see several problems: 1) Getting the source. The movie industry doesn't exactly like their trailers being distributed in VOB format, but for reproducability a VOB source would be the best solution with nothing else getting even close.
2) The movie industry also does not like trailers being distributed otuside of their channels. I know there are trailers sites, but it's still a risk
3) trailers do not compare to a real movie. If you take an action movie, the trailer will on the average contain more action scenes than the final movie, resulting in a worse image than if the whole movie were encoded. Also, cuts are more frequent than in the entire movie which also leads to a quality degradation. Maybe that's what you wanted but I'd rather have results that apply to encoding entire movies.
4) as for using only common codec features, you're going to have a problem because codecs differ. I started contacting codec makers and asking them for their suggested settings to escape the common "you should've used setting x instead of y" critique. If codec makers are involved, they have an interest in showing their codec in the best light, and making optimal use of the features they offer. If you restrict those features, they'd critisize the results and say "if you used feature z our codec would've looked much better", and all the fans of that particular codec would join the blues. Therefore I think it's preferable if every codec be used to the limit. Disadvantages of doing that (for instance in terms of encoding speed or worse size prediction) will in any case be discovered and reported.

cordraconis

8th September 2003, 10:48

Originally posted by Doom9
(Some good stuff)
That's what I meant by saying that we should choose very carefully which trailers etc ...

An other idea popped up: What about the compression test?
Like taking every n'th frame and the next 14(I think) frames?
This is not a whole movie (not even a trailer or something recognizeable), and also small enough to ditribute.

Only immedeate problem I see is in which format to distribute the source in ... huffyuv? MPEG-2 reencode?

Doom9

8th September 2003, 10:59

Like taking every n'th frame and the next 14(I think) frames?
This is not a whole movie (not even a trailer or something recognizeable), and also small enough to ditribute.
1400mb (spr) / 14 is still a hundred megs. Plus, it's not really usable, is it? Who'd want to see only every 14th frame of a movie. Let's not forget how I make comparisons: frames are of no significance, the impression when watching the movie counts.

temporance

8th September 2003, 11:19

And to test the different (settings of each) codec(s), the number of degrees of freedom should be as low as possible, meaning that all the common settings (like resolution, bitrate/size, keyframe interval, Qpel, etc ...) should be the same for all codecs, so the uniqueness of the features (or the different implementations thereof), can make the difference.To my mind we want to compare the best that a codec has to offer at a certain bitrate, not how good it is within arbitrary constraints. Let's say xvid+qpel is better than DivX+qpel, and DivX-qpel is better than xvid-qpel. Which codec is better? If your standard settings include qpel, then xvid is better, otherwise DivX. For the whole picture we would need to do a further comparison between xvid+qpel and DivX-qpel.

The same goes for resolution, IMHO. Choice of resolution should be left to the person doing the encoding. If you want to do any side-by-side checks, image diffs, or objective measurements, then use a lanczos resize to enlarge both clips you're comparing to the original source resolution. For ordinary viewing, resolution is unimportant as most modern video cards are capable of a good resize to fullscreen.

I recently did a PSNR test with this setup at different encoding resolutions but same bitrate:

[reduce res]->[xvid encode]->[xvid decode]->[enlarge to original res]

What was interesting was that the best PSNR figure was not at the original res (which encoded quite blocky). In the case I tried, there was a resolution sweet-spot at ~75% full res. Although this test was done with PSNR, it's well known that there is also a resolution sweet-spot for visual quality too (as exploited by tools like gknot). What I'm arguing is that that sweet-spot may be at a different resolution for each codec, so to enforce a resolution may give some codecs an unfair advantage.

Fictional example:

A. 720x352, RV9 encode looks very clean but textures washed out.
B. 720x352, xvid encode looks sharp but lots of blocking/ringing.
C. 640x320, RV9 encode shows a little softening.
D. 640x320, xvid encode looks perfect.
Encode D looks nicest when watched on fullscreen -> xvid wins!
Edit: if we considered only A and B, then RV9 would win

This is why it would be nice if the supporters of each codec (or even the companies behind the codecs) would choose the best settings for their codec. There really are so many degrees of freedom. The whole exercise then becomes one of research and discovery with a hint of competition, rather than just a dry comparison.

cordraconis

8th September 2003, 12:04

Originally posted by temporance
(...) Let's say xvid+qpel is better than DivX+qpel, and DivX-qpel is better than xvid-qpel. Which codec is better? If your standard settings include qpel, then xvid is better, otherwise DivX. For the whole picture we would need to do a further comparison between xvid+qpel and DivX-qpel.
(...)

Good example, but according to my proposal, since between these 2 codecs Qpel is in common, the comparison should be between xvid+qpel
and DivX+qpel, given the reason why Qpel is implemented was to increase quality.

This would show (correctly IMHO) that the Qpel-implementation of xvid is superior to divx.

But if we would compare divx, xvid and codecY, but codecY hasn't Qpel, then we would not use Qpel on any of them.

I'm beginning to realise that it's like crippling the codecs who have more options than the others, so maybe it's better to turn everything to the maximum settings. But this would take away the reason why some things are there, like Qpel was made for low resolution encodes I remember.

Now that I come to think about it, letting the codec makers decide which setting to use, isn't such a bad idea. But it's still not an objective criterum. If one would compare the PSNR for all the settings of a given codec (automated ofcourse), then the comparison could be between the "top settings" of each codec.
(Not that I think this idea is viable :) )

And about this compression-test-thing: Maybe I misunderstood you, D., but it's not every 14'th frame I mean. I didn't search the forum for this thread, but Johnny somewhere explained how a compression test works, and if I remember correctly it's by taking 14 successive frames each n frames. So the file would be a sequence of a lot of mini-scenes and if there is a macroblock somewhere, it could be easier studied by looping these 14 frames succesively.
And of course, the comp-test shouldn't be over the whole movie, just the chapters you usally encode.

temporance

8th September 2003, 12:17

Originally posted by cordraconis
Good example, but according to my proposal, since between these 2 codecs Qpel is in common, the comparison should be between xvid+qpel
and DivX+qpel, given the reason why Qpel is implemented was to increase quality.Yes, Qpel was implemented to increase quality, but it also increases bitrate. And for many sources (particularly high-motion, high resolution), it's known to give a worse picture for the same bitrate. So, to me, insisting on Qpel is a bad idea.

To continue my example, we might then discover that DivX-QPel looks better than xvid+Qpel. What then?

If one would compare the PSNR for all the settings of a given codec (automated ofcourse), then the comparison could be between the "top settings" of each codec.PSNR is particularly bad for comparing different encoding methods or different codecs. For example, PSNR is more sensitive than our eyes to the quality reduction caused by B-frames, but it is less sensitive than our eyes to the artifacts resulting from Qpel motion compensation. Unfortunately, the only way to choose the top settings, is, IMPO, to do a visual check of a number of full encodes. But, don't worry, this would not be part of a codec comparision. It would be the way we choose which particular e.g. xvid settings are used to generate the xvid entry to the competition.

Doom9

8th September 2003, 12:46

And about this compression-test-thing: Maybe I misunderstood you, D., but it's not every 14'th frame I mean. I didn't search the forum for this thread, but Johnny somewhere explained how a compression test works, and if I remember correctly it's by taking 14 successive frames each n frames. So the file would be a sequence of a lot of mini-scenes and if there is a macroblock somewhere, it could be easier studied by looping these 14 frames succesively.
And of course, the comp-test shouldn't be over the whole movie, just the chapters you usally encode.
Well, you could trigger those repeats with a simple avisynth script. and I still don't quite get what you want. A compressability test value? What would that be good for on the visual side?

cordraconis

8th September 2003, 13:19

Originally posted by temporance
Yes, Qpel was implemented to increase quality, but
(...)
It would be the way we choose which particular e.g. xvid settings are used to generate the xvid entry to the competition.
Yep! The qpel thing @ high bitrates etc. is indeed a problem I've encountered myself lately as part of a test.
And I've also read about the qpel raising the PSNR a few dB, which sounded strange to me when I saw my encode and compared it to the non-Qpel one.

Since the subjective nature of lossy video codecs, it's difficult to put numbers on everything. Now, I don't know the ins and outs on how the PSNR is determined, but for MP3 compression there is something like a "psychoacoustic model" that is used to determine what people can hear.
Isn't there something like that for visuals?
I know for one thing that the ears are more sensitive to certain frequencies than to others, given the same Sound Pressure Level.
Wouldn't it be reasonable to assume the same thing exists for the eyes, that can be used to modulate the PSNR?

Hmm, I just realize that this is the may mpeg-4 works, so it's useless since it's already in the codec ... Nevermind. :confused:

Maybe skipping the B frames in the PSNR calculation could compensate for the low rating, but I dunno how we could do that for the qpel-problem.

Originally posted by temporance

To continue my example, we might then discover that DivX-QPel looks better than xvid+Qpel. What then?

Hmmm, I won't put my uttering (which was in Flemish anyway) here, but it boils down to "ah!, Making it difficult for me huh?" ;)

Well ... This means that xvid scr**s it up with qpel, since (as you said) it was ment to increase quality, but it doesn't.
But I get your point: With my guidlines, we wouldn't detect this discrepancy, unless the xvid+Qpel looks worse than the xvid-Qpel, and then some automated method would select xvid-Qpel as the final entry for the comparison. My mistake was to assume that each option was added for increased quality no matter what, while in reality they are only added for sertain bitrate/resolutions.
You are right, the ideal settings *for each codec* should be determined before the comparison. Doom9 assumes the codec makers already determined them, and that is a reasonable assumption for me.
(Happy now? :D )

@Doom9: Aha! now I see where we lost each other. :)
To put it simple: If you encode a whole movie for comparison, then you would have to destribute the whole source (A Chapter, a whole DVD, a Trailer-VOB, ...) over the P2P network to the people who want to see/compare it for themselves. If you make an intermediate file (hufyuv, MPEG-2 reencode, etc.) with the avisynth script you said, then the "representable source file" generated by the script (and that you used for your comparison), would be a lot smaller and easier to download and spread.

temporance

8th September 2003, 13:51

You are right, the ideal settings *for each codec* should be determined before the comparison. Doom9 assumes the codec makers already determined them, and that is a reasonable assumption for me.
(Happy now? )I guess there are generally two levels of user: the one who uses all default or adaptive settings, and the one who knows how to tweak every setting to get the very best results. So there could be two comparisons going on
- which codec gives best result for the newbie, or for minimum effort, and
- which codec gives best result for the expert who wants to invest a lot of time.

cordraconis

8th September 2003, 15:48

Originally posted by temporance
I guess there are generally two levels of user: the one who uses all default or adaptive settings, and the one who knows how to tweak every setting to get the very best results. So there could be two comparisons going on
- which codec gives best result for the newbie, or for minimum effort, and
- which codec gives best result for the expert who wants to invest a lot of time.
Not really: People who care about the best codec's, settings, etc. will check out the compression test and see the (comments about) the settings used. People who don't care, will just use the defaults.
When I said that the programmers already determined the best settings, I didn't mean the defaults (speed 's also an issue there) but the settings they recommended for doing the quality comparison.

SeeMoreDigital

8th September 2003, 20:52

If users are woried about posting encodes of prohibited material. I have a couple of 'high bitrate' vobs that may be of interest.

Both vobs are infact the same 4min 39sec clip (with Mpeg2 video @ 8500kbps and AC3 2Ch audio @ 192kbps). However, one is 16:9 and the other is 4:3. Both are PAL and have a pixel image frame size of 720x576.

This clip has got the lot. Plenty of colour, fast and low motion scenes, bags of flashing white, stobe effects, CGI etc.

It's actually an Jaguar car promo that a friend of mine filmed!

As both vobs easily fit onto a CD-R. I don't mind at all posting a few copies around the country. I'll even post one to Doom9 if he wants!

Anybody interested?

Cheers

nuked

9th September 2003, 03:28

What's un-objective about letting the codec makers decide the settings? Seems perfectly objective to me. There's no opinions of testers involved only opinions of coders.. but they already inserted their opinions in how to write the codes. They wrote the codec.. they decide how it works, why not let them decide how to work it? Let the codec makers present what they think is the best way to make encodes (for a given bitrate). If they give the wrong instructions.. condsider it a bug in the instructions. They can fix it in their next instruction release and better luck to them next time. Oh but you say but some users wnat to know how to make the codec work even better than the programers know how... well then they could also rewrite the soruce code for XVID if they want.. but come-on... you have to set limits somewhere, and most people want to be told the best settings really. Maybe 2 submissions should be allowed, but not encouraged, one for high speed and one for high quality. Then a codec can win double points for doing well in both. I wouldn't go so far as to allow a blocky and a detail submission.. let them decide what they shine best in.

I think this would actually be great. I'm looking at the new DIVX codec and the threads about it and it's flodoed with posts about what happens when you combine this and that but not the other setting and half the time teh result is the settings don't even make sense to do at all or are even just plain silently disabled combos that revert to unexpected behavior and people are VERY confused. The codec makers could stand to streamline usage guidlines more anyway.

P.S... not that I'm volunteering to run these test ;)

edit: A C++ compiler could be included as one of the "codecs".. You chose the settings :).