RV9-EHQ

[karl_lillevold]

[Edit Feb 2004: This post is a little dated by now, but I have not had time to update lately. Please see the thread on "The Real 10 Platform" (http://forum.doom9.org/showthread.php?s=&threadid=68245)] and RealVideo 10 'Elysian' (http://forum.doom9.org/showthread.php?s=&threadid=71022).

The Helix Producer 9.2 June 4th build was the first Producer to include a RV9-EHQ. You can download the latest Milestone build from the Helix Community file sharing section (https://helixcommunity.org/beula/download/).
Remember that after signing up, you have to agree to the RPSL (or RCSL) license and also the Binary EULA before you can download it. Note that most RV9 encoding tools [see below] already include a version of Producer with EHQ, and then you do not have to download a separate Producer from above.

In many cases a quality improvement corresponding to a 30% bitrate reduction can be seen compared with standard RV9, and this is with a fully backwards compatible bitstream.

As you may know, PSNR measurements are the most commonly used indication of compression efficiency for video codecs. Compared with for instance VSS H.264 codec in its best quality mode, RV9-EHQ has better compression efficiency, and still encodes 25X faster.

It would not help if I were to say it is the best available codec today, so you should try it out to see for yourself. It is really easy to get started, using one of the tools mentioned below.

Also, unless you have read it already, please see the first post in the sticky RealVideo 9 Information (http://forum.doom9.org/showthread.php?s=&threadid=40392) thread.

Feedback

Very good so far. Some examples (hope you don't mind - can also be read further down in this thread)

Sagittaire's PSNR and visual comparison (http://forum.doom9.org/showthread.php?s=&threadid=57687): "PSNR: RV9 EHQ is the most powerful codec in this test and by far. It's also the codec which most beautiful is visually compared with the others codecs."

iwod: "EHQ has proven to be extremely sucessful. Quality has been improve 10-30% across the board. And EHQ only sacrifices the encoding time without the need for more resources on decoder!"

Sirber: "Oh yeah! The image is sharper with complexity at 80, at the same bitrate. I think waiting 4 hours worth it :D "

zedude: "good news :). i did some tests and got beautiful results :D. "my tests showed me i could now encode with a lower bits/(pix*frame) value (about 0.03 less [20%]) without losing any quality and at the same time i get a better quality in high action scenes."

31 Flavas: "450kbps (386kpbs video @634x344:24fps, 64 kpbs audio) was previously just outside of what I consider 10 out of 10 video (on Japanese cartoons). But it is now firmly inside. The "stuff going on" that is in the pre-EHQ encode is not in the EHQ (complexity = 80) encode."

DaWolf: "Now, with encoder complexity at 80, the results are really impressive: a clear, tight picture with hardly any "stuff going on". Karl really must be too much with his nose in it for him to say "I am really glad you notice a difference!" as only extremely visually impaired persons would not notice an difference :-) It's just like that: it's not a matter of bending over closely to your screen to try to figure out what, if anything, has changed - it is self evident. Well worth the extra encoding time."

wing1: "EHQ for RV9 is awesome for quality at low bitrate [...] I got sharp detail video (656x464 NTSC) for 1/2 the filesize (1min=4Mb) that I would have gotten if encoded normally (8.2Mb)"

How to enable RV9-EHQ

EDIT: 07/24: Producer Milestone 5 includes a change that accidentally removed the previous method to enable EHQ. Please see this thread (http://forum.doom9.org/showthread.php?s=&threadid=58196) for the new method to enable EHQ, and a corrected encoder DLL, that will work with the previous method and all existing tools, or preferably, use Milestone 6 instead.

Most RV9 encoding tools include support for EHQ, but it is rarely the default setting, so remember to change the setting to Extra High, or '80'. Three examples:

AutoRV9 1.3b4 (http://forum.doom9.org/showthread.php?s=&threadid=29077): Pull-down menu in codec tab "Select EHQ Mode : Very High". With 1.3b4 the corrected encoder DLL is not needed, since it uses the new method to enable EHQ.

rmfactory (http://forum.doom9.org/showthread.php?s=&threadid=53518&highlight=rmfactory): Pull-down menu in final tab: "EHQ Level : higher (3X)".

Helix Producer GUI (http://helixproducergui.fr.st/): check Enable EHQ in Audience Generator, select '80'

You can use registry over-rides for tools that do not yet support EHQ (see below) as well as for the GUI Helix Producer after having replaced the RV9 encoder DLL (instructions in next post)

or Edit Audience/Job file manually:

Include the following in the <videoStream> section of the audience:
<codecProperties type="bag">
<encoderComplexity type="uint">80</encoderComplexity>
<customPacketSize type="uint">16000</customPacketSize>
</codecProperties>
encoderComplexity sets the EHQ level:
65 = Default : improved efficiency for high action
75 = High : same as 65 + better mode decisions, better representation of high motion
85 = Extra High: same as 75 + best possible mode decisions, very high accuracy motion representation
50 = Fast : not recommended, use only for Live capture encoding

as you can see, there is some improvement even for the default mode.
The customPacketSize parameter increases compression efficiency for high action. Note that streams compressed with the customPacketSize parameter set to 16000 are not recommended for Internet streaming via Helix server. This parameter will be default for VBR over a certain bitrate, but is needed for now.

Encoding times:
65: same encoding time as before
75: will take about 2X - 2.5X encoding time compared to default
85: about 3X - 4X default

Can it be made any faster? Every CPU cycle is spent trying to find more optimal compression parameters, and every CPU intensive function is fully MMX/SSE/SSE2 optimized. I am looking into speeding up the 1st pass in a 2-pass encoding, but no results on this yet.

Is the improvement worth the slower encoding speed? Well, certainly for me it is, and based on the feedback, I think those who have tried it agree.

Registry over-rides

--->8---

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\RealNetworks\RV9]
"encoderComplexity"=dword:00000055
"customPacketSize"=dword:00003e80

--->8---

[copy and paste this to a new file, save as rv9-ehq.reg (http://www.lillevold.com/files/rv9-ehq.reg), double-click to enter in registry. Please remember that you have these these keys, otherwise the audience file settings will have no effect. These keys may change in the future]

These settings can be used after replacing the encoder DLL in the GUI Helix Producer, and any other tool which does not have the EHQ setting. Note that the encoder DLL needs to be replaced in all cases...

IMPORTANT: These values are in HEX so 0x50 = 80 decimal, and 0x3e80 = 16000 decimal. Remember to click the Decimal checkbox when entering new values in the registry editor.

[karl_lillevold]

Download a build of Command line Helix Producer that has EHQ (see above).

1) Go to C:\Program Files\Real\Helix Producer Plus\codecs (or the codecs folder where you installed Helix Producer.
2) move rv403260.dll and erv43260.dll to a backup folder
3) copy erv4.dll in the codecs folder from the Command line Helix Producer into the folder mentioned in 1)
4) rename erv4.dll to rv403260.dll

Use registry over-rides to set the encoderComplexity level as described above. Remember to use decimal values.

(At encoderComplexity=80 encoding should take around 3X what it takes at 65)

Have fun!

[slavickas]

Originally posted by karl_lillevold
... Note that streams compressed with this parameter are not recommended for Internet streaming.
...

can i assume (big)LAN!=internet?

EDIT: (maybe it was posted?) is it possible to get that updated resizer work with GUI version?

EDIT2: it seems there is new multi-channel codec, but it's based on "cook" :( , anyway i don't care about more than stereo :rolleyes:

[karl_lillevold]

Originally posted by slavickas
can i assume (big)LAN!=internet?

EDIT: (maybe it was posted?) is it possible to get that updated resizer work with GUI version?
Regarding the customPacketSize parameter: "Internet streaming" = streaming on the Internet at large via Helix or RealServer. LAN playback is no problem. Also, this applies only to the customPacketSize parameter, not the EHQ mode in general. The customPacketSize is only a very small part of the overall improvement.

If with "updated resizer" you are referring to what is mentioned here:
https://helix-producer.helixcommunity.org/specs/Producer9.2/9.2Release/index.htm#29_Faster_Video_Resize
I am afraid this has not yet been included.

EDIT: yes, Helix Producer can now encode multi-channel audio natively, but since it can not be played back in released players, its usefulness is a little limited for now.

[Sirber]

With Helix GUI, on my computer:

Input: Ranma ½ S01E01 (640x480)
Output: Q80, 300kbps including a 32kbps voice

Statistics:

3-6 FPS

I'll post some screens later.

[edit]

I forgot, THANKS A LOT KARL!!! :D :D :D

[edit #2]

What will it do if I set complexity to 90 or 100?

[another edit]

After 1h, 50% of the first pass done. So I can say that at Complexity 80, the codec is 4x slower. Whitout the new mode, it's 1h05 per episode.

[karl_lillevold]

Sirber: 4X is probably more reasonable on an AMD without SSE2, and it also depends on content and bitrate. Sorry about that! I have edited my first post to reflect this.

EDIT: encoderComplexity above 80 does not improve anything further (yet)

[bond]

hy
i have two questions
1) where and how can i download the latest compiles for helix producer? i already registered but :rolleyes:
2) am i right that with your work on helix producer you try to get the best possible out of realvideo9 (for example with ehq) without changing the codec itself?

[karl_lillevold]

Originally posted by bond
hy
i have two questions
1) where and how can i download the latest compiles for helix producer? i already registered but :rolleyes:
2) am i right that with your work on helix producer you try to get the best possible out of realvideo9 (for example with ehq) without changing the codec itself?
1) When you have registered and obtained a username on helixcommunity.org, all you have to do is agree to the binary EULA, and then you should have access to the binary download section. The release with EHQ is the June 4 build. This is a zip file which unpacks the command line Helix Producer. Did you try the link in the first post?
2) all my work on RV9-EHQ is actually in the codec itself. It's all about the codec making more optimal encoding decisions, without changing the format of the bitstream. The resulting bitstream can then be played back in existing decoders. There are also improvements in Producer, but these are feature and system related. So to summarize: the RV9-EHQ changes live in the encoder codec which is part of Helix Producer, but produces RV9 bitstreams that are backwards compatible with existing RV9 decoder codecs.

[31 Flavas]

Originally posted by bond
hy
i have two questions
1) where and how can i download the latest compiles for helix producer? i already registered but :rolleyes: You have to agree to their binary EULA.

