NuEnc 0.01b Released

[dragongodz]

In VBR-2Pass, at low bitrate, I did not see any real improvement in picture quality compared to the preceding versions even if the choice of the advanced options is much vaster and more pointed.
remember that the new rate control is trying to do exactly that, control the bitrate. the old rate control does not do a real good job. so the old RC can produce rather big spikes which will look great for those scenes but may not play happy on hardware. while the new RC should produce a more consistant bitrate which should produce a more consistant quality. sort of like xvids new stricter scaling option. thats the hope atleast. :)
as for all the extra options Peter has added to the gui....no comment. ;)

[Peter1234]

Peter Cheat,
Is there a VBV buffer size problem? When I set VBV to 224 in NuEnc, BitRateViewer shows output VBV as 112.

[freelock7]

@Dragongodz
Yes.This is why the new version of QuEnc0.56 functions less better in the top bitrate.
My test are based on PC results not on TV. I know the underflow and VBV problems but I think that the goal of the new libavcodec-on the strict level of quality- is to succeed at the same result of the old version.It would be absurd to evolve and obtain worse performances, no?
But I was not satisfied with your conclusion.
So I tested once again in the morning and I found this strange result(I'm lost here):
QuEnc0.55Alpha -with the new modified libavcodec????-produces the same great quality as its little brother QuEnc0.54.
But-last but not least-QuEnc0.56 is worse!!!
What kind of libavcodec 0.55Alpha is using?

[Peter Cheat]

@Peter1234
I thought this too, but BV reports 1835008 / 1024 / 16 (not in KB) whereas NuEnc is asking for a size in KB (1835008 / 1024 / 8). Just there to confuse us ;).

@evade
I intend to upload all my sources, but I don't see a point in uploading everything while I don't have a reliable host. But I have found an awesome free host, just need to get things set up.

@freelock7
The bit distribution (and quality) depend on the rc equation used. Did you try increasing the value of rc variability to 1 (hint hint). QuEnc uses 0.5 by default, but because of the bitrate tolerance, its value is somewhere between 0.5-1 and varies throughout an encoding. Setting RC Variability to 1 is the same as CQ Mode (but not for 1-pass VBR). The bonus being that you know what file size to expect. The downside is you need to do at least 2 passes. RC variability changes the bitrate response - 0 means no change (CBR), 1 means change to keep constant quality (average quantiser).

@dragongodz
I added more options to clutter the GUI :D. Actually, I added the extra options because I was annoyed that I had to recompile every time I changed a parameter. The fact that it is more complicated to use doesn't hurt me :D.

I've done some testing for macro block based rate control (for potentially higher quality). The problem is that first pass stats file becomes MUCH larger than the actual MPEG. Might be better to just forget about that one. There is no real point for me to port the XviD rate control. I stole the good bits :D.

EDIT:
My aim was to fix the underflow issues. As a consequence, quality may improve as the bitrate follows a strict rule (the rc equation).

[Peter Cheat]

@freelock7
QuEnc0.56 may appear to be worse because Nic is using constant quant 2 for first pass, but I don't think he reduced the scene change threshold to compensate. You then get fewer scene changes detected (avcodec uses a stupid scene change algorithm which detects more scene changes with higher quantisers. Scene changes do not vary with quantiser to my eyes ;))

[dragongodz]

It would be absurd to evolve and obtain worse performances, no?
no. the aim is to stick to that standards and be hardware compatible. who cares how great it looks if when you go to play it on hardware it doesnt play or stutters like crazy. so yes everyone wants the quality to stay as good as possible but there will be times when it has to be reduced.

QuEnc0.55Alpha -with the new modified libavcodec????-produces the same great quality as its little brother QuEnc0.54.
that would be because 0.55 and 0.56 do not use the new rate control. Nic said he was planning 0.60 to be released in 2 versions, 1 with old RC and 1 with new RC.

I've done some testing for macro block based rate control (for potentially higher quality). The problem is that first pass stats file becomes MUCH larger than the actual MPEG. Might be better to just forget about that one
for 2 pass MB rate control is probably overkill. for 1 pass VBR however it would be very good.

My aim was to fix the underflow issues. As a consequence, quality may improve as the bitrate follows a strict rule (the rc equation).
or decrease in scenes that the old RC threw copious amounts of bits at. :)

[freelock7]

