Could Xvid deliver same 2-pass Quality for 1- pass?

[dihelson]

Hello, friends,

Pardon my ignorance about the processes,
But, I always think that there should be a way to make good quality convertions in ONE pass only. Why 2-pass?
I'm thinking on a solution:
Since we need hi-quality captures, and since we can't capture on 2-passes :) :) I thought that if Xvid could make the 2-passes in 1-pass would be fine.
This could work this way:
While capturing, Xvid at the same time, could analise the input stream and determine the second pass correspondent output, AND WRITE, not generating any stats.
Could be a fast computer!!
It could use kind of a Buffer to put information, and work AHEAD of time, capturing, analysing, and then converting, then read the buffer, then capturing, analising, then converting, and so on... It would be 2-passes, but made one after another, not making the second pass ONLY when the first was finished. We wouldn't have any stats, it would be in RealTime!!
I don't have a minimum idea that this could work, but it's a suggestion.
I can't imagine a future where we couldn't capture, or make Xvid, or any other standard at the best quality if not on 1-pass. 2-passes? No! Future is simpler. Things have to be more practical!

Dihelson Mendonca

[ChronoReverse]

Too bad you need to analyse the entire video before you can allocate bits. So your buffer needs to be the size of the entire video rendering it pointless.

[KpeX]

ChronoReverse makes a good point. You don't need a first pass to encode in VBR, but you do need a full pass to totally optimize bit allocation. I don't really understand your need, however. As far as capturing goes, capture to lossless and then encode to Xvid, you can encode as long as you want. I never understood people who would choose encoding time over quality......maybe just a different mindset ;)

[tangent]

I think what you want is constant quantizer 1-pass encoding.

[K_R]

If you want capture at the best quality then: 1-pass Quality Based = 100. QM=MPEG. VHQ=0.

[dihelson]

Originally posted by KpeX

I never understood people who would choose encoding time over quality......maybe just a different mindset ;) [/B]

Perhaps I couldn't make myself clear...
Nor I can't understand people who always think we HAVE to capture on 2 processes, first on a lossless, then convert... this is tradition, and you are familiar with it. Think another way: No Lossless, think RealTime! Without any quality loss. Think no intermediate state. Think about capture directly onto Xvid, with the same quality of a lossless, eliminate the intermediate "lossless" process, and you can see what I'm thinking. There should be a way to maintain quality and realtime, there may be, perhaps a really fast computer.... Perhaps not the way the actual codecs works... That's why I question the 2-pass model.
There shouldn't be 2 passes, there should be an optimal 1-pass.
Made I myself clear this time? I hope so!, on a phrase:
"No 2 passes".

[gotaserena]

Answering your question, yes, there is a way of keeping all the quality of the source, it is to use K_R's suggestion: encode at 1-pass, 100 quality, no B-Frames, no VHQ, no Qpel, no Chroma motion/optmizer, no trellis, and MPEG quantization matrix. With a reasonably fast computer you should be able to encode in real-time up to 720x576.

This will ensure that you keep maximum quality, but will result in enormous files -- though not as big as MJPEG or huffyuv or some other lossless codec. And you may find it hard to fit a whole movie or a full two hours of sports into a single CD.

2-pass, OTOH, proposes to solve a different problem: how to get the best quality constraining the final size of the file. This has nothing to do with tradition, but whether your final filesize is constrained or not. Bit allocation, as stated before by ChronoReverse, needs a full analysis of the whole video and there's no way around it.

In your words, the problem is in the definition of "optimal". Some people think of "optimal" the best quality they can get in a file to fit in a CD. Some other people think of "optimal" as the best possible quality they can get, period. If I belonged to the latter group, I would seriously consider a hardware encoding approach for capturing -- like an MPEG-2 capture card -- and drop XviD altogether.

[Nibor]

This post is a reply on dihelson's post.

Did you read the replies? ChronoReverse pointed it out!
The _whole_ video must be analized..
Why do you think there's something like 2 pass encoding, do you think the developers are just lazy to do something "better" ;) :p

