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 (http://forum.doom9.org/showthread.php?s=&threadid=75278), compared to the one included with the original Elysian release.

So, download it here: RealVideo 10 'Elysian' Preview (https://helixcommunity.org/beula/download/). 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/forum2/viewtopic.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 -->

[RadicalEd]

Sweeeeeeeeeeeeet :D :D :D
Merry Christmas to you too, Karl.

[damrod]

i will add this new version and the new options to realbatch soon...

[bond]

great to see that you are working on the high-motion treatment, karl :) (and that the opensource communities work helped you with it)

[h9903209]

wow, that's what you mean before saying "waiting for news!" ... ^^

btw, just come up a question, if I use 450 to encode, the resulting file average bitrate becomes say 550, I suppose it's because it "feels" needs that extra bitrate for better quality, right? so comparing with this new rate control, which the resulting file bitrate must be close to 450, then the qualitity would be lower (compare to the previous one with average bitrate 550) though filesize would be smaller, right?

[Sagittaire]

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

Vive Karl, vive la France ... ;-)

[Sirber]

YS RealAnime is on it's way with those new features. May take some days, developping in Delphi is not as fast as developping in VB.

[damrod]

delphi gui is not like vb ;-))

[kamiller42]

Originally posted by Sirber
YS RealAnime is on it's way with those new features. May take some days, developping in Delphi is not as fast as developping in VB.
The IDE is different than VB, but once you learn it, you'll love it. :)

FYI, if you would like something a bit more useful than the component palette, try using CompBAR. Since installing it, I hide the component palette and never use it.

http://www.geocities.com/componentbar/

If you have any questions, I can try to help. You can reach me on Yahoo IM via kylethedelphiguy.

[JaTeMaTec]

Originally posted by kamiller42
The IDE is different than VB, but once you learn it, you'll love it.

Agree (off-topics i quess) - i used VB6 for a looong time, because it was so dooomn easy, but always: slow code, hard to implement system dll's, needed vb runtimes etc...

Once i found Delphi i realized it's Pascal with Windows and i had used pascal for 10 years before (at DOS) - so combining these 2 ideas (vb easyness and pascal knowhow, i chose Delphi. It makes much more faster code and dll's & assembler can be embedded into it easily!

AND : good luck to RealVideo 10 encoder - i like to see it ready ready (twice said hoping for a bugfree fine encoder soon to inherit all kind of containers into it from AAC (MP4) to RA10 and produce good videos for broadcasting, which is one of my hobbies (200 to 300kbps with audio from my 512kbps ADSL upload-line ...)

Peace!

[karl_lillevold]

Originally posted by h9903209
just come up a question, if I use 450 to encode, the resulting file average bitrate becomes say 550, I suppose it's because it "feels" needs that extra bitrate for better quality, right? so comparing with this new rate control, which the resulting file bitrate must be close to 450, then the qualitity would be lower (compare to the previous one with average bitrate 550) though filesize would be smaller, right?
I am not sure I understand your question, but yes, an encoded clip at a bitrate of 450 kbps will have a smaller filesize and lower quality than 550 kbps :) If you are not very concerned about filesize, and you have a short clip, then perhaps the old rate control is just what you need. If you would like very accurate filesize and/or achieve constant quality for the whole clip, low and high action, then this new rate control is just right.

I used the new rate control to encode an important demo, 15 minutes or so of high and low action, categorized as very hard material. The requested parameters were 352x152 @ 800 kbps :p Someone else first used the old rate control, and even at 480x208 the high action scenes looked rather blurry with the old rate control. With the curve compression method the whole clip looked great throughout at 640x272. So it has already gotten some useful mileage.

Oh, while I remember, on another topic:

Previous B frame parameters

Generally these are not needed, especially not with this update, However:
patternAdaptivity: still works, but locks the B frame pattern, i.e. turns off adaptivity. Allow values are 0,1,2,3.
scalingFactor: Works only with previous rate control. Turns off adaptive quant scaling for B frames, and locks the scaling factor.

[h9903209]

just 2 questions:
1. is this new rate control required 2-pass? can 1-pass also use it?
2. can you explain a bit more about what it means by old way being not that "constant quality"? because high action rather blurry so it's not "constant"?

[Sirber]

1) The new RC is 2-pass VBR only.
2) Old RC was tweaked for streaming, so it's not delivering constant quality.

Hopes this helps :D

[karl_lillevold]

How to avoid a large file output for 1st pass separate encoding

Tip: when running the first pass as a separate encoding, Producer does not know about this feature yet, and thinks that it is encoding normally. It will therefore output a large file corresponding to the reference encoding. To avoid this, call the output filename something that ends with .null, for instance filename.rmvb.null Then there will be no file output.

[CruNcher]

Nice finaly the possibility to turning off the Inloop filter :thanks: karl and Neelesh :)

[karl_lillevold]

bond: Yes, as I was trying out the latest XviD myself, I was curious how it managed to keep the quants so constant during the 2nd pass, leading to great quality in the high action parts. So I had to learn the simple and elegant curve compression technique. Now if the GPL had been compatible with the Helix open-source RPSL license, it might have been possible to have used the XviD RC with all its advanced options as an open-source plugin in Helix for anyone to tweak on, but alas, I had to implement it from scratch. The basic technique is not too complicated, but the advanced settings are a little troublesome to get right, and are left out for now. Using a common first pass analysis format is very useful that since the .pass file can then be read by already existing tools, for instance this Java tool:
http://atlas2.tgv.net/~media-video/forum2/viewtopic.php?t=3594
(And this same tool can also plot graphs indicating motion, and frame type distribution. Very nice. EDIT: version 0.40 of this tool had a minor bug where it would not read the realvideo .pass file, but the developer fixed it right after I mentioned it to him. Try it out!)

CruNcher: Agreed, finally: inloop is now an option, it took some time to convince us. First after making the rate control work as well as XviD's I realized there was still something missing. Your low + high action videos continue to be challenging for accurate rate control. For instance, one of my test clips has a profile like this:

http://www.lillevold.com/files/png/bitdist.png

With the new rate control, there is no overspending or filling the MSL buffer, even for this high action towards the end clip.

[damrod]

is this a stable release?

[iwod]

Originally posted by damrod
is this a stable release?

I think it is still a preview. So Rv10 isn't finish yet.

I suppose Now with all this imporvement Rv10 does decerve to its Number up from 9 to 10.

[Sagittaire]

Function of this decoding RV10 key ... strength for In-Loop filtering perhaps ... ???

Windows Registry Editor Version 5.00

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

[karl_lillevold]

@damrod: yes, it is a stable release, but not the final build going into Producer 10 Gold. I do expect only minor tweaks though, nothing in the codec itself. In particular the default inloopCutOff threshold parameters for the 'sharp' setting needs to be found.

@Sagittaire: This is a new postfilter: HFE = High Frequency Emphasis. I will add a short description of it later today. This was my colleague Neelesh' invention. (The inloop filter is not adjustable on the decode side, but its cutoff treshold can be adjusted on the /encode/ side)

[JaTeMaTec]

Originally posted by karl_lillevold
RealVideo 10 'Elysian'.........[/B]

When do you think that the final codec is ready (RealVideo 10) and will it cost something to get to use it when ready?

A bit n00b question, but i have never tested rv much (only the amount of prev. codec, which could be outputted with the free version of Helix Producer - up to 300 kbps...)

The specs seems to be very interesting, so i would like to know "the money case", because i do not have too much it per month and for sure i am not going to buy the next (rv10 capable) Helix Producer commercial version.

Just let me know if you have time to answer or then just leave this as a 'begging comment' :)

Peace!

[karl_lillevold]

JaTeMaTec: Helix Producer from the Helix Community is completely free, and has no limitations. This is a command line encoder. Several GUIs exist for it and are in active development, most of them even bundle this free Helix Producer.

RealProducer 10 on the other hand, the RealNetworks GUI version, comes in a Free and a Plus version. The Free version has some annoying restrictions, like no editing of the pre-defined audiences, but there is no max bitrate I think. Personally, I almost never use the RealNetworks GUI. The command line version + a few easily editable audience files, Avisynth, VirtualDubMod, and the GUIs do more than what I need.

[Sagittaire]

bug with these setting

<rcPFrameRefQuant type="uint">8</rcPFrameRefQuant>
<rcBFrameRefQuant type="uint">12</rcBFrameRefQuant>

Q6 for P and Q10 for B is the defaut setting for first pass and second pass is correct but if the setting is Q8 for P and Q12 for B for exemple the second pass is incorrect. the required bitrate is not respected: P Quantizer is always 8 or 9 and Quantizer B 12, 13 or 14.



122560 8 5672 46.83 73064 38.84 44.57 51683 70
122520 12 500 44.89 17176 38.84 44.57 51671 d 70
122640 8 5716 47.64 63600 38.84 44.57 51675 70
122600 12 1756 45.82 16632 38.84 44.57 51664 d 70
122720 8 4348 48.79 48584 38.84 44.57 51663 70
122680 12 1200 46.79 7992 38.84 44.57 51648 d 70
122800 8 4364 49.64 37440 38.84 44.58 51644 70
122760 12 668 48.04 5808 38.84 44.58 51629 d 70
122880 8 3316 50.88 26536 38.84 44.58 51621 70
122840 12 292 49.29 2488 38.84 44.58 51605 d 70
122960 8 2204 52.05 14632 38.84 44.58 51593 70
122920 12 284 51.43 1368 38.84 44.58 51576 d 70
123000 8 816 54.14 7480 38.84 44.59 51562 70
=======================================================
mes: 64
frd: 1
rda: 1
rdai: 1
hfe: 1
cpu_scal: 100
met: F
TR Q am PSNR Bits MiPSNR AvPSNR AvBits Fr.type
=======================================================
0 8 10896 60.27 4504 60.27 60.27 4504 Key 100
80 9 9328 49.16 23880 49.16 54.72 14192 100
40 13 496 50.15 1496 49.16 53.20 9960 d 100
160 9 10584 48.00 38664 48.00 51.90 17136 100
120 13 1216 47.05 5000 47.05 50.93 14708 d 100
240 9 9308 47.28 42200 47.05 50.32 19290 100
200 13 172 47.91 1392 47.05 49.98 16733 d 100
320 9 9176 47.05 48104 47.05 49.61 20655 100
280 13 280 47.16 2160 47.05 49.34 18600 d 100
400 9 9284 46.39 55184 46.39 49.04 22258 100
360 13 472 46.13 3048 46.13 48.78 20512 d 100
480 9 8928 45.90 62800 45.90 48.54 24036 100
440 14 344 45.74 3152 45.74 48.32 22429 d 100
560 9 8932 45.75 67336 45.74 48.14 25637 100
520 13 492 45.65 4016 45.65 47.97 24195 d 100
600 9 5596 45.73 44848 45.65 47.83 25486 100
640 9 6144 45.70 43720 45.65 47.71 26559 100
680 9 6244 45.61 48824 45.61 47.59 27796 100
720 9 6180 45.45 53384 45.45 47.48 29142 100
760 9 6032 45.37 50656 45.37 47.37 30218 100

[damrod]

la fleche du sagittaire a touche sa cible... ;-)

[karl_lillevold]

Sagittaire: This works for me. Could you please look at the RC log file, and make sure that you have set the rcSourceFrameRate correctly, and what the reported bitrate overflow is at the end?

In general, it should not be necessary to modify those settings though, but I really don't see how changing them by just a little could cause a problem. Are you using any other custom codecProperties?

Also I notice you are running 1st pass at 70. This does not really make any difference. Just leave it at default so it runs at 50.
EDIT: Well, I should say in my tests. Maybe for very short clips (< 1 minute), it's better to run at 1st pass complexity closer to 2nd pass. However, if you find differently, please let us know.

Thanks!

[Sagittaire]

yes ... thanks

<rcTargetVideoSize type="uint">585728</rcTargetVideoSize>
<rcPFrameRefQuant type="uint">8</rcPFrameRefQuant>
<rcBFrameRefQuant type="uint">12</rcBFrameRefQuant>

Thus these three adjustments should be used together ...

[karl_lillevold]

Sagittaire: No, there is no correlation between rcTargetVideoSize and the two RefQuant settings.

<rcTargetVideoSize> overrides the bitrate given in the audience, for video. When rcTargetVideoSize is used, using the right rcSourceFramerate is not necessary. rcSourceFrameRate is necessary only when bitrate is used. This is because the codec needs to calculate the target size for video, and given a bitrate and number of frames, it also needs the framerate. rcSourceFrameRate will go away (be ignored) when Producer fixes the bug where it sends the codec the wrong source framerate.

Adjusting <rcPFrameRefQuant> and <rcBPFrameRefQuant> should not be needed in most cases. EDIT: could be changed if you prefer a different ratio between P and B quantizers.

Summary:

Use normal bitrate setting and correct rcSourceFrameRate or
Use rcTargetVideoSize (for the full filesize, you will then have to take into account the audio size yourself)

[JaTeMaTec]

Originally posted by karl_lillevold
JaTeMaTec: Helix Producer from the Helix Community is completely free, and has no limitations. This is a command line encoder. Several GUIs exist for it and are in active development, most of them even bundle this free Helix Producer.

Thanx a lot for this info, because i was dump enough half a year ago and downloaded the free version of RealNetwork's Helix Producer (GUI free version) and it really did have annoying limitations and i had to hack some time for my registry and hex-edit the main exe and few dll's to get bypassed the limits and was able to make my own higher-level profiles - i do not know whether regediting and hex-coding is a crime, but still - i got my work done 2 months later.

I will DL the free version from Helix Community and try the command-line tools next time (=soon) :)

Thanks once more!

JaTeMaTec

[CruNcher]

hmm Karl would it be possible to implement a live OSD for RV10 into Real Player 10 like the one in ffdshow ? it's hard to tweak without knowing the acctual Quantizer of the Picture you viewing and looking into a logfile is to time dependent. I finished my first tests with high bitrate encodes compression factor 2,5 of Mpeg2 and i have to say without inloop filtering it looks WOW hehe ok now some blocks appear and also in scenes with low motion hmmm but it's still ok and very detailed :) took 12 mins for this 1:30 trailer 640x360 1.78:1.

the audience file i used

<?xml version="1.0" encoding="UTF-8"?>
<audience>
<avgBitrate type="uint">550000</avgBitrate>
<maxBitrate type="uint">2200000</maxBitrate>
<streams>
<stream xsi:type="videoStream">
<pluginName type="string">rn-videocodec-realvideo</pluginName>
<codecName type="string">rv10</codecName>
<encodingType type="string">vbrBitrate</encodingType>
<codecProperties type="bag">
<noisyEdgeFilter type="bool">false</noisyEdgeFilter>
<rcEnableCurveCompression type="bool">true</rcEnableCurveCompression>
<!-- <rcSourceFrameRate type="uint">25000</rcSourceFrameRate> -->
<rcAnalysisFileName type="string">realvideo.pass</rcAnalysisFileName>
<rcLogFileName type="string">realvideo.log</rcLogFileName>
<rcTargetVideoSize type="uint">22323</rcTargetVideoSize>
<!-- <rcPFrameRefQuant type="uint">6</rcPFrameRefQuant> -->
<!-- <rcBFrameRefQuant type="uint">10</rcBFrameRefQuant> -->
<maxConsecutiveBFrames type="uint">3</maxConsecutiveBFrames>
<inloopCutOffQuant type="uint">31</inloopCutOffQuant>
<!-- <inloopCutOffBUseRefQuant type="bool">false</inloopCutOffBUseRefQuant> -->
</codecProperties>
<encodingComplexity type="string">high</encodingComplexity>
<quality type="uint">100</quality>
<maxStartupLatency type="double">60</maxStartupLatency>
<maxFrameRate type="double">25</maxFrameRate>
<maxKeyFrameInterval type="double">10</maxKeyFrameInterval>
<enableLossProtection type="bool">false</enableLossProtection>
</stream>
<stream xsi:type="audioStream">
<pluginName type="string">rn-audiocodec-realaudio</pluginName>
<codecName type="string">cook</codecName>
<codecFlavor type="uint">14</codecFlavor>
<encodingComplexity type="string">high</encodingComplexity>
<streamContext type="bag">
<presentationType type="string">audio-video</presentationType>
<audioMode type="string">voice</audioMode>
</streamContext>
</stream>
</streams>
</audience>

[karl_lillevold]

High Frequency Emphasis

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

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
CruNcher: it is funny you should mention OSD... Another feature by Neelesh:


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

Useful values: 0 [off], 1, 2, 3
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.

[CruNcher]

ok here you can find some pictures that i made for comparsion of Detail Preservation
http://cruncher.mufflastig.com/XviD/extra_details/

1 is Source 2 is RV10 (without inloop) and 3 is XviD with my Extra Details Profile

Size
-------
RV10 = 21.6 mb
XviD = 21.6 mb

Encode Time
------------
RV10 = 10 min
XviD = 6 min

[kilg0r3]

Originally posted by CruNcher
XviD with my Extra Details Profile Might I ask you what it looks like?
Whew, RV9 ...erh ..10 retains quite a lot of fine structures. How long where the source clips?

[Sirber]

NICE!!!!!!!!!!!!! :D :D :D

RV10 is as detailled as the source or XviD :cool:

[Stux]

Originally posted by Sirber
NICE!!!!!!!!!!!!! :D :D :D

RV10 is as detailled as the source or XviD :cool:

Hmmm, i'm not so sure, one thing I am sure though is RV10 is full of really horrible blocks (probably because the loop filter is off)

[Sirber]

there is some blocks in the smoke of pic2, but the rest is #1

[Lekanda]

Originally posted by CruNcher
[B]ok here you can find some pictures that i made for comparsion of Detail Preservation
http://cruncher.mufflastig.com/XviD/extra_details/

Hey Cruncher, your link is dead I think... I cannot reach your pics!

[Sirber]

Works for me, slow but reachable.

[Stux]

Originally posted by Sirber
there is some blocks in the smoke of pic2, but the rest is #1

Am I reading this right?

There are 3 PNGs, and they each contain 3 pictures, the top picture is source, the middle picture is RV10 and the bottom picture is XviD?

If that's the case then the RV10 is full of blocks

In 1.PNG the entire image appears to be made out of blocks (small ones) but they're *everywhere*

In 2.PNG the blue background on the left is composed entirely of blocks, and look at the top of arnies right eyebrow (on the left)

In 3.PNG the background on the right is composed entirely of blocks again, as is her neck, there is some horrible quantization/stairstepping on her shoulder on the right, left lapel has obvious blocks too

Now, I'm not saying XviD doesn't have blocks, but I think its fair to say there are certainly less

I do think her hair is slightly sharper in PNG3 for RV10 though

And XviD has some nasty artifacts where her cheek meets the shadow on her jawline, sortof looks like horizontal hilites 2 pixels high, 16 pixels wide... nasty

So, RV10 might be as detailed as XviD, but imho opinion the overall quality is far worse in these 3 snapshots

(unfortunately I don't have the time for a more indepth analysis ;))

[karl_lillevold]

I never recommended turing the inloop completely off, but we allowed it as an option for instance for HD and mobile devices where there are severe CPU constraints on playback. For instance, I am sure the smoke snapshot mentioned above is a B frame at a relatively high quant.

I think the recommended settings are going to be:
<inloopCutOffQuant type="uint">12</inloopCutOffQuant>
<inloopCutOffCompatible type="bool">false</inloopCutOffCompatible>
<inloopCutOffBUseRefQuant type="bool">true</inloopCutOffBUseRefQuant>


Also, when posting snapshots, it is all about picking the right ones... For instance, see this example (http://www.lillevold.com/files/png/test.png) [600 kbps, both codecs 12.8 MB filesize, cropped from 640x272]. RV10 top, XviD with the Extra Details Profile bottom. (I do not usually post comparisons, this is an exception to illustrate these points).

Of course, you can always argue, do you want the awful blocks, or slighly smoothed out bricks on the background wall? Since this is high motion and not stills like we are looking at here, I much prefer not to be distracted by these blocks. In the high action, there is no chance my eyes are looking at that wall for the tiny instant it is visible. My eyes are drawn to the moving object that is the focus of the scene. Anyway, just felt it necessary with some response to this discussion on blockiness and comparisons.

Finally, I can not reproduce CruNcher's timings. On my 3 GHz P4, for a three minute 640x272 encoding I get:
XviD: 6:59
RV10: 7:34

[Sagittaire]

No HighSpeed first pass for Cruncher perhaps ...

[CruNcher]

I used the basic producer version with the above audience file and it needed 12 min for both passes @ least thats what the end times shown in producer. i think it could be possible that the Preview took some more Cpu cycles damn that then but i cant get the new Priducer Commandline version from the helixcomunity :( And also in this comparsion the frame numbers where chosen randomly and Stux is right the 2nd has a more detailed skin then the XviD one also the other Skin shoot on the 3rd PNG is more detailed only the 1st PNG with the fence in the background is not as much detailed as the XviD one.

[karl_lillevold]

After transitioning helixcommunity.org over to another system, they are having some trouble getting the file sharing section up and running again, which is very unfortunate. I will ask today what the status is. The latest Helix Producer 10 Preview is already included with the latest AutoRV10, I think, and possibly other GUIs. You can always use only producer.exe from those tools.

Re Preview windows: for 640x272 on a fast computer (fast moving previews), since Producer uses no overlay for either preview window, the overhead is pretty bad. I would guess at least 30-40%, but have not measured accurately.

[lilhobo]

i am not getting producer to recognise the new codec...do i need to rename it anything??? i havent run the reg file cuase of the warning :D

noob alert :D

[31 Flavas]

Originally posted by karl_lillevold
Re Preview windows: for 640x272 on a fast computer (fast moving previews), since Producer uses no overlay for either preview window, the overhead is pretty bad. I would guess at least 30-40%, but have not measured accurately. Turning off the video preview will prevent this added time though right?

[Stux]

Originally posted by karl_lillevold
I never recommended turing the inloop completely off, but we allowed it as an option for instance for HD and mobile devices where there are severe CPU constraints on playback. For instance, I am sure the smoke snapshot mentioned above is a B frame at a relatively high quant.


Exactly :), I think the only valid conclusion is that you shouldn't completely turn off the inLoop filter in RV10 (unless you have to)


Of course, you can always argue, do you want the awful blocks, or slighly smoothed out bricks on the background wall? Since this is high motion and not stills like we are looking at here, I much prefer not to be distracted by these blocks. In the high action, there is no chance my eyes are looking at that wall for the tiny instant it is visible. My eyes are drawn to the moving object that is the focus of the scene. Anyway, just felt it necessary with some response to this discussion on blockiness and comparisons.


Thanks :)

I initially glanced at the snapshots and thought "oooh that's interesting... and look at the blocks" and wasn't going to comment, but as the discussion continued felt it necessary to point out that all was not roses :)

That blocky car is the perfect example, severe blocking is a horrible thing

[kilg0r3]

Sorry, I have been away for a while. So please excuse this lame OT question. Whta and where is this xvid extra detail thingy? :o

[Sirber]

dunno either (very surprizing isn't it? :D)

[CruNcher]

I rechecked the Encode Time and also the Video Preview it isn't really the matter with preview 1 minute is lost i know used <firstPassComplexity type="uint">65</firstPassComplexity>

Encode Size
-----------
RV10 = 21.6
XviD = 21.6

Encode Time
------------
RV10 = 10 min
XviD* = 4.40 min /Extra Details Beta4

* 1pass = 22 fps, 2pass = 13 fps

the pictures are updated (look the same tough)

My CPU is a P4 Williamete Core 1.8 GHZ

[karl_lillevold]

lilhobo: Sorry, I don't know. Should not be a problem. With recent Producer versions it should replace erv4.dll in Producer's codecs directory, and drop right in. Are you sure you put it in the right folder and for the right Producer version? What is the error message?

31 Flavas: Turning preview off makes the encoder run faster.

CruNcher: Like I wrote in the first post: " Additionally, the 1st pass now runs at complexity 50, and always without the inloop filter, making the 1st pass faster than ever."

So either remove the firstPassComplexity=65 option, or set it to 50. Also check your registry at HKLM\SOFTWARE\RealNetworks\RV9 to see if anything is left over there. Registry will over-ride everything else. Running at 50 1st pass should shave off another 1-2 minutes off your encode time, but there is still a difference from my timings. I don't know what this is caused by. Make sure your encoderComplexity is 85, and not 100. No need to encode again. :)

[Assault]

@ kilg0r3

I don't know either. I can only guess that CruNcher compiled XviD and optimized it for detail preservation. :D

Assault