RealVideo 10 'Elysian'

[karl_lillevold]

I think this new RealVideo 10 encoder version includes the most two requested features from this forum, so I am looking forward to some feedback.

Download

EDIT: The latest RealVideo 10 'Elysian' is now included with Helix Producer 10 and the most recent GUIs as well. It is not necessary to download a separate DLL. There is also a new and much improved HFE, compared to the one included with the original Elysian release.

So, download it here: RealVideo 10 'Elysian' Preview. I am tired of making minor adjustments. I know it works. Time for some feedback. I have tested this only with Helix Producer 10 Preview cmd line version. However, it should also work in older Producer versions.
2/19: no change, except compiled w. Intel Compiler for 5-7.5% faster encoding.
2/20: moved to file sharing section on helixcommunity.org.
2/24: added new options to reduce large frames, increase small frames, increase keyframes
03/01: bugfix keyframe interval + new complexity level 30% faster than High, almost same quality

New encoder features

Curve Compression 2-pass rate control

Motivated mostly by doom9's codec comparison and how well XviD maintains constant quality, I decided it was time to implement a new rate control in Realvideo, with no streaming inheritance left-over at all.

This new rate control uses the same "curve compression" principle as XviD, and can achieve constant quality throughout the encode, and very accurate target filesize/bitrate.

Also new is the codec's ability to drop down to zero B frames during high action. Previously it would go down to one. Additionally, the 1st pass now runs at complexity 50, and always without the inloop filter, making the 1st pass faster than ever.

Please note for typical average PSNR comparisons with short clips for medium to low bitrates, there may be a slight loss, even though minimum PSNR is much improved. This is because the high action scenes, even though visually improved, are too expensive in terms of bits/PSNR. Please experiment with the advanced options to reduce high bitrate frames, this will improve average PSNR. However, for pure comparisons of avg PSNR, the previous rate control is probably better. Visually, I like the new rate control. Video is approaching audio in the sense that pure PSNR based comparisons are not matching the human sense preferences.

Full length encodes, like those used in the codec comparison on doom9 can hardly be recognized with this new rate control, during the high action scenes. No screen shots are needed. You can see for yourselves. It also works great for any length clip. The previous 2-pass VBR improvement was just a small step in the right direction. This is the real thing, finally constant quality 2-pass VBR with RealVideo!

Inloop filter

Implemented by my colleague Neelesh, and included in this preview is the ability on the encode side set the quant threshold at which the inloop filter is completely disabled. For high bitrates, this corresponds to another significant quality improvement, with better detail preservation. See the comments in the options below for details. Please be aware that completely disabling the inloop filter for low to medium bitrates is not a good idea, significant visual and PSNR degradation will be the result, so set the threshold wisely. We are specifically interested in feedback on which values you prefer.

New decoder features

High Frequency Emphasis

HFE is included with RealPlayer 10 Gold, currently available from http://www.real.com but not enabled by default. Use reg keys below to enable

Please try out this new feature in the included decoder, developed by Neelesh.

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

Useful values: 0 [off], 1, 2, 3
Recommended: 1

Video codecs employing methods like inloop filter and B-frame interpolation have a tendency to attenuate certain spectral information in the video. For example an inloop filter can smoothen out certain frequencies and B-frame interpolation mode can hurt the high frequencies present in video.

HFE (High Frequency Emphasis) post filter corrects and further enhances the spectral information lost or attenuated in video. Look for subtle improvements in textures/noise in the spatial domain and their temporal continuity.

Visualizations

Another feature by Neelesh:

[HKEY_LOCAL_MACHINE\SOFTWARE\RealNetworks\RV10HFE]
"visualizations"=dword:00000000

Useful values: 0 [off], 1, 2, 3
1: shows one dot to indicate HFE is enabled
2: shows a number of dots to indicate quantizer
3: showtime
Note that HFE needs to be enabled for this to work (strength >= 1). This is because OSD can only be done with a postfilter, i.e. the processed data is not used for future prediction. HFE is a postfilter as opposed to the inloop filter, which makes this possible.

You were asking about tweaking the inloop thresholds using OSD. Remember, an inloop filter than only be changed in the encoder, because encoder and decoder need to match. However, it's indirectly possible, since the OSD will show you the quants of a clip.

HFE on the other hand is a postfilter, and can be adjusted on playback as much as you like.

Etc

GUIs supporting the new features are on the way. Thanks to Sirber, D-C, and zedude for providing valuable feedback.

For those who want to try new options in a GUI now, you can use reg keys, since all the options have corresponding reg keys. There is a sample reg file included in the zip.

Going forward, this new rate control will most likely be hooked up the the previously un-used 'vbrUnconstrainedBitrate' parameter in Producer 10 Gold. The inloop option will be hooked up to 'sharp' with the parameters found to work best.

Why 'Elysian'? Because of Champs Elysées in Paris, the final stage of the Tour de France. Maybe I will add more to this explanation later.

List of encoder options

Here are all the new options, these are included in a sample .rpad. Of course, to use a commented out option, it needs to be commented back in. All these options go in the <codecProperties type="bag"> of the audience:

<!-- New RC options -->

<rcEnableCurveCompression type="bool">true</rcEnableCurveCompression>
<!-- Enables new curve compression based rate control -->
<!-- This disables all other RC modes, MSL and maxBitrate ignored -->
<!-- Still, include maxBitrate and MSL; needed for stream properties -->

<!-- The new RC's goal is constant quality throughout the encode. -->
<!-- It works very well at high bitrates, and is much more accurate than -->
<!-- the old rate control.

<!-- Note that his constant quality is not the best solution for -->
<!-- highest overall or average PSNR. For my sample test clip, -->
<!-- I got a reduction of 0.3 dB average PSNR, but 6.5 dB better -->
<!-- minimum PSNR, corresponding to a huge visual improvement -->
<!-- Other news about this RC, is that it allows 1st pass to be run -->
<!-- at the lowest possible complexity (50), with inloop filter off -->
<!-- This makes the 1st pass run even faster than before -->

<!-- Since the analysis file is the same format as XviD uses it -->
<!-- can be read, plotted, and analyzed with some of the same tools. -->
<!-- External scaler tools can be used as well -->
<!-- New is that with this new RC the 2nd pass can be re-run at -->
<!-- different target bitrates than the 1st pass. -->

<!-- WARNING: This rate control works only in 2-pass mode. -->
<!-- If you enable rcEnableCurveCompression, and run -->
<!-- a 1-pass encode, the encoder will run the 1st pass of -->
<!-- a 2-pass encode, and you will end up with a very large -->
<!-- output file. If you like, you can then run the 2nd -->
<!-- pass separately, using the rcPassNumber option below. -->


<!-- <rcSourceFrameRate type="uint">23976</rcSourceFrameRate> -->
<!-- If source != 30fps, this is temporarily needed, due to a bug -->
<!-- in Producer which sends the wrong framerate to the codec, which -->
<!-- needs the framerate to calculate target file size, from bitrate -->
<!-- Note that this param is an integer: fps * 1000 -->

<!-- <rcAnalysisFileName type="string">realvideo.pass</rcAnalysisFileName> -->
<!-- First pass analysis file, ASCII text, same format as XviD -->
<!-- This is possible, since all it contains are: frame types, -->
<!-- quants, MBs, frame sizes, (scalable and un-scalable part) -->
<!-- Can be read by XviD stats analysis tools, like this one : -->
<!-- http://atlas2.tgv.net/~media-video/f...pic.php?t=3594 -->
<!-- http://forum.doom9.org/showthread.php?s=&threadid=67639 -->
<!-- An external scaler would add a last column (desired frame size) -->
<!-- The binary .stats format is not supported -->

<!-- <rcLogFileName type="string">realvideo.log</rcLogFileName> -->
<!-- Rate control log file from 2nd pass -->
<!-- Useful only if problems occur, and for the curious -->

<!-- Advanced options -->
<!-- <rcTargetVideoSize type="uint">585728</rcTargetVideoSize> -->
<!-- Target filesize is kilobytes for /VIDEO ONLY/, over-rides target bitrate -->
<!-- If this option is used, rcSourceFrameRate is not needed -->

<rcKeyFrameBoost type="uint">0</rcKeyFrameBoost>
<!-- Boost keyframes by rcKeyFrameBoost % -->

<rcHighBitrateReduce type="uint">0</rcHighBitrateReduce>
<!-- Reduce larger than average frames by rcHighBitrateReduce % -->
<!-- Usually good for average PSNR, and/or low/medium bitrate -->
<!-- streams, where the largest frames cost too many bits -->
<!-- compared to the PSNR achieved -->

<rcLowBitrateBoost type="uint">0</rcLowBitrateBoost>
<!-- Boost smaller than average frames by rcLowBitrateBoost % -->

<!-- <rcPassNumber type="uint">2</rcPassNumber> -->
<!-- Specify pass # to run, requires cmd line -dt or jobfile -->
<!-- enableTwoPass to 'false'. 2nd pass can be re-run with any -->
<!-- target bitrate changes, other parameters should be the same -->
<!-- When pass #1 is run by itself, Producer will appear to be -->
<!-- encoding normally, and also output a large RMVB, but it will -->
<!-- also output .pass file correctly. -->

<!-- <rcPFrameRefQuant type="uint">6</rcPFrameRefQuant> -->
<!-- <rcBFrameRefQuant type="uint">10</rcBFrameRefQuant> -->
<!-- Quantizers to use for the 1st pass reference encoding -->
<!-- Range [0-30] Leave alone unless you know what you are doing -->
<!-- Quants do not correspond to MPEG-4 quants and do not scale -->
<!-- the same way either. -->

<!-- End of new RC options -->

<maxConsecutiveBFrames type="uint">3</maxConsecutiveBFrames>
<!-- Maximum consecutive number of B frames -->
<!-- Leave B frame adaptivity ON, but sets the max number of B frames -->
<!-- Only 3, 1, and 0 are allowed, due to current impl. restriction -->

<!-- Inloop filter options -->
<inloopCutOffQuant type="uint">11</inloopCutOffQuant>
<!-- Inloop filter is turned off below this quant. -->
<!-- Set to 0 to always use inloop (this is the default, but -->
<!-- in reality, the default level is around 8 -->
<!-- Set to 31, to completely disable inloop postfilter -->
<!-- When quant is below the threshold, the encoder will -->
<!-- skip the inloop filter, and put a bit in the bitstream -->
<!-- so the decoder will do the same. Use with caution for -->
<!-- low to medium bitrates. No inloop will lower PSNR as well -->
<!-- These quants do not correspond to MPEG-4 quants! -->

<inloopCutOffCompatible type="bool">false</inloopCutOffCompatible>
<!-- Make bitstream 100% compatible with earlier*) decoders -->
<!-- What this means is that /key/frames will always be inloop -->
<!-- filtered with the default quant threshold. This is a -->
<!-- bug in old decoders, they always inloop filter keyframes. -->
<!-- When set to false, the threshold applies to all frame types. -->
<!-- When an old decoder tries to decode such a bitstream -->
<!-- there will be a very minor decoder mismatch, in most cases -->
<!-- not visible. *: RV8/9/10 decoders prior to RealPlayer 10 Gold -->

<inloopCutOffBUseRefQuant type="bool">true</inloopCutOffBUseRefQuant>
<!-- If true, the threshold to enable the inloop filter -->
<!-- for B frames, will use the reference frame's quant -->
<!-- If false, the B frame's quant is used. -->
<!-- Looking for feedback what works best here -->