Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Video Encoding > New and alternative video codecs

Reply
 
Thread Tools Search this Thread Display Modes
Old 24th July 2003, 17:51   #1  |  Link
karl_lillevold
Moderator
 
karl_lillevold's Avatar
 
Join Date: Oct 2002
Location: Seattle
Posts: 1,584
Producer M5: How to enable RV9-EHQ

EDIT 09/05/2003: This problem has been fixed in Milestone 6, and the custom DLL listed below is no longer needed to fix the previous method to enable EHQ.

Since Milestone 5 of Producer was supposed to be a Beta1 for Producer 9.2, it was a little annoying to find that a change had been made that effectively disables EHQ, no matter what the GUIs set in the audience file. The reg key is similarly disabled. There is a way to set encoderComplexity via a load level setting, but this is not well known and none of the encoder tools use it. I would rather suggest to use an erv4.dll from Milestone 4, or the one below. Just replace the erv4.dll in the codecs folder of producer.

This is what can happen when we make available these intermediate Milestone builds with minimal QA testing. Some will simply have a feature that's missing or broken. Sorry about this. I am just glad I caught it now, and not later.

Any encoding tool that includes Milestone 5, will have the same problem. This includes AutoRV9 1.3b3.

alternatively, get this erv4.dll, which is the exact same DLL as in M5, but with the problem resolved such that the previous <codecProperties> <encoderComplexity> again works.

In AutoRV9, go to softs\Rp9_Light\codec and replace erv4.dll with the corrected version. The corrected version says "RealVideo 9 EHQ (karll 07/24/2003)" in the Version Description field of the DLL.
__________________
This information is provided "AS IS" with no warranties, grants no rights, and reflects my personal opinion.

Last edited by karl_lillevold; 5th September 2003 at 19:13.
karl_lillevold is offline   Reply With Quote
Old 24th July 2003, 18:42   #2  |  Link
karl_lillevold
Moderator
 
karl_lillevold's Avatar
 
Join Date: Oct 2002
Location: Seattle
Posts: 1,584
There is a new interface to set encoderComplexity that will work. Here is the relevant section from the producer documention.

encodingComplexity

A measure of how hard the codec will work to achieve the desired result. The specific result varies according to the codec. For some codecs, like RealVideo, the result is quality. For other codecs, like RealAudio Lossless, the result is file size.

For RealVideo 9, the value of encodingComplexity affects the resulting video quality and how long it takes to encode. The lower the value of encodingComplexity (very-fast being the lowest) the faster it will take to encode and lower the resulting image quality. The higher the value of encodingComplexity (very-high being the highest), the the longer it will take to encode and better the resulting image quality.

This property is only enabled for RealVideo 9 (rv9). This property is ignored for RealVideo 8 (rv8) and RealVideo G2 SVT (rvg2svt) codecs.

Default:
normal

Values:
very-fast, fast, normal, high, or very-high

Type:
string

Example:

<encodingComplexity type="string">very-high</encodingComplexity>

For RV9-EHQ, this goes in the <videoStream> section of the audience.

The problem in M5 is that the old method was disabled as a result of this change. It should not have been, the codecProperties should over-ride encodingComplexity, and the reg key should over-ride both This has been fixed in the erv4.dll mentioned in the previous post.
__________________
This information is provided "AS IS" with no warranties, grants no rights, and reflects my personal opinion.

Last edited by karl_lillevold; 25th July 2003 at 20:22.
karl_lillevold is offline   Reply With Quote
Old 24th July 2003, 19:12   #3  |  Link
Nic
Moderator
 
Join Date: Oct 2001
Location: England
Posts: 3,285
LoL...I should have guessed something was up, I couldn't see a difference in speed between using EHQ and not with M5. Just added <encodingComplexity type="string">very-high</encodingComplexity> and now im noticing a big difference (just got to wait to see if there's a big difference in quality too - Ill edit this post when I know)

(yup, finished the small clip, EHQ gets rid of the noise round the edges, which is v.important for me)