To get 2 pass quality you have to make 2 seperate passes, easy to understand isn't it :sly:

Maybe it would be possible to take 1000 frames, encode it in 2 passes and than take the next 1000 frames and so on... But I doubt if that would make any sense at all!

Have a nice evening!
Nibor

[dihelson]

Originally posted by Nibor
This post is a reply on dihelson's post.

Did you read the replies? ChronoReverse pointed it out!
The _whole_ video must be analized..
Why do you think there's something like 2 pass encoding, do you think the developers are just lazy to do something "better" ;) :p

To get 2 pass quality you have to make 2 seperate passes, easy to understand isn't it :sly:

Maybe it would be possible to take 1000 frames, encode it in 2 passes and than take the next 1000 frames and so on... But I doubt if that would make any sense at all!

Have a nice evening!
Nibor

Yes, I read the replies. I understood that the movie must be analized the whole thing. In this case, It is really impossible to get my idea to work on this method.
But, in your last part of your message, you told something exciting:

"Maybe it would be possible to take 1000 frames, encode it in 2 passes and than take the next 1000 frames and so on... But I doubt"..."

That is the idea of a buffer I was thinking.
That's what I was thinking, another METHOD.
What I was questioning here, was not the quality made with today's method, I think it's correct, the developers really made a nice work, I don't doubt about it. We must indeed congratulate them.
I was just trying to think on a different direction, another method.
Sometimes, the history tell us that some extravagant ideas impulse the progress, and new extravagant ideas always conducts strong reactions. Trying to think different, seek another ways sometimes is very constructive. See, you pondered the idea of 1000 frames. This is good. This is to think different! It is good to try to think different. When I used the word "tradition" I mean "traditional method", if some guy didn't think about putting image along with the audio, we were listening to radio till today, and TV would never be invented.
I appoligize for any inconvenience my thoughts may arise, I'm not a technician, just pondered that perhaps while everybody is looking onto one direction, I had the desire to look another way.
As someone said: "Think is just what is: Think"

Thank you all for the explanations.

Dihelson Mendonca

[Dee]

but instead of traditional 3-pass process:
1. capture
2. 1st pass
3. 2nd pass
it's possible IMHO to have advanced capturing tool combined with xvid encoder to reduce overall time:
1. capture + 1st pass creating stats file
2. 2nd pass

[Koepi]

Uhm, that you can do already now: setup xvid to 2pass 1st, disable "discard first pass bitstream" and there you have a first pass of the video, the stats file will be slightly off,...

Bad idea, we discussed and tested it back when someone wnated to save time and do the 2nd pass on that first pass generated bitstream. It plain and simple sucked.

Regards
Koepi

[Owen]

I think a compromise could be reached here.
Some people want max quality and can do that with HUFYUV etc in one pass.
Others want smallest files. Two or more passes will allways be required for that.
Others like myself, want near original quality at reasonable bit rates.
How about DVD quality at less than DVD data rate and in real time.
I believe that many people will want to do this in future.
CD's as a medium are reaching the end of there usefull life.
In about one year DVD+-r will be so cheap that allmost no one will bother with CD's.
The ability to put 2 hours+ of DVD quality video on a DVDr disk in real time is what myself and many others are looking for.
Haveing to resize and do two pass encoding just to get over compressed, low resolution video to fit on a CD is getting out of date.

Regards,

Owen

[dihelson]

Originally posted by Owen
I think a compromise could be reached here.

How about DVD quality at less than DVD data rate and in real time.
I believe that many people will want to do this in future.
CD's as a medium are reaching the end of there usefull life.
In about one year DVD+-r will be so cheap that allmost no one will bother with CD's.
The ability to put 2 hours+ of DVD quality video on a DVDr disk in real time is what myself and many others are looking for.

Owen

I definetely agree with you. CD is at the end, DVD is the future. 2004 will be the DVD year. If we could put "SAME" , I mean SAME DVD quality in a little less space than DVD, say 2 hours or 3 would be a big advance. And if we could capture at this quality in Realtime, would be the solution... DVD recorders are becoming cheap and will do even more, as media also.