@Peter
VBR-2Pass comparison (2500kbs)
I confirm with Bitrateviewer: QuEnc0.55Alpha is better than 0.56 with a versatile response in high bitrate.
Peak in high motion picture at 8200 (5500 for QuEnc0.56).
[Settings:Scene detection/GOP15/DC10/QLB Matrix/interlaced]
@Dragongodz
no. the aim is to stick to that standards and be hardware compatible. who cares how great it looks if when you go to play it on hardware it doesnt play or stutters like crazy. so yes everyone wants the quality to stay as good as possible but there will be times when it has to be reduced.
I do not agree
I encoded with FreeEnc and it is read by my DVD player (some minnor underflow can appear sometimes).
I'm looking for the best picture quality on my TV screen. If not, I choose another encoder which works better.
So why CCE is so expensive?
Because it works fine with a good quality.

[Peter Cheat]

@freelock7
Set the RC variability to 1. The quality will be much better. Try it.

The idea is to maximise quality, and stick within the standards. NuEnc does both, but you have to chose RC variability to your own personal tastes. 0.5 introduces heavy curve compression, 1 is just linear even compression. FreeEnc uses 1 by default (rc_eq=tex).


So why CCE is so expensive?
Because it works fine with a good quality.


No, because they are rip-off merchants :D.

[Easy123]

@Peter Cheat:

If you´ve got a free minute could you look after the Link for NuEnc 0.01b on your Homepage. I´d like to give it a go, but the only thing I get is "Error 404" :(

[Peter Cheat]

Another mirror:
NuEnc0.01b (http://www.petersplace.000k2.com/projects/nuenc0.01b.zip)

[johnnyquid]

Peter,

Since there are a lot more options in the GUI that might confuse people it might be a good idea to have a button that resets all the settings back to default settings.

[Mug Funky]

I do not agree
I encoded with FreeEnc and it is read by my DVD player (some minnor underflow can appear sometimes).
I'm looking for the best picture quality on my TV screen. If not, I choose another encoder which works better and everybody can tell you that.

not so. ask anyone who encodes for a living.

people don't worry about how good the quality is if the thing glitches out on their equipment. they'll only notice the glitches. that's a guarantee.

between a slightly blocky DVD and a slightly glitchy one, i can guarantee that the glitchy one will be returned more often (people feel like snobs if they complain about the quality... don't know why).

personally, i think standards compliance is THE ONLY thing stopping lavc based codecs from being used in the mainstream. once that hurdle is overcome, THEN we can make the quality even better. not the other way around, because you must bear in mind that the good quality we spend time trying to achieve might not be possible in a standard compliant model. we should work with the standards and put in as much quality as they'll allow, being careful not to break any possible compliance in the process.

otherwise we might as well author DVDs with VP6, or RV10, or any number of codecs that a DVD player will not understand.

it seems to me that the point of using MPEG-2 rather than a superior codec is precisely one of standard compliance - who wants good looking mpeg-2 if it doesn't play? we might as well be using a better codec.

[edit - minor grammatical adjustments]

[Peter1234]

Peter Cheat,
After you get all of the important things fixed, could you do something to more clearly indicate when encoding is complete. The progress bar color is not very different when starting and finished, and I usually end up looking at the Remaining Time number to confirm that it is finished. Maybe make progress bar change from gray to red. Ringing a bell when finished would also be a nice touch. I know you have already put a lot of work into this, hopefully you are willing to put in a little more. Thanks for all the work you have done already.

[freelock7]

@Mug Funky
It is explained much better but I never said anything else.
Quality & compliance are working together.
@Peter
No change with RC variability <1>.

[dragongodz]

It is explained much better but I never said anything else.
maybe english isnt your first language so you misunderstood but Mug Funky just said basically what i had already said. to which you replied "i do not agree". so actually you DID say something else.

[freelock7]

Sure! Here I'm talking french! So, excuse me for my bad explanations.

What you have to know, that's my research of the quality.
Everybody is trying to obtain such result by developing new product!
I believe in the great libavcodec potential.
That's all.

[Peter Cheat]

@johnnyquid
Good point. Probably why some are complaining about are quality issues. I'll throw that in next release.

@Peter1234
Another good point. I'll make it more obvious that encoding has finished too.

@freelock7
If there is no change when using RC variability = 1, then you are probably doing something wrong. Btw, did you try more than 2 passes? 3 passes gets to over 99% optimal. Also what settings are you using in FreeEnc that provides better results than NuEnc?

EDIT:
Perhaps I should add support for FreeEnc's templates and reduce the number of options in the GUI? Is this a better idea?

[dragongodz]

reduce the number of options in the GUI? Is this a better idea?
the eternal dilema, how much is too little and how much is too much. :)
its better IMHO to have people saying they wish an option was there than to have them complaining the output is bad because they frelled with things they dont understand(but think they do). :D

add support for FreeEnc's templates
what would be the point though ? to give people back access to things they shouldnt be playing with unless they really know what they are doing ?

[Peter Cheat]

Adding some sort of template support would be beneficial I guess because known settings could be put into files and users would select a template, bitrate, mpeg version etc and the output would be more predictable. Editting those templates would not be a good idea for newbies, but on the other hand, the only way to learn is to try, make a mistake, then figure out what you did wrong. For example, settings used for high quality in avcodec doesn't work well at low bitrates, especially trellis and RD MB decision. But I didn't know that until I tried.

Here is a mirror (http://www.petersplace.000k2.com/projects/) to all the files relating to avcodec. I haven't finished uploading all the sources, but I do intend to. I've rewritten the scene detection algorithm in avcodec, and now intend to implement closed gop with scene detection, the same way as done in CCE (only closing gops when there is scene change). Just need to figure out what the current code actually does in that area.

[dragongodz]

Adding some sort of template support would be beneficial I guess because known settings could be put into files and users would select a template, bitrate, mpeg version etc and the output would be more predictable.
yes i can see the benefit of templates but i just dont agree with the freeenc model of having every option possible, buts thats me. :)

now intend to implement closed gop with scene detection, the same way as done in CCE (only closing gops when there is scene change).
cool. another minor problem is open GOP streams do not start with a closed GOP even when B frames are used, so starts IP instead of IBBP(for example). so the first GOP is always shorter than specified. other encoders such as CCE and Tmpgenc close the first GOP in such cases from memory.

[Fl0ppy]

Hi!! i'm just trying to make a xvcd with this great tool, but i have some questions about it:
Where i can found some explanations about the options like
Mb decision (compare fn, least bits, rd), Compare fn (SAd and satd)and wich it's the best search size?

i tried to make a simple comparasion with an xvid file to vcd, but if i want a loot of quality i need to put Min quant in 1 (but when it plays i see some artifacts).

i tried this conf:
gopsize 12
Min Quant:2 Max quant: 31
Md decision: Copmnf
Compfn: SaTD
Search size: Diamond 0
Aspect ratio 4:3
Noise reduction: 0
Rate control: 0.5
Min bitrate 300
Max bitrate 2500
CQ: 100

Any mini-howto-explanation?

[dragongodz]

SATD is slightly better quality than SAD.
least bits good for low bitrate while rate distortion(rd) may be better for high bitrates.
diamond size should be atleast 1 really if you expect reasonable quality. higher should increase quality(slightly) each step.


how technical do you want the information ?

[freelock7]

Encountered problem with NuEnc01.01b mirror:
If <nuEnc.exe> don't run after installation, just go in the registry at
1)<HKey_LOCAL_MACHINE_/SOFTWARE/NuEnc>
2)<HKey_LOCAL_MACHINE_/SOFTWARE/QuEnc>
3)Delete both of them.
It resets all default parameters.