-Nic

Last edited by Nic; 24th July 2003 at 19:19.
Nic is offline   Reply With Quote
Old 25th July 2003, 02:03   #4  |  Link
ookzDVD
DVD Rebuilder!
 
ookzDVD's Avatar
 
Join Date: Oct 2001
Posts: 1,147
Yes,

I was thinking the EHQ has been optimized
ookzDVD is offline   Reply With Quote
Old 25th July 2003, 03:13   #5  |  Link
RadicalEd
Registered User
 
Join Date: Dec 2001
Posts: 987
karl, what exactly are the different modes? It said default was normal, I assume that means if an EHQ mode is not specified, it will use normal EHQ. Is normal = regular RV9? If so, then fast and very-fast are less than old RV9 quality. Or is normal something like EHQ=70, and very-fast is the same as old RV9. I'm curious, because I did a rather large encoding test (21 jobs) using the old ignored EHQ settings with Milestone 5, meaning it was really using EHQ normal... I think :| so what was I really using?
or something
X|
RadicalEd is offline   Reply With Quote
Old 25th July 2003, 03:49   #6  |  Link
karl_lillevold
Moderator
 
karl_lillevold's Avatar
 
Join Date: Oct 2002
Location: Seattle
Posts: 1,584
I am really sorry about those encoding jobs. Sometimes it's better to use a Milestone that's been out a few weeks, but I really did not expect this problem. You happened to use normal, which corresponds to the old RV9, with no EHQ.

The mapping is as follows:

very-high: 85
high: 75
normal: 65
fast : 50
very-fast : don't use, need to check


So even the mapping is out of whack from what I would have wanted. it should have been 80, and 70. very-high = 85 will be slower than 80 without much gain in quality. For now, I would recommend just getting the fixed DLL and use your previous method to enable EHQ.
__________________
This information is provided "AS IS" with no warranties, grants no rights, and reflects my personal opinion.
karl_lillevold is offline   Reply With Quote
Old 25th July 2003, 04:29   #7  |  Link
karl_lillevold
Moderator
 
karl_lillevold's Avatar
 
Join Date: Oct 2002
Location: Seattle
Posts: 1,584
how to verify

To verify the encoder complexity level, with the corrected DLL, add this to the codecProperties section in the videoStream section of the Audience:

<codecProperties type="bag">
...
<calcPSNR type="bool">true</calcPSNR>
...
</codecProperties>

this will create a file rv9log.txt in the 'current' directory, in most cases in the same directory as producer.exe. In this file, the line that says cpu_scal: <n>, indicates the encoderComplexity level. It should say 80 or higher for full EHQ.

This will also enable you to verify PSNR obtained with the DirectShowSource method. I did this earlier today, and it was correct within 0.01 dB as long as I removed the first two frames and the last frame from the original sequence, and the first and last frame from the DirectShowSource sequence.
__________________
This information is provided "AS IS" with no warranties, grants no rights, and reflects my personal opinion.
karl_lillevold is offline   Reply With Quote
Old 25th July 2003, 06:12   #8  |  Link
LeonMcNichol
Chief Inspector
 
LeonMcNichol's Avatar
 
Join Date: Aug 2002
Posts: 246
I was wondering why I was getting a massive speed increase in my encodes. When they normally take me 6 hours to encode, I was getting 2 hours instead. (Though I switched to forced film FieldDeinterlace instead of Telecide/Decimate due to some field order problems I was having.) I also noticed a quality drop. Which was kind of bad, but I thought I was just being too picky. I'm not about to re-encode those episodes again.

Anyways, I changed the dll to the one linked above. It will now work with <encoderComplexity type="uint">80</encoderComplexity> now right?
LeonMcNichol is offline   Reply With Quote
Old 25th July 2003, 06:26   #9  |  Link
karl_lillevold
Moderator
 
karl_lillevold's Avatar
 
