RealVideo 10 "Winter 2004" update

[karl_lillevold]

Download:
Helix Binary Downloads (https://helixcommunity.org/beula/download/)

Readme.txt:

Changelog:
** 2004-12-06: Fix for rcBestPSNRMode introduced 11-24.
Affects all encodes. Please update when you have a chance.

** 2004-11-24: Fix for parameter firstPassComplexity. This
was in most cases ignored, and always set to 50 for the
new R/C and 65 otherwise.

** 2004-11-08: Fix for Medium EHQ complexity, which
almost no one is using. No need to update if you are not.

** 2004-10-28: fix for chromaModeDecision on
single CPU systems (no hyper-threading or multi-proc)
- chromaModeDecision always ON for EHQ 100

** 2004-10-25: added option <chromaModeDecision>
This option takes chrominance (or color) into
account when choosing the best encoding modes.

Fix: encodeAllFrames and rcBestPSNRMode would always
be ON if included in audience, if if set to 'false'

Fix: long standing bug where if Constant Quality less than 20-30
and EHQ greater than 70, bitstream could not be decoded. Thanks
to Satsuki for discovering the problem.

** 2004-10-22: fixed bug related to the new EHQ100


Here is an updated RV10 encoder DLL with some small changes
that have been added since the last release. This is not
all we have been working on, of course, but we figured it
would be useful to have this in the community.

Replace erv4.dll in Producer's codecs directory. Remember
to back up the existing one. This DLL may (as always)
contain new bugs...

1. Improvement to EHQ 85 and higher, additional coding mode

2. minor improvements to EHQ 100

These combined will provide some improvement
in quality, but not anything like EHQ did. There is no need
to perform detailed comparisons.

3. new option <chromaModeDecision>
This option takes chrominance (or color) into
account when choosing the best encoding modes.

3. new option <encodeAllFrames>, which in streaming RC mode
forces encoder to encode all frames. In curve compression RC mode,
this has always been the case, and the option is not needed when
the CC RC mode is used.

4. new option <rcBestPSNRMode>. In curve compression RC mode,
sets parameters in a way that testing has shown provide the
best PSNR, in addition to a small codec change. This may not
always correspond to best visual quality. This option is
mostly applicable to the new RC mode, not the old streaming RC
mode.

The settings rcBestPSNRMode imply are:
patternAdaptivity => 2
rcHighBitrateReduce => 60
rcPFrameRefQuant => 6
rcBFrameRefQuant => 12
+ the internal codec improvement
Experiments show an improvement generally
from 0.25 - 0.5 dB, but of course, your mileage may vary.


New options are used like this:
<codecProperties type="bag">
<chromaModeDecision type="bool">true</chromaModeDecision>
<rcBestPSNRMode type="bool">true</rcBestPSNRMode>
<encodeAllFrames type="bool">true</encodeAllFrames>
</codecProperties>

The same settings are available in the registry, standard location.
[HKEY_LOCAL_MACHINE\SOFTWARE\RealNetworks\RV9]
"chromaModeDecision"=dword:00000001
"rcBestPSNRMode"=dword:00000001
"encodeAllFrames"=dword:00000001

Note that even though I listed both rcBestPSNRMode and
encodeAllFramesON, it really does not make sense to use both
at the same time, since encodeAllFrames applies to the old rate control,
and rcBestPSNRMode to the new rate control.

As usual, let us know of any problems.

-- Karl.

[Sirber]

Cool! Releasing RealAnime 2.22 :D

[Sirber]

Some tests

On my 2000+, using 1-pass CQ65 EHQ100, it takes ~4 sec to encode ~.5 sec :cool:

[karl_lillevold]

I rolled back some initial EHQ100 changes, and now encoding speed at EHQ100 should be about the same as before, still with some improvement/bugfix included.

[Sirber]

I'll check my logs tomorrow to check if I go up to 3h / file. Speed is not that important, and I'm glad you did this update before winter, I'll be able to heat my room while encoding! :D

[Sirber]

Average 2h30 per file.

[Sagittaire]

1) RV10 seem to be better with high sensitivity for bframe. XviD regulate bframe number with BVOP sensitivity: perhabs a good idea for RV10 ... ?