Login first, and on the left hand side there is a "(licensees only!)" Click on it and click on "Binary EULA". Agree to it and you can then download the pre-compiled binaries.

[Sirber]

With Ranma, from the preview, quality hasn't increased much IMHO. I'll post clips of both when ready.

Still 1h45 to go.

[karl_lillevold]

Like I mentioned, it depends a lot on the content, and the preview window shows a fast resized video (read low quality) preview. You will not always get the improvement you saw in the example I compressed for you earlier. In fact, I am sure sometimes it is impossible to see any improvement, that's how video compression works. However, the encoder always makes better encoding decisions in this mode, but whether or not the resulting visual improvement is worth the extra time depends on your computer and your available time.

Instead of just compressing one long clip at one set bitrate to decide the new mode's usefulness, I would perhaps have recommended trying a few shorter clips at different bitrates. Then you would have much more varied results.

[bond]

thanks :)

[Sirber]

I'll wait for the final before concluding :D

I'll make the clip using smil to have both playing at the same time.

[karl_lillevold]

well, at least then you can make a conclusion for that particular clip at that bitrate ;)

[31 Flavas]

Karl I remember something about max startup latency being increased to 60 seconds, is this true? Was it included in the June 4th build?

Would following the procedures to use the June 4th build in the Helix GUI Producer allow a msl of 60 to be used?

