RealVideo 10 'Elysian'

[Sagittaire]

For resume use this reg file for best quality/speed with new RV10

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\RealNetworks\RV9]
"calcPSNR"=dword:00000001
"firstPassComplexity"=dword:00000032
"encoderComplexity"=dword:00000055
"customPacketSize"=dword:00003e80
"rcEnableCurveCompression"=dword:00000001
"rcAnalysisFileName"="realvideo.pass"
"rcAnalysisLogFileName"="realvideo.log"
"rcSourceFrameRate"=dword:00005da8
"maxConsecutiveBFrames"=dword:00000003
"inloopCutOffQuant"=dword:0000000c
"inloopCutOffCompatible"=dword:00000000
"inloopCutOffBUseRefQuant"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\RealNetworks\RV10HFE]
"strength"=dword:00000001

[karl_lillevold]

Sagittaire: Nice summary, but as always: be careful with registry settings. If you forget about them, you're stuck... and will always be encoding with those options forever after. Especially "rcSourceFrameRate"=dword:00005da8. Until a fixed Producer comes out, this has to be the correct framerate for the new rate control to accurately determine target size.

Framerate Decimal Hex
23.976fps = 23976 = "rcSourceFrameRate"=dword:00005da8
25.000fps = 25000 = "rcSourceFrameRate"=dword:000061A8
29.970fps = 29970 = "rcSourceFrameRate"=dword:00007512
30.000fps = 30000 = "rcSourceFrameRate"=dword:00007530

[kilg0r3]

Besides my ot question above, I'd like to know if there is any benefit for one-pass encodes?

[karl_lillevold]

Originally posted by kilg0r3
Besides my ot question above, I'd like to know if there is any benefit for one-pass encodes?
No, the new method does not work for 1-pass. If rcEnableCurveCompression is set to true for a 1-pass encode, it runs the 1st pass. If you want to run the 2nd pass by itself using already created .pass file (make sure it's the right one!), then set rcPassNumber to 2, and run a 1-pass encode (option -dt).

[Sirber]

For some anime, like One Piece, old RC + DropDupe gives better quality.

[CruNcher]

hmm Karl sorry but i dont get lower with the Encode Time 10 min is the maximum i can reach with this 640x360 clip with RV10

http://cruncher.mufflastig.com/XviD/extra_details/Detail_Preservation/

here are some shoots you can see all three XviD Postfilter Combinations in Comparsion to the inloop filter still for me personaly inloop filter is to agressive in every Scene and i prefer the Deblocking on the Y Plane :) as you can see it doesn't hurts in the Closeups as the inloop filter does so Detail Preservation is constant for every Scene :)

[karl_lillevold]

Thanks for trying out the new version, CruNcher. Your feedback is appreciated.

I have posted a minor update: erv4.dll compiled with the Intel Compiler (which is normally used when building this DLL, just not for the first version I made available). See first post.

The Intel Compiler generally produces faster code, even though all our core functions are already MMX/SSE/SSE2/SSE3 optimized, because it does a good job inlining code. Thus, the 100 KB size increase in DLL size as well. Still, it's worth it, with 5-7.5% speedup. My quick test this afternoon:

Dimensions: 704 x 272
Frame Rate: 24.000 FPS
Format: I420
Duration: 01:43.958

MSVC : 3min 27sec
ICL : 3min 12sec

Your milage will vary, especially if your input format is not native YV12 or I420, because then the improvement will be watered out by decoding/color converting the source.

I also know how it is possible to increase the speed of the 2nd pass by 15-25%, but I don't know when I will have time to implement it...

P.S. Regarding the new Intel Prescott. Finally hyper-threading has an effect on the encode speed. With Prescott, the encoding speed increases 5% due to SSE3 optimizations, and 20% due to hyper-treading, a total of 25%. Yes, it produces a lot of heat, so don't try (http://www.sudhian.com/showdocs.cfm?aid=494) one of those in a small form-factor XPC, like mine (http://www.lillevold.com/files/cube/index.html).

[31 Flavas]

Originally posted by karl_lillevold

Yes, it produces a lot of heat, so don't try (http://www.sudhian.com/showdocs.cfm?aid=494) one of those in a small form-factor XPC, like mine (http://www.lillevold.com/files/cube/index.html). Is that heatsink going to be able to cool off your video card enough? I mean it's such a tiny one... :p

I feel like I need a magnifier to see it :)

Nice mod though! :D

[damrod]

ehq50 for the first pass?? does this etting apply to rv10 "normal" producer ie not elysium version ??

[h9903209]

Originally posted by Sirber
For some anime, like One Piece, old RC + DropDupe gives better quality.

Could u elaborate a bit why?

[Sirber]

With the old RC, you can get to higher bitrate (up to max). Using DropDupe, RV10 cut bitrate in slow motion scenes and give more bitrate to the high ones, so the average quality is higher with the old RC on some anime.

[edit]

After reviewing my clips, both are similar. I was refering to the RC + 1BF, instead of RC + 3BF. I'm posting 2 samples. In fact, both are very similar, but the old.rmvb is less blury in the intro (clip), but is also bigger.

Old RC + DD: http://www.webernic.com/sites/sirber/old.rmvb
New RC: http://www.webernic.com/sites/sirber/new.rmvb

[31 Flavas]

What is needed to get your clips to play in RP10? RP10 tells me it can't find the stuff it needs to playback racp.

[h9903209]

seems you once said that dropdupe is recommended only when bitrate is <300kb/s, do I remember right? now around 550k still can use it?

btw, both very similar, both 2-pass vbr 85 ehq?

according to my experience, in anime, unless it is really very very high motion, e.g. tornado, 1-pass 65 has no visible difference with 2-pass 85 ehq except filesize... ^^ but if it's this high motion, I wouldn't recompress to rmvb.

and one piece is my most most favorite no.1 anime, I must not recompress it! ^O^

[Sirber]

I use it sometimes at 450kbps, depends on the anime. Both clip are at 450kbps.

[karl_lillevold]

Originally posted by 31 Flavas
What is needed to get your clips to play in RP10? RP10 tells me it can't find the stuff it needs to playback racp.
racp = HE-AAC.

Quote from my FAQ in The Real 10 Platform thread (http://forum.doom9.org/showthread.php?s=&threadid=68245):

"Playback problems with HE-AAC in RealPlayer 10
RealPlayer 10 can not currently play back HE-AAC in RM due to two bugs: 1) the AAC renderer plugin does not recognize the 4cc racp for HE-AAC, triggering an auto-update request. Hex-edit to raac is possible. However, then 2) raac.dll will crash, due to another bug. Both bugs have been fixed, and will be included in the Gold release of RealPlayer 10. In the meantime, neither of these bugs affect how Media Player Classic plays back HE-AAC in RM, even when it uses the buggy raac.dll. You need the latest release of MPC: 6.4.7.6 or higher."

-=-

EDIT: Fixed DLLs available:
https://helixcommunity.org/project/showfiles.php?group_id=30
This includes another DLL needed to handle racp (the 4cc code). With both of these DLLs in the right place you should be able to play back racp in RealPlayer 10 Beta.

[karl_lillevold]

Originally posted by damrod
ehq50 for the first pass?? does this etting apply to rv10 "normal" producer ie not elysium version ??
EHQ 50 for 1st pass is recommended only with the new Curve Compression based 2-pass rate control. For the old 2-pass VBR rate control, EHQ 65 is recommended.

[karl_lillevold]

Why can sometimes the old 2-pass VBR provide a better results?

From the first post, in the documentation for the rcEnableCurveCompression setting:

The new RC's goal is constant quality throughout the encode.
It works great at high bitrates, and is much more accurate than
the old rate control. For low bitrates, until more advanced
parameters are added, the old rate control, or an external
scaler is recommended. Specifically useful for low bitrates
would have been High bitrate scenes degradation (%) and
Low bitrate scenes improvement (%). These are not yet implemented.

This is because the high action scenes take a too large percentage of the available bit budget, and the low motion scenes are too heavily sacrificed. It will vary from clip to clip. I have not tested the curve compression much with anime and/or low bitrates.

I hope to add the ability to slush bits from high bitrate scenes to low bitrates scenes shortly. This should be useful for low bitrates with this new rate control.

[justin]

Should the max bitrate still be 2.1x the average bitrate for traditional quality high bitrate / low bitrate?

[karl_lillevold]

Originally posted by justin
Should the max bitrate still be 2.1x the average bitrate for traditional quality high bitrate / low bitrate?
Please do remember to read all the documentation I provided... I know it's a lot of information, but I tried to make most of it useful. :) Thanks!

Another quote from the 'rcEnableCurveCompression' option:

This disables all other RC modes, MSL and maxBitrate ignored

[damrod]

filesharing doesn't work on helixcommunauty???

ahhhhhhhh.... calming...

sorry : how can i retrieve the activx dll for rv10 beta ??
i neeed itttttt ;-)
i want to use it in realbatch (an activeX dll in vb6 miam miam :-))
btw it seems i need on only the dlls no? no need to retreive the full producersdk no?

[karl_lillevold]

I have been told all the binaries should be back up by Monday. Stay calm, take a deep breath ... :) [minor suggestion: please remove that long ahhhh. It really messes up the page formatting ]

[damrod]

ouffff

i will wait till new week to modify realbatch core encoding...

btw do you know how to retrieve clip duration? do i need to use the dll or can rmeditor give me the data?

[Griniaris]

Hi there!

I am upgrading my RV10 plugin for DVX to use the new elysian options and I was wondering what the suggested values to be set as default for the following parameters would be?

rcPFrameRefQuant
rcBFrameRefQuant
maxConsecutiveBFrames
inloopCutOffQuant
inloopCutOffCompatible
inloopCutOffBUseRefQuant

Would something like 6/10/3/9/false/false be ok or should I use something else for better results?
The default I think will be to use the old rc but if user chooses to use the new one I would like to have some presets for the not advanced ones.

Thanks

[h9903209]

Originally posted by karl_lillevold
Why can sometimes the old 2-pass VBR provide a better results?

From the first post, in the documentation for the rcEnableCurveCompression setting:

The new RC's goal is constant quality throughout the encode.
It works great at high bitrates, and is much more accurate than
the old rate control. For low bitrates, until more advanced
parameters are added, the old rate control, or an external
scaler is recommended. Specifically useful for low bitrates
would have been High bitrate scenes degradation (%) and
Low bitrate scenes improvement (%). These are not yet implemented.

This is because the high action scenes take a too large percentage of the available bit budget, and the low motion scenes are too heavily sacrificed. It will vary from clip to clip. I have not tested the curve compression much with anime and/or low bitrates.

I hope to add the ability to slush bits from high bitrate scenes to low bitrates scenes shortly. This should be useful for low bitrates with this new rate control.

Can you tell an example of when is high bitrates and when is low?
e.g. 450kb/s is high or low or medium?

[karl_lillevold]

Originally posted by damrod
Do you know how to retrieve clip duration? do i need to use the dll or can rmeditor give me the data?
I know it is possible to parse the RM file to find the clip duration. D-C has figured out how to do with his RMVB Analyzer/Shell Extension tool, referenced in the RV9 sticky post. You could always ask him.

rmeditor can give you the duration too, not quite sure what you mean "use the dll"...

[karl_lillevold]

Originally posted by Griniaris
I am upgrading my RV10 plugin for DVX to use the new elysian options and I was wondering what the suggested values to be set as default for the following parameters would be?
Great! I would suggest to use the numbers provided in the first post (6/10/3/12/false/false). Please, if anyone prefers other settings, let us all know, and for which types of clips/bitrates.

[karl_lillevold]

Originally posted by h9903209
Can you tell an example of when is high bitrates and when is low?
e.g. 450kb/s is high or low or medium?
that's a very general question. 450 kbps is high for a low resolution clip, but low for a high resolution clip. I would imagine you are asking about a high rez clip, perhaps letterbox, then I would say 450 is low-medium. 'High' probably starts around 650-750 .. but every clip is different, as is everyone's preferences. There is no answer set in stone which RC is always best. I do however plan to include those two parameters to move bits from high action to low action, which will be useful for low-medium bitrates. This seems to be the most requested extra option.

[MictXP]

Well, I've got an interesting question--
I'm trying to make a large collection of low bitrate movies that can play across a wide variety of machines. RV9 is great, and now I'm trying RV10. It looks amazing! I fit LOTR onto an 815 MB file! It looks very decent -- good enough for my uses.

My problem is with the wide variety of machines thing. I need to have Macs be able to play the content. I think it would work, except the racp error. Is there a solution for Macs that would not make the file unplayable on a PC? I'm going to try the hex edit -- I'll post my results.

[justin]

k, I might be completely wrong on everything I'm about to say....

I still like the results from the old Real Video 10 build better. Faces on the new one look less detailed and the backgrounds look more detailed. If it was tweaked so that, ok, I see background, mega blur.. oh, a face in the foreground, sharpen.. it would look better.

if this is even possible, but some sort of pigment calculator that sees that if an area is foreground, and skin, then sharpen alot, and anything backround that is blurred is blurred just a tiny bit more, And have The tweaked Xvid quants for motion

[damrod]

MictXP
LOTR long version?
in which resolution and audio/video bitrate settings?

[MictXP]

Two Towers, not the extended. Time is 2:59:21
I think it's something like 504x278. I used 633 kbs for overall bitrate, with 96 kbs for audio. I'm not so concerned with quality right now -- I have real DVDs for that. I'm very concerned with size, though, which is why I'm doing these at 500-550 kbs for video. I tried Divx -- sometimes it would work (with Animation usually), while LOTR looked worse than crap. But Real works beautifully for what I'm doing.

Switching racp to raac didn't work :-( And I don't think OSX can read the DLL files too well...If Media Player Classic can play Real content, does that mean I could install some filter codec (possibly ffdshow) to get the Mac player (VLC or Quicktime) to play the RV10 content?

[damrod]

633kbits for video... i bet you get a very good quality no?

[MictXP]

It's 633 overall bitrate. Video is 537 I think, audio is 96.
The video is still really good -- much more than I was hoping for. ffdshow didn't work because it's a directshow filter. VLC didn't work either -- not for 10 or 9 contect. Hmm...I don't think Real has released a beta 10 player for OSX either...

So I can encode in RV10 and get the quality but piss of my very few Mac friends, or encode in RV9 and lose a little quality. Or, if anyone else has a fix, I'll try it. Any suggestions?

[damrod]

make sure you encode in rv9-ehq... maybe its the rv10 tag that cause problems...

[Sirber]

Use RV9 @ 85 with the RC, nothing else.

[hellfred]

MPlayer might help, or not. Latest CVS can handel AAC and HE-AAC in the rm container, but on the not x86 processors, the real codecs dlls will not work. I do not know if there is a way to make mplayer use the codecs that come together with the OSX version of the realplayer.
(http://www.real.com/freeplayer/?rppr=d9)
The linux compile of mplayer can make use of both the win32 dlls and the libraries of the linux version of realplayer.

hellfred

[karl_lillevold]

MictXP (and damrod and Sirber): There is no difference in the bitstream format, whether you choose RV9 or RV10. The Mac player will be able to decode both, but it does not know about our 'rv10 tag', it will simply ignore it, and the video will show as RV9. I suspect there is a problem with the audio track (RealAudio 10). I am not sure about the status of playing back AAC (raac) and HE-AAC (racp) on the Mac. I will ask. Thanks for bringing this up.

[Sirber]

Never heard Mac could play video with audio at the same time :confused:

[karl_lillevold]

I was told there should be an updated OSX player with AAC and HE-AAC playback support very very soon.

[damrod]

so MictXP must try with a file encoded with cook audio codec

[MictXP]

My mac receives the same error as on a PC without the fixed DLLs -- the racp error. I think it will play content encoded with the Helix Producer as long as I use AutoRV9 and not AutoRV10. I tried that a while ago, though, so maybe producer has changed.

If an updated OSX player is coming out very soon, that's good enough for me. I don't think I have too many friends that use Mac, but it still is something that I think about.

[damrod]

use cook codec instead of aac ;-)
and you will have normal rv9 files...

[MictXP]

How do I use the cook codec?

[karl_lillevold]

MictXP: AutoRV10 has switched to raac and racp "under the hood", i.e. you can not see the name of the codec being used. AutoRV9 uses cook instead. Perhaps it would be nice for AutoRV10 to include the actual codec being used in the drop-down box. I would have certainly liked to see AAC and HE-AAC, these by many recognized as the most efficient codecs today.

GUI developers: I just finished adding three new options to the rate control:

<rcKeyFrameBoost type="uint">0</rcKeyFrameBoost>
<rcHighBitrateReduce type="uint">0</rcHighBitrateReduce>
<rcLowBitrateBoost type="uint">0</rcLowBitrateBoost>

Each parameter takes a number from 0-100. Send me a note if you would like a pre-prelease to help you include these new options. In a few days after I have done some more testing, I should be able to update the publicly available preview with these options as well. We already know this, but I have verified that reducing high bitrate scenes somewhat is good for average PSNR for a clip where some scenes take a large amount of available bits.

[MictXP]

Is there a way to use RV10 with the cook codec?
I'm thinking that using AutoRV9 with the RV10 producer would work. Would that take advantage of the Elysian features though?

I sound like I know nothing except easy to use GUIs...I'm very familiar with doing a lot of grunt work with Divx and Xvid, but I'm new to the Real platform. I can do grunt work here too, though. I just like GUIs better :D

[damrod]

not sure since there are three codecs rv9, rv9-ehq and rv10...

rv10 is rv9-ehq + aac but the value-settings for the ehq are different ...

if you have autorv9 with ehq support you will have same quality as rv10
but not elysium feature sorry...

[damrod]

use last version of autorv9 it has rv9-ehq support and cook codec...

[hellfred]

@MictXP:
First, MPlayer is not yet able to play back RV10 content on MaxOSX. Booting a linux port on the Mac and then play the RV10 content is no alternative.
Second, AutoRV10 v1.0b1 used to automatically select cook for stereo audio. I have not tested v1.0b1.1 yet. But nevertheless, you can use both of them and easily make sure that cook is bein used. Just choose your source and run through all tabs swithching the parameters as usual. But after adding the job and before starting to encode check the jobfile that was created by AutoRV10. It usually is c:\AutoRV_Movie.rpjf. This is a ascii file and have a look at the last lines
</stream>
<stream xsi:type="audioStream">
<pluginName type="string">rn-audiocodec-realaudio</pluginName>
<codecName type="string">cook</codecName>
<codecFlavor type="uint">23</codecFlavor>
<streamContext type="bag">
<presentationType type="string">audio-video</presentationType>
<audioMode type="string">music</audioMode>
</streamContext>
</stream>
</streams>
</audience>
</audiences>
</job>


See the codecName line already contains cook, and codecFlavor 23 means stereo@44Kbps. stereo@96Kbps would need a codecFlavor 25
Have a look at the documentation of helixcommunity.org for a full list. (AudienceFile.htm#Audio_Codec_Tables)
I hope that for the second pass, no hew joblile is being created or at least that the audiostream part is not being edited. You can try to use the edit audience button, too, which will be available when adding a job. But always keep in mind, that it is still beta.

hellfred

[MictXP]

That worked great. I first tried to edit the file through the Audience button, but that didn't change the .rpjf file at all.
I changed the movie and credit .rpjf to cook and changed the codecflavor to 25 (it was 0). Now the movie is playable on Mac and PC. Thank you!

I encoded Gattaca @ 550 kbs, with 544x280 resolution. Turned out great. I'm very surprised at the quality of this codec vs. divx.

[Griniaris]

What are the recommended settings for the keyframe and low motion boosts and high motion reduce? Anyone did any tests? What ranges give the best results? I know it is a bit subjective but I would like to have something like a default value and then the user can change it if he likes to...