Undocumented RV9 tweaks

[karl_lillevold]

These new codecProperties are available in Producer Milestone 6, unless someone broke them since I added them a while back.

patternAdaptivity: 0, 1, or 3 (2 does not work correctly). Default adaptive, when property is not present.

This parameter sets the number of discardable frames to be encoded in between each non-discardable (P or I) frame.

scalingFactor: 0 - 199. Default adaptive, when property is not present.

This parameter sets the quantization scaling factor for the discardable frames, compared to the P/I frames. 0 means same quantization.

example usage (just like the encoderComplexity for EHQ). Include the following in the <videoStream> section of the audience:

<codecProperties type="bag">
<patternAdaptivity type="uint">1</patternAdaptivity>
<scalingFactor type="uint">50</scalingFactor>
</codecProperties>

Verify how they work with the calcPSNR feature and its resulting rv9log.txt file. No warranties and no support, except what I find time to reply to here.

When these properties are not present, the encoder chooses these parameters adaptively while encoding. This adaptive mode is the recommended mode, but as always, adaptivity may not be perfect for all content and everyone's preferences. If you find that you like a fixed setting, over the default adaptivitiy, please let us know.

There are corresponding reg key over-rides as well, just like for EHQ:

--->8---

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\RealNetworks\RV9]
"patternAdaptivity"=dword:00000001
"scalingFactor"=dword:00000032

--->8---

[Sirber]

can you explain them a little more?

thanks :D

[karl_lillevold]

@sirber: done. see first post. I had hoped someone else would have figured it out by now :)

[slavickas]

is it simply b frames parameters? or my english very adaptively discardable (tm) :) ??

[Sagittaire]

patternAdaptivity and scalingFactor configure bframe ... !!?

[Sirber]

I think discardable frames are b-frames. You can't go beyon 3 coz it's useless, but I think the encoder can take it if karl codes well :p :D

[edit]

Yes, it's about B-Frames.

[ChristianHJW]

Karl, would this require to update the matrix trailer sample i received from you, to present the latest RV9 quality ? We dont wnat to be behind actual technology when finally launching them ( hopefully soon, have to talk to Cruncher about this, i was away more or less 4 weeks now ) ...

[karl_lillevold]

These features have been in use since the launch of RV9, they have always been adaptive. I just now made it possible to set the parameters manually. There would not be much improvement for the trailer encoding, I think. (However, I still would like to re-encode with the motion adaptive pre-filter that Sagittaire used to encode the great Confidence trailer a while back).

I do not really have any advice to provide how to set these parameters to increase video quality. The only case I know of where adaptive does not work all that great is for animation content with duplicated frames (with or without the dup frame dropper). For such content, I have seen PSNR increase of 0.5 dB or more from setting the patternAdaptivity (number of 'discardable' frames) to 1. So that's my only advice for now:
use patternAdaptivity=1 (or perhaps even 0) for animation content with less than full framerate.

Other recommendations to be found and posted by you :cool:

[Sagittaire]

Here is a very high quality anamorphic demo in RV9/RA8/MKV in 850x360 ...
http://jfl1974.free.fr/Video/MatrixII.rar

Here is a LOTRII demo with WMV9/WMA9/SSA/MKV with WMA9 5.1 132 Kbps ...
http://jfl1974.free.fr/Video/Matroska-WM9.rar

[Kaiousama]

Other recommendations to be found and posted by you

Tested last evening:

patternAdaptivity = 1 gives also to me around 0.5 db of average psnr gaining!!
(readed from rv9log.txt, tested on Animatrix - World Record)

patternAdaptivity = 0 or 3 results in a psnr loss compared to standard adaptive method
I'll test on other clips (this one was a very clean source) to see if this gaining is really generalized or if it was an exception (karl: what/how was your test's source clip?).

I'd like to point out a strange behaviour: from my last evening tests i've obtained lesser psnr values for 2pass encodings than for 1 pass encodings (if you need i can attach all the logs, let me know), is it possible that 2 pass gives a worser result or maybe psnr is not the right metrics to judge the 2pass encoding improvements?

[karl_lillevold]

@Kaiousama: The source for my animation test (+0.5 dB) with patternAdaptivity=1, was also very clean. The main reason for this behavior is that the adaptivity is somewhat based on the amount of motion. Duplicated frames have no motion, and patternAdaptivity usually ends up being 3. However, our 'discardable' frames are not perfectly optimized for duplicated frames in-between non-dupes (very non-linear motion), which is also why the dup frame dropper gives an improvement.

1-pass can result in higher PSNR than 2-pass, in fact for short clips, where it does not run out of MSL buffer space, rather dramatically higher quality. In most cases this is because it has spent too many bits, resulting in an oversized file.

[deXtoRious]

Sagittaire

I'm sorry for the offtopic question, but how much free webspace do you get on free.fr?

[iwod]

Originally posted by karl_lillevold
@Kaiousama: The source for my animation test (+0.5 dB) with patternAdaptivity=1, was also very clean. The main reason for this behavior is that the adaptivity is somewhat based on the amount of motion. Duplicated frames have no motion, and patternAdaptivity usually ends up being 3. However, our 'discardable' frames are not perfectly optimized for duplicated frames in-between non-dupes (very non-linear motion), which is also why the dup frame dropper gives an improvement.

1-pass can result in higher PSNR than 2-pass, in fact for short clips, where it does not run out of MSL buffer space, rather dramatically higher quality. In most cases this is because it has spent too many bits, resulting in an oversized file.

will the improved 2 pass VBR improve current situation??

off topic..... what are you currently working on Karl in the helix project.........?? And how are you?? ( as i have notice you don't seems to be online as often... )

[Kaiousama]

@Karl:
I've tested it on another clip (a noised 24 minutes source this time) with the result of a 0.56 boost in psnr :)
It seems that patternAdaptivity = 1 is a very good choice for anime! thanks for this new useful parameter.
I also have two feature requests and an idea for you:

Feature requests:

- It would be very useful if the user may optionally specify (like in Nandub's SBC or Xvid) the initial and/or ending credits interval in order to apply them a lower bitrate.

- What about exposing to the user a parameter to control how much the bitrate will be assigned to slow motion sequences and how much to fast motion ones?

Idea (for anime material):

One of the differences between animation and live films is that an animation frame is not as well complex as the reality, there are less particulars and bigger color-uniform parts; but most of all the animation frame is well delimited by huge edges compared to the reality.

That produces the fact that whatching an anime frame the eye pay more attention to the few important edges, where in a live film's frame the eye has to elaborate too many edges to extract the essential ones (that's also because reality is not drawn with bigger edges for important things like in anime ;) )

To properly handle this situation it would be useful if the encoder applies an edge detection mask to the frame before compressing it; and when it's time to apply the compression quantitizer for each block, the encoder could check if the block belongs to an edge detected by the mask and in positive case apply more bitrate on that block. This will results in a compressed clip where bitrate is not assigned only by motion amount but also by edge presence (even in static sequences)

I don't know if producer actually works in this way, please tell me what do you think about.

[RadicalEd]

Originally posted by Kaiousama
It would be very useful if the user may optionally specify (like in Nandub's SBC or Xvid) the initial and/or ending credits interval in order to apply them a lower bitrate.

Alternatively, it wouldn't be too hard to implement that into a gui by using different encoding sessions and joining the files with rmeditor.

[Kurosu]

Originally posted by deXtoRious
Sagittaire

I'm sorry for the offtopic question, but how much free webspace do you get on free.fr?
5x100MB maximum, for free. But I wonder how they handle sites with high bandwidth use and unregular content (like video sequences, audio files). You have PHP4 on it AFAIK.

Still AFAIK (:D), you have to be french to get a webspace or have a french person giving out one (child) account.

[karl_lillevold]

@Kaiousama: Glad to hear the custom parameter is working so well for animation.

Thanks for your suggestions and ideas. Regarding your feature request about different bitrates for different parts of an encode. This is a really useful feature, and I have seen it used with success in AutoRV9. It belongs either in a GUI or Producer, but I don't really know where it fits best in Producer, cmd line or job file, and either does not fit really well. RadicalEd is right about how it fits nicely in a GUI where you can set up encoding sessions.

A parameter to float bits between high and low motion areas would be a suitable codec parameter though. I will add it to the list of improvements to look into.

Regarding edge encoding; RV9 already does it pretty well, does it not, but your suggestion is a sound one. However, smooth gradients also need their fair share of attention :)

[Kaiousama]

Regarding your feature request about different bitrates for different parts of an encode. This is a really useful feature, and I have seen it used with success in AutoRV9. It belongs either in a GUI or Producer, but I don't really know where it fits best in Producer, cmd line or job file, and either does not fit really well.

I think job file would be good to place this option, in a way like this:


<input xsi:type="avFileInput">
<filename type="string">D:\Hack_Liminality\Hack_01.avs</filename>
<StartCredits>
<Begin Type="unit">0</Begin>
<End Type="unit">1560</End>
<Bitrate Type="unit">400000</Bitrate>
</StartCredits>
<EndCredits>
<Begin Type="unit">23500</Begin>
<End Type="unit">24900</End>
<Bitrate Type="unit">400000</Bitrate>
</EndCredists>
</input>


I think doing that from the encoder is the smartest way (even because in this way i can always reproduce the encoding session with the job file backup only), but if not possible the gui solution is still usable.

[Sirber]

I admit that way it would be easyer then create 2 RMVB and remux them later using wierd and undocumented commandline options :D

[karl_lillevold]

@Kaiousama: that's a nice starting point. The problem is bitrate is defined in the audience, and the audience applies to each output, not the input. I am sure it's possible to work something out, but it's a rather significant change from the current thinking, where Producer is intended for both Live and File-To-File. Maybe a feature for Producer 9.3. If you would like to get feedback directly from the Producer team, please enter a feature request here:
https://helix-dna.helixcommunity.org/issues/enter_bug.cgi?issue_type=FEATURE
Feel free to include your sample XML code as an example.

[Kaiousama]

@Karl: I think i've figured out the problem you told me, and maybe this feature could be added without any changing in current thinking; i mean with a job like this:


<parOutputs>
<output>
<destinations>
<destination xsi:type="fileDestination">
<filename type="string">D:\Hack-Sign\Hack01.rmvb</filename>
</destination>
</destinations>
<mediaProfile>
<audioMode type="string">music</audioMode>
<disableAudio type="bool">false</disableAudio>
<disableVideo type="bool">false</disableVideo>
<resizeQuality type="string">high</resizeQuality>
<videoMode type="string">normal</videoMode>
<audienceRefs>
<audienceRef>My Audience</audienceRef>
</audienceRefs>
<credits>
<credit>
<start Type:"unit">0</start>
<end Type:"unit">2500</end>
</credit>
<credit>
<start Type:"unit">34600</start>
<end Type:"unit">38400</end>
</credit>
</credits>
</mediaProfile>
</output>
</parOutputs>


In this way credits could be enabled or not for each output, with the possibility to specify more credits intervals simply adding an additive <credit> section (i'm beginning to understand how much xml-based jobs are useful).

The Credits desired bitrate would be simply stored in audience definition like the other bitrate values like this:


<audiences>
<audience>
<name type="string">My Audience</name>
<avgBitrate type="uint">967000</avgBitrate>
<maxBitrate type="uint">2000000</maxBitrate>
<creditsBitrate type="uint">400000</creditsBitrate>
..
..
</audience>
</audiences>


Producer will check if current frame is included in credits interval, if yes it'll encode that frame using the <creditsBitrate> value for that specific output.


If you would like to get feedback directly from the Producer team, please enter a feature request here:
https://helix-dna.helixcommunity.or...ue_type=FEATURE
Feel free to include your sample XML code as an example.


I prefer to discuss a little more this feature with you in order to focalize an effectively implementable proposal and then i'll be glad to post it in official feature request on helixcommunity (btw, i've visited your link and after 5 minutes of confusion i've finded your bug tracking/feature request section very well organized).
Let me know your opinion ;)

[karl_lillevold]

I think it could be made more general, by added a startTime and endTime to the audienceRefs section:

<audienceRefs>
<audienceRef>Audience_Credits</audienceRef>
<startTime type="time">0</startTime>
<endTime type="time">0:0:20.345</endTime>
</audienceRefs>
<audienceRef>Audience_Main</audienceRef>
<startTime type="time">0:0:20.345</startTime>
<endTime type="time">1:45:35.488</endTime>
</audienceRefs>
<audienceRefs>
<audienceRef>Audience_Credits</audienceRef>
<startTime type="time">1:45:35.488</startTime>
<endTime type="time">0</endTime>
</audienceRefs>

'0' endTime means the end. '0' startTime means the beginning.

This would be a nice feature request for 9.3, but it is still a little complicated to implement cleanly, because there are certain restrictions as to how the audiences can differ. For instance, the same audio codec has to be used.

However, there are other priorities to be completed first, for instance improved 2-pass VBR, with settings exposed for fine-tuning.

So until then, the best option is to use a combination of AVS scripts, and rmeditor, to achieve this, or a GUI with this feature (AutoRV9). The manual procedure would be to create 3 AVS scripts, exactly the same, except use Trim to specify the section for each AVS script. Then encode each with AVS file with producer with the right audience for each section. Then, finally use rmeditor to merge the 3 sections together.

[Sagittaire]

I make test with this new setting and best result for PSNR for my test is ...

<encoderComplexity type="uint">100</encoderComplexity>
<customPacketSize type="uint">16000</customPacketSize>
<patternAdaptivity type="uint">1</patternAdaptivity>
<scalingFactor type="uint">100</scalingFactor>
<calcPSNR type="bool">true</calcPSNR>

For anamorphic encoding with high bitrate I use this setting ...

<encoderComplexity type="uint">80</encoderComplexity>
<customPacketSize type="uint">16000</customPacketSize>
<patternAdaptivity type="uint">0</patternAdaptivity>
<calcPSNR type="bool">true</calcPSNR>

[Sirber]

encoderComplexity @100 works?

[iwod]

Originally posted by Sirber
encoderComplexity @100 works?

I think so........ But karl said that the quality improvement may be so neligble that it is not worth wasting time on it.

I think it is a bit like improving the image quality >0.5% but adding another 50% time ( that is compare to EHQ @ 80 to encode )

However, i really don't mind to secrifice time. Because i will normally encode overnight........

@ Karl..... what is the highest complexity??

[karl_lillevold]

@all: 90 is the highest encoderComplexity, so for now, 100=90. 90 is ever so slightly better than 80, and takes perhaps 20-25% longer. You can do your own tests of course, but the difference in quality between 80 and 90 is pretty minimal.

I also want to add an even more complex mode, but that will take some time, and 100 should be reserved for this.

@Sagittaire: I have rarely seen patternAdaptivity=0 provide the best results, unless it's very very complex and fast motion. What type of sequence is this? For slow motion, adaptive (or even 3) is highly recommended. With adaptive, when there is slow motion, 3 will be chosen most of the time anyway.

[slavickas]

@Karl
scalingFactor=199 should double quantizer?

[karl_lillevold]

@slavickas: kind of :) It doubles the internal floating point representation of one form of the quantizer, but the Q number printed in the rv9log.txt does not correspond directly to this representation. 199 does however result in the lowest possible bit usage on discardable frames, while 0 corresponds to same quality discardable and P frames, which is not usually the best idea.

[Sirber]

I think it would be better to have a setting to specify a multiplier for BF quant like XviD quant.

[karl_lillevold]

it does specify a multiplier, just like you mentioned.

[karl_lillevold]

oops, let me correct myself. just checked my code.

here is the actual pseudo code:
floatQP = prevQP * (1.0 + scalingFactor/100.0)

199 corresponds to ~3X
100 corresponds to ~2X
0 corresponds to ~1X

[Sirber]

ha! :)

That's the info I needed. Thx :D

[karl_lillevold]

I just realized I referred to a scalingFactor fix on another thread, and since this was discussed only via PM with slavickas, I wanted to add the info here in the appropriate thread. This is applicable only of the scalingFactor is used.

slavickas wrote:

i'm doing test with b oops discardable(tm) frames, encoding @ q70
scalefactor=199,
if complexity > 41h then //smells like pascal
i,p quantizer - 11
and b 15,
while encoding at complexity 65they are 10 and 20, so is it normal behavior ar some bug?

This is almost normal with q70 and higher, RV9 can use a higher quantizer and still obtain the same quality, which is why you see 10 and 11 for P frames. However, 20 and 15 for the "d frames" is not normal, it should have been 20 and 21. So I looked into the code, and there is indeed a bug (scalingFactor has not been tested that much, except by very advanced users like yourself). I just fixed it, and now I see
complexity 80: 11,21
complexity 65: 10,20
This should be available in the next Milestone build.

Thanks! If you had not found this, it would have likely gone un-noticed for a long time.

[Atamido]

What is a "d frame"?

[Sirber]

I think he refers to "b frames"

[slavickas]

is scalingfactor fixed in milestone 7 ?

[karl_lillevold]

i thought it would have been, but it turns out the Producer team had branched right before I checked in that fix, and thus did not pick it up. I will post a DLL for those very few who might need it.

[Sirber]

I'd like it :D

[karl_lillevold]

EDIT: Updated link to zip. See this thread (http://forum.doom9.org/showthread.php?s=&threadid=64163) for details.

updated zip to include both improved 2-pass VBR and fast 1st pass (http://www.lillevold.com/files/erv4_xVBR_x1stPass_120203.zip)
This fix is useful only if you use the scaleFactor option. If you do not know what the scaleFactor option is, you do not need this update :)

[TFC]

Originally posted by karl_lillevold
erv4_scaleFactor.zip (http://www.lillevold.com/files/erv4_scaleFactor.zip)
This fix is useful only if you use the scaleFactor option. If you do not know what the scaleFactor option is, you do not need this update :)

Does this fix needed with milestone 7?

[slavickas]

Originally posted by TFC
Does this fix needed with milestone 7?

yes, but it only fixes 1 pass mode :(

[karl_lillevold]

See this comparison (http://www.lillevold.com/files/png/comparison2.png) (750 kbps, cropped)

Finally, like I have been saying for a while, after a lot of feedback from this forum, and suggested test material (low+high action), some 2-pass VBR improvements are almost ready. I found a way to improve the rate control, without too many changes.

The following will be included in the update:

Let VBR be much more variable, and spend more bits in high action, see above examples. This is the most significant change.
Separable 2-pass. This includes the ability to edit 2-pass analysis file, re-start 2nd pass only.
Improved adaptive choice for # of 'd' frames in 2nd pass.
MSL not truncated to 30 seconds.
patternAdaptivity parameter fixed for 2nd pass.

DLL should be available shortly. Would you like to help test :cool:, or should I wait until I have tested much more ?

[bilu]

I don't have the time (or the machine :D ) to help you test, but I'm impressed with the improvement.

A suggestion: now that On2 VP6 is out Doom9 may do another codec comparison soon. Please give some priority to this improvements, I would like to see RV9 improving reputation in the video encoding world :)

Cheers,
Bilu

[bond]

karl:
great that you improved the high motion scenes, thats what i have waited for :)

[Shinobu]

@Karl
I often use the mode 1-pass quality based with real 9 for anime archiving, so will this upgade change anything to the 1-pass quality based mode ?

I'm realy impressed with the improvement, no blur, more accurate details, If only i could test it without wait ^^

++

[Kaiousama]

That's a great news karl!
I'm also using 1 pass ode for anime, having a good 2 pass especially on high motion scenes would be perfect.

I hope these changes will also results in a lesser "segmented edges moving" on high motion scenes, because in my opinion it represents the only very important rv9 bad behaviour.

[HomiE FR]

Karl said:
DLL should be available shortly. Would you like to help test , or should I wait until I have tested much more ?

Of course I wanna test it! :)
If my tests can be of any help, I'd be happy to try these new (and appealing) improvements. That's really great to see developers who listen to their users, thanks for your work Karl you deserve it.

[Sagittaire]

Real VBR for RV9 EHQ ... ;-)

Of course I wanna test it!

Visual, PSNR , SSIM and VQM tests if you want ...

[karl_lillevold]

Thanks for all the encouragement. Just cleaning up the changes, and I am very happy with my own tests so far. If nothing unexpected shows up, I should have something for you to try tomorrow. I am looking forward to the feedback, my own tests indicate the target filesize is met just as before, but that's my main worry with these changes, especially for short clips.

@Shinobu: no change for 1-pass quality.

@Sagittaire: For content with a constant action level, there is probably very little change. For content with low+high action, PSNR during high action will go up significantly, but low action PSNR will suffer a little, but it was previously so high, the visible degradation should be relatively small. The average PSNR may come out about the same.

[karl_lillevold]

I started a new thread (http://forum.doom9.org/showthread.php?s=&threadid=64163) for the 2-pass VBR improvements. Go there to read the details and get the new encoder DLL.