[Peter1234]

dragongodz,
Thanks for the helpful hints. I tried the following and got much better results at low bit rates (and much longer encode times).

Mode = VBR
Passes = 2
Scene Detection = checked
MB Decision = Least bits
Compare Fn = SATD
Search Size = Diamond 6
RC Variability = 0.5
Matrix = KVCD Notch
Noise Reduction = 0
Use Trellis Quantisation = unchecked
Turbo 1st Pass = checked

[Peter Cheat]

@Peter1234
A search size of 6 isn't worth the extra encode time. Try 3 or 4 (or less). The difference between 3 and 6 is small.

@freelock7
The mirror is the exactly the same file. Shouldn't be any problems.

@dragongodz
Ok, first GOP will always start IP then. It isn't a good idea to have only 1 reference for b-frames ;).

Some of the options in FreeEnc don't even refer to MPEG1 or 2. That is what I think is silly.

[Fl0ppy]

i'm looking the best (if it's possible) configuration for convert mpeg4 to mpeg 1 and 2.
Now tmpgenc offer better quality (i now it's relative).:D
And if it's possible a doc with explanations about the options in Advanced.

When a version with sse2-p4-ht?:rolleyes:

Cheers.

[dragongodz]

Ok, first GOP will always start IP then.
sorry Peter i didnt explain that well enough. what i meant is that when closed GOP is not selected then MainConcept, CCE and Tmpgenc all have the first GOP closed and then following GOPs are open. with avcodec the first GOP is open aswell. as i said just a minor thing really which may not make much difference in the scheme of things. :)
i also checked their first GOP patterns and they all did IP.

