Divx 5.11 V Xvid 1

[Brazil]

Hello all,

I've been encoding with Divx for the past few years and now that Xvid 1 has been released I decided to give it a go. I encode my films for the greatest quality regardless of size so I do always do a 1 pass quality pass in Divx. I use GKnot to create an AviSynth Script file and then use VDubMod to encode with.

I wanted to see the difference in quality between a DivX rip and an Xvid rip of the same film using similar settings for each codec. This is what I found and have a couple of questions regarding the results.

DivX 5.11 (free codec)
LanczosResize
1 Pass quality based. Quantizer = 2
No Psychovisual Enhancements

The file output size was 1,615 MB
The bitrate was 1993 kb/s
Qf = 0.487 bits/pixel

Xvid 1
LanczosResize
Profile @ Level = AS @ L5
Quantization type = Mpeg
B-Vops on as codec default
Packed Bitsteam on and Closed GOV on
Target Quantizer = 2
Motion search precision = 6 Ultra High
VHQ Mode = 1 Mode decision
Use Chroma Detection on
Everything else as default.

The file output size was 1,061 MB
The bitrate was 1264 kb/s
Qf = 0.309 bits/pixel

Basically I could not really see any difference between the two encodes, although I am sure there are differences at some point.

My question is that there is over half a Gig difference between the file sizes and about 600 kb/s difference in the bitrate. Is it therefore the case that Xvid is more capable of compressing a file and able to use a smaller bitrate than DivX to achieve similar looking results?

Also this is my first time using Xvid so are the settings that I have used sensible in order to achieve "the best quality" looking rip (without going under Q2)? Or is the fact that the bitrate of the Xvid rip being far lower than the DivX rip indicative that I have not achieved "the highest possible quality?"

Finally as an observation, My Xvid rip playback was stuttering until I uninstalled FFDshow. The FFDshow was the version in the latest GKnot installation package. I assume therefore that this version FFDshow is not the latest version.

Thanks for any responses,
Ben.

[Teegedeck]

Welcome to our little place here, Ben!

I'm afraid if you wanted to compare quality you'd better have used two pass to encode to the same filesize with XviD and DivX.

But if you are content with XviD's result and save a good deal of space, then it's probably fine! And yes, 'better compression without visible quality-loss' can usually be translated into 'same filesize but better quality'. In this case, you could for example use a high-bitrate custom-matrix and get better quality than DivX at about the same filesize.

[Sagittaire]

Use slowest and bframe for DivX 5.1.1 but XviD is slightly better and especially much faster.

But the profiles of Hardware encoding are not active function with XviD I believe.

XviD is the best MPEG4 ASP codeur for me, a slightly better than DivX 5.1.1, really better than ND MPEG4 or 3ivX.

[Brazil]

Hi Teegedeck

That was a quick reply!

Are you saying then from the Xvid settings I have used I could have achieved a better looking rip?

From what I know about DivX, to achieve the best possible rip, a 1 pass quality based encode will give the rip as high a bitrate as it needs, therefore producing the best quality it is able to achieve. Is this not what happens with Xvid when you do a 1 pass encode with a quantizer of 2, not counting a quantizer of 1 as I have been led to believe that this would be going a bit too far?

Its not really that I was after a side by side comparison of Xvid against DivX, I just wanted to see the best of what each could do and then have a little comparison. I see what you mean though for it to be a fair comparison it should be done against files of the same size.

Also could you point me in the right direction to find information about using a high-bitrate custom-matrix. So using this will improve the quality of the Xvid rips? (Not that I could see how it could visually have been much better.) This sounds quite involved.

Thanks again,
Ben.

[Tommy Carrot]

Originally posted by Brazil

My question is that there is over half a Gig difference between the file sizes and about 600 kb/s difference in the bitrate. Is it therefore the case that Xvid is more capable of compressing a file and able to use a smaller bitrate than DivX to achieve similar looking results?