Thank you.

[karl_lillevold]

The good news is Max startup latency is now 60 seconds, and minimum 1 second (previously 5) for those who need really short latency (near real-time communication, security, live etc).

The bad news is I don't think this can be made to work in the GUI Producer, since this max / min limitation is built into Producer and not the codec.

[Kaiousama]

As you may know, PSNR measurements are the most commonly used indication of compression efficiency for video codecs. Compared with for instance VSS H.264 codec in its best quality mode, RV9-EHQ has higher compression efficiency, and encodes 25X faster. I may post a couple of these PSNR charts.

Is there a way to assay PSNR on RealVideo files? if yes, how? (the actual avisynth's PSNR would be good but i don't know how to open a .rmvb file via Avisynth)

Thanks

[slavickas]

Originally posted by Kaiousama
Is there a way to assay PSNR on RealVideo files? if yes, how? (the actual avisynth's PSNR would be good but i don't know how to open a .rmvb file via Avisynth)

Thanks

with new producer it is possible output to raw yuv file, and probably Karl have spme self-made tools :cool:

[Sirber]

Oh yeah!

The image is sharper with complexity at 80, at the same bitrate. I think waiting 4 hours worth it :D :D :D

[Sirber]

Originally posted by karl_lillevold
The good news is Max startup latency is now 60 seconds, and minimum 1 second (previously 5) for those who need really short latency (near real-time communication, security, live etc).