When a version with sse2-p4-ht?
avcodec has mmx,sse,sse2(bit buggy) already. as for HT well thats also meant to be rather buggy so should probably wait until everything else is ok. 1 problem at a time. :D

[Peter Cheat]

Is there a reason for closing the first GOP? I don't see any benefits of closing the first gop (unless it is a new scene).

@Fl0ppy
Try the 'HVS Good' matrix.

[dragongodz]

Is there a reason for closing the first GOP? I don't see any benefits of closing the first gop (unless it is a new scene).
no idea. have had a search for a possible reason but havnt found any yet. its just strange that they all do it. as i said it may not make much difference in the scheme of things. if i do eventually find a reason i will let you know. :)

[dragongodz]

hmm ok found this snippet

http://www.geocities.com/medinotes/vcd/chapters.html

if you go down to the Tmpgenc part it says
Another excellent MPEG encoder all round. This one does insert regular MPEG sequence headers, but there is a setting should probably be changed from default in the template:

1. If encoding a VCD, make sure that either the PAL VCD or NTSC VCD template is loaded. Then click on "Configure"
2. Click on GOP structure
3. Now, click and tick the option "Create bitstream for editing"

This will ensure that there are regular closed GOPs and thus regular MPEG sequence headers (as you can see in figure 3, TMPGEnc automatically puts in 1 sequence header per GOP).

If this setting isn't ticked, TMPGEnc can sometimes encode the MPEG in such a way that the GOP isn't closed for an extended interval (> 2 seconds). During that interval, no MPEG sequence header will be present and thus there may be an issue with entrypoint (and thus chapter) placement.
so maybe thats why Tmpgenc does the first GOP closed(big maybe i say).

still for dvd all GOPs should have sequence headers anyway.
http://www.pioneeraus.com.au/computer/dvdInfo/dvdInfo_9.html

so long as sequence headers are neing written every GOP then i dont think it really matters. still as i said before it is strange that the other encoders do it aswell.

[Mug Funky]

FWIW, premiere pro has problems with i-frames. editing is fine, but on export it places the b-frame after the i-frame on the other side of it, causing a kind of "double-take" at scenechanges. this only happens when the user has placed an edit on that scenechange.