[Dee]

Originally posted by Koepi
Uhm, that you can do already now: setup xvid to 2pass 1st, disable "discard first pass bitstream" and there you have a first pass of the video, the stats file will be slightly off,...


No, my idea is to capture as usual (in MJPEG/HUFFYUV) and perform 1st pass analysys on-the-fly. Then make ordinal 2nd pass: MJPEG->XVID.

[Didée]

originally posted by dihelson
and work AHEAD of time
Great idea, indeed! That would solve lots of problems! ... But create some urgent others :D

dihelson,

it simply isn't possible.

3. Are you never performing any filtering on your captures when encoding??? Any filtering will drive your concept completely ad absurdum ...

2. You are suggesting that two codecs are compressing the live stream in realtime *simultaneously* - one codec for capturing to disk, and XviD in parallel for analyzing. I guess you want XviD to use B-frames, Qpel and VHQ4 on an 720*xxx full-size source, whilst your MJPEC codec has enough room to breathe and not drop one single frame?
Please tell me by the time when you will have that machine running ;)

1. To equal a 2pass-encode, you must have analyzed the *complete* stream, not only some limited buffer. That means, in the end your proposal is not very different from ... an ordinary CBR encoding! And after all, CBR encodings are not necessarily bad! With some little tweaking of the CBR values, some 'feeling' for what you are actually doing, and the will to accept loosing [quite] some filesize predictability, a good encoding is indeed possible.

But what about that:
- Do a normal 5% compressability test, or even 2.5% only
- perform an accordingly scaled 2nd-pass on that compressability test. Ba-ding, there you have your average quantizer!
- Now set the quality control up to meet that average quantizer you just found, and do the full encode.

Or that:
- Buy a DVD burner *today*, and start encoding at quant-2 only :)


- Didée

[Danzel]

I see someone posted while i wrote all this, lol

hhmm... i think that with a bit of work this could be done.

Although, think about it: What speed do you currently encode in xvid with your settings you would usually use in 2pass, probally not many fps. And then you would also have MJPEG/HUFFYUV using some of your CPU time.
At this speed you wouldnt be able to do live capture.

Although for doing a 2pass from a DVD Source this would be useful as you would only have to do your avisynth filtering once so your 2nd pass would be faster (Theoretically).
(This topic has been mentioned before.)

Danzel.

[Owen]

Why does every one keep going on about 2 pass encoding.
At data rates approaching DVD I cant see any difference between 1 pass and 2 pass.
Its only when data rates are restricted that 2 pass is worth while.
There should be more time spent on optimizing 1 pass high bit rate encoding.
Xvid has problems in this area.
DVDr is here. CDs are dead.

Regards,

Owen

[ChronoReverse]

Um, if you had space for DVD bitrates, WHY BOTHER RE-ENCODING AT ALL?

[gotaserena]

My point exactly. Buy a MPEG-2 hardware encoder capture card and be done with it. No hassle, no 18-hour reencoding, no lucubrations over filter settings or custom quantization matrices.

[Owen]

I don’t want to re encode anything.
This thread is about getting high quality in 1 pass.
Very low data rates are no longer required now that DVDr is cheap.

Why buy an obsolete Mpeg2 card to go in a P4 3.2Gig PC.
I have more than enough power to encode in real time.
DVD quality at a data rates about 30% lower than DVD would be useful to many.
I don’t see why 2 pass would be required for this.
Divx is getting close now.

Regards,

Owen

[dihelson]

Originally posted by Owen
I don’t want to re encode anything.

Why buy an obsolete Mpeg2 card to go in a P4 3.2Gig PC.
I have more than enough power to encode in real time.

Owen

