RV9-EHQ

[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!