i learnt this one the hard way. :(

whether this has anything at all to do with sequence headers and p-frames immediately proceeding i-frames on closed GOPs, i don't know.

[hank315]

Is there a reason for closing the first GOP?
No, there is no real reason.
If you create the first GOP as IPBBPBB... than the closed gop flag may be set to 0 or 1.
But if the first GOP looks like IBBPBB... and the closed gop flag is not set, a lot of decoders and editors will complain even if the first B-frames are backward predicted so it could be decoded fine.

According to the specs:
closed_gop
This is a one-bit flag which indicates the nature of the predictions used in the first consecutive B-pictures (if any) immediately following the first coded I-frame following the group of picture header .
closed_gop is set to ‘1’ to indicate that these B-pictures have been encoded using only backward prediction or intra coding.
This bit is provided for use during any editing which occurs after encoding. If the previous pictures have been removed by editing, broken_link may be set to ‘1’ so that a decoder may avoid displaying these B-Pictures following the first I-Picture following the group of picture header. However if the closed_gop bit is set to ‘1’, then the editor may choose not to set the broken_link bit as these B-Pictures can be correctly decoded.
broken_link
This is a one-bit flag which shall be set to ‘0’ during encoding. It is set to ‘1’ to indicate that the first consecutive B-Pictures (if any) immediately following the first coded I-frame following the group of picture header may not be correctly decoded because the reference frame which is used for prediction is not available (because of the action of editing).
A decoder may use this flag to avoid displaying frames that cannot be correctly decoded.

To be on the safe side and make the stream fully compatible with all decoders just create the first GOP in the same manner as after a scene change and make it IPBBPBB... and set the closed gop flag.

[Peter Cheat]

AFAIK, closed GOP is about how a GOP ends, not how it starts.

Not Closed
I B B P B B P B B I B B P B B

Closed GOP
I B B P B B P B P I B B P B B

(In decoded or display order)

The B-frames in bold are referencing a frame which is unrelated to the current frame - which is wasteful. A closed GOP means that a P frame precedes the next I frame.

CCE and TMPGEnc both start:
I B B P B B P in decoded order (or display order)
1 2 3 4 5 6 7

I P B B P B B in encoded order
1 4 2 3 7 5 6

Avcodec already does this, so I don't have to change anything there. Avcodec also inserts a sequence header with every I frame, regardless of whether the GOP is closed or not, so no problems there.

[hank315]

AFAIK, closed GOP is about how a GOP ends, not how it starts.
It's about the start of a GOP. If a GOP is closed you can make a cut before that GOP and both parts will decode OK.
Also in the case of a scene change you start with a closed GOP so you can make a cut before that GOP.
The order I was referring to was the encoding order so:
IBBPBB --> open GOP --> temporal reference 2 0 1 5 3 4
IPBBPBB --> closed GOP --> temporal reference 0 3 1 2 6 4 5

If you write in display order I B B P B B P B B I B B P B B than the bold B-pics actually belong to the next GOP.

If AVcodec starts with IPBBPBB... (encoding order) it's OK but I still think you should set the closed gop flag.

[dragongodz]

wow what a can of worms i opened with 1 little observation. :D

actually something else i was thinking about Peter, would it be possible for you to make your RC a seperate and selecatable RC ? that way have both old RC and new usable from the 1 program. no need for Nic to release 2 versions of QuEnc for people to test and compare the 2 RC's then. :)

i know Michael(from FFMpeg) said thats what he planned for a second ,better, RC but as far as i know he has still only half done it(the second RC that is).

[Peter Cheat]

Originally posted by hank315
If you write in display order I B B P B B P B B I B B P B B than the bold B-pics actually belong to the next GOP.

True, but this would depend on the definition of GOP (true if considering decoded order).
EDIT: Since the B-frames are referring to 2 different GOPs, how can you say which GOP it belongs to. Is a bisexual person gay or straight?

@dragongodz
Can be easily done. I've finished the code for closed gop and it seems to work as it should. I'll separate RC next.

[Fl0ppy]

Hi again :D
After severals tests (converting xvid and dvd to mpeg1) i tried nuenc 0.01b and tmpgenc.
If in nuenc i put CQ 100, the quality is great, but if i put CQ 80 or 90 the quality in less than tmpgenc at same quality (80 or 90)
And the file created by nuenc/ffmpeg is half of tmpgenc :confused:
And the speed is 32fps (at 352x288 mpeg1) (i can wait);)

[dragongodz]

if i put CQ 80 or 90 the quality in less than tmpgenc at same quality (80 or 90)
And the file created by nuenc/ffmpeg is half of tmpgenc
if the nuenc encodes are half the size then i am not surprised they are of less quality. you can only fairly judge the quality with encodes of the same size.

two things to also remember.
1. mpeg1 encoding with avcodec is not meant to be the absolute best.
2. the CQ mode is brand new so will probably take a little time and tweaking to get towards optimal.

[Fl0ppy]

1. mpeg1 encoding with avcodec is not meant to be the absolute best. :rolleyes:
okay, it's better codify with tmpgencoder actually?,'coz i'm trying to migrate to nuenc.
Thanks.:D

[Mug Funky]

also, TMPG uses a different scale. so 80 in TMPGenc ≠ 80 in QuEnc.

i'd be interested in seeing what equal sized encodes look like between TMPG and QuEnc.

[spase]

like Fl0ppy, i too am encoding xvid to mpeg-2 for dvd purposes... looks like at about 2300kbps abr (maybe a little higher or lower).