Join Date: Oct 2002
Location: Seattle
Posts: 1,584
Yes, you can use that method, with the corrected DLL. You can verify by the fact that it again should take 6 hours ("no pain, no gain"), and also by the new calcPSNR method to print a log file, and check cpu_scal there.
__________________
This information is provided "AS IS" with no warranties, grants no rights, and reflects my personal opinion.
karl_lillevold is offline   Reply With Quote
Old 25th July 2003, 19:57   #10  |  Link
phrentec
waprout?
 
phrentec's Avatar
 
Join Date: Jan 2002
Location: LA
Posts: 224
there is a big difference in the file size of the old helixproducerGUI erv4.dll and the new erv4.dll.
erv4.dll.old 364KB - approx.
erv4.dll.new 154KB - approx.

is this normal?

also if i just replace the old dll in TFCs helixproducerGUI will RV9-EHQ then work with the gui created audience file or would i have to go in and manually set to RV9-EHQ to 85 or would 80 still work?
thanks.

Last edited by phrentec; 25th July 2003 at 20:07.
phrentec is offline   Reply With Quote
Old 25th July 2003, 20:20   #11  |  Link
karl_lillevold
Moderator
 
karl_lillevold's Avatar
 
Join Date: Oct 2002
Location: Seattle
Posts: 1,584
oh i just used UPX to compress it. It decompresses automatically when it's loaded. Pretty neat.

I recommend level '80', no need to change this. The fact that 'very-high' maps to '85' was another little mistake. There is no harm in using '85', but it slows it down more than the quality gain is worth. Next Milestone, I will move that extra complexity to '90', so even 'very-high' will not enable it
__________________
This information is provided "AS IS" with no warranties, grants no rights, and reflects my personal opinion.
karl_lillevold is offline   Reply With Quote
Old 25th July 2003, 23:21   #12  |  Link
LeonMcNichol
Chief Inspector
 
LeonMcNichol's Avatar
 
Join Date: Aug 2002
Posts: 246
There we go. I just did another encode last night and it was indeed 6 hours and the quality is back to the way it was. So all is well with the world.
LeonMcNichol is offline   Reply With Quote
Old 25th July 2003, 23:45   #13  |  Link
wata
Registered User
 
Join Date: Jul 2002
Posts: 166
Re: how to verify

[QUOTE]Originally posted by karl_lillevold
[B]To verify the encoder complexity level, with the corrected DLL, add this to the codecProperties section in the videoStream section of the Audience:

<codecProperties type="bag">
...
<calcPSNR type="bool">true</calcPSNR>
...
</codecProperties>

this will create a file rv9log.txt in the 'current' directory, in most cases in the same directory as producer.exe. In this file, the line that says cpu_scal: <n>, indicates the encoderComplexity level. It should say 80 or higher for full EHQ.

i set <encoderComplexity type="uint">80</encoderComplexity>
but the cpu_sal: in rv9log.txt still show 65, anything wrong?

mes: 32
frd: 0
rda: 0
rdai: 0
cpu_scal: 65
met: H


btw, what happen if the temp drive become full during the process of encoding, i was half way thru when i realize the temp partition is out of diskspace, i abort and set temp path to another drive and restart.

Last edited by wata; 25th July 2003 at 23:49.
wata is offline   Reply With Quote
Old 25th July 2003, 23:54   #14  |  Link
karl_lillevold
Moderator
 
karl_lillevold's Avatar
 
Join Date: Oct 2002
Location: Seattle
Posts: 1,584
Yes, something may or may not be wrong.
1) the rv9log.txt is appended. Check the log for the last encoding, at the end of the file
2) maybe producer is using the DLL with the problem in M5. Did you get the corrected DLL, and place it in Producer's codecs directory, replacing the old one? Make sure you move the old erv4.dll to another folder, and not only rename it.
3) maybe you put the encodercomplexity in the wrong place in the audience file, but I really suspect (1) is the "problem"..

running out of temp space is never good. I know producer did not handle that well in the past. It may be better now, but it's best to be safe than sorry, and have plenty of temp space.