We've got a nice discussion here, :)
Yes, we've come to a point that our machines are becoming really powerful, that "perhaps" we could have a nice capture in RealTime.
I think we won't need an almost obsolete MPEG2 card (Would be nice a Xvid card :)
I have an Athlon XP 2200 and I make some captures directly into DivX.
But since my computer is not powerful enough, I have do disable some things, like Bi-diretional encoding and GMC , and audio cannot encode in realtime, then I capture in PCM :( . Once I tried Xvid, but it was even more heavy, and caused many dropped frames in VirtualDub.
When capture I often use DivX instead of Xvid, because it has that "de-interlace" feature, that although not as perfect as a dedicated de-interlace filter, give some good results, mostly because I capture at 640X480 or superior.
I think that If I had such a Pentium 3.2Ghz, I could make excellent captures in Realtime without dropped frames. This would be a blessing, I could for instance, record the whole Week of HBOs and select what I want later...
since, when I capture using HUFFYUV and use tons of memory), I have to encode to Xvid - de-interlace, and some movies, this takes about 16hours. If I capture directly into DivX or Xvid, it is in realtime, even with encoded audio in MP3, that's why I love realtime, although, as many knows, in our time, realtime quality inexpensive captures is a dream. Perhaps, one day we would have a nice capture system with DVD quality in an inexpensive way...
perhaps...

Regards,

Dihelson Mendonca

[TheXung]

Why is this still being discussed? This thread keeps re-surfacing.

Don't want to spend extra time encoding? Arguing that you're willing to have large files? Then set it to quant 2 and be done with it. Enough is enough. People have thought long and hard about avoiding two pass and they have come up with various rate-distribution schemes. Obviously none of them will be as optimal as 2-pass. We're not going to come up with much better one pass encoding.

[dihelson]

Originally posted by TheXung
Why is this still being discussed? This thread keeps re-surfacing.


Because we enjoy Freedom. We live in Free Countries. I think everybody here is free to discuss Whatever they want to.
:cool:

Regards,
Dihelson

[Sagittaire]

If 2 pass is better 1 pass then 3 pass is better 2 pass ... :devil:

Test PSNR

3 Pass
XviD ffvfw : .... 44.6666 dB
XviD ffvfw : .... 45.2154 dB
XviD ffvfw: ..... 45.7189 dB

2 Pass
XviD Koepi : .... 44.3536 dB
XviD Koepi : .... 44.8755 dB
XviD Koepi : .... 45.5521 dB

[symonjfox]

@ Sagittaire

How could you make 3 passes with Xvid?

@ all

This is not a bad idea. Well, maybe nowadays PCs are too slow to perform an HFFYUV and Xvid 1st pass togheter, but I really think that in a copule of years, this would be possible (or if you have 4 or more processors).

IMHO the easyest solution would be to create a special version of Virtual Dub Mod, including Xvid code in the capturing process (that writes down the STAT file while capturing). The bad side of this idea is that you can't edit the captured file any more (filters or cropping/resizing will create a different file to encode, so the stat won't refer to the real source). I really like to tweak my work as more as I can. Then someone should continuously update VDM to lastest Xvid CVS and I really don't know if would be a good or bad idea.

PS: IMHO this is a good idea just for a P4 3.2 Ghz owners. I switched to DVB and MPEG2 conversions so this kind of process would be useless.

[Owen]

TheXung,
The reason the issue keeps resurfacing is because there is a demand for this functionality.
Fixed quant 2 encoding of PAL 720x576 in Xvid gives data rates nearly double that of DVD. A little over 1 hour of video on a DVDr is not very useful. Quality is not good enough either.
Divx can do variable bit rate encoding at about half that bit rate and with better quality.
It can and will be done. Maybe the next release of Divx will get there.
I can see no reason why software and a fast CPU cant do what a hardware mpeg2 card can do.
Even CCE encoding can be done at about 4x real time on current hardware. So what’s the problem. 4Gig+ CPU’s are only months away.

The only reason I bring this up is that there seems to be very little discussion on real time encoding, and I want to get the developers to put more emphasis on real time encoding quality and performance in stead of just concentrating on how much compression they can achieve. The need to compress video enough to put it on CD is passing fast.
High quality, high resolution, and high bit rate performance is becoming much more important then maximum compression.