i have been testing with quenc to see what bitrates produce acceptable quality (acceptable to me that is) and i decided to give NuEnc a try, just for the fact that it has more than 2 passes (encode time isn't really an issue for me right now) and it has all these matrices built in via the ini file.

in any case, i am test encoding right now @ 2600kbps 3 pass vbr with...

tellis quant. enabled
DC precision: 10
search size: diamond 1
compare fn: satd
MB decision: RD
dynamic b-frames enabled
scene detection enabled
4:3 aspect
noise reduction: 0
rc variability: 0.5
quantiser: 2-31
matrix HVS Good (based on peter cheat's comment to Fl0ppy earlier in this thread)

i plan on comparing this to the encode of similar settings in QuEnc 0.56... i posted in another thread regarding this.

any suggestions for tweaking these options @ about 2300kbps?

anyhow, my REAL questions is: how do i choose a custom matrix from the ini from the command line?... or is this not possible?

the reason i ask, is i am leaving for a few days and would like to write a batch file to let my computer encode while i am gone, whether it be using QuEnc or NuEnc.

[Peter Cheat]

@spase
Custom matrices can not be selected via the commandline yet. The last matrix chosen will be used. If you want to use the same matrix for all the files you won't have a problem.

MB decision: RD is very slow. Least bits may be better.
setting rc variability to 1 gives better quality
trellis is a bit buggy, but should work ok for the settings you've chosen.

The settings you've chosen will make for extremely slow encoding.

@Fl0ppy
CQ Mode in NuEnc is not same as TMPGEnc for a fair comparison, file size must be the same (or at least very close). In NuEnc, CQ Mode is linear while in TMPGEnc its not. This is for easy prediction. Infact, the value represents the proportion of the filesize to expect, where CQ100 is maximum (100%), and CQ80 is very roughly 80% of the size of CQ100. The accuracy depends on what you are encoding. Initially, I had made it very much the same as TMPGEnc, but changed it as requested on the KVCD forum.

@dragongodz
MPEG-1 encoding with avcodec is on par with TMPGEnc's MPEG-1 encoding. I don't know how or why it has a bad name. Try a visual comparison of CQ mode in NuEnc with TMPGEnc (same matrix/filesize).

[dragongodz]

MPEG-1 encoding with avcodec is on par with TMPGEnc's MPEG-1 encoding. I don't know how or why it has a bad name.
possibly because of the RC ?

[Fl0ppy]

I tried a few samp`les (5520frames from xvid file) and a CBR 700, with the same matrix (standard). Results:
The file size it's the same, but the quality it's much much better in tmpgenc. :confused:

[Peter Cheat]

CBR encoding does suck with NuEnc and every avcodec derivative. For a comparison of optimal quality attainable by both encoders, you have to use CQ mode, and try to get the same filesizes.

CBR @700kbit/s is never going to look good anyway.

[spase]

@Peter Cheat: thanks for the quick reply!

now off to encode video forever and author a DVD (using all freeware!)

[Peter1234]

Peter Cheat,
The more I use NuEnc 0.01b, the more impressed I get with it. Several times it has been recommended to use RC Variability = 1 for better results. My tests seem to indicate that this is true. So, when should I not use RC Variability = 1?

[Paced]

Originally posted by Peter1234
Peter Cheat,
The more I use NuEnc 0.01b, the more impressed I get with it. Several times it has been recommended to use RC Variability = 1 for better results. My tests seem to indicate that this is true. So, when should I not use RC Variability = 1?

You should tend to go towards a value of 0 (not necessarily 0, just something lower than 1) when working with lower bitrates.

[Peter1234]

Paced,
OK. That seems reasonable. Thanks.

EDIT: So a value of zero would allow more variablility than a value of 1. Is that correct? I was assuming it was the other way around.

from READ ME file: RC Variability - 1 = Constant Quality, 0 = Constant Bitrate. 0.5 is default (Use 1 for high bitrates).

For low bit rates wouldn't you want to have the bit rate vary a lot so that only those parts of video needing high bit rates would use more bits?

I guess I am still confused.

EDIT 2: After thinking about this for a while I have come to the following conclusion (which may be completely wrong). At low bit rates a larger variability is better since only those portions of video needing more bits should have bits allocated to them. Setting RC Variability to less than 1 should only be done for CBR, and CBR does not give as good a quality of output as VBR. Therefore, for best quality set RC Variability to 1 and only set to less than 1 if CBR is desired. If I am guilty of fuzzy thinking please correct me.

[Peter1234]

Since I was not clear about what RC value was best at low bit rates, I did a test at 773 kbps video with 96 kbps audio using 352x480 mpeg2. The results show that always using RC=1.0 seems to be best. Also shows that CQ mode gives better quality than VBR mode for same file size.

mode_________peak_kbps____ave_kbps____peak_Q______ave_Q____size_____passes


VBR_RC=0.2______2402_________899_______15.0________7.01___16.3_MB______2

VBR_RC=0.5______2121_________897_______12.7________6.85___16.2_MB______2

VBR_RC=1.0______1898_________895_______11.0________6.94___16.3_MB______2

CQ__RC=1.0______1753_________869_______5.94________5.83___15.6_MB______1


Results from BitRateViewer. All paramters except mode and rate control were the same for all tests. kbps values are for video plus 96 kbps audio.