EDIT: you can specify alternative tempDir location in producer.pref
__________________
This information is provided "AS IS" with no warranties, grants no rights, and reflects my personal opinion.

Last edited by karl_lillevold; 25th July 2003 at 23:56.
karl_lillevold is offline   Reply With Quote
Old 26th July 2003, 02:30   #15  |  Link
ookzDVD
DVD Rebuilder!
 
ookzDVD's Avatar
 
Join Date: Oct 2001
Posts: 1,147
I just realize that I need a processor upgrade to do the RV9-EHQ,
it seems to slow on my machine right now, I only get 6-7 fps
on my Athlon Xp +1700
I takes about 15-16 hours to encode ~2 hours movie, oh no....
it's horrible
ookzDVD is offline   Reply With Quote
Old 26th July 2003, 02:42   #16  |  Link
RadicalEd
Registered User
 
Join Date: Dec 2001
Posts: 987
wait wait.. okay...
Out of the box, will producer milestone 5 work correctly with <encodingComplexity type="string">very-high</encodingComplexity>
?
Because I haven't switched any dlls around, and I re-did that encoding comparison like that :\
RadicalEd is offline   Reply With Quote
Old 26th July 2003, 03:20   #17  |  Link
karl_lillevold
Moderator
 
karl_lillevold's Avatar
 
Join Date: Oct 2002
Location: Seattle
Posts: 1,584
@RadicalEd: yes, that's fine, but 'very-high' = encoderComplexiy '85', which adds a lot of complexity over '80' without much gain in quality, and this extra complexity slows it down more than necessary. I will adjust this in next release.

@ookzDVD: sorry about how long it takes, but I spent a large amount of time tuning the settings to make sure the extra time will give you better quality, and that the extra time is not wasted. For instance, this is why I do not recommend '85' because the extra time relative to '80' is not worth the small improvement in quality from '80' to '85'. If it is too slow, make sure you are using encoderComplexity='80' (the previous method) instead of the new 'very-high' setting. In the next release, these will be the same.

Also, one more thing, if you take a look at Sagittaire's PSNR comparison, you will see that even though RV9-EHQ has both the highest PSNR and visual quality, by a rather noticable margin, it is not slower than any of the other codecs' highest quality modes. The CPU cycles are well spent.
__________________
This information is provided "AS IS" with no warranties, grants no rights, and reflects my personal opinion.
karl_lillevold is offline   Reply With Quote
Old 26th July 2003, 08:43   #18  |  Link
LeonMcNichol
Chief Inspector
 
LeonMcNichol's Avatar
 
Join Date: Aug 2002
Posts: 246
Quote:
Originally posted by ookzDVD
I just realize that I need a processor upgrade to do the RV9-EHQ,
it seems to slow on my machine right now, I only get 6-7 fps
on my Athlon Xp +1700
I takes about 15-16 hours to encode ~2 hours movie, oh no....
it's horrible
You think that's bad, on my 1.2ghz it takes me 6 hours for about 24 minutes. Which means, if I wanted to do a 2 hour movie, it would take me like 24 hours... Yes... I wish I could afford a new PC.
LeonMcNichol is offline   Reply With Quote
Old 26th July 2003, 09:05   #19  |  Link
wata
Registered User
 
Join Date: Jul 2002
Posts: 166
all ok now put the
<calcPSNR type="bool">true</calcPSNR>
in the wrong place.

Last edited by wata; 26th July 2003 at 10:38.
wata is offline   Reply With Quote
Old 27th July 2003, 01:00   #20  |  Link
Nic
Moderator
 
Join Date: Oct 2001
Location: England
Posts: 3,285
Just finished Road To Perdition. Seemed to take all day pretty much on this 2Ghz p4. But at 1:47:57 long 650mb at 640x256, its looking very impressive (not perfect, obviously, but impressive)
Nic is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 04:45.


Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2017, vBulletin Solutions, Inc.