Dihelson,
My old P4 2.1Gig could capture PAL 720x576 to Xvid 1 pass fixed quant 2, PCM sound without dropping frames. The current DIVX is even more efficient.
Your problems are probably due to using Vdub (a VFW app.) to capture.
WDM capture applications like FLYDS and Virtual VCR work much better.
The P4 3.2 encoding PAL 720x576 to DIVX5.05 at slowest setting (maximum quality) only uses between 50% and 80% CPU in FLYDS from MSI TV@nywhere card.

Regards,

Owen

[dihelson]

Originally posted by symonjfox
@ Sagittaire

The bad side of this idea is that you can't edit the captured file any more (filters or cropping/resizing will create a different file to encode, so the stat won't refer to the real source). I really like to tweak my work as more as I can.

In some cases, for example, capturing from a fized base, like a DIRECTV channel, like HBO, or Discovery channel, we often "guess" the crop and size parameters, so, this could be pre-fixed on the capture configuration, as de-interlace also, since channels like Discovery Channel don't change too much.
Well, I've made some captures that although not really "optimal", due to the last explained dropped frames (machine...) is reasonably good, and so, the process sometimes is preferable to the Lossless option ( HUFFYUV + 2-pass XVID + 16hs for crop, de-interlace).

Regards.

[dihelson]

Originally posted by Owen
TheXung,

My old P4 2.1Gig could capture PAL 720x576 to Xvid 1 pass fixed quant 2, PCM sound without dropping frames. The current DIVX is even more efficient.
Your problems are probably due to using Vdub (a VFW app.) to capture.
WDM capture applications like FLYDS and Virtual VCR work much better.
The P4 3.2 encoding PAL 720x576 to DIVX5.05 at slowest setting (maximum quality) only uses between 50% and 80% CPU in FLYDS from MSI TV@nywhere card.

Regards,

Owen

Thanks, Owen,
for this nice hint. I will try it. Perhaps, my Athlon could do this also. But remembering, one of the best softwares that "people say" dont lie about the dropped frames are Virtualdub, eh? I will send you a private message so we can discuss it better, ok?.

Regards,
Dihelson

[yingx2]

You guys are making me confused

I see no point of using 2-pass mode when filesize predictibility is not of interest. For better bits allocation? As far as I know, for the same filesize, 1 Pass Quantizer mode should deliver better or equal quality than 2-pass mode. 2-pass mode cannot allocate bits more efficiently, when compared to 1-pass quantizer mode (not CBR mode)

In an ideal situation, 2-pass mode 1.) makes your file reach your desired filesize, and 2.) delivers constant quality for your encoding. Which means that a "perfect" 2-pass encoding will have all its frames encoded at a fixed quantizer to assure consistent quality. (not too far away from the quantizer mode, yeah?)

2-pass mode could outperform 1-pass quantizer mode only if it were able to deliver "more constant" quality consuming limited bits. In that case, 2-pass mode must implement a more sophisticated detail removal/preservation algorithm, which is entirely independent from the standard quantization method.

If you encode your movie using quantizer mode, and it turns out exactly 700MB, you cannot expect that another 700MB 2-pass encoding will be more visually pleasing.

Some users expect 2-pass mode to take bits from frames that "don't need them", and redistribute those bits to frames that "need them". Sounds very wierd to me. 2-pass mode works like: figuring out how well the source can be compressed during the first pass, and scaling down the framesize to reach the desired filesize, and trying its best to make each frame receive equal amout of compression in the 2nd pass. There is no extra bitrate distrbution scheme that can make your 2-pass encoding look better than a fixed-quant encoding. (payback with bias is another story).

Any idea why people don't like 1-pass quantizer mode even when they are not aiming at a desired filesize?

By the way, I am very new to XviD, and I will be more than happy to be corrected.

[dihelson]

Originally posted by yingx2
You guys are making me confused

I see no point of using 2-pass mode when filesize predictibility is not of interest. For better bits allocation? As far as I know, for

