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

[karl_lillevold]

** 2004-12-06: Fix for rcBestPSNRMode introduced 11-24.

rezard found a problem in which I accidentally always enabled a feature that was supposed to only be used with rcBestPSNRMode, so please update when you have a chance.

[Sirber]

RealAnime 2.30 will be ready with it.

[rezard]

the Rate Control stretch tiny frames.

RealVideo Rate Control 2nd pass log:
Framerate: 23976/1000 = 23.976000 fps
Total number of frames: 30518
Target filesize: 123833344 bytes
Keyframe boost adj: 1.00 Nonlinear adj: 1.00
CtrlStrngth: 5 MaxOFlowImpr: 1 MaxOFlowDegr: 1
Num Type Quant Size Scaled AdvSc Target Actual Error OFlow
0 i 14 19333 7627 7627 7627 9216 1589 -1589.00
1 p 13 5836 2581 2581 2555 2313 -242 -1387.74
2 p 13 8262 3746 3746 3708 2812 -896 -532.49
3 p 13 7850 3611 3611 3585 2645 -940 366.77
4 p 14 11903 4978 4978 4995 4364 -631 957.03
5 p 14 10873 4460 4460 4504 4059 -445 1361.28
6 p 13 8414 3821 3821 3859 3600 -259 1579.54
7 p 13 8376 3788 3788 3825 3127 -698 2236.79
8 p 13 11388 4773 4773 4820 4767 -53 2249.05
9 p 13 10531 4315 4315 4358 4449 91 2117.31
...
3297 p 5 892 459 459 1018 3002 1984 1152267.81
3298 p 3 453 240 240 798 3267 2469 1149796.56
3299 p 5 1083 563 563 1120 2639 1519 1148275.31
3300 p 7 1789 907 907 1463 2487 1024 1147249.06
3301 p 7 1517 808 808 1363 2211 848 1146398.80
3302 p 6 1367 714 714 1269 2526 1257 1145139.55
3303 p 7 1430 749 749 1303 2153 850 1144287.30
3304 p 5 960 499 499 1053 2948 1895 1142390.05
3305 p 5 918 468 468 1021 2614 1593 1140794.79
3306 p 4 725 378 378 930 2834 1904 1138888.54
3307 p 6 1101 576 576 1127 2180 1053 1137833.29
3308 p 5 1066 571 571 1122 2744 1622 1136209.04
3309 p 7 1622 819 819 1369 2389 1020 1135186.79
3310 p 5 806 425 425 975 2854 1879 1133305.53
3311 p 7 1559 817 817 1366 2250 884 1132419.28
3312 p 8 2105 1010 1010 1558 2397 839 1131578.03
3313 p 8 1886 900 900 1448 2222 774 1130801.78
3314 p 7 1337 677 677 1224 2241 1017 1129782.52
3315 p 8 1967 950 950 1497 2247 750 1129030.27
3316 p 8 1776 906 906 1453 2041 588 1128440.02
3317 p 9 2051 959 959 1505 2151 646 1127791.77
3318 p 9 2912 1415 1415 1961 2343 382 1127407.51
3319 p 8 2062 1011 1011 1557 2255 698 1126707.26
3320 p 9 2232 1117 1117 1663 2034 371 1126334.01
3321 p 8 1915 964 964 1509 2080 571 1125760.76
3322 p 9 2094 1041 1041 1586 1967 381 1125377.50
3323 p 8 1501 710 710 1255 2132 877 1124498.25
3324 p 8 1561 718 718 1262 2057 795 1123701.00
3325 i 15 29926 11020 11020 11130 13880 2750 1120951.00
3326 p 10 24994 9416 9416 9959 16862 6903 1113993.00
3327 p 12 11881 4740 4740 5279 4956 -323 1114261.00
3328 p 13 15048 6191 6191 6730 4956 -1774 1115980.00
3329 p 13 20556 8106 8106 8646 9054 408 1115517.00
3330 p 13 11945 4955 4955 5495 4445 -1050 1116512.00
3331 p 13 10167 4170 4170 4711 4034 -677 1117134.00
3332 p 14 23325 8987 8987 9528 9160 -368 1117447.00
3333 p 13 12313 4882 4882 5423 5275 -148 1117540.00
3334 p 13 11753 4891 4891 5432 4348 -1084 1118569.00
...

[Sagittaire]

CtrlStrngth: 5 MaxOFlowImpr: 1 MaxOFlowDegr: 1

you must use higher Oflow because quant prediction isn't very good

CtrlStrngth: 5 MaxOFlowImpr: 50 MaxOFlowDegr: 50

But for me the RV10 RC isn't good: for me a good RC could make second pass with constant quantizer (for I,P,B with possible ratio/offset for I quant boost and B quant reduction) with RC variability setting ...

XviD or RV10 use rcLowBitrateBoost and rcHighBitrateReduce for variability setting but I don't understand the difference between these setting: if you reduce bitrate for "high motion" (high bitrate part) you boost automaticaly bitrate for "low motion" (low bitrate part). Only one setting is necessary: varaibility like for x264 or Bitrate Modulation for DivX ...

For me the best example is x264 RC ...

[rezard]

I tried 5/50/50.
indeed, the number of extreme low quants were much less. but not perfect.

RealVideo Rate Control 2nd pass log:
Framerate: 23976/1000 = 23.976000 fps
Total number of frames: 30518
Target filesize: 123833344 bytes
Keyframe boost adj: 1.00 Nonlinear adj: 1.00
CtrlStrngth: 5 MaxOFlowImpr: 50 MaxOFlowDegr: 50
Num Type Quant Size Scaled AdvSc Target Actual Error OFlow
0 i 14 19333 7627 7627 7627 9216 1589 -1589.00
1 p 13 5836 2581 2581 2503 2261 -242 -1387.74
2 p 13 8262 3746 3746 3678 2782 -896 -532.49
3 p 13 7850 3611 3611 3585 2645 -940 366.77
4 p 14 11903 4978 4978 4995 4364 -631 957.03
5 p 14 10873 4460 4460 4506 4061 -445 1361.28
6 p 13 8414 3821 3821 3886 3627 -259 1579.54
7 p 13 8376 3788 3788 3864 3166 -698 2236.79
8 p 13 11388 4773 4773 4881 4828 -53 2249.05
9 p 13 10531 4315 4315 4423 4514 91 2117.31
...
6285 p 10 8181 3728 3728 4921 4944 23 24583.59
6286 p 11 7971 3517 3517 4708 4351 -357 24910.06
6287 p 11 10966 4918 4918 6125 5655 -470 25349.53
6288 p 11 7709 3521 3521 4749 4005 -744 26063.00
6289 i 7 2656 2425 2425 2465 2389 -76 26139.00
6290 p 9 2086 1168 1168 1801 1640 -161 26300.54
6291 p 7 954 565 565 1202 1831 629 25672.07
6292 p 5 467 268 268 890 2326 1436 24236.61
6293 p 3 184 161 161 748 2302 1554 22683.14
6294 p 1 465 256 256 805 2411 1606 21077.68
6295 p 2 482 247 247 757 2351 1594 19484.21
6296 p 4 862 436 436 908 2433 1525 17959.75
6297 p 6 747 356 356 791 1804 1013 16947.28
6298 p 7 931 427 427 837 1859 1022 15925.82
6299 p 9 1657 775 775 1162 1906 744 15182.35
6300 p 9 1650 735 735 1102 1939 837 14345.89
6301 p 10 1719 768 768 1152 1776 624 13722.42
6302 p 10 1635 724 724 1086 1769 683 13039.96
...

can I request you to explain about the MaxOFlowImpr/MaxOFlowDegr?

I'm eager to have a quant-limit option in the RC.

[Dark-Cracker]

@rezard
do u think u can try the RC AltCC who is in autorv10 to see which result it give u ?

++

[rezard]

sorry, I love manual encoding.

what should I do with .pass(analysis) file produced by ScaleCurve.exe?

[karl_lillevold]

I have on my list of things to do, to do another pass at the rate control. These are good suggestions for areas to look into:
1) QP limits.
2) improve prediction of QP for small frames.
3) perhaps combine rcLowBitrateBoost and rcHighBitrateReduce

Thanks.

[Sagittaire]

@ karl_lillevold

I test seriously the RV10 Rate Control ... and I humbly make some suggestion to improve it.


1) Don't use Average PSNR for RC optimization. Overall PSNR is very better for visual optimisation tweak. Use Overall PSNR in rv9log.txt.


2) Overall PSNR is better with quality mode (vbrQuality + scalingFactor). The quant prediction for New RC is not good for me. If second pass average quant is very higher than the first pass rcPFrameRefQuant then variability quant in 2 pass could be very high. That observation is confirmed by the high default overflow setting. Perhabs multipass rate control could be very better. First pass for first evaluation, second pass with first pass average quant prediction and final pass with better quant prediction. Perhabs bframe sensivity/treshold setting could be good too for test ...


3) bframe decision seem strange: 1 or 3 bframe but not 2. Bframe decision in P(n-2) B (n-1) I(n) with Iframe scene change frame is strange too:


23160 17 1752 40.08 23280 34.11 41.26 12943 100
23200 17 1508 39.96 21640 34.11 41.26 12958 100
23240 17 1180 40.35 19096 34.11 41.26 12969 100
23280 23 2120 35.15 17800 34.11 41.24 13150 d 100 ????
23320 17 13696 37.50 113648 34.11 41.25 13142 Key 100
23360 23 1304 35.37 13128 34.11 41.23 13230 d 100
23400 17 4920 36.91 60272 34.11 41.24 13230 100


IMO if you change bframe for Pframe the quality for Pframe is very higher (Pframe use previous frame, bframe use previous frame and Iframe scene change for reference ... :eek: ). Min frame PSNR is praticaly always for bframe in these particular sequences. IMO with Iframe scene change you must close GOP ...

[karl_lillevold]

Sagittaire: these are good suggestions. Thanks!

[dexx]

Can the RV10 codec be used with virtualdub for encoding?
Has there been any further updates since 10/2004?

[karl_lillevold]

no, and no. Sorry.

[stax76]

no, and no. Sorry.

Is there (COM+) automation or cli and a config dialog that can be invoked or any other effort, interface or API to support developers of batch encoding applications like Gordian Knot. Supporting a codec usually is very painful, XviD is the only exception.

[Sirber]

You can use helix producer commandline, like every other RV devs used.

[Castor-Troy]

@ karl_lillevold

I test seriously the RV10 Rate Control ... and I humbly make some suggestion to improve it.


1) Don't use Average PSNR for RC optimization. Overall PSNR is very better for visual optimisation tweak. Use Overall PSNR in rv9log.txt.


2) Overall PSNR is better with quality mode (vbrQuality + scalingFactor). The quant prediction for New RC is not good for me. If second pass average quant is very higher than the first pass rcPFrameRefQuant then variability quant in 2 pass could be very high. That observation is confirmed by the high default overflow setting. Perhabs multipass rate control could be very better. First pass for first evaluation, second pass with first pass average quant prediction and final pass with better quant prediction. Perhabs bframe sensivity/treshold setting could be good too for test ...


3) bframe decision seem strange: 1 or 3 bframe but not 2. Bframe decision in P(n-2) B (n-1) I(n) with Iframe scene change frame is strange too:


23160 17 1752 40.08 23280 34.11 41.26 12943 100
23200 17 1508 39.96 21640 34.11 41.26 12958 100
23240 17 1180 40.35 19096 34.11 41.26 12969 100
23280 23 2120 35.15 17800 34.11 41.24 13150 d 100 ????
23320 17 13696 37.50 113648 34.11 41.25 13142 Key 100
23360 23 1304 35.37 13128 34.11 41.23 13230 d 100
23400 17 4920 36.91 60272 34.11 41.24 13230 100


IMO if you change bframe for Pframe the quality for Pframe is very higher (Pframe use previous frame, bframe use previous frame and Iframe scene change for reference ... :eek: ). Min frame PSNR is praticaly always for bframe in these particular sequences. IMO with Iframe scene change you must close GOP ...

Sagittaire: these are good suggestions. Thanks!

No hope to see thoses tweaks :( ?