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.
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.

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 "

zedude: "good news . i did some tests and got beautiful results . "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 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: 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.

encoderComplexity sets the EHQ level:65 = Default : improved efficiency for high action75 = High : same as 65 + better mode decisions, better representation of high motion85 = 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.

[copy and paste this to a new file, save as 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.

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)

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.

hy
i have two questions
1) where and how can i download the latest compiles for helix producer? i already registered but
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?

__________________
Between the weak and the strong one it is the freedom which oppresses and the law that liberates (Jean Jacques Rousseau)I know, that I know nothing (Socrates)

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
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.

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.

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

__________________
"All that we see or seem is but a dream within a dream" E.A.Poe

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.