Please, help on my question:
(this queston may be simple for most people, please, don't laugh :) )

You are saying that if we make an 1-pass file on sufficient bitrate above the best level of a 2-pass file could be, the quality would be the same, the only thing which would change, would be the filesize, but the quality would be the same, is that true?
Then, perhaps, if I capture at a 3000kbs 1-pass Realtime, wouldn't make much difference from a 2-pass captured on HUFFYUV and then converted to 1500kbs at the end (of course, disregarding crop, de-interlace, etc...) ... right or wrong?
Which of those "theoretically would seem better: 1-pass at 3000 or 2-pass on 1500?

Regards,
Dihelson

[KpeX]

Which of those "theoretically would seem better: 1-pass at 3000 or 2-pass on 1500?

That depends on what the meaning of the word 'better' is ;).

Yingx2, despite his own newbie claim, makes probably the best point in this thread in a while. If filesize doesn't matter, there is no reason to do two-pass. While keeping in mind that xvid is not optimized for high bitrates such as, say, MPEG-2, if you can afford to do a quantizer-2 encode without dropping frames, I don't see any reason to two-pass. Theoretically, two-pass encoding gives bits to scenes the algorithm feels need it. If a low-motion or low-detail scene doesn't require as many bits, they will not be allocated, thus improving the efficiency of the encode.

Moving back to your direct question, which is better ( which I don't believe the forum rules allow one to ask ;) ), if you can only afford space for the 1500 bitrate, and it looks as good to your eyes on your equipment as the 1-pass 3000, then by all means 1500 is better. But if time is more important, and space is not an issue, why not encode at 1-pass. Especially if it is possible to eliminate dropped frames...I don't capture much, but it sounds like I may have to look into some of these WDM apps....hope this helps,

[yingx2]

Originally posted by dihelson

Which of those "theoretically would seem better: 1-pass at 3000 or 2-pass on 1500?



Hi, dihelson

If you are talking about 1-pass CBR at 3000kbps vs 2-pass at 1500kbps, there is no definite anweser.

The peak bitrate for a 1500kbps 2-pass encoding could be something like 5000kbps. In that case, the 3000kbps CBR encoding would look better than the 1500kbp 2-pass encoding for "most" scenes, but still become inferior in those bitrate-eating scenes - complex frames where the 2-pass encoding uses 5000kbps to maintian consistent visual perception.

If the maximum bitrate of the 2-pass encoding is 2500kbps, you should be very happy with you 3000kbps CBR one.

[Owen]

dihelson,
I just made a 80min test capture of PAL 720x576 to DIVX5.05 at slowest setting (maximum quality) with HD 8Mbit profile with MP3 192kbs audio (Radium codec)with no dropped frames and and no audio sync problems. File size worked out at just over 2.2Gig per hour or just under 2 hours on a DVD.
I'm running a 3 hour test capture now. I dont expect any problems.
CPU usage never gets over 80%. Hyper Threading does work.
I cant wait for the next version of DIVX.:D

Regards,

Owen

[dihelson]

Originally posted by Owen
dihelson,
I just made a 80min test capture of PAL 720x576 to DIVX5.05 at slowest setting (maximum quality) with HD 8Mbit profile with MP3 192kbs audio (Radium codec)with no dropped frames and and no audio sync problems. File size worked out at just over 2.2Gig per hour or just under 2 hours on a DVD.
I'm running a 3 hour test capture now. I dont expect any problems.
CPU usage never gets over 80%. Hyper Threading does work.
I cant wait for the next version of DIVX.:D

Regards,

Owen

Ahhhhhh!!! I'm Jealous...
Hyper-T... is really nice. in my Xp2000 at 2200, I work on CPU 80% to 100% (dropped):devil
I'll have to buy another CPU, mine is already old for what I want...
I have to use all codec at the minimum...:devil:
I will catch you soon... :)
:D

[Blue_MiSfit]

I was thinking something along the same lines as running a custom version of vdub mod that was totally designed for smp capturing of huffyuv and xvid firstpass at the same time... you would have to have a fierce dual channel memory controller, possibly the next gen opteron chipsets or more likely the next gen P4 Xeon chipsets.