The bad news is I don't think this can be made to work in the GUI Producer, since this max / min limitation is built into Producer and not the codec.

Can you make a crack for it? :D

[zedude]

good news :)
i did some tests and got beautiful results :)
also i have some questions :
- in producer log , i get:
PID828,Informational,SDK Encoding,2003/06/10 01:22:32,15004,Starting analysis pass
PID828,Diagnostic,Video Codec,2003/06/10 01:22:32,20049,Setting video packet size to 1352
the video packet size should be 16380 like i asked in the audience ? i think i'm wrong somewhere but don't know where :)
in general , is there a way to ensure ehq is 'really' enabled ?
- is <useThreads> enabled ? (should i delete this line ?)
- do you think that max startup latency at 60 is a good default for encodes ? i make my tests on short files (about one minute), does it have any influence on bits distribution ?

[Sirber]

@Zedude

Make me a special build and I'll test :D :D :D :D :D

[zedude]

@sirber : you just have to edit video audience and change maxstartuplatency value...you know i'm lazier than you :D

[Dark-Cracker]

@zedude

>the video packet size should be 16380 like i asked in the audience ?

in the audience i think custom=MAXpacketsize at 16380 not the average packet size :) but i am not sure.

>- do you think that max startup latency at 60 is a good default for encodes ?

much latency is hight and must the codec can analyse the motion to made a better bit redistribution.

Bye.

[karl_lillevold]

Re customPacketSize : the reason this is currently needed for the codec, is to over-ride Producer's request to set it to 1352. Later this will change, and Producer will set it correctly for high bitrate VBR streams meant for download, and it will also be a Producer option. But for now, please use 16000 in the codecProperties, not 16380 (long story, this is due to a bug in old renderers, and we would like old players/renderers to work..)

Re useThreads : this is no longer needed. If you have a dual CPU, you could set useThreads to 0, but there is no advantage, it will just run slower, so this is good only for debug purposes. With regards to hyper-threaded P4s : I detect this, and actually disable threading, due to cache contention causing slightly lower performance with two codec threads on hyper-threaded systems. True dual CPU systems rock though, almost twice the speed of single CPU systems.

Re Max startup latency : Maybe I will add a codec registry hack later, but the problem is the codec is too good at staying at the average bitrate, and it would rarely, if ever fill a large buffer. Perhaps only in 1-pass where it is not as good at keeping the average bitrate (yes, 1-pass sometimes actually looks better for short clips, because it spends more bits, filling the latency buffer to a higher level, but then also creating a higher bitrate larger file). We are planning to improve 2-pass VBR, so maybe there will be improvements happening in this area.