I think the b-frames are the reason of the bitrate difference. B-frames are there for saving bitrate, but they are also decreasing the quality a bit. If you want to get max quality, do not use b-frames.

[tedgo]

I think the difference between the filesizes caused by the b-frame-settings.
Divx only uses 1 "consecutive b-frame" whereas xvid's default settings uses 2 "consecutive b-frames".
You also should set xvid to 1 consecutive b-frame, if you wants to compare it with divx. But if there is no visible difference between them with default settings, there is no really need to ;)

Btw. The version of ffdshow used in gknot seems to have problems with more than 1 consecutive b-vop and activated packed bitstream. This may cause the stuttering playback of the xvid-file.
Try a newer version of ffdshow

[Teegedeck]

Originally posted by Tommy Carrot
I think the b-frames are the reason of the bitrate difference. B-frames are there for saving bitrate, but they are also decreasing the quality a bit. If you want to get max quality, do not use b-frames.
That's a poorly founded belief IMHO.

Especially when dealing with restricted filesizes I would strongly advise to use B-frames.

[Tommy Carrot]

Originally posted by Teegedeck
That's a poorly founded belief IMHO.

Especially when dealing with restricted filesizes I would strongly advise to use B-frames.

We wont disagree about this, but i'm talking about the max reachable quality, and since the b-frames are more quantized, they can just hurt the quality, even if minimally. For general use, they are obviously very useful.

[Pen-Pen]

If you want to be even more amazed of XViD's power, go for VHQ-4 ;)

And I agree with tedgo : compare what's comparable... set the same B-VOPS settings for both codecs

anyway, I'm pretty sure of the result ^^