2) Why RV10 put always 0, 1 or 3 consecutives bframes but never 2. RV10 seem to have no bug with 0, 1, 2 or 3 ? (I test that with first pass XviD stat file in producer for second pass ... lol)

[Sirber]

2-pass VBR seems faster than 1-pass CQ :confused:

[karl_lillevold]

Sagittaire:
1) I am not sure I understand.. "high sensitivity for B frames".. RV10 also decides # of B frames based on video complexity, but there is always room for improvement.
2) In particular this aspect can be improved. The frame queue implementation has made it hard to include 2 when the number of B frames is to be decided (1st), but not a problem in a fixed pattern, or when specified in the .pass file (nice experiment you did..!). This too is something that will be improved one day.

Sirber: "seems"
There is an invention called a stopwatch. You press a button to start a timer, then press again to stop the timer. The stopwatch will then display the amount of time that has passed from the time you pressed the start button until you pressed the stop button. It is sometimes quite useful :D ;)

1-pass CQ at 100 might be slower than 2-pass at 85, since the 1st pass is always very fast. At the same EHQ, 1-pass will be faster.

[Sirber]

My encode is finished.

1-pass CQ65, EHQ100: average 2h30
2-pass VBR, EHQ65/100: average 2h30

[karl_lillevold]

Sirber: nice. shows that 2-pass 1st past is super fast, and 2-pass is great to achieve a target filesize/bitrate.

[haibane]

The patternAdaptivity was set to 2 in the rcBestPSNRMode, does this also give the best psnr for anime? I remember reading the patternAdaptivity = 1 gives the best result for anime sometime ago.

The second question is that does rcBestPSNRMode override rcHighBitrateReduce and other setting it changed in jobfile?

[karl_lillevold]

I fixed a bug that was introduced with this update, related to EHQ100. Download same location as given in first post. Thanks again to Sirber for finding it.

haibane: sorry for the delay. I don't know whether or not the 'shortcut' rcBestPSNRMode always results in best PSNR for anime. For your second question, see my post below.

[Sirber]

From my test, in general, oldRC and CQ gives the best results for anime content.

[karl_lillevold]

haibane: All "uint" types are set before "bool". Thus, 'rcBestPSNRMode' will over-ride all "uint" settings. So if you want your own settings for the parameters rcBestPSNRMode is a shortcut for, you have to remove the rcBestPSNRMode parameter.

[Sagittaire]

I think that Average PSNR isn't a good tool for testing Rate Control quality: Overall PSNR or Frame PSNR graph are very better. Average PSNR must be very better with CBR than VBR. For example sample with very long/very "low motion" part and very short/very "high motion" part done very better Average PSNR for CBR.

Best PSNR mode for RV10 use rcHighBitrateReduce = 60. it's a very high reduction for bitrate modulation. Quality is higher for "low motion" but worst for "high motion". it's a very good strategy for Average PSNR but not for Overall PSNR.

[karl_lillevold]

Sagittaire: I agree. the rcBestPSNRMode shortcut is not meant for anything but experiments, and to show that best PSNR does not correspond to best visual quality, or constant quality.

[Sagittaire]

Originally posted by karl_lillevold
Sagittaire:
1) I am not sure I understand.. "high sensitivity for B frames".. RV10 also decides # of B frames based on video complexity, but there is always room for improvement.


For example with XviD BVOP sensibility ...

sensibility = -25:

i 6 680 0 0 1971 1953
p 6 113 547 20 3217 1154
p 6 293 354 33 4034 1703
p 6 353 327 0 4917 2047
p 6 45 622 13 4485 1246
p 6 88 591 1 4021 1416
p 6 54 610 16 4277 1233
p 6 53 625 2 4185 1314
p 6 85 595 0 4645 1374
p 6 41 638 1 4751 1296