[bond]

Originally posted by karl_lillevold
2) all my work on RV9-EHQ is actually in the codec itself. It's all about the codec making more optimal encoding decisions, without changing the format of the bitstream. The resulting bitstream can then be played back in existing decoders. There are also improvements in Producer, but these are feature and system related. So to summarize: the RV9-EHQ changes live in the encoder codec which is part of Helix Producer, but produces RV9 bitstreams that are backwards compatible with existing RV9 decoder codecs.so all the work on the improvement of the codec quality is done in the codec itself (so nothing like nandub-tuning?)...

is there any official codec numbering, like realvideo9.0.2, to know which version i am using...
there are so many files i dont know which one is the most important to check the version number (erv43260.dll/erv4.dll ?) :confused:

thanks :)

[31 Flavas]

Originally posted by karl_lillevold

Will the improvement be worth the slower encoding speed? Yes! At least in my humble opinion.

450kbps (386kpbs video @634x344:24fps, 64 kpbs audio) was previously just outside of what I consider 10 out of 10 video (on Japanese cartoons). But it is now firmly inside. The "stuff going on" that is in the pre-EHQ encode is not in the EHQ (complexity = 80) encode.

Impressive work, karl!

---

Heh, time to bug Doomie for another codec shootout :D

[zedude]

ok , thank you for these answers :)
i 'll soon update rmfactory with this custompacketsize and keep maxstartuplatency at 25 sec as default...
my tests showed me i could now encode with a lower bits/(pix*frame) value (about 0.03 less) without losing any quality and at the same time i get a better quality in high action scenes :)
you did great work karl !!

[karl_lillevold]

@everyone : thanks for your comments, I am really glad you notice a difference! I am sure it is much too soon for another codec test, but Doom9's most recent test along with one from c't, were part of the reason I started this work.

@bond : I am not exactly sure what nanDub-tuning means, but this work is all in the core codec, improving its decision logic. Good idea re version information. I will change it in the DLL to read "RealVideo 9 EHQ". that way it is easier to see which version is which. Until then, you could always keep backup copies in appropriately named folders :)

@31 Flavas : good example on where visual improvement can be found. I have a clip provided by Sirber, with foreground objects moving across a pure white background. At 350 kbps, the improvement is much higher than I had hoped for.

@zedude : interestingly enough, that reduction in number of bits/pix is just about what I have noticed as well during my experiments. As an example, if I were previously using 0.18 bits/pix for a certain clip, I can now use 0.15 or even 0.145.

[RadicalEd]

Originally posted by slavickas
with new producer it is possible output to raw yuv file, and probably Karl have spme self-made tools :cool:

hey yeah, speaking of this, is there a better way than EO Video to decompress RealVideo stuff :|

[Sirber]

What's the point in decompressing RMVB?

[slavickas]

Originally posted by Sirber
What's the point in decompressing RMVB?

maybe burning as (s)vcd? and that's all i can think

[Sirber]

I made some tests with EHQ. Quality is deffinitly better. Image is sharper and low-bitrate encodes really needs it. :D

[edit]

But... 4 hours is SO long!!! Would be great to optimize the encoder for 3DNOW!/3DNOW!+.

3DNow!+ : Enhanced 3DNow!

Technology from AMD.

The enhanced 3DNow! technology implemented in the AMD Athlon takes 3D multimedia performance to new heights and builds on the 21 instructions of AMD's original 3DNow! technology - the first x86 instruction set to use superscalar SIMD floating-point techniques. Enhanced 3DNow! adds 24 new instructions - 19 to improve MMX™ integer math calculations and enhance data movement for Internet streaming applications and 5 DSP extensions for soft modem, soft ADSL, Dolby Digital, and MP3 applications. This new DSP functionality of the AMD Athlon is not supported by the Pentium III.

3DNow!+ capable CPU

AMD :

Athlon
Duron

[Ramirez]

LOL! Sirber, you're really thinking that 4 hours it's a long time? How about 20 hours just to complete the first pass.:D

Duration: 2:28:34 /EHQ-80/1024x436/850kbps/2-passVBR
wanna guess the name of the DVD title? (A hint: "Stay with me!") :p

Btw: Great work Karl!,:) thank you very much. Speed is really none important factor for me (well, almost :))as long as I am getting great results.

[Sirber]

Originally posted by Ramirez
wanna guess the name of the DVD title? (A hint: "Stay with me!") :p

[censored]

P.S. My FTP is open :D

To all modo: I'm just joking.

In fact, I have no idea what's the DVD title. "Stay with me!" can suite a lot of movies, like E.T., Home Alone and Terminator 2...

[nah]

Some tests with dual AMD :

Tests done with x2real (720x304 avi source from a divX 2CD 1200 Kbits)
compression at 675 Kbits
complexity 65 : 75-83 % of CPU load -> 35-42 fps (a bit degraded compare from divx)
complexity 80 : 92-99 % of CPU load -> 14-18 fps (no visual degradation from the divx)

Very good !

<UseThread> create in .rpad from RMFactory 0.3 lock the dual mode : 50% cpu load. I delete it in my tests.

EHQ at 80 use all the power of dual cpu !! cool. Before it was about 80-85 %

I use X2Real to convert AVI-AVS, and easy insertion of filters and job control (but no jobsave :( ).
RMFactory 0.3 avi option is not very intuitive.

------------------------------------------------------------------------
A7M-266 2x2XP1.77Ghz@2.4GHz 1Go RAM XP

[DaWolf]

44 minutes X-File episode SVCD (org. source: DVD) -> 350 Kbits (318 video) 1-pass VBR, encoder complexity 80 @ 480 x 360: 6 hours and 10 minutes (was: 1 and a half hour at encoder complexity 65) on a Celereon 1.7 GHz with 384 MB RAM.

The result is really most impressive and pleasing to my eyes.

At 65 this rate used to produce acceptably good results. The "stuff going on" in the background or out of the focus would sometimes hint at that this was a low bitrate encode but overall the quality was good enough (TV/VHS) to watch without being bothered or having a cheap messy feel to it.

Now, with encoder complexity at 80, the results are really impressive: a clear, thight picture with hardly any "stuff going on". Karl really must be too much with his nose in it for him to say "I am really glad you notice a difference!" as only extremely visually impaired persons would not notice an difference :-) It's just like that: it's not a matter of bending over closely to your screen to try to figure out what, if anything, has changed - it is self evident.

Well worth the extra encoding time.

Ruud

[Sirber]

Originally posted by DaWolf
44 minutes X-File episode SVCD (org. source: DVD) -> 350 Kbits (318 video) 1-pass VBR, encoder complexity 80 @ 480 x 360: 6 hours and 10 minutes (was: 1 and a half hour at encoder complexity 65) on a Celereon 1.7 GHz with 384 MB RAM.

Always do a 2-pass VBR. Quality will be better and you won't spend too much bits on useless places.

[DaWolf]

Originally posted by Sirber
Always do a 2-pass VBR. Quality will be better and you won't spend too much bits on useless places.

Yeah indeed, if time is an issue it's usually better to do a CBR. My reasoning for doing 1-pass was the idea that if I set the peak high action scenes get a bit smoother. The X-Files are quite static; lot of walking, standing, talking. But once in a while they chase someone or wrestle someone to the floor and I figured (1-pass) VBR would give it some extra leeway. I wouldn't mind having a CBR setting where I can adjust how much it will go over the CBR when it encounters (too much) movement. As it is the normal leeway in CBR doesn't hold up to sudden movements.

Ruud

[Sirber]

So you encodes animes... 2-pass VBR is the best for that. Still scenes are at 16kbps, and high-action scenes at >800kbps.

[zedude]

@ karl :
i registered the new keys but these keys override any further settings in audience, true ? (in fact, if i register complexity at 80 and ask for 70 in audience , producer will still encode at 80 ? )that's what i realized.
so i might guess i have to delete keys in registry ?


@ nah :
<UseThread> markup will also be deleted from rmfactory in next release. About avi ( now avs too ) input , give me please some ideas on how to improve it : i can't read in users mind , neither can they in mine ( i 'really' should write some docs )

[Sirber]

Originally posted by zedude
[B]so i might guess i have to delete keys in registry ?

Don't do that :devil:

[DaWolf]

Originally posted by zedude
so i might guess i have to delete keys in registry ?

Indeed.

A nicer, simpler way is to have a reg-file for the different settings. That way you can switch from one to the other simply by clicking on the appropriate reg-file.

Ruud

[RadicalEd]

Originally posted by Sirber
What's the point in decompressing RMVB?

psnr :\ and compare/subtract scripts in avisynth.
Also people always ask on amv.org how to convert RM to something else and I think I remember karl saying that EO uses a crappy renderer or something to decode, but that's what I've always used and recommended because it's like the only thing that works.

[karl_lillevold]

PSNR calculations can sometimes be very inaccurate. For instance, we have a built-in filter that removes potential capture noise along the edge of the video. Even though the resulting compressed video looks better than the original for those areas, it will significantly degrade a PSNR number, which just looks at pixel for pixel differences. I have no idea how a program like EO video will affect PSNR when it saves RM files as AVI files. By using the proper audience settings it is possible to disable this noisyEdgeFilter though, and there are also some other settings which can be used, but I will leave it as an exercise for the reader to check the producer documentation for these options. Even then there could be problems with rate control and dropped frames. So it is possible to get accurate numbers, but a little complex.

[karl_lillevold]

Originally posted by zedude
@ karl :
i registered the new keys but these keys override any further settings in audience, true ? (in fact, if i register complexity at 80 and ask for 70 in audience , producer will still encode at 80 ? )that's what i realized.
so i might guess i have to delete keys in registry ?

Actually, since you are using an audience file, it would be best to not touch the registry. You should place these options in the audience (or job) file.

The registry settings are meant to enable this mode in the old GUI Helix Producer and other tools which have not (yet) included the ability to set this mode in the audience file

Or it is nice for those that always want to use encoderComplexity=80, and not have to worry about remembering to enable this in whichever tool they use. And then it would be bad if your tool decided to delete these keys. They are meant to always over-ride whichever setting would otherwise have been chosen.

[zedude]

yes karl, i deleted the keys in registry and now i can choose complexity for each encoding

[BigPapaSmurf]

Some results with the EHQ-mode:

1 pass, quality 85, 132Kbps sound.

---

Clip 1: 1162 frames, 25fps, 448x336 (Bright, medium motion, clean);

Complexity 65: 1957Kbps, 10.9MB, ~1799Kbps video (.478 b/p)
Complexity 80: 1558Kbps, 8.68MB, ~1406Kbps video (.374 b/p)

---

Clip 2: 1446 frames, 25fps (Bright, high motion, noisy at times);

448x336 complexity 65: 3139Kbps, 21.8MB, ~2965Kbps video (.788 b/p)
448x336 complexity 80: 2603Kbps, 18MB, ~2436Kbps video (.647 b/p)

512x384 complexity 65: 3846Kbps, 26.7MB, ~3662Kbps video (.745 b/p)
512x384 complexity 80: 3161Kbps, 21.8MB, ~2987Kbps video (.608 b/p)

---

Oh, and hi ppl! :)

[Sirber]

Welcome to the world of Real Video :D

[wing1]

MaxStartupLatency=60 makes my day :D I am seeing the most quality increase using this option.