EDIT : as for the quant matrices, if you want to achieve high quality, give hvs-best a try (that's one matrix, there are lots of others, and surely as many threads about them in this forum ;)) I personaly *HATE* MPEG matrix, since it introduces *heavy* (and ugly for my sweet eyes) "mosquito noise"

[tripnotik]

Originally posted by Tommy Carrot
We wont disagree about this, but i'm talking about the max reachable quality, and since the b-frames are more quantized, they can just hurt the quality, even if minimally. For general use, they are obviously very useful.

B-frames are more quantized only if you want to. Just set the ratio to 1 and the offset to 0 and you will get b-frames that are the same quality as p-frames.

[Manao]

tripnotik : have a look here (http://forum.doom9.org/showthread.php?s=&threadid=76778)

B-frames will have a lower objective quality ( meaning PSNR ) than p-frames, even at quant 2.

[Tommy Carrot]

Originally posted by tripnotik
B-frames are more quantized only if you want to. Just set the ratio to 1 and the offset to 0 and you will get b-frames that are the same quality as p-frames.

But doing that doesn't make too much sense, cuz the main benefit of the b-frames, the bitrate-saving is not in effect then, in some cases it's even increasing the bitrate.

[Brazil]

In response to everything that has been covered so far I have a couple of questions.

I'm using Koepi's Xvid build and have the selection of quant matrices to choose from. Mostly the titles of the matrices are self explanatory.

Out of all of these on offer is the hvs-best-picture going to give me the best resutlts? Will there be situations where using such a matrix will not be appropriate and a different matrix would be better suited?

Does the use of a custom matrix slow down encoding and produce a larger file size?

Finally if I use VHQ mode 4 how much longer will it take to do an encode compared to a VHQ mode of 1 and will that increase the file size?

Thanks again,
Ben.

[Manao]

Will there be situations where using such a matrix will not be appropriate and a different matrix would be better suited?Yes, but at quant 2, you won't notice the difference in such cases.
Does the use of a custom matrix slow down encoding No
and produce a larger file size?It depends of the matrix, and of the movie. Generally, at quant 2, you can expect :

Size(HVS_GOOD) < Size(H263) < Size(HVS_BEST) < Size(MPEG)
will vhq4 that increase the file size?No, it will reduce it. For the slow down, try yourself on a small clip.

[Pen-Pen]

Originally posted by Manao
Yes, but at quant 2, you won't notice the difference in such cases.


I don't agree... whatever the quant, there IS a noticeable difference...

[stephanV]

I'm not getting any of this...

1. using b-frames with a constant quant encoding is in a way contradicting. B-frames increase compressibility and decrease quality, not in a 1:1 relationship but still. But why increase compressibility if the file size with a quant-based encoding is unpredictable anyway? if you're aiming at a certain filesize: use multipass.

2.
If you want to be even more amazed of XViD's power, go for VHQ-4
why? it does only affect compressibility as far as i can understand it and does not improve image quality and on top of that slows down encoding. i could bring up the same argument for the b-frames here but I'm at a loss here... everything i read about VHQ seems contradicting:

from Crusty's FAQ (http://www.vslcatena.nl/~ronald/docs/xvidfaq.html):
VHQ is more intensive search and takes a wider approach. Higher settings will slow down encoding significantly. Setting 1 has a relatively small impact and it is recommended for all encodes. Using higher values will give you better quality at the cost of encoding speed.
from doom9's XviD guide (http://www.doom9.org/xvid-vdub-final.htm):
VHQ mode enables an even more accurate motion search. Setting it to more than level 1 usually only cripples speed but won't increase image quality.
then there is this thread (http://forum.doom9.org/showthread.php?s=&threadid=45746&perpage=20&pagenumber=1) where people report a decrease in quality with higher VHQ-modes.

but having read all this I certainly wouldn't use VHQ-4 but only VHQ-1.

3.
anyway, I'm pretty sure of the result ^^
that's trolling. unless you can provide me with a *good* test where constant quant encodes are compared with each other, this has no basis at all.

[Koepi]

At fixed filesize (2nd pass, anyone? ;) ), VHQ4 vs VHQ1 _will_ increase quality.

[Nic]

@StephanV: I can see why it's confusing. To begin with VHQ wasn't perfect and VHQ=1 did seem to produce better results. But things have changed alot since early last year (as is always the case with XviD ;) )

As a general rule with XviD, always take the most recent information to be the most up to date and accurate. In this case Crusty's FAQ is the most recent.

As you wrote at divx.com;

sometimes it seems XviD-people (BTW - i mean users, not developers)try to make DivX look worse than good old MPEG1, not the least influenced by their own misinterpretation of the codec-test at doom9

I hope that's not what you feel is happening here, although a certain amount of bias will probably exist in the XviD Forum as you can imagine. Perhaps people on both forums can make their own encoding comparisons and compare results... :)

Take Care,
-Nic

[stephanV]

My comment belonged in that thread and nowhere else. People there started to make quality comparisons by the file sizes of the XviD/DivX.dll's. This is, as I stated there, not only silly, but they got it wrong as well. Also, to make things clear, my comment was not an attack on the codec-test of doom9 or XviD but on how sometimes the test is used/interpret by some people. I am not biased to either DivX or XviD (or ffvfw, 3ivx, etc. for that matter), but I will not put up with unfair comments (either way). But enough OT-talk now. :)

What my point was is that B-frames and VHQ are bit rate saving techniques that IMO have no place in quant-based encodings. The bits saved by the B-frames are not beneficially used elsewhere during such an encoding if I'm right. Since B-frames (and perhaps VHQ too, I still don't know*) decrease the quality of that particular frame (be it not always noticable) it is best to avoid them. In any case, doing a fixed quantizer encode at quant 2 and then end up with B-frames at a higher quant is at least a bit weird concept IMO ;)

BTW
a certain amount of bias will probably exist in the XviD Forum as you can imagine.
but it is still the XviD-forum right? not the XviD-fan-page ;)

*note that Crusty's FAQ provides a link to the sysKin-thread, which does not prevent any confusion. other than that, the FAQ is quite good i must say :rolleyes:

[Soulhunter]

Originally posted by Tommy Carrot
But doing that doesn't make too much sense, cuz the main benefit of the b-frames, the bitrate-saving is not in effect then, in some cases it's even increasing the bitrate. Hmm...

Im using Q2 B-VOP's often (without QPel...), but the filesize was always smaller than without them !!!

IIRC Ive also posted some examples for this, but I cant remind where/when this was... :confused:


Bye

[Tommy Carrot]

Originally posted by Soulhunter
Hmm...

Im using Q2 B-VOP's often (without QPel...), but the filesize was always smaller than without them !!!


It was long ago when i played with the settings of the b-frames, but i stumbled upon a few samples where using b-frames with Q2 gave higher bitrates than no b-frames at all. IIRC particularly fast motions with a lot of details.

[stephanV]

Ok guys, small test with random 50 seconds file:

all files were encoded with quantizer 2 and 'out-of-the-box'-settings, except for the b-frame settings. max. consecutive b-frames in all tests was 1, except for one XviD test, where max. 2 consecutive b-frames were used.

results:

DivX, no B-frames: 13,294 kB
DivX, B-frames (q=3): 13,336 kB (avg. q = 2.41)

XviD, no B-frames: 12,176 kB
XviD, B-frames (q=2): 14,430 kB
XviD, B-frames (q=3): 12,562 kB (avg. q = 2.48)
XviD, B-frames (q=4): 11,356 kB (avg. q = 2.96)

XviD, B-frames (q=2, max=2): 15,134 kB

my conclusion:

the benefit of b-frames in quant based encodings is at least debatable for both DivX and XviD

[Magno]

why everybody is saying rubbish about B-frames? Who was the first who said using B-frames would result in less quality?
B-frames, or bidirectional predicted frames, were first used in MPEG-1 (ISO/IEC 11172-2) and then included as well in MPEG-2 (ISO/IEC 13818-2), and the only drawback they had was.... that the resulting sequence was not causal! This forced to reorder frames inside the GOP to achieve a causal decoding.

The advantages of B-frames are that they predict uncovered background, can reduce the noise in the sequence (as the forward and backward predictions are averaged) and the square mean error between the bidirectional predicted macroblock and the target macroblock is the the less it could be, so you can use a bigger quantiser without losing quality. In my test with MPEG-2 sequences, the average number of DCT coefficients which weren't zero before quantization was about 6 coeffcients (of 64). So, after the quantization, i was losing the high-frequency information of the diference between the averaged forward and backward predictions and the target macroblock, which is a tiny loss.

But reducing the quantiser is the cause of the quality loss, not the simply use of B-frames; of course, if you increase the B-frame quantiser ratio and the quantiser offset, you would have a worse quantized macroblock, but this is not the aim B-frames were invented for.

In a MPEG-2 sequence (where two consecutive B-frames are allowed), using the proper quantization scaler in B and P-frames (which is decided on a macroblock basis taking into account how accurate the prediction was), the average size for B-frames was 2,5 times less than that of the P-frames.
This means that B-frames are worthy even if you use the quantiser ratio = 1 and the quantiser offset = 0, which would be the equivalent options in MPEG-2.

[Tommy Carrot]

Magno, as you can see in stephanV's tests, using equivalent quantizers for b-frames is not always a good idea. The b-frames are indeed smaller, but having b-frames means that the p-frames are farther from each other, so the differences are usually bigger, which results in bigger p-frames, and the b-frames not always can compensate this, except if they are more compressed.

[sysKin]

Originally posted by Magno
In a MPEG-2 sequence (where two consecutive B-frames are allowed), using the proper quantization scaler in B and P-frames (which is decided on a macroblock basis taking into account how accurate the prediction was), the average size for B-frames was 2,5 times less than that of the P-frames. True for mpeg-2, not so true for mpeg-4. Mpeg-4 is much more optimized for low bitrates - so if difference between p-frames is bigger (due to bframes in between), it works worse, because p-frames were designed to carry very little data.
Also, b-frames are not expected to carry much data either, and are not optimized for that either (even more than p-frames). B-frames at the same quant are not what bitstream expects, so the compression is much worse.

Last but not least, p-frames are much better than in mpeg-2, while b-frames are very simplistic, almost like in mpeg-2.

It is also true that for xvid, p-frames have much better ME due to VHQ.

Radek

[stephanV]

Originally posted by Magno
Who was the first who said using B-frames would result in less quality?
Crusty does (FAQ):
The advantage of B-frames is that they are usually encoded with a higher quantizer and take less space per frame, while the loss in quality is less than equal to the loss in used bits. Basically you use the inherently smaller and lower quality b-frames to save space that will be used for improving quality all over the clip.
B-frames make no sense in quant based encodings. The bits you've saved (which didn't even happen in the quant based encodings with B-frames of q = 2 and q = 3) are not useful spend elsewhere, as the codec does not care what the file size will be; it will give every frame what it needs.
In a file size based encoding B-frames make perfect sense, no doubt.

[Sagittaire]

With equivalent bitrate MPEG4 with bframe are always better than MPEG4 without bframe ... it's easy to see difference with high quant but it isn't easy with low quant.

[Magno]

Originally posted by Tommy Carrot
Magno, as you can see in stephanV's tests, using equivalent quantizers for b-frames is not always a good idea. The b-frames are indeed smaller, but having b-frames means that the p-frames are farther from each other, so the differences are usually bigger, which results in bigger p-frames, and the b-frames not always can compensate this, except if they are more compressed.

Yes, indeed. But the fact that two consecutive P-frames are farther implies a bigger ME and more bits in the following P-frame, but you have reduced by two the amount of bits in the two B-frames between them. I don't think the increase of bits needed to compensate the P-frame distance is the same order of magnitude than the saved bits in the B-frames.


Originally posted by stephanV
B-frames make no sense in quant based encodings. The bits you've saved (which didn't even happen in the quant based encodings with B-frames of q = 2 and q = 3) are not useful spend elsewhere, as the codec does not care what the file size will be; it will give every frame what it needs.

Well, good explanation. I am for you: in a quant-based encoding B-frames maybe are less useful. The only benefit would be the decreased file size.



Originally posted by sysKin
True for mpeg-2, not so true for mpeg-4. Mpeg-4 is much more optimized for low bitrates - so if difference between p-frames is bigger (due to bframes in between), it works worse, because p-frames were designed to carry very little data.
Also, b-frames are not expected to carry much data either, and are not optimized for that either (even more than p-frames). B-frames at the same quant are not what bitstream expects, so the compression is much worse.

I can't tell if this is true or not, because i don't know the syntaxis of MPEG-4 streams (i do know the MPEG-2's as it was my own son) but i thought the great difference between MPEG-2 and MPEG-4 was the object-based predictions, plus some minor improvements in bitstream syntax. I can't figure out why B-frames are not optimized for carrying much data, as they are just like P-frames (except that they include two more motion vectors for backwards prediction) but the data to be carried is less due to the more accurate prediction. Maybe some technique in encoding motion vectors would increase the amount of bits if P-frames are too far (such as dual-prime, which doesn't allow B-frames between two P-frames, but i think it has been deleted from MPEG-4 standard), but i really think that the increase in bits caused by P-frames to be farther are far compensated by the use of B-frames.


Anyway, i think it is a matter of being for or against B-frames. Technically, there are some scenarios where B-frames would result in a loss of quality (scenes with fast motion or with a lot of textures, maybe?), but in a two-pass encoding, it could be a great way to redistribute bits and quality through the final video.

That is my opinion :D :D

[Sagittaire]

Anyway, i think it is a matter of being for or against B-frames. Technically, there are some scenarios where B-frames would result in a loss of quality (scenes with fast motion or with a lot of textures, maybe?), but in a two-pass encoding, it could be a great way to redistribute bits and quality through the final video.

bframe=2 for exemple is Max consecutive Bframe for MPEG4. In High Motion scene the MPEG4 will not put bframe, in Medium Motion scene the MPEG4 will put one bframe and in Slow Motion scene the MPEG4 will put two bframe ...

[stephanV]

Originally posted by Magno
Anyway, i think it is a matter of being for or against B-frames. Technically, there are some scenarios where B-frames would result in a loss of quality (scenes with fast motion or with a lot of textures, maybe?), but in a two-pass encoding, it could be a great way to redistribute bits and quality through the final video.


Don't get me wrong, I'm not at all against B-frames. I just think there are cases (e.g. quant based encodings) where the use/benefit of B-frames is at least questionable. Note that my small test was not at all a quality comparison. For all I know all 7 files have the same (subjective) quality. But strange things (e.g. larger file size than without B-frames) *can* happen if you use B-frames.

In a 2-pass encoding scenario I'm all in favor of B-frames. :)

[Teegedeck]

Well, even when we talk about quant-based encodings, usually we don't have a limitless suppy of HD-space and DVD-Rs - so in the end we always deal with limited space. So, take a look at a B-frame that's been compressed at quant=6 and at that same frame as a P-frame at quant=3. I'm pretty sure that you won't be able to see many differences (not each and every sentence in an FAQ is carved in stone). While the difference in filesize is evident. I guess you understand what I mean to point at. :)

I think a DVD-R-filling encode that doesn't have B-frames would look worse than a DVD-R-filling encode with B-frames that uses a high-bitrate matrix (which we could only afford to use because of the space we've safed using B-frames).

Edited: mainly an obvious typo in quantizer-numbers

[stephanV]

Originally posted by Teegedeck
Well, even when we talk about quant-based encodings, usually we don't have a limitless suppy of HD-space and DVD-Rs - so in the end we always deal with limited space.
unfortunately, yes... ;)

So, take a look at a B-frame that's been compressed at quant=6 and at that same frame as a P-frame at quant=3. I'm pretty sure that you won't be able to see many differences (not each and every sentence in an FAQ is carved in stone). I'm not suggesting B-frames always look like crap, don't get me wrong. But there is that chance of course. Moreover, with quant based encodings you're not looking for compressability but for quality.

While the difference in file size is evident.
And here's where the problems seem to start. You are right if you compare just one B-frame with just one P-frame. But if I understand sysKin in the right way, putting B-frames between P-frames will result in much larger P-frames at low q-values. So the file size increment is caused by larger P-frames, not by larger B-frames.

I think a DVD-R-filling encode that doesn't have B-frames would look worse than a DVD-R-filling encode with B-frames that uses a high-bitrate matrix (which we could only afford to use because of the space we've safed using B-frames).
I don't understand the whole (custom)-matrices thing (yet).. I have virtually zero understanding how a quantization matrix influences the encode. What i do know is this:

If you're doing a DVD-R-filling encode (which is a file size based encode) then quant based encode is not something you should be looking at. I don't think there will be a lot of people who can set up a quant based encode so that it fills exactly 1 DVD-R or CD. While with two pass even a beginner would be able to get that right.

To me the whole concept of doing a quant based encode and then still trying to aim for a certain file size is a contradiction. If you want q = 2, you should go for q = 2. Not for q = 2 and then hold a little back with the B-frames. You don't really know what the file size is gonna be anyway.

But of course this is just my n00bish opinion and you may surely disagree with me. :)

[Soulhunter]

Ok, I found this 3 moths old stuff on my HD...
X-MAN 2 / DVD - PAL (R2) - 128 min.
_____________________________________________________________________

Crop(4,80,714,416).LanczosResize(1024,416).AddBorders(0,80,0,80)
_____________________________________________________________________

XviD: Version 1 RC2
Fixed Quantizer 2 | (VHQ1)
I-frame interval = 250
Matrix = Soulhunters v2

Audio: Dolby Digital (AC3)
5.1 - Channels
384 kBit/s

Size: File = 4.42GB

About 160 min. (time to encode) ("2600XP")
X-MAN 2 / DVD - PAL (R2) - 128 min.
_____________________________________________________________________

Crop(4,80,714,416).LanczosResize(1024,416).AddBorders(0,80,0,80)
_____________________________________________________________________

XviD: Version 1 RC2
Fixed Quantizer 2 | (VHQ1)
I-frame interval = 250
BVOP's = 1 / 1 / 0
Matrix = Soulhunters v2

Audio: Dolby Digital (AC3)
5.1 - Channels
384 kBit/s

Size: File = 4.21GB

About 160 min. (time to encode) ("2600XP")


So, in this scenario the Q2 BVOP encode is slightly smaller !!!

But is this source depended, or coz it is a full movie encode... :rolleyes:


Bye

[Teegedeck]

Originally posted by stephanV
But if I understand sysKin in the right way, putting B-frames between P-frames will result in much larger P-frames at low q-values. So the file size increment is caused by larger P-frames, not by larger B-frames.
The p-frames do get bigger but not that much. Still an encode with standard b-frame settings will be considerably smaller than an encode without b-frames.

Custom matrices (those for high bitrates) are good for the following: If you encode a movie using the standard MPEG matrix at quant=2 you won't be able to fill a DVD. There's no headroom for improvement; not using b-frames will enlarge the file but it won't help quality much (or at all). The solution is to use a matrix that quantizes less i.e. removes less details than the standard matrix. (Or one that does it in a more cunning way than the standard matrix.)

Quant=3 with the SixOfNine matrix will be larger than quant=2 with the standard MPEG matrix and it will look much better! Quant=2 with SixOfNine will help you to really fill that DVD... But it will give you something in return, which is not the case if you simply don't use b-frames.

BTW, you encode at quant=2. What do you do with the result afterwards? How do you store it if it turns out larger than 4.6 GB?

[stephanV]

Originally posted by Teegedeck
BTW, you encode at quant=2. What do you do with the result afterwards? How do you store it if it turns out larger than 4.6 GB?
I don't encode with q=2 (im a 2-passer); the guy who started this thread did... I'm just curious :D

From what I've read and heard I couldn't make sense of justabout the whole first page of this thread and didn't think it would be resolved for me by the looks of how the thread was going. Therefore I just dropped in and took a stance. With participating in a discussion you usually learn a lot more then being by-stander all the time. Sorry for the inconvenience. :rolleyes:

[Teegedeck]

No, no - I'm sorry! :p

[Soulhunter]

Ok, I did this encode yesterday...

_____________________________________________________________________

The Italian Job / DVD - PAL (R2) - 106 min.
_____________________________________________________________________

Crop(18,78,696,424).LanczosResize(1024,408).AddBorders(0,84,0,84)
_____________________________________________________________________

XviD: Version 1 final
Fixed quantizer 2 (VHQ1)
I-frame interval = 250
Matrix = Soulhunters v3

Audio: Dolby Digital (AC3)
5.1 - Channels
448 kBit/s

Size: File1 = 3.98 GB

Average PSNR: 49.51 dB (Y 48.93 U 49.62 V 49.97)
_____________________________________________________________________

XviD: Version 1 final
Fixed quantizer 2 (VHQ1)
I-frame interval = 250
BVOP's = 1 / 1 / 0
Matrix = Soulhunters v3

Audio: Dolby Digital (AC3)
5.1 - Channels
448 kBit/s

Size: File1 = 3.78 GB

Average PSNR: 49.37 dB (Y 48.82 U 49.48 V 49.82)
_____________________________________________________________________

So, in this scenario the Q2 BVOP encode is also the smaller one !!!

But the average PSNR as well... :rolleyes:


Bye