sensibility = 0:

i 6 680 0 0 1971 1953
b 10 0 680 0 445 373
p 6 270 384 26 4143 1591
b 10 0 680 0 1134 437
p 6 470 210 0 5525 2218
b 10 0 680 0 894 334
p 6 261 419 0 5564 1898
b 10 0 680 0 1195 353
p 6 327 352 1 5655 1979
b 10 0 680 0 1562 397



sensibility = +25:

i 6 680 0 0 1971 1953
b 10 0 680 0 445 373
p 6 270 384 26 4143 1591
b 10 0 680 0 1134 437
p 6 470 210 0 5525 2218
b 10 0 680 0 1711 843
b 10 0 680 0 1548 482
p 6 427 253 0 6127 2164
b 10 0 680 0 2173 901
b 10 0 680 0 2238 596

[karl_lillevold]

Sagittaire: Thanks! Now I understand. It's a threshold for how 'easy' the encoder chooses B frames. I could expose such a parameter as well. Something to think about for the next update :)

[Conanzsw]

when using 2pass 2nd ,new ehq100 still takes 1.4~1.5 times longer than old one ....@@

[Sirber]

You should use EHQ85. Not sure EHQ100 brings more quality for the time spent.

[karl_lillevold]

Hi, I posted a small update:

** 2004-10-25: added option <chromaModeDecision>
This option takes chrominance (or color) into
account when choosing the best encoding modes.

Fix: encodeAllFrames and rcBestPSNRMode would always
be ON if included in audience, if if set to 'false'

Fix: long standing bug where if Constant Quality less than 20-30
and EHQ greater than 70, bitstream could not be decoded. Thanks
to Satsuki for discovering the problem.

With option chromaModeDecision, for a chroma intensive anime test clip I measured +0.25 dB improvement in Overall PSNR for UV, and 0.04 dB for YUV. No change in Luma PSNR.

[Sirber]

woot woot!

gonna release RealAnime 2.25 in 24h. :D

[karl_lillevold]

** 2004-10-28: fix for chromaModeDecision on
single CPU systems (no hyper-threading or multi-proc)
- chromaModeDecision always ON for EHQ 100

[Krismen]

I've updated Real Producer Basic 10 with 2004-10-28 patch and I can't get it to work (application crashes on start). My CPU dosen't have HT tech. (AXP1700+). Luckly for me I made a backup of "erv4.dll".

[Sirber]

WFM here, on a 2000+, but with cmdline producer. Could you try RealAnime if it works for you?

[karl_lillevold]

Originally posted by Krismen
I've updated Real Producer Basic 10 with 2004-10-28 patch and I can't get it to work (application crashes on start). My CPU dosen't have HT tech. (AXP1700+). Luckly for me I made a backup of "erv4.dll".
I am not sure what could be wrong. I /think/, but am not sure the new erv4 will work in both RealProducer 10 Pro and Basic. However, you can not really enable the new features except via the registry. I would suggest one of the other GUIs, like RealAnime or AutoRV10.

[Krismen]

Thank you guys. I'll try AutoRV10 soon.


EDIT:
Problem with patch & RMP Basic 10 solved by deleting backup file (erv4.bak) from codecs dir.

[gavo]

ok I have ehq at 100 for best quatily, but I wondering what should 1st pass compelixty be on.

[Sirber]

50

[karl_lillevold]

It seems no one is using EHQ Medium (75), which is good, because then you would have noticed that it can create blocky (broken) video in this release. I will post a fix tomorrow. No reason to update if you use EHQ High (85) or higher.

[Sirber]

:D

Never heard there was a "75" setting before :confused:

[gavo]

so going over 85 wont make a difference at all? or going over with 1 pass complexity?

[Sirber]

over 85 for encoding pass won't have mych quality gain
over 50 for analisis pass won't have much quality gain

[gavo]

but it still a gain.. what the max for 1st pass 100?

[gavo]

[QUOTE]Originally posted by gavo
[B]but it still a gain.. what the max for 1st pass 100 and ehq?

[Sirber]

Guess...

Dude, EHQ numbers are written everywhere. :(

:search: :readfaq:

Rules:

1) Read up before asking! There are tons of guides, FAQs and each forum has a dedicated Q&A thread with additional info.

1a) Use the search function before posting. Chances are your question has already been answered.

Next time I will report to the moderator. :sly:

[hubereevez]

( Gavo , tu nous gaves )

but it still a gain.. what the max for 1st pass 100?

You have your answer here (http://forum.doom9.org/search.php?s=).

Moreover, stop acting like this or you'll be ban ! Because of people like you, Modos and users (like Karl_super user) are tired. And when these guys get tired, they do not respond so quickly to good question !!!!!!!!

So read the f*ù*^$^rules and use the search button !!!!!!!!:mad:

[Sirber]

:goodpost:

[Shinobu]

test it yourself, after that if you think ehq 100/100 can be usefull, use it.
to my mind:
ehq 50/85 is enought for common encoding.
ehq 65/100 is usefull for very difficult encoding.
ehq 100/100 is realy useless.

++

[karl_lillevold]

Shinobu: thanks for explaining ehq levels so well!

gabo: please do use search, and read the stickies. Next time you ask before you search, you will be given a strike.

[karl_lillevold]

** 2004-11-08: Fix for Medium EHQ complexity, which
almost no one is using. No need to update if you are not.

[hubereevez]

hi,

I did search the rv section, but didn't see anything related to my question/problem....

I do have 1 Go DDR, but producer uses quite a lot : 430 Mo.... lol

I didn't check if this is normal or not (due to the 10.1.0.390 ?)

With Process explorer from sysinternals, I can check wich handle is open from producer. This not telling me smthg, cose I'm a big noob.....

Voilà ! should I format ?

Thanks

hubert

[karl_lillevold]

hubereevez: with Avisynth as the input to Producer, the memory usage will be very large. Most of it is in Avisynth. Compare with encoding a short uncompressed AVI file :)

And especially during the 2nd pass, because due to a bug in Avisynth/DirectShow, memory from the 1st pass is never freed, and memory usage pretty much doubles :(

[hubereevez]

oki

Actually I did red somthg like that in a post from satsuki.... but I had missundertand it perhaps, I believed that the cause may be dll encoding and not through producer cmd...

i will check without avisynth

thanks karl (who said you're not fast lol) :)

[karl_lillevold]

It's even worse when using the SDK for batch encoding, since then memory will not be freed in between each encoding. This results in memory usage becoming quite impossible to deal with, for more than a couple of sequences.

[Sirber]

I wonder why this bug don't get corrected... it's been known for years :(

[damrod]

realbatch 1.5b in vb6 with sdk => around 80Mo for each pass (no avs)
realbatch 2.1 in delphi7 with sdk => around 25Mo for each pass (no avs)

but it's true sdk don't free memory : when i encode lot of files, usually after 10 files sdk use 100-130Mo and it remains like with for the rest of the list....never more (with rb in vb6)

does the sdk proc 'release ressources' can release memory?

[karl_lillevold]

** 2004-11-24: Fix for parameter firstPassComplexity. This
was in most cases ignored, and always set to 50 for the
new R/C and 65 otherwise.

Thanks to D-C for discovering this bug. There is no need to update unless you specifically need to increase firstPassComplexity, which very very rarely has any effect on the accuracy of the rate control.

[Sirber]

ok

I'm using it for "Extreme" at 65, otherwise I'm at 50. Gonna upadte for RealAnime 2.30. Thanks D-C and Karl! :D