I can see this running feasably on a serverworks board with twin dual channel memory controllers (I think this exists, but I may be foolish), with one pair devoted to each cpu. with a gig in each bank, you are running 4 gigs of ram, 2 gigs going to each cpu. this is being powered by either DDR2 or perhaps the new RDRAM thats just taping out. insane speed with that stuff. Might just save rambus in the end - evil bastards... :devil:

Or... how about rewriting in RISC and running on OSX or Linux with a dually 2.0 GHz G5 hooked into an Xserve RAID array running dual 200MBit Fibre Channel on a 3 Terabyte RAID 50 array :D :D I bet you could do first pass and capture at the same time easily. Even at HDTV resolution. Ridiculous I know and totally unrealistic, but I can dream, no? :)

anyways sorry about being a troll and bringing up an old thread, I think its a good one though.
~misfit

[Danzel]

well, the new opterons have integrated memory controllers, and you can get dual cpu boards wheree they each have their own memory.

I think something like that could be done, although it would be rather difficult to impliment.

You would have a codec that encodes the stream to xvid 1stpass and huffyuv at the same time in different threads, so they could use seperate cpus.
This would be coded so that huffy was the "buffer" so that if your xvid encoding wasnt realtime then you wouldnt lose frames in your 1stpass results.
A mighty challenge indeed.

You wouldnt need all that memory, although fast hard drives would be nice, a gig ram on each cpu would be more than enough probally.

Danzel.

[Soulhunter]

Originally posted by Owen
Fixed quant 2 encoding of PAL 720x576 in Xvid gives data rates nearly double that of DVD. A little over 1 hour of video on a DVDr is not very useful...
Ehm...

Lets see some of my last encodes... :rolleyes:

___________________________________________________

Animatrix - File01 - DVD (R2)

Image: 1024x576 Pix. / 25fps / 09:12 min.

XviD: Version 1 Beta 2
Fixed Quantizer 2 | (VHQ1)
MPEG Matrix

Audio: Dolby Digital (AC3) / 384 kBit/s

Size: File = 310 MB
___________________________________________________

Dreamcatcher - DVD (R2)

Image: 1024x576 Pix. / 25fps / 128 min.

XviD: Version 1 Beta 3
Fixed Quantizer 2 | (VHQ1)
Chroma motion / Trellis
I-frame interval = 250
Matrix = H.263

Audio: Dolby Digital (AC3) / 384 kBit/s

Size: File = 4.32GB
___________________________________________________

Hulk - DVD (R2)

Image: 1024x576 Pix. / 25fps / 132 min.

XviD: Version 1 Beta 3
Fixed Quantizer 2 | (VHQ1)
I-frame interval = 250
Chroma motion / Trellis
BVOP's = 1 / 1 / 0
Matrix = H.263

Audio: Dolby Digital (AC3) / 384 kBit/s

Size: File = 4.21GB
___________________________________________________

Safecrackers - DVD (R2)

Image: 1024x576 Pix. / 25fps / 82 min.

XviD: Version 1 Beta 3
Fixed Quantizer 2 | (VHQ1)
Chroma motion
Matrix = H.263

Audio: Dolby Digital (AC3) / 448 kBit/s

Size: File = 2.23GB
___________________________________________________

X-Man 2 - DVD (R2)

Image: 1024x576 Pix. / 25fps / 128 min.

XviD: Version 1 Beta 3
Fixed Quantizer 2 | (VHQ1)
Chroma motion / Trellis
I-frame interval = 250
Matrix = MPEG

Audio: Dolby Digital (AC3) / 384 kBit/s

Size: File = 3.84GB
___________________________________________________

Note: Resolution is even more than 720x576 pix. here !!!


Bye

[MfA]

Looking ahead for future scene complexity is a good way of improving quality in CBR, but better CBR isnt really relevant to 99.9% of the people here.

If you only care about quality but think fixed quantizer assigns too many bits to for instance high motion scenes aks for better fixed quality coding, if you think the quality of 2-pass is too variable ask for better 2-pass coding.