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.

[Sirber]

Does it increase the "time to encode"?

[uaco72]

Originally posted by BigPapaSmurf
Some results with the EHQ-mode:

1 pass, quality 85, 132Kbps sound.

...


How can you encode with a prefixed quality percentage?
:confused:

[31 Flavas]

You have to ehit the .rpad or the .rpjf. Change the encoding type to vbrquality I believe. Also change the quality to what ever you want.

<encodingType type="string">vbrBitrate</encodingType>
<quality type="uint">95</quality>

[karl_lillevold]

hmm, perhaps you meant

<encodingType type="string">vbrQuality</encodingType>
<quality type="uint">85</quality>

vbrQuality instead of vbrBitrate. Note that the <maxBitrate type="uint">99999999</maxBitrate> has an effect when vbrQuality is used, so if you want a very high quality, make sure to set maxBitrate high enough.

Also note that RV9's quality levels are very different from other codecs, so for instance RV9 at 85 is not the same as 85 for any other codec.

@BigPapaSmurf: hilsen til Norge fra Seattle! Those bitrate reductions are similar to what I have seen.

[karl_lillevold]

Right now I am looking into speeding up 1st pass to faster than default (complexity 50), while 2nd pass runs at normal complexity 80 speed. I am not sure it will be complete for Producer 9.2 - we shall see, but in any case a temporary build can always be made available from helixcommunity.

[Sirber]

Great news :) Thanks Karl :D

1-pass is usualy for live capture, while 2-pass is for file2file encoding. What if I set Complexity higher than 80? Will I get better results?

[karl_lillevold]

better quality for complexity > 80? No, (not yet).

(just in case there was a misunderstanding: what I meant was that for 2-pass encoding, I am trying to make the 1st out of the two passes run much faster than the 2nd pass)

[Sirber]

Ha!

I was misunderstanding :D.

[wing1]

@sirber

no it does not increase encoding time.

I am using 1-pass encoding all the time with RV9, and I found that it is good enough already. Filesize wise, it is perfectly acceptable with 1-pass encoding :D

[Sirber]

Originally posted by wing1
@sirber

no it does not increase encoding time.

I am using 1-pass encoding all the time with RV9, and I found that it is good enough already. Filesize wise, it is perfectly acceptable with 1-pass encoding :D

On low-motion scene (anime):

CBR: 300kbps
VBR: 30kbps

On high-motion scene (anime):

CBR: 300kbps
VBR: 800kbps

Same output filesize :D

2-pass VBR is the best, it's long, but the overal quality is better IMO.

[edit]

I'd like to use max startup latency in Helix GUI... :(

[traragorn]

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


when i clicked that link and went to the helix community forums i saw i need to register so i did that but when i tried to open that link ot try the new producer the forum says:

"Your account does not have the "Project Document - View" permission needed for you to access the page you requested in the distribution project (view your permissions). Either ask the project administrator for more permission, or log in using a different account."

so what do i need to see and dl that new build,isit avaiable from another place ;what can i do now ?

i am very interested in rv since rv8 and i see many improvements in 9,so i hardly want to try that new feature...

[Sirber]

Use the search button. It's boring always answering the same question you know... :devil:

[Dark-Cracker]

@traragorn
u must first go in the licence agreement page and accepte all the tree licence once it will do your account will be unlocked for the download :)

Ps: avoid to post some msg in this thread who doesn't have a *direct* relation with the thread :)

@sirber
damn u are very nervous :)


Ps2: it's useless to answer this post i think it will be better to keep this thread clean.


Bye.

[avih]

Dark-Cracker, Sirber is not nervous (well, maybe sometimes, but not in this case). it IS a question you could have answered by yourself if you didn't post here right away. ppl on this forum need to think, or stay out. asking questions is fine AFTER you tried to solve the issue by yourself. otherwise, the board get cluttered with irrelevant stuff, and it makes the moderator's job harder. there's already a massive inclease in posts/day during the last month, so the least that ppl can do is TRY to solve their issues before asking on the forum.

case closed. please don't respond on this issue anymore.

cheers
avih

[traragorn]

thanks for your patience and thanks for answering my question ; i didn't meant to make trouble , sorry ...

sorry ...
:(

[avih]

Originally posted by traragorn
thanks for your patience and thanks for answering my question ; i didn't meant to make trouble , sorry ...

sorry ...
:(

forgiven ;)

[Sirber]

What software is EHQ powered (whitout the reg key) ?

[edit]

RMFactory is, but what about x2real and AutoRV9 ?

[karl_lillevold]

@traragorn: i really should remember to inform about the license and binary EULA when I post a link to Helix Community for download. It is not entirely clear these steps are needed to get download access.

@Sirber: AutoRV9 as well.

I have significantly edited the first post in this thread to include some of the very good feedback that has been posted. I have also included the information above re download access and tools with RV9-EHQ support.

Later today or tomorrow I will post some results I found when creating demos for this mode, and one nice screenshot showing improved visual quality at 30% lower bitrate.

[wing1]

EHQ for RV9 is awesome for quality at low bitrate. However, it is extremely slow: I am encoding at 4.5fps using a 2100+ (1.85Ghz) AMDxp!

The trade off is I got sharp detail video (656x464 NTSC) for 1/2 the filesize (1min=4Mb) that I would have gotten if encoded normally (8.2Mb). 1hr of vid = approximately 6hrs of encoding time! This brought back the memories of good ole days when it took 20hrs+ to encode a decent VCD on a P2 or K6 :D

I need to upgrade my CPU -> 10Ghz+ :D :D

Thanks Karl for the EHQ mode...I luv it.

[karl_lillevold]

Glad you like the quality, sorry it has to take so long -- a lot of calculations to be made.

By the way, on a P4 3.06 GHz as provided by Intel, I have about 12-14 fps at 704x288 in EHQ mode. So I am afraid an AMD 2100+ is not really equivalent to 2.1 GHz for RV9 encoding, but more like its true clock speed 1.85 GHz.

Having had 3DNow(+) support would probably have sped it up by around 20% on your system, the same amount that SSE2 helps for P4, relative to plain SSE/MMX. One reason we are slightly biased towards Intel processors is admittedly the hundreds of hours of optimization help Intel has done for us, in fact way back since RV G2, incl RV8, and RV9. They have also provided development systems free of charge, and in fact I don't think we have more than one AMD based system in the codec group right now.

[Sirber]

I understand why Real always show "Uses Intel optimizers" :). I might buy one some day... to have 35% more speed :)

[DaWolf]

Lol, in PC Hardware I was asking about people's experiences with a low-end processor but I think I'll invest in a P4 system and hand my current Celereon to the kids instead. I'd love to get Karl's speed and there's no way I'm going back to EHQ 65 :D If I'll do it will be too quickly get something out - but the fun is that with RV9 even that quick EHQ 65 encode is high quality.

Ruud

[wing1]

no problem Karl, speed is not as important as quality. I can live with 4.5fps. I can always do the over-night encoding from the VCD dayz. If performance reduces to 0.15fps then I'll think about switching over to Intel :)

[Sgt_Strider]

Just wondering is this EHQ mode in beta right now or is everything final? Also is this part of the rv9 specification?

[karl_lillevold]

Since I did not change the bitstream, it is still part of the RV9 spec, so every RV9 decoder out there will be able to decode RV9-EHQ. This also means that I may still add some tweaks to further improve the quality, and/or speed, but I have spent enough time on it to realize it's pretty stable now. Hard to call it "final" though, but definitely final enough to recommend for general use..

[31 Flavas]

Originally posted by DaWolf
Lol, in PC Hardware I was asking about people's experiences with a low-end processor but I think I'll invest in a P4 system and hand my current Celereon to the kids instead. [...] As far as playback, I found that on a P3 500 (my one of my friends computers), at 450kpbs, playback of RMVB/EHQ files is fine. As far as encoding, @ 500 mhz, it would be slow :)

[slavickas]

i have 2 more q:
is fixed quality 2nd pass useful?
registry keys are read during encoding startup or producer startup?
if i change complexity values in egistry do i have to restart encoder?

[iwod]

Originally posted by karl_lillevold
Since I did not change the bitstream, it is still part of the RV9 spec, so every RV9 decoder out there will be able to decode RV9-EHQ. This also means that I may still add some tweaks to further improve the quality, and/or speed, but I have spent enough time on it to realize it's pretty stable now. Hard to call it "final" though, but definitely final enough to recommend for general use..

Speed is not any where as important as quality. Considering it only slows down encoding speed but NOT decoding speed. Unlike H.264.........

Therefore i am suggesting Karl do more tweaks to further improve quality. ( EHQ 100 ?? :sly: :devil: )

After Helix Producer 9.2 gone final. The next big thing might be RealONE 3.0 or a DDShow playback filter b4 RV9 truly rules over the world.

[bond]

Originally posted by iwod
... or a DDShow playback filter b4 RV9 truly rules over the world.yep

[Ramirez]

Hi Karl, can you please tell us a little bit more about "noisyEdgeFilter"?
Should we deactivate if the video source is high Q noise free material?
Does it affect encoding speed/ level of details preservation?

Thanks! :)

[Sirber]

Originally posted by bond
yep

Nan.... it's great like it is now.

[karl_lillevold]

Originally posted by Ramirez
can you please tell us a little bit more about "noisyEdgeFilter"?
Should we deactivate if the video source is high Q noise free material?
Does it affect encoding speed/ level of details preservation?
This filter affects only 1-2 lines around the outer edge of the image in case they do not match the rest of the image. For instance, for live capture, there is usually some noise around the edge of the frame, specifically the top line or bottom line. Or if you do a bad job cropping the video, 1-2 lines of black might be left. The only thing this filter does is detect such cases, and then copy lines of real video in their place. It does this because black/noisy lines that do not match the rest of the video are hard to compress and oftentimes create visible compression artifacts along this edge. You could try with noisyEdgeFilter ON or OFF, after leaving 1 line of black on the top and bottom after cropping, and see if you notice its effect.

Generally there is no reason to deactivate this filter, since it (i) affects only pixels around the outer edge, and (ii) only when these pixels do not match the rest of the image.

[wing1]

@karl,

something is broken in the rmeditor.exe? I tried to merge 2 encoded EHQ rmvb into one and cmdline is telling me that there is an error in the rmtool engine.

[karl_lillevold]

@wing1: no, that should work just fine, but make sure the rmeditor you are using is the newest one. There was a problem for a while causing problems merging .rmvb files with different maxBitrates. If you still can not get it to work, send me a PM or e-mail and we can set up a file transfer to debug the problem. The files also need to have the same dimensions. EHQ or not does not matter for merging.

[wing1]

@karl,

Ok, here is what I've found so far. The last installed EHQ version is giving me this error. The previous milestone build 3 works just fine. Copying the rmeditor.exe from milestone build3 over to EHQ build gave the same error.

msg -> A general error in rmtools engine.

the clips are generated using avs function blankclip + subtittle, and encoded using RV9-EHQ=80 @ avgbitrate=644k & maxbitrate=avgbitratex2.1 with maxstartuplatency=60. The rest are default.

update: after replacing files after files on build 205 with build 166, I have tracked it down to ralf.dll in the codecs folder. Replacing only this file will allow rmeditor to work without the above error.

[karl_lillevold]

@wing1: thanks for the assistance in tracking down the problem! I have forwarded your information, so it should be fixed in the next build.

@everyone:Until then, pls follow wing1's instructions and replace ralf.dll with a previous version (ralf = RA Lossless)
EDIT: even easier: just delete or move away ralf.dll from the codecs folder into another folder.

[karl_lillevold]

I was creating some RV9-EHQ demos and wanted to post an interesting screenshot.
This is Foreman CIF with 30% less bits on the left (http://www.lillevold.com/files/fmn30percent.jpg).
This is double-sized, compressed at a very low bitrate, and a good example of the EHQ visual improvement.
Foreman is one of most widely used ITU test sequences. I found that with EHQ, the quality is about the same with 25% less bits. Even though the clip to the right has some ugly artifacts, it is slightly sharper. Thus, 25% bitrate reduction and not 30% for this clip.

For a couple of other difficult ITU clips the results were:
BUS [SIF] : 27% less bits with EHQ
Stefan [CIF] : 35% - " -
for close to identical quality.

[uaco72]

waiting for the new version of AutoRV9 1.3x, with EHQ options...
:cool:

[Sirber]

While waiting, you could try RMFactory :D

[Sagittaire]

Here small comparative of celerity enters the most recent versions of codecs their most powerful configurations. Same script avs was to use on a celeron 1470 MHz...


RV9 04/06/2003
EHQ 80
2 pass: 1401 sec
5.88 fps

XviD Koepi
Ultra hight+VHQ4+bframe+chroma ME
2 pass: 1080 sec
7.65 fps

DivX Thahanea
Slow+bframe
3 pass: 2280 sec
5.42 fps

WMV9 VCM
Complexe+Quality max
2 pass: 1620 sec
5.09 fps

[Sirber]

Would be great to have some pictures :D

[justin]

me is just curious, how come EHQ isn't included in RV9 Milestone 6 when you download? It is confusing in M6 you need old dll from M4 and downgrade EHQ Dll from M5 and change EncodingComplexity to EncoderComplexity and 85 needs to be changed to 80

[Sirber]

Supposed to be in M6...

[karl_lillevold]

EHQ is in every version since M4, but there was a problem with its enabling in M5, where the producer team accidentally broke my method used in M4. With M6 and M7 everything works fine, both new and old methods to enable EHQ, and there is no reason to switch any DLLs around. Is something not working right?

[justin]

oh sorry, I thought EHQ wasn't in M6.

Is it in the help file?!

[karl_lillevold]

I implemented EHQ on top of RV9, and I may know a thing or two about video compression, but I am a bad documentation writer, so I did not focus too much on other documentation than what I have contributed in this forum. The Producer docs are good at describing audience and job file syntax, but does not cover the codec details or EHQ too well. Let me know if you have any other questions.

On a sidenote, thanks for all the useful feedback on EHQ quality. We are currently hearing very nice comments from other sources as well, but this forum was the first. It is very motivating for improving the quality even further. there is headroom. more later!

[snowcrash]

karl,

In this thread you seem to be pushing the EHQ "very high" setting, but what do you think of the "high" setting? I would think it might be a good compromise between time and quality, since the very high setting is quite slow.

If one is encoding at relatively high bitrates, say 800-1000 kbit, do you think it's still beneficial to even use EHQ at all? Perhaps at higher bitrates the EHQ "high" setting would be sufficient?

[Sirber]

lol

If you want the best quality, at any bitrate, use very-high EHQ. If not, you may get bluring and less details.

[karl_lillevold]

@snowcrash: 'high' is indeed a good compromise, you get many of the visual benefits of EHQ. It does not, however, do as extensive a mode comparison, and the motion estimation is also slightly less accurate. I am fortunate enough to have a speedy fast computer, so I don't have to compromise. I would recommend at least 'high', but if you are running low on time, 'normal' will still produce very good quality at 0.18-0.20 bits/pixel and above.

[Sirber]

I can't find how to use "high, medium and low" instead of their numbers in the jobfile.

<encoderComplexity type="uint">[EHQ2]</encoderComplexity>using "string" instead of "uint", producer tells me:,Informational,SDK Encoding,2004/01/09 10:51:07,15004,Starting analysis pass
,Error,Video Codec,2004/01/09 10:51:07,0,Failed to Set Property: Key encoderComplexity Value high
,Diagnostic,Video Codec,2004/01/09 10:51:07,20049,Setting video packet size to 0
,Error,Video Codec,2004/01/09 10:51:07,0,Failed to initialize video codec 04VR
,Error,SDK Encoding,2004/01/09 10:51:07,15001,Job failed to start encoding
,Error,Command Line,2004/01/09 10:51:07,10536,Encoding failed!

[karl_lillevold]

How to set encoding complexity in RV10

What it all comes down to is the encoding complexity setting to the RV9/10 encoder. It is the same encoder, this is true, but for RealVideo 10 relative to RealVideo 9, the complexity scale was shifted, as illustrated below:

85 RV10 high
75 RV10 medium
65 RV9 high RV10 low
57 RV9 medium
50 RV9 low


You can to set your complexity level in one of two ways, either choose codec name + high/medium/low, or just codec name and direct complexity as a number. The recommended quality is RV10 High = Complexity level '85'.

Method one, preferred, "official" method

<videoStream>
<pluginName type="string">rn-videocodec-realvideo</pluginName>
<codecName type="string">rv10</codecName>
<encodingComplexity type="string">high</encodingComplexity>
<codecProperties type="bag">
<customPacketSize type="uint">16000</customPacketSize>
</codecProperties>
</videoStream>


encodingComplexity takes a string:
'high', 'medium', 'low'

or

command line option to producer : -eco <complexity>, where complexity is high, medium, or low. This means that you can simply run producer 10 on the command line with '-eco high' for the best quality.

Method two, direct codec control, inside the <codecProperties> tag. This is undocumented, except here in this forum

<videoStream>
<pluginName type="string">rn-videocodec-realvideo</pluginName>
<codecName type="string">rv10</codecName>
<codecProperties type="bag">
<encoderComplexity type="uint">85</encoderComplexity>
<customPacketSize type="uint">16000</customPacketSize>
</codecProperties>
/videoStream>


encoderComplexity takes a number, here is the mapping:
100: RV 10 max
85 : RV 10 high
75 : RV 10 medium
65 : RV 10 Low = RV 9 High
57 : RV 9 Medium
50 : RV 9 Low

(note than 100 is "undocumented", and just a tiny better than 85, but slower, may be improved in the future, as time permits)

Again, I am sorry these settings have been changing, but that happens during development.

[methos]

Are the settings for rv10 different for encoding a fast first pass or are they the same? (i didn' see them in your video stream settings above, so i'm wondering...)

[Sirber]

the first pass tweak is the same, in <codecProperties type="bag">. :D

[karl_lillevold]

I just checked in the change to make this default behavior as well (firstPassComplexity=65 when encoderComplexity>65). Next Milestone build will have this change included.

[Sirber]

Cool, I'll revert to default as soon as the new producer comes out.