RealVideo 10 'Elysian' [Archive]

View Full Version : RealVideo 10 'Elysian'

karl_lillevold

17th February 2004, 04:28

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:



<rcEnableCurveCompression type="bool">true</rcEnableCurveCompression>




















































<rcKeyFrameBoost type="uint">0</rcKeyFrameBoost>


<rcHighBitrateReduce type="uint">0</rcHighBitrateReduce>





<rcLowBitrateBoost type="uint">0</rcLowBitrateBoost>



















<maxConsecutiveBFrames type="uint">3</maxConsecutiveBFrames>





<inloopCutOffQuant type="uint">11</inloopCutOffQuant>










<inloopCutOffCompatible type="bool">false</inloopCutOffCompatible>









<inloopCutOffBUseRefQuant type="bool">true</inloopCutOffBUseRefQuant>

RadicalEd

17th February 2004, 04:44

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

damrod

17th February 2004, 09:48

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

bond

17th February 2004, 10:16

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

h9903209

17th February 2004, 13:00

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

17th February 2004, 13:05

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

17th February 2004, 14:00

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

17th February 2004, 14:53

delphi gui is not like vb ;-))

kamiller42

17th February 2004, 18:20

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

17th February 2004, 19:20

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

17th February 2004, 20:48

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

18th February 2004, 02:29

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

18th February 2004, 02:48

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

18th February 2004, 05:02

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

18th February 2004, 05:12

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

karl_lillevold

18th February 2004, 07:14

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

18th February 2004, 10:38

is this a stable release?

iwod

18th February 2004, 13:49

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

18th February 2004, 14:21

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

18th February 2004, 15:10

@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

18th February 2004, 15:31

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

18th February 2004, 15:42

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

18th February 2004, 16:40

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

18th February 2004, 17:41

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

karl_lillevold

18th February 2004, 18:03

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

18th February 2004, 18:25

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

18th February 2004, 18:36

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

19th February 2004, 00:58

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

19th February 2004, 01:45

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>

<rcAnalysisFileName type="string">realvideo.pass</rcAnalysisFileName>
<rcLogFileName type="string">realvideo.log</rcLogFileName>
<rcTargetVideoSize type="uint">22323</rcTargetVideoSize>


<maxConsecutiveBFrames type="uint">3</maxConsecutiveBFrames>
<inloopCutOffQuant type="uint">31</inloopCutOffQuant>

</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

19th February 2004, 05:00

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

19th February 2004, 05:24

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

19th February 2004, 09:25

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

19th February 2004, 14:07

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

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

Stux

19th February 2004, 14:37

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

19th February 2004, 15:06

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

Lekanda

19th February 2004, 15:13

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

19th February 2004, 15:23

Works for me, slow but reachable.

Stux

19th February 2004, 16:33

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

19th February 2004, 17:53

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

19th February 2004, 17:57

No HighSpeed first pass for Cruncher perhaps ...

CruNcher

19th February 2004, 18:18

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

19th February 2004, 18:45

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

19th February 2004, 19:50

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

19th February 2004, 19:58

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

19th February 2004, 20:32

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

19th February 2004, 20:53

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

19th February 2004, 21:00

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

CruNcher

19th February 2004, 22:40

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

19th February 2004, 22:53

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

19th February 2004, 22:54

@ kilg0r3

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

Assault

Sagittaire

19th February 2004, 23:00

For resume use this reg file for best quality/speed with new RV10

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\RealNetworks\RV9]
"calcPSNR"=dword:00000001
"firstPassComplexity"=dword:00000032
"encoderComplexity"=dword:00000055
"customPacketSize"=dword:00003e80
"rcEnableCurveCompression"=dword:00000001
"rcAnalysisFileName"="realvideo.pass"
"rcAnalysisLogFileName"="realvideo.log"
"rcSourceFrameRate"=dword:00005da8
"maxConsecutiveBFrames"=dword:00000003
"inloopCutOffQuant"=dword:0000000c
"inloopCutOffCompatible"=dword:00000000
"inloopCutOffBUseRefQuant"=dword:00000001

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

karl_lillevold

19th February 2004, 23:08

Sagittaire: Nice summary, but as always: be careful with registry settings. If you forget about them, you're stuck... and will always be encoding with those options forever after. Especially "rcSourceFrameRate"=dword:00005da8. Until a fixed Producer comes out, this has to be the correct framerate for the new rate control to accurately determine target size.

Framerate Decimal Hex
23.976fps = 23976 = "rcSourceFrameRate"=dword:00005da8
25.000fps = 25000 = "rcSourceFrameRate"=dword:000061A8
29.970fps = 29970 = "rcSourceFrameRate"=dword:00007512
30.000fps = 30000 = "rcSourceFrameRate"=dword:00007530

kilg0r3

19th February 2004, 23:19

Besides my ot question above, I'd like to know if there is any benefit for one-pass encodes?

karl_lillevold

20th February 2004, 00:21

Originally posted by kilg0r3
Besides my ot question above, I'd like to know if there is any benefit for one-pass encodes?
No, the new method does not work for 1-pass. If rcEnableCurveCompression is set to true for a 1-pass encode, it runs the 1st pass. If you want to run the 2nd pass by itself using already created .pass file (make sure it's the right one!), then set rcPassNumber to 2, and run a 1-pass encode (option -dt).

Sirber

20th February 2004, 03:19

For some anime, like One Piece, old RC + DropDupe gives better quality.

CruNcher

20th February 2004, 03:28

hmm Karl sorry but i dont get lower with the Encode Time 10 min is the maximum i can reach with this 640x360 clip with RV10

http://cruncher.mufflastig.com/XviD/extra_details/Detail_Preservation/

here are some shoots you can see all three XviD Postfilter Combinations in Comparsion to the inloop filter still for me personaly inloop filter is to agressive in every Scene and i prefer the Deblocking on the Y Plane :) as you can see it doesn't hurts in the Closeups as the inloop filter does so Detail Preservation is constant for every Scene :)

karl_lillevold

20th February 2004, 04:36

Thanks for trying out the new version, CruNcher. Your feedback is appreciated.

I have posted a minor update: erv4.dll compiled with the Intel Compiler (which is normally used when building this DLL, just not for the first version I made available). See first post.

The Intel Compiler generally produces faster code, even though all our core functions are already MMX/SSE/SSE2/SSE3 optimized, because it does a good job inlining code. Thus, the 100 KB size increase in DLL size as well. Still, it's worth it, with 5-7.5% speedup. My quick test this afternoon:

Dimensions: 704 x 272
Frame Rate: 24.000 FPS
Format: I420
Duration: 01:43.958

MSVC : 3min 27sec
ICL : 3min 12sec

Your milage will vary, especially if your input format is not native YV12 or I420, because then the improvement will be watered out by decoding/color converting the source.

I also know how it is possible to increase the speed of the 2nd pass by 15-25%, but I don't know when I will have time to implement it...

P.S. Regarding the new Intel Prescott. Finally hyper-threading has an effect on the encode speed. With Prescott, the encoding speed increases 5% due to SSE3 optimizations, and 20% due to hyper-treading, a total of 25%. Yes, it produces a lot of heat, so don't try (http://www.sudhian.com/showdocs.cfm?aid=494) one of those in a small form-factor XPC, like mine (http://www.lillevold.com/files/cube/index.html).

31 Flavas

20th February 2004, 06:17

Originally posted by karl_lillevold

Yes, it produces a lot of heat, so don't try (http://www.sudhian.com/showdocs.cfm?aid=494) one of those in a small form-factor XPC, like mine (http://www.lillevold.com/files/cube/index.html). Is that heatsink going to be able to cool off your video card enough? I mean it's such a tiny one... :p

I feel like I need a magnifier to see it :)

Nice mod though! :D

damrod

20th February 2004, 07:53

ehq50 for the first pass?? does this etting apply to rv10 "normal" producer ie not elysium version ??

h9903209

20th February 2004, 12:00

Originally posted by Sirber
For some anime, like One Piece, old RC + DropDupe gives better quality.

Could u elaborate a bit why?

Sirber

20th February 2004, 13:17

With the old RC, you can get to higher bitrate (up to max). Using DropDupe, RV10 cut bitrate in slow motion scenes and give more bitrate to the high ones, so the average quality is higher with the old RC on some anime.

[edit]

After reviewing my clips, both are similar. I was refering to the RC + 1BF, instead of RC + 3BF. I'm posting 2 samples. In fact, both are very similar, but the old.rmvb is less blury in the intro (clip), but is also bigger.

Old RC + DD: http://www.webernic.com/sites/sirber/old.rmvb
New RC: http://www.webernic.com/sites/sirber/new.rmvb

31 Flavas

20th February 2004, 15:29

What is needed to get your clips to play in RP10? RP10 tells me it can't find the stuff it needs to playback racp.

h9903209

20th February 2004, 15:34

seems you once said that dropdupe is recommended only when bitrate is <300kb/s, do I remember right? now around 550k still can use it?

btw, both very similar, both 2-pass vbr 85 ehq?

according to my experience, in anime, unless it is really very very high motion, e.g. tornado, 1-pass 65 has no visible difference with 2-pass 85 ehq except filesize... ^^ but if it's this high motion, I wouldn't recompress to rmvb.

and one piece is my most most favorite no.1 anime, I must not recompress it! ^O^

Sirber

20th February 2004, 18:51

I use it sometimes at 450kbps, depends on the anime. Both clip are at 450kbps.

karl_lillevold

20th February 2004, 20:19

Originally posted by 31 Flavas
What is needed to get your clips to play in RP10? RP10 tells me it can't find the stuff it needs to playback racp.
racp = HE-AAC.

Quote from my FAQ in The Real 10 Platform thread (http://forum.doom9.org/showthread.php?s=&threadid=68245):

"Playback problems with HE-AAC in RealPlayer 10
RealPlayer 10 can not currently play back HE-AAC in RM due to two bugs: 1) the AAC renderer plugin does not recognize the 4cc racp for HE-AAC, triggering an auto-update request. Hex-edit to raac is possible. However, then 2) raac.dll will crash, due to another bug. Both bugs have been fixed, and will be included in the Gold release of RealPlayer 10. In the meantime, neither of these bugs affect how Media Player Classic plays back HE-AAC in RM, even when it uses the buggy raac.dll. You need the latest release of MPC: 6.4.7.6 or higher."

-=-

EDIT: Fixed DLLs available:
https://helixcommunity.org/project/showfiles.php?group_id=30
This includes another DLL needed to handle racp (the 4cc code). With both of these DLLs in the right place you should be able to play back racp in RealPlayer 10 Beta.

karl_lillevold

20th February 2004, 20:20

Originally posted by damrod
ehq50 for the first pass?? does this etting apply to rv10 "normal" producer ie not elysium version ??
EHQ 50 for 1st pass is recommended only with the new Curve Compression based 2-pass rate control. For the old 2-pass VBR rate control, EHQ 65 is recommended.

karl_lillevold

20th February 2004, 20:25

Why can sometimes the old 2-pass VBR provide a better results?

From the first post, in the documentation for the rcEnableCurveCompression setting:

The new RC's goal is constant quality throughout the encode.
It works great at high bitrates, and is much more accurate than
the old rate control. For low bitrates, until more advanced
parameters are added, the old rate control, or an external
scaler is recommended. Specifically useful for low bitrates
would have been High bitrate scenes degradation (%) and
Low bitrate scenes improvement (%). These are not yet implemented.

This is because the high action scenes take a too large percentage of the available bit budget, and the low motion scenes are too heavily sacrificed. It will vary from clip to clip. I have not tested the curve compression much with anime and/or low bitrates.

I hope to add the ability to slush bits from high bitrate scenes to low bitrates scenes shortly. This should be useful for low bitrates with this new rate control.

justin

20th February 2004, 20:50

Should the max bitrate still be 2.1x the average bitrate for traditional quality high bitrate / low bitrate?

karl_lillevold

20th February 2004, 21:14

Originally posted by justin
Should the max bitrate still be 2.1x the average bitrate for traditional quality high bitrate / low bitrate?
Please do remember to read all the documentation I provided... I know it's a lot of information, but I tried to make most of it useful. :) Thanks!

Another quote from the 'rcEnableCurveCompression' option:

This disables all other RC modes, MSL and maxBitrate ignored

damrod

20th February 2004, 23:21

filesharing doesn't work on helixcommunauty???

ahhhhhhhh.... calming...

sorry : how can i retrieve the activx dll for rv10 beta ??
i neeed itttttt ;-)
i want to use it in realbatch (an activeX dll in vb6 miam miam :-))
btw it seems i need on only the dlls no? no need to retreive the full producersdk no?

karl_lillevold

20th February 2004, 23:26

I have been told all the binaries should be back up by Monday. Stay calm, take a deep breath ... :) [minor suggestion: please remove that long ahhhh. It really messes up the page formatting ]

damrod

20th February 2004, 23:35

ouffff

i will wait till new week to modify realbatch core encoding...

btw do you know how to retrieve clip duration? do i need to use the dll or can rmeditor give me the data?

Griniaris

21st February 2004, 00:21

Hi there!

I am upgrading my RV10 plugin for DVX to use the new elysian options and I was wondering what the suggested values to be set as default for the following parameters would be?

rcPFrameRefQuant
rcBFrameRefQuant
maxConsecutiveBFrames
inloopCutOffQuant
inloopCutOffCompatible
inloopCutOffBUseRefQuant

Would something like 6/10/3/9/false/false be ok or should I use something else for better results?
The default I think will be to use the old rc but if user chooses to use the new one I would like to have some presets for the not advanced ones.

Thanks

h9903209

21st February 2004, 02:55

Originally posted by karl_lillevold
Why can sometimes the old 2-pass VBR provide a better results?

From the first post, in the documentation for the rcEnableCurveCompression setting:

The new RC's goal is constant quality throughout the encode.
It works great at high bitrates, and is much more accurate than
the old rate control. For low bitrates, until more advanced
parameters are added, the old rate control, or an external
scaler is recommended. Specifically useful for low bitrates
would have been High bitrate scenes degradation (%) and
Low bitrate scenes improvement (%). These are not yet implemented.

This is because the high action scenes take a too large percentage of the available bit budget, and the low motion scenes are too heavily sacrificed. It will vary from clip to clip. I have not tested the curve compression much with anime and/or low bitrates.

I hope to add the ability to slush bits from high bitrate scenes to low bitrates scenes shortly. This should be useful for low bitrates with this new rate control.

Can you tell an example of when is high bitrates and when is low?
e.g. 450kb/s is high or low or medium?

karl_lillevold

21st February 2004, 09:22

Originally posted by damrod
Do you know how to retrieve clip duration? do i need to use the dll or can rmeditor give me the data?
I know it is possible to parse the RM file to find the clip duration. D-C has figured out how to do with his RMVB Analyzer/Shell Extension tool, referenced in the RV9 sticky post. You could always ask him.

rmeditor can give you the duration too, not quite sure what you mean "use the dll"...

karl_lillevold

21st February 2004, 09:25

Originally posted by Griniaris
I am upgrading my RV10 plugin for DVX to use the new elysian options and I was wondering what the suggested values to be set as default for the following parameters would be?
Great! I would suggest to use the numbers provided in the first post (6/10/3/12/false/false). Please, if anyone prefers other settings, let us all know, and for which types of clips/bitrates.

karl_lillevold

21st February 2004, 09:29

Originally posted by h9903209
Can you tell an example of when is high bitrates and when is low?
e.g. 450kb/s is high or low or medium?
that's a very general question. 450 kbps is high for a low resolution clip, but low for a high resolution clip. I would imagine you are asking about a high rez clip, perhaps letterbox, then I would say 450 is low-medium. 'High' probably starts around 650-750 .. but every clip is different, as is everyone's preferences. There is no answer set in stone which RC is always best. I do however plan to include those two parameters to move bits from high action to low action, which will be useful for low-medium bitrates. This seems to be the most requested extra option.

MictXP

21st February 2004, 11:49

Well, I've got an interesting question--
I'm trying to make a large collection of low bitrate movies that can play across a wide variety of machines. RV9 is great, and now I'm trying RV10. It looks amazing! I fit LOTR onto an 815 MB file! It looks very decent -- good enough for my uses.

My problem is with the wide variety of machines thing. I need to have Macs be able to play the content. I think it would work, except the racp error. Is there a solution for Macs that would not make the file unplayable on a PC? I'm going to try the hex edit -- I'll post my results.

justin

21st February 2004, 12:11

k, I might be completely wrong on everything I'm about to say....

I still like the results from the old Real Video 10 build better. Faces on the new one look less detailed and the backgrounds look more detailed. If it was tweaked so that, ok, I see background, mega blur.. oh, a face in the foreground, sharpen.. it would look better.

if this is even possible, but some sort of pigment calculator that sees that if an area is foreground, and skin, then sharpen alot, and anything backround that is blurred is blurred just a tiny bit more, And have The tweaked Xvid quants for motion

damrod

21st February 2004, 12:58

MictXP
LOTR long version?
in which resolution and audio/video bitrate settings?

MictXP

21st February 2004, 14:31

Two Towers, not the extended. Time is 2:59:21
I think it's something like 504x278. I used 633 kbs for overall bitrate, with 96 kbs for audio. I'm not so concerned with quality right now -- I have real DVDs for that. I'm very concerned with size, though, which is why I'm doing these at 500-550 kbs for video. I tried Divx -- sometimes it would work (with Animation usually), while LOTR looked worse than crap. But Real works beautifully for what I'm doing.

Switching racp to raac didn't work :-( And I don't think OSX can read the DLL files too well...If Media Player Classic can play Real content, does that mean I could install some filter codec (possibly ffdshow) to get the Mac player (VLC or Quicktime) to play the RV10 content?

damrod

21st February 2004, 14:41

633kbits for video... i bet you get a very good quality no?

MictXP

21st February 2004, 14:49

It's 633 overall bitrate. Video is 537 I think, audio is 96.
The video is still really good -- much more than I was hoping for. ffdshow didn't work because it's a directshow filter. VLC didn't work either -- not for 10 or 9 contect. Hmm...I don't think Real has released a beta 10 player for OSX either...

So I can encode in RV10 and get the quality but piss of my very few Mac friends, or encode in RV9 and lose a little quality. Or, if anyone else has a fix, I'll try it. Any suggestions?

damrod

21st February 2004, 15:19

make sure you encode in rv9-ehq... maybe its the rv10 tag that cause problems...

Sirber

21st February 2004, 15:29

Use RV9 @ 85 with the RC, nothing else.

hellfred

21st February 2004, 18:04

MPlayer might help, or not. Latest CVS can handel AAC and HE-AAC in the rm container, but on the not x86 processors, the real codecs dlls will not work. I do not know if there is a way to make mplayer use the codecs that come together with the OSX version of the realplayer.
(http://www.real.com/freeplayer/?rppr=d9)
The linux compile of mplayer can make use of both the win32 dlls and the libraries of the linux version of realplayer.

hellfred

karl_lillevold

21st February 2004, 18:10

MictXP (and damrod and Sirber): There is no difference in the bitstream format, whether you choose RV9 or RV10. The Mac player will be able to decode both, but it does not know about our 'rv10 tag', it will simply ignore it, and the video will show as RV9. I suspect there is a problem with the audio track (RealAudio 10). I am not sure about the status of playing back AAC (raac) and HE-AAC (racp) on the Mac. I will ask. Thanks for bringing this up.

Sirber

21st February 2004, 18:22

Never heard Mac could play video with audio at the same time :confused:

karl_lillevold

21st February 2004, 18:35

I was told there should be an updated OSX player with AAC and HE-AAC playback support very very soon.

damrod

21st February 2004, 19:32

so MictXP must try with a file encoded with cook audio codec

MictXP

21st February 2004, 21:31

My mac receives the same error as on a PC without the fixed DLLs -- the racp error. I think it will play content encoded with the Helix Producer as long as I use AutoRV9 and not AutoRV10. I tried that a while ago, though, so maybe producer has changed.

If an updated OSX player is coming out very soon, that's good enough for me. I don't think I have too many friends that use Mac, but it still is something that I think about.

damrod

21st February 2004, 22:42

use cook codec instead of aac ;-)
and you will have normal rv9 files...

MictXP

21st February 2004, 22:49

How do I use the cook codec?

karl_lillevold

21st February 2004, 22:51

MictXP: AutoRV10 has switched to raac and racp "under the hood", i.e. you can not see the name of the codec being used. AutoRV9 uses cook instead. Perhaps it would be nice for AutoRV10 to include the actual codec being used in the drop-down box. I would have certainly liked to see AAC and HE-AAC, these by many recognized as the most efficient codecs today.

GUI developers: I just finished adding three new options to the rate control:

<rcKeyFrameBoost type="uint">0</rcKeyFrameBoost>
<rcHighBitrateReduce type="uint">0</rcHighBitrateReduce>
<rcLowBitrateBoost type="uint">0</rcLowBitrateBoost>

Each parameter takes a number from 0-100. Send me a note if you would like a pre-prelease to help you include these new options. In a few days after I have done some more testing, I should be able to update the publicly available preview with these options as well. We already know this, but I have verified that reducing high bitrate scenes somewhat is good for average PSNR for a clip where some scenes take a large amount of available bits.

MictXP

21st February 2004, 23:04

Is there a way to use RV10 with the cook codec?
I'm thinking that using AutoRV9 with the RV10 producer would work. Would that take advantage of the Elysian features though?

I sound like I know nothing except easy to use GUIs...I'm very familiar with doing a lot of grunt work with Divx and Xvid, but I'm new to the Real platform. I can do grunt work here too, though. I just like GUIs better :D

damrod

21st February 2004, 23:27

not sure since there are three codecs rv9, rv9-ehq and rv10...

rv10 is rv9-ehq + aac but the value-settings for the ehq are different ...

if you have autorv9 with ehq support you will have same quality as rv10
but not elysium feature sorry...

damrod

21st February 2004, 23:28

use last version of autorv9 it has rv9-ehq support and cook codec...

hellfred

22nd February 2004, 09:45

@MictXP:
First, MPlayer is not yet able to play back RV10 content on MaxOSX. Booting a linux port on the Mac and then play the RV10 content is no alternative.
Second, AutoRV10 v1.0b1 used to automatically select cook for stereo audio. I have not tested v1.0b1.1 yet. But nevertheless, you can use both of them and easily make sure that cook is bein used. Just choose your source and run through all tabs swithching the parameters as usual. But after adding the job and before starting to encode check the jobfile that was created by AutoRV10. It usually is c:\AutoRV_Movie.rpjf. This is a ascii file and have a look at the last lines
</stream>
<stream xsi:type="audioStream">
<pluginName type="string">rn-audiocodec-realaudio</pluginName>
<codecName type="string">cook</codecName>
<codecFlavor type="uint">23</codecFlavor>
<streamContext type="bag">
<presentationType type="string">audio-video</presentationType>
<audioMode type="string">music</audioMode>
</streamContext>
</stream>
</streams>
</audience>
</audiences>
</job>

See the codecName line already contains cook, and codecFlavor 23 means stereo@44Kbps. stereo@96Kbps would need a codecFlavor 25
Have a look at the documentation of helixcommunity.org for a full list. (AudienceFile.htm#Audio_Codec_Tables)
I hope that for the second pass, no hew joblile is being created or at least that the audiostream part is not being edited. You can try to use the edit audience button, too, which will be available when adding a job. But always keep in mind, that it is still beta.

hellfred

MictXP

22nd February 2004, 21:27

That worked great. I first tried to edit the file through the Audience button, but that didn't change the .rpjf file at all.
I changed the movie and credit .rpjf to cook and changed the codecflavor to 25 (it was 0). Now the movie is playable on Mac and PC. Thank you!

I encoded Gattaca @ 550 kbs, with 544x280 resolution. Turned out great. I'm very surprised at the quality of this codec vs. divx.

Griniaris

23rd February 2004, 17:45

What are the recommended settings for the keyframe and low motion boosts and high motion reduce? Anyone did any tests? What ranges give the best results? I know it is a bit subjective but I would like to have something like a default value and then the user can change it if he likes to...

Shinobu

24th February 2004, 08:29

Just have le little problem with new rc

if i use
<rcEnableCurveCompression type="bool">false</rcEnableCurveCompression>
it's all right and i can customise all a want i'll be alway ok.
but if i use
<rcEnableCurveCompression type="bool">true</rcEnableCurveCompression>
i canencode but the vidéo i get is unseekable , if i seek >1 min it freeze, if i dont seek, there is no bug at all during the play...

any clues ?

++

karl_lillevold

24th February 2004, 08:41

No, I am afraid I do not know. Seeking takes just a moment for all the encodes I have done with the new RC, and it is quite a few by now. However, the new rate control introduces enough variability in the bitrate that very old players (or old DLLs/registry settings) may have a problem seeking.

I use RealPlayer 10 Beta, with updated decoder DLLs (HFE + inloop), and I use Media Player Classic.

Which player are you using? If codec pack + RealMediaSplitter, then it is most likely a problem with RealMediaSplitter or the codec pack. You should try r1pclean (http://www.lillevold.com/files/r1pclean.zip) and then install RealPlayer 10. You can still use any alternative player you like, but then you know all the codecs and registry are in order.

EDIT: if after making sure everything is up to date, and you still have a problem seeking, please try to arrange for me to get a copy of the problematic rmvb file.

phrentec

24th February 2004, 17:13

I've had several problems and not all of them happened concurrently. I just wondered if anyone else had it or if it is just me because I'm running under a nonadmin account.
1)Sometimes producer(command line with and without elysian dlls) stops at 100% in the first pass and doesn't go on to the 2nd pass
2)producer exceeds the specified bitrate as if it didn't take it into consideration, actual bitrate was like way over a thousand, specified bitrate was 400, and the wierd thing is I had to calculate that bitrate because realone player showed an incorrect bitrate during playback.
3)when I try to stop producer with crtl+c it doesn't stop. I have to sometimes just hit the X to close the commandline. Then I have to use dtdriver and demux the video. It could be because I used "run as" and ran the producer under an admin.
4)I sometimes get this warning when trying to encode an avi. and the avi plays perfectly in windowsmediaplayer. Warning: Neither uncompressed audio or video was available in DirectShow Reader

These are just a few problems I'm running into on this computer. However when testing on a seperate computer it worked perfectly fine.

karl_lillevold

24th February 2004, 18:49

phrentec: This sound very much like a DirectShow problem. As you know, Producer uses DirectShow to read its input files. Perhaps it will give you some insight into what goes wrong if you load the source file into graphedit. It will show you the filters that DirectShow loads. Auto-loading filters like VSFilter and Morgan Stream Switcher are known to cause problems for Producer.

karl_lillevold

24th February 2004, 21:58

rv10_elysian_022404.zip

Available from the Helix Community Binary Downloads (https://helixcommunity.org/beula/download).

<rcKeyFrameBoost type="uint">0</rcKeyFrameBoost>


<rcHighBitrateReduce type="uint">0</rcHighBitrateReduce>





<rcLowBitrateBoost type="uint">0</rcLowBitrateBoost>


Please do not ask me what the best values are. This depends on many factors. In most cases, leave them alone. Or try to find what works best for you. Here is some initial advice: For constant quality and high bitrates, all zeroes are best. For low/medium bitrate and for best average PSNR, try rcHighBitrateReduce 30-80 or so. I have not really found a good use for rcLowBitrateBoost, it tends to increase mostly tiny B frames, which are best left on their own. Maybe some tuning is still needed here.

This update also hooks up video mode 'sharp' to the following inloop options:

<inloopCutOffQuant type="uint">10</inloopCutOffQuant>
<inloopCutOffCompatible type="bool">false</inloopCutOffCompatible>
<inloopCutOffBUseRefQuant type="bool">true</inloopCutOffBUseRefQuant>

Finally, this option did not change, but if you have not tried the new decoder postfilter HFE, please do. At strength 1 it adds a nice improvement in textures/noise in the spatial domain and their temporal continuity.

phrentec

25th February 2004, 00:43

okay I am now trying to encode a vob file(unencrypted). Here is a picture of what graphedit shows
http://www.geocities.com/nvet8/1vob.htm

the error I get in the commandline is here

---edited out---

problem found to be ligos, thanks to Karl
will now try avs script with dvd2avi/ac3

karl_lillevold

25th February 2004, 00:57

I don't know how many times this question comes up... It's also in the FAQ section in the main RV info thread, but I really should improve the answer I put there.

The Ligos MPEG-2 decoder filter is probably not working as input to Producer. Few MPEG-2 decoders do, since they only expect to be used as playback filters. The MPEG-2 decoder from Elecard has been known to work, but as always, the safest method to encode MPEG-2 is DVD2AVI-> .d2v/ac3. Then you can create an Avisynth script, or use one of the GUIs that can do the job for you, for instance AutoRV9/10.

Sagittaire

25th February 2004, 01:24

@ Karl

rcKeyFrameBoost, rcHighBitrateReduce & rcLowBitrateBoost ... ?

You can describe precisely the influance of these new seeting ... please

phrentec

25th February 2004, 13:26

one problem still not solved. the bitrate goes more than two times beyond the average.

karl_lillevold

25th February 2004, 16:27

Originally posted by Sagittaire
rcKeyFrameBoost, rcHighBitrateReduce & rcLowBitrateBoost ... ?
You can describe precisely the influance of these new seeting ... please
I am not sure what more there is to say than what I wrote in the previous post:

rcKeyFrameBoost: adds <n> % to the size of keyframes, where <n> is the rcKeyFrameBoost parameter.

rcHighBitrateReduce: reduces <n> % from the size of frames that are larger than the average for a certain frametype, where <n> is the rcHighBitrateReduce parameter. Applies to P and B frames, not I frames.

rcLowBitrateBoost: adds <n> % to the size of frames that are smaller than the average for a certain frametype, where <n> is the rcLowBitrateBoost parameter. Applies to P and B frames, not I frames.

In all cases, please enable rcLogFileName. You will see a number of columns. First is the size from the 1st pass (Size), then the linearly scaled size that would have been the target for constant quality (Scaled). Then is the column for the scaled size after the parameters above have been applied (AdvSc). After that the column for target sizes after it has been adjusted for the current bitrate overflow (Target). (Actual) is the actual framesize achieved. (Error) is the different between Target and Actual. And finally, the current bitrate buffer overflow (OFlow). Please take a look at how these parameters affect the AdvScale column to understand how they work.

Originally posted by phrentec
one problem still not solved. the bitrate goes more than two times beyond the average.

I am not sure what this means. Are you using the new rate control, and the file ends up at more than twice the bitrate requested? This either sounds like the 1st pass reference file, when the encoder runs in two separate passes, or the rcSourceFrameRate parameter is half of what it should be. In either case, the rate control log file (rcLogFileName) is the key to resolving the problem, and will tell you what the rate control is doing. The last frame should have a overflow of just a few thousand bytes (usually less than 100,000) compared to its calculated target, which will be listed in the beginning of the same file.

If what you mean is that the peak bitrate goes to more than twice the average, this is perfectly normal, like Sirber mentions. I would imagine even higher peaks. The average should come out almost exactly as requested though.

datascab

25th February 2004, 18:26

@ karl

Hi, nice work with the new R-C.

Is this release ok enough for archiving some dvd's yet?

I'm just hanging on so I dont have to use the old method

Thanks

Data

karl_lillevold

25th February 2004, 18:55

datascab: thanks, but credit really goes to the XviD team for showing how it is possible to achieve such constant quality with a completely different method than RealVideo had been using in the past. When I first saw how XviD picked a quantizer (quality level) for the 2nd pass and stuck with with throughout a 2 hour encode, and still reached the target filesize, made me realize it was not possible to continue to hack on the old RealVideo rate control, but that it was time to learn something new :)

Re stability: I do not expect to make any further changes. This should be the method that goes into Producer 10 Gold. All my test encodes and feedback indicate it works well.

datascab

26th February 2004, 00:10

@ Karl...

With regards to real producer gold...

Did the the powers that be decide it would be a good idea for people like us doom9'ers to be able to use use a fully functional real producer with GUI?

Surely it would put real P in the forefront? :)

(Attempt to make the real bosses feel good, lol) :D

Data

phrentec

26th February 2004, 02:37

the bitrate problem I had is now solved. I was encoding just a short 10sec which made the bitrate look like it was going way beyond but now that I encoded the whole video the bitrate came down to the average.

I still have one problem though.
I was trying to encode a quicktime file with 2-pass and producer always fails to go on to the 2nd pass. It reaches up to and just stays put at 100% in the firts pass.

oh yeah and before it hits to producer gold do you thing there will still be time to have a fps, time left/elapsed counter?

feedback:
one thing I notice about the video I encoded is at the initial change of a scene, the first few frames of the new scene are very blurry, and then it gradually becomes sharp. this happens allmost all the time at the beginning of a scene change. So I was wondering how it would be possible to insert a keyframe at the beginning of each scene change?

karl_lillevold

26th February 2004, 03:21

Originally posted by datascab
Did the the powers that be decide it would be a good idea for people like us doom9'ers to be able to use use a fully functional real producer with GUI?
No news on that front, I am afraid. Fortunately there are many really nice 3rd party GUIs.

Originally posted by phrentec
I still have one problem though.
I was trying to encode a quicktime file with 2-pass and producer always fails to go on to the 2nd pass. It reaches up to and just stays put at 100% in the firts pass.

Sorry, I don't know. I almost never encode Quicktime files, and once I needed to, I first converted to AVI. If you can upload the file to me, I can file a bug.

oh yeah and before it hits to producer gold do you thing there will still be time to have a fps, time left/elapsed counter?

No, I am afraid not.

feedback:
one thing I notice about the video I encoded is at the initial change of a scene, the first few frames of the new scene are very blurry, and then it gradually becomes sharp. this happens allmost all the time at the beginning of a scene change. So I was wondering how it would be possible to insert a keyframe at the beginning of each scene change?
This is really an indication something is very wrong. I don't know the bitrate you are using, but this should not happen. The codec already inserts key frames at every scene change. I have seen something like this when someone encoded the 2nd pass with a 1st pass analysis file for another source file. Perhaps if you are encoding directly from .vob (not recommended, and if you do, anything can happen), the MPEG-2 DirectShow filter is in some kind of real-time mode, and skips frames such that the codec does not see the same frames in the 2nd pass and the 1st pass.

phrentec

26th February 2004, 03:43

where can I upload my quicktime file to(it is around 1mb).

When I ecoded the video(.vob) I loaded it into dvd2avi and saved the project and then through this avisynth script I encoded the video with producer.

LoadPlugin("C:\producer\soft\decodefix100\MPEG2Dec3dg.dll")
video=mpeg2source("C:\Documents and Settings\All Users\Documents\2\2.d2v")
audio=wavsource("C:\Documents and Settings\All Users\Documents\2\2 AC3 T01 2_0ch 384Kbps 48KHz.wav")
ConvertToYV12(audiodub(video,audio))
Crop(00,94,720,300)

karl_lillevold

26th February 2004, 04:17

phrentec: I'll PM you the upload URL.

Your MPEG-2 encoding method appears to be just the way it should be. Could you also upload your encoded file, with the blurry frames, including the 1st pass file (.pass) and the 2nd pass log file (rcLogFile parameter). Thanks.

SometimesWarrior

26th February 2004, 23:52

Hi Karl, I have a couple of questions.

1) When making changes to the new bitrate boost and reduction parameters, do I need to re-encode the first pass with every change, or can I simply redo the second pass?

2) By setting inloopCutOffQuant to 0, am I turning the filtering on permanently, or am I allowing the encoder to decide when to activate it (the way it did before Elysian)? Does the encoder then apply the filtering adaptively (per-frame), does it decide on a cutoff quant at the start (lower or higher depending on bitrate), or is it hard-coded (cutoff at 8, for example)?

phrentec

27th February 2004, 02:50

a little off topic but how do I merge two elysianProducer encoded rmvb files into just one rmvb file. I have tried one shareware tool for this and it didn't work. I was wondering if there were any freeware alternatives. Thanks.

Sirber

27th February 2004, 03:17

what about cmdline rmeditor?

phrentec

27th February 2004, 03:33

ok that will work.

another question. How do determine the colorspace that my avs script is outputing to. and if I use the ConvertToYV12, is that converting my dvd to rgb and then to yv12? what is the most effecient way to reach yv12 colorspace without loss of quality. thanks. and also after installing karls' yv12 codecs I still don't see it being used in graphedit. DOes that have to do with the merit? thanks.

karl_lillevold

27th February 2004, 03:48

Originally posted by SometimesWarrior
Hi Karl, I have a couple of questions.

1) When making changes to the new bitrate boost and reduction parameters, do I need to re-encode the first pass with every change, or can I simply redo the second pass?

2) By setting inloopCutOffQuant to 0, am I turning the filtering on permanently, or am I allowing the encoder to decide when to activate it (the way it did before Elysian)? Does the encoder then apply the filtering adaptively (per-frame), does it decide on a cutoff quant at the start (lower or higher depending on bitrate), or is it hard-coded (cutoff at 8, for example)?

1) The only parameter that has an effect during the 1st pass is maxConsecutiveBFrames. This has no effect during the 2nd pass, because the frame types will be forced to the same in the 2nd pass.

You can repeat the 2nd pass as many times as you like using the same 1st pass file, and change all the other options, including bitrate boost and reduction, inloop options, target filesize/bitrate etc.

2) setting it to 0 results in the codec operating normally, i.e. adaptively, where the effective threshold is somewhere around 8, at which it starts to do a little filtering, but very limited, and depending on the video content.

Originally posted by phrentec
How do determine the colorspace that my avs script is outputing to. and if I use the ConvertToYV12, is that converting my dvd to rgb and then to yv12? what is the most effecient way to reach yv12 colorspace without loss of quality. thanks. and also after installing karls' yv12 codecs I still don't see it being used in graphedit. DOes that have to do with the merit? thanks.
If you use the right mpeg2dec in Avisynth it will output to YV12 directly. There is no need to ConvertToYV12.

My YV12/I420 codecs are VfW (Video for Windows). In DirectShow they are loaded via AVI Decompressor, and graphedit does not show which VfW codec gets loaded. Media Player Classic does though (Play -> Filters -> AVI Decompressor (YV12).

SometimesWarrior

27th February 2004, 04:33

Thanks for the reply, Karl, that will save me some time when testing various parameters. I'll post my results when I've found an easy way to do double-blind comparisons between encodes. Coming from Hydrogenaudio, where listening tests are flamed unless possible sources of bias are throughly eliminated, I'm sometimes surprised by what passes for "testing" on this forum... :rolleyes:

What video lengths are appropriate for testing the rate-control mechanisms? Right now, I'm simply re-encoding the entire 2-hour movie each time I change the bitrate boost or reduction. Would a 30-minute or 10-minute segment be just as effective for testing purposes, or does Elysian really shine only on full-length videos?

karl_lillevold

27th February 2004, 20:37

I can not answer which clips will work best for double blind comparisons, but during development and testing of the new rate control, I would never have finished if I were to use 2 hour test videos.

In fact, I was using an 8min test clip I constructed from several segments of one of my favorite sources; first 3 minutes of low motion, then 2 minutes of the most intense action, finally 3 minutes of mixed action. This I resized down and saved as YV12 to speed up encoding even further, down to just about one minute for both passes in low complexity mode.

The new rate contol works really well on anything a few minutes long, that has varying action, with some very complex and lengthy scenes. However, the shorter the total length, the closer the new and old rate control will work. The old rate control started having problems when high activity lasted for relatively long periods.

My most used test video:
mpeg2source("source.d2v")
crop(0,60,718,356)
#BicubicResize(640,272,0,0.5)
LanczosResize(320,136)
a = Trim(106926, 111368)
b = Trim(147000, 152074)
c = Trim(178310, 180905)
v = a+b+c
return v

For the bit distribution illustrated with the stats viewer on the 1st page of this thread, I had another test clip, half almost no motion, half the highest motion you can imagine. This was only 3 minutes total length.

Griniaris

1st March 2004, 12:10

I have a problem when using the new elysian rc.

Files are produced ok and look good enough but seeking in them is sometimes very very slow...
This does not happen with all the positions in the file. If I click to seek to time 'x' seeking might only take a few msecs but if I click to seek to time 'y' seeking might take a few secs. Maybe it is because I do not have realplayer installed but I use MPC instead but I never had any problems before... Until now I had MPC and drvc.dll in the same folder and all video files were working fine. I replaced the dll with the new one but seeking is still slow. Will my problem be solved if I install RealPlayer or could it be something else? Does it have anything to do with seeking near keyframes or away from one? I remember reading something similar a few days ago but I do not know if it was somehow solved.

Thanks,
Chris

Sirber

1st March 2004, 14:08

It's simply a bug. Sometime producer don't use keyframe, so seeking is slow or impossible :). Redownload the lastest DLL.

Griniaris

1st March 2004, 16:46

Which dll do you mean?

I have allready downloaded and used the latest "elysian" 24/02 release. Do I need to update another dll too? Maybe you mean to redownload the full producer command line package?

Sirber

1st March 2004, 18:15

nope, the lastest Elysian DLL.

karl_lillevold

1st March 2004, 18:26

Based on the problem reported by Shinobu, I found that I had bypassed too much of the old rate control, and the key frame interval was ignored. Thus, for sections where the codec does not auto-insert key frames based on the video content, for instance credits, or certain anime, it will be hard to seek.

I have fixed the problem, and sent Sirber and Shinobu a fixed DLL. Sirber, you are too early. It is not yet available, should be later today. It also has a new CPU scalability level.

Sirber

1st March 2004, 18:35

Sorry, my mistake :)

karl_lillevold

2nd March 2004, 00:06

https://helixcommunity.org/beula/download/

030104:

Fixed bug, where max key frame interval
was ignored.

Added new encoder complexity level, which is almost
the same quality as High, but 30% faster. Made
Medium 30% faster as well. So we now have the following
levels:

100: Very High (95-100)
90 : High (85-94) ** Recommended
80 : Medium-High (78-84) ** 2nd Recommended
70 : Medium (70-77)
60 : Low (60-69)
50 : Very Low (50-59)

The numbers on paranthesis indicate the actual range
which the codec interprets to mean the same. The range
is needed for Live encoding.

The bold lines correspond to the modes available with the command line switch -eco, and the encodingComplexity mode parameter, via 'low', 'medium', or 'high'.

karl_lillevold

2nd March 2004, 00:10

Thanks especially to Shinobu for noticing the seeking problem in files created with this new rate control, and for him taking the time to carefully reproduce the problem, make log files for me to examine, as well as verify the problem to be fixed.

Griniaris

2nd March 2004, 00:24

Thanks a lot for this fix!

I just got it and will test tonight...

Chris

phrentec

2nd March 2004, 01:44

<encoderComplexity type="string">high</encoderComplexity>

<encodingComplexity type="string">high</encodingComplexity>

I tried both of those and producer.log still says

PID696,Informational,Command Line,2004/03/01 16:41:44,10529,Preparing to encode file "C:\1.avs" to file "C:\producer\encode.rmvb"
PID696,Informational,SDK Encoding,2004/03/01 16:41:44,15000,Starting encode
PID696,Informational,SDK Encoding,2004/03/01 16:41:44,15004,Starting analysis pass
PID696,Error,Video Codec,2004/03/01 16:41:44,0,Failed to Set Property: Key encodingComplexity Value high
PID696,Error,Video Codec,2004/03/01 16:41:44,0,Failed to initialize video codec 04VR
PID696,Error,SDK Encoding,2004/03/01 16:41:44,15001,Job failed to start encoding
PID696,Error,Command Line,2004/03/01 16:41:44,10532,Encoding failed!

karl_lillevold

2nd March 2004, 01:59

encoderComplexity, uint goes inside codecProperties:

<videoStream>
<pluginName type="string">rn-videocodec-realvideo</pluginName>
<codecName type="string">rv10</codecName>
...
<codecProperties type="bag">
<encoderComplexity type="uint">90</encoderComplexity>
</codecProperties>
...
<encodingType type="string">vbrBitrate</encodingType>
</videoStream>

encodingComplexity, string (low, medium, high), goes outside:

<videoStream>
<pluginName type="string">rn-videocodec-realvideo</pluginName>
<codecName type="string">rv10</codecName>
...
<encodingComplexity type="string">high</encodingComplexity>
...
<encodingType type="string">vbrBitrate</encodingType>
</videoStream>

encoderComplexity over-rides encodingComplexity, and allows setting of more levels. Hope this helps.

ookzDVD

2nd March 2004, 02:10

@karl,

I don't know what is wrong, my machine is getting slower or the RV10.

but I'm experiencing that RV10 is very2 slow on my machine,
for 2.30 minutes clip, res 640x344, i have to wait about 30 minutes. :(

[edit]I'll try the latest update. I hope it will be faster :)

phrentec

2nd March 2004, 02:49

Thanks for the reply.

So to experience the new 30% faster encoder complexity level, which tags (encodercomplexity or encodingcomplexity) would I use and at what value(ie high, veryhigh, very high, very-high, 80, 90, 100, 85?).

Sorry for any confusion that i've caused myself.

karl_lillevold

2nd March 2004, 03:03

Sorry for the confusion: the new mode, "medium-high", is available only with encoderComplexity, uint, at 80. The "official" encodingComplexity parameter that also corresponds to the -eco command line switch, supports only low, medium, high.

I edited the post above to indicate which modes are available via this Producer codec agnostic interface.

Griniaris

2nd March 2004, 23:08

I used the latest dll last night and everything seems to work fine now! The file is seekable to all times and looks great. Thanks for that!

phrentec

3rd March 2004, 00:00

How do I force producer to use directshow to open up quicktime files, as opposed to the default quicktime opener in producer? Or there there a way to add a switch like that?

karl_lillevold

3rd March 2004, 18:46

ookzDVD: Hope you figured out the problem. I can not think of any change I made to make encoding slower. There have been some cases, where GUIs or codec interface changes accidentally resulted in the wrong encoding complexity level being chosen though. As always, rv9log.txt will show you the encoding complexity the codec is actually using.

pthrentec: that's easy.. Just go to the tools folder, move qtreader.dll into a backup folder. I just tried it, and it works.

without qtreader.dll (options -lc e,d):
"Input File Properties from rn-avfile-directshow"

with qtreader.dll:
"Input File Properties from rn-avfile-qt"

Big_Berny

3rd March 2004, 20:50

Hi,
is it possible to activate the old rate-controle? Because I think that it worked better on lowbitrates. Perhaps it would be good, that it uses automaticaly the old rate-controle if you use a low bitrate, what do you mean?

EDIT: Sorry, I only tested with a short clip. I'll try a longer one.

Big_Berny

Sirber

3rd March 2004, 21:01

If you want to use the old RC, just *NOT* enable the new one :p

karl_lillevold

3rd March 2004, 21:45

For very low bitrates, constant quality is not the best option, since too many bits are spent for the high complexity scenes, and low motion scenes pay too much in terms of having too low bitrate. At least use the rcHighBitrateReduce parameter, I found that average PSNR increased with this parameter even as high as 80.

Sirber is right though, if you do not specifically enable the new RC, everything will be as before. However, be aware that the old RC for very short clips and VBR would sometimes end up with a much higher bitrate than you asked for, due to its use of the MSL buffer. The new RC should be very accurate down to very short clips, and perhaps you ended up with a lower bitrate than with the old RC...

Big_Berny

3rd March 2004, 22:01

I'll do a test on a simpsons episode:
I choose a resolution of 384x288 and it's about 22 minutes long.

Do you think that on these conditions the new ratecontrole is better?

Big_Berny

Caddis

4th March 2004, 02:24

@Karl or D-C

I seem to be having getting a constant error when using Autorv10.
It allways come up to do with racp.dll. I have all the updates for Real10 and am using the latest Autorv10 exe. I can't figure out what it is. I've read everything I can find on this too.

I'll post the error from the cmd. line window.

Diagnostic: "C:\DivX\AUTORV~1.0_B\Softs\RP9_LI~1\producer.exe -j E:\DivX_VOB\Movie.rpjf -daw -lc e,d" command line being run
Helix DNA(TM) Producer 10.0 Preview Build number: 10.0.0.74
Diagnostic: --------- Input File Properties from rn-avfile-directshow
Diagnostic: Input Filename: E:\DivX_VOB\Movie.avs
Diagnostic: File Size: 1KB
Diagnostic: Total Duration: 01:51:35.821
Diagnostic: Video Track
Diagnostic: Dimensions: 640 x 276
Diagnostic: Frame Rate: 23.976 FPS
Diagnostic: Format: YV12
Diagnostic: Duration: 01:51:35.821
Diagnostic: Audio Track
Diagnostic: Channels: Stereo
Diagnostic: Bit Depth: 16
Diagnostic: SampleRate: 44100 Hz
Diagnostic: Format: Uncompressed Audio
Diagnostic: Duration: 01:51:35.821
Diagnostic: --------- End Input File Properties
Diagnostic: Load Level Headings: Reference Time, Stream Time, Delay, Inte
rval Load, Average Interval Load, Processing Load, Stream Interval, Reference In
terval, Accrued Delay, Average Delay, Load Level
Diagnostic: Using AutoRV9 Audience File Audience
Diagnostic: Using video codec: rv10 (772000 bps)
Diagnostic: Using audio codec: racp (96000 bps)
Diagnostic: Setting video packet size to 15000
Encoding: 4:08.2/1:51:35.9 ( 3%) Errors: 0 Warnings: 0

***************************************************
2004/03/01 16:49:48
Exception code: C0000005
Fault address: 60A57817 01:00056817 C:\DivX\AUTORV~1.0_B\Softs\RP9_LI~1\codecs\racp.dll

Call stack:
Address Frame Logical addr Module
60A57817 00000001 0001:00056817 C:\DivX\AUTORV~1.0_B\Softs\RP9_LI~1\codecs\racp.dll

***************************************************
2004/03/01 16:49:48
Exception code: C0000005
Fault address: 004015F7 01:000005F7 C:\DivX\AUTORV~1.0_B\Softs\RP9_LI~1\producer.exe

Call stack:
Address Frame Logical addr Module
004015F7 053B29AC 0001:000005F7 C:\DivX\AUTORV~1.0_B\Softs\RP9_LI~1\producer.exe
00401952 053B2B24 0001:00000952 C:\DivX\AUTORV~1.0_B\Softs\RP9_LI~1\producer.exe
620090DE 053B305C 0001:000080DE C:\DivX\AUTORV~1.0_B\Softs\RP9_LI~1\PNCRT.dll
77E9D702 053BFFEC 0001:0003C702 C:\WINDOWS\system32\kernel32.dll
***************************************************

Sirber

4th March 2004, 02:44

Looks like a nice bug :D

Can you post your AVS and your jobfile?

karl_lillevold

4th March 2004, 02:50

Big_Berny: Sorry, I do not know the general answer. It depends... on bitrate, and your own preferences for variation in quality in low and high motion scenes.

Caddis: That does look like a nice bug. Unfortunately I have not worked on the wrapper code for the HE-AAC encoder, but I have asked what kind of information would be most useful, and will let you know. I don't really need job file or avs file, I think, since I know how those generally are generated by AutoRV10.

Sirber

4th March 2004, 03:00

Originally posted by karl_lillevold
I don't really need job file or avs file, I think, since I know how those generally are generated by AutoRV10. At least it's some infos to look at :)

Caddis

4th March 2004, 06:39

I'll post what I think you want.... .rpij and .avs

<?xml version="1.0" encoding="UTF-8"?>
<job xmlns="http://ns.real.com/tools/job.2.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<enableTwoPass type="bool">false</enableTwoPass>
<clipInfo>
<entry>
<name>Created with</name>
<value type="string">AutoRV9 (www.video-tools.com)</value>
</entry>
</clipInfo>
<input xsi:type="avFileInput">
<filename type="string">E:\Movie.avs</filename>
</input>
<parOutputs>
<output>
<destinations>
<destination xsi:type="fileDestination">
<filename type="string">E:\Movie.rmvb</filename>
</destination>
</destinations>
<mediaProfile>
<audioMode type="string">music</audioMode>
<disableAudio type="bool">false</disableAudio>
<disableVideo type="bool">false</disableVideo>
<videoMode type="string">sharp</videoMode>
<audienceRefs>
<audienceRef>AutoRV9 Audience File</audienceRef>
</audienceRefs>
</mediaProfile>
</output>
</parOutputs>
<audiences>
<audience>
<avgBitrate type="uint">1052000</avgBitrate>
<maxBitrate type="uint">5030000</maxBitrate>
<name type="string">AutoRV9 Audience File</name>
<streams>
<stream xsi:type="videoStream">
<pluginName type="string">rn-videocodec-realvideo</pluginName>
<codecName type="string">rv10</codecName>
<codecProperties type="bag">
<encoderComplexity type="uint">85</encoderComplexity>
<noisyEdgeFilter type="bool">false</noisyEdgeFilter>
<calcPSNR type="bool">true</calcPSNR>
<maxConsecutiveBFrames type="uint">3</maxConsecutiveBFrames>
<rcEnableCurveCompression type="bool">true</rcEnableCurveCompression>
<rcAnalysisFileName type="string">C:\realvideo.pass</rcAnalysisFileName>
<rcTargetVideoSize type="uint">1280737</rcTargetVideoSize>
<rcPassNumber type="uint">2</rcPassNumber>
<rcLogFileName type="string">c:\realvideo.log</rcLogFileName>
<rcKeyFrameBoost type="uint">0</rcKeyFrameBoost>
<rcHighBitrateReduce type="uint">0</rcHighBitrateReduce>
<rcLowBitrateBoost type="uint">0</rcLowBitrateBoost>
<rcPFrameRefQuant type="uint">6</rcPFrameRefQuant>
<rcBFrameRefQuant type="uint">10</rcBFrameRefQuant>
<inloopCutOffQuant type="uint">11</inloopCutOffQuant>
<inloopCutOffCompatible type="bool">false</inloopCutOffCompatible>
<inloopCutOffBUseRefQuant type="bool">true</inloopCutOffBUseRefQuant>
<customPacketSize type="uint">16000</customPacketSize>
</codecProperties>
<encodingType type="string">vbrBitrate</encodingType>
<quality type="uint">1</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">racp</codecName>
<codecFlavor type="uint">1</codecFlavor>
<streamContext type="bag">
<presentationType type="string">audio-video</presentationType>
<audioMode type="string">music</audioMode>
</streamContext>
</stream>
</streams>
</audience>
</audiences>
</job>

************************************************************
# PLUGINS
LoadPlugin("C:\DivX\AUTORV~1.0_B\SOFTS\AVSFILE\MPEG2DEC3.DLL")
#
# VIDEO SOURCE
Video=Mpeg2Source("E:\movie.d2v")
#
# AUDIO SOURCE
Audio = WavSource("E:\movie\Stream1.wav")
#
# COMBINE VIDEO + AUDIO
Video=AudioDub(Video,Audio)
#
# TRIM MOVIE
Video=Trim(Video,0,276185)
#
# CROPPING
Video=Crop(Video,12,88, -14, -90)
#
# RESIZING
Video=LanczosResize(Video,640,252)
#
# LIMIT Chroma & Luma Value
Video=Limiter(Video)
#
# FINISH
Return(Video)

phrentec

4th March 2004, 13:42

I don't want to use B frames at all. So do I use

<maxConsecutiveBFrames type="uint">0</maxConsecutiveBFrames>

to disable B frames. or maybe I don't even need to use the tags. ?

Sirber

4th March 2004, 13:45

<maxConsecutiveBFrames type="uint">0</maxConsecutiveBFrames> will use 0 BF. What is your bitrate?

phrentec

4th March 2004, 14:10

Sirber:I am encoding some training videos that go at 5fps and at a bitrate around 150kbps.

Karl: When I move qtreader.dll out of the tools folder, so that producer doesn't use it to read mov files, producer just crashes. And it doesn't even output anything in the log file.

btw, I still haven't gotten around that problem where producer hangs at 100% in the first pass of encoding mov file, and I later found that I can play quicktime files in windowsmediaplayer(WMP) and graphedit and so that is why I wanted producer to use directshow to open the mov file. Thanks again for your reply.

My batch script

producer.exe -i "c:\producer\e.mov" -vm sharp -arq high -ad "C:\producer\audiences\mov.rpad" -o "C:\producer\mov.rmvb"

and Audience file

<?xml version="1.0"?>
<audience>
<avgBitrate type="uint">157000</avgBitrate>
<maxBitrate type="uint">1300000</maxBitrate>
<streams>
<videoStream>
<pluginName type="string">rn-videocodec-realvideo</pluginName>
<codecName type="string">rv10</codecName>
<codecProperties type="bag">
<encoderComplexity type="uint">80</encoderComplexity>
<rcSourceFrameRate type="uint">5000</rcSourceFrameRate>
<rcKeyFrameBoost type="uint">10</rcKeyFrameBoost>
<rcHighBitrateReduce type="uint">80</rcHighBitrateReduce>
<inloopCutOffCompatible type="bool">false</inloopCutOffCompatible>
</codecProperties>
<encodingType type="string">vbrBitrate</encodingType>
<maxFrameRate type="double">5</maxFrameRate>
<maxKeyFrameInterval type="double">10</maxKeyFrameInterval>
<enableLossProtection type="bool">false</enableLossProtection>
<maxStartupLatency type="double">60</maxStartupLatency>
</videoStream>
<audioStream>
<pluginName type="string">rn-audiocodec-realaudio</pluginName>
<codecName type="string">cook</codecName>
<codecFlavor type="uint">2</codecFlavor>
<streamContext type="bag">
<presentationType type="string">audio-video</presentationType>
<audioMode type="string">music</audioMode>
</streamContext>
</audioStream>
</streams>
</audience>

karl_lillevold

4th March 2004, 19:02

There is a new Producer command line version available:
10.0.0.195 Command Line App (Beta) (https://helixcommunity.org/beula/download/)
This includes a recent version of the new rate control, but the RV10 encoder DLL has the bug which ignored the max keyframe interval, so the latest Elysian DLL is needed to fix this.

All: This new Beta fixes the framerate problem that forced me to add the rcSourceFrameRate parameter, so from the next release, this option will be ignored. I will not remove it to avoid breaking something, but just ignore it. Another new feature in the Beta is that it is possible to activate the new rate control with encodingType set to vbrUnconstrainedBitrate instead of vbrBitrate. All the advanced parameters have to be set via codecProperties though.

phrentec: the ability to encode QT via Directshow seems clip dependent. I can not get it to work for your problem clip, even though it worked for another .mov. Could you please try the latest Producer mentioned above? If it still freezes at the end of pass 1, please create an empty file called debug.txt in Producer's directory. First delete producer.log, then run with options -lc w,i,d,e, and send me producer.log via e-mail or PM. Thanks.

karl_lillevold

4th March 2004, 19:19

phrentec: I just tried your exact audience, and realized there are a couple of problems. For your very special screen capture content you need to disable the codec's RPR (Reference Picture Resampling) functionality, to avoid it resampling the video to a low resolution, which it does for very low bitrates relative to resolution. However, since this is almost static content, you really don't need any higher bitrate even at full resolution.

Also, you had forgotten to enable the new rate control.. So add these two parameters to the codecProperties section:

<rcEnableCurveCompression type="bool">true</rcEnableCurveCompression>
<enableRPR type="bool">false</enableRPR>

EDIT: the codec's use of RPR would probably have caused the blurring you reported earlier.

phrentec

5th March 2004, 09:02

regarding

<enableRPR type="bool">false</enableRPR>

Is that one of the undocumented features/tags that we can use? Are there more like that? Also how can I know if producer actually used the tag and didn't just bypass it?

I also didn't enable the curvecompression because I think I read that it would not help much at low bitrates, or maybe that was referring to shorter clips/encodes. I might have been wrong about that.

The problem(blurring of initial frames of a scene change) that I had reported earlier hasn't occurred scince the first few times that it happened so I haven't been able to recreate the problem in order to further send a report.

Also, can someone please direct me to where Karl talks about how realvideo doesn't postprocess, preprocess, deblock/blur, video during playback/encoding or something similar to that. In the latest version of on2's vp6, it includes a Hightened Sharpness Profile which seems to retain the sharpness/graininess of the source video when encoding even at low lower bitrates. I was wondering if realvideo had something similar to that effect.

eMotionEstimation

5th March 2004, 15:30

congratulations to karl!

just some feedback regarding the new rate control. it works great as does the new complexity level medium-high. i'm getting really amazing quality for bitrates from 400 to 800 kbit at very reasonable speed.

lowBitrateBoost:
also seems to work as expected when comparing in rmvb-analyse. but i've not yet found any clip really profiting from it. (when comparing normal with 50%)

i've registered several month ago and this is my first post. i'm into video coding for several years now (since project majo) and this is the first time i wanted to say how impressed i am.

i've been fiddling around with rv9/10 for several month now and with the introduction of the new rate control i get simply amazing quality for low bitrates (say 400-500 kbits, 2pass "medium-high" + he-aac @ 64 kbit).

in my opinion there's not any video-codec coming close at those bitrates. on2 has also done a good job with vp6 but i dislike the artefact-noise around edges at those bitrates.

all i wanted to say is, rv10 has come along way since ehq first was introduced but i'm heavily impressed what real now is able to do in low bitrate regions.

amazing job karl! keep up the good work and keep the updates coming!

cheers,

eMotionEstimation

EDIT: btw. would someone be so kind to post a listing of all parameters one can change for rv10 through the registry

karl_lillevold

5th March 2004, 15:30

Originally posted by phrentec
Is that one of the undocumented features/tags that we can use? Are there more like that? Also how can I know if producer actually used the tag and didn't just bypass it?

Not any of the custom options in codecProperties are officially documented in any other way than via this forum. The ones that are decided are useful enough for general audiences, will be then moved out of codecProperties, then run through QA and documented. This happened with the original EHQ settings, customPacketSize, and now this new rate control, and the inloop settings.

I think I have explained most of them here, one time or another, even enableRPR. Maybe one day I will make a list of all of them. When I encoded your example, it was as clear as night and day, that RPR was enabled or not. With RPR, the video was so blurry I could not read the text. Without RPR, the video was as sharp as the original.

I also didn't enable the curvecompression because I think I read that it would not help much at low bitrates, or maybe that was referring to shorter clips/encodes. I might have been wrong about that.

OK. I was confused since many of the other rc... options had been left in, and without rcEnableCurveCompression, they are ignored.

Sharpness preservation at low bitrates

You can increase the threshold for the inloop filter, and of course disable RPR.

phrentec

6th March 2004, 16:35

just a side question, what are two ways to comment inside a .bat file?
thanks.

Sirber

6th March 2004, 16:36

Originally posted by phrentec
just a side question, what are two ways to comment inside a .bat file?
thanks. I think it's only REM.

Sirber

6th March 2004, 16:40

Originally posted by karl_lillevold
There is a new Producer command line version available:
10.0.0.195 Command Line App (Beta) (https://helixcommunity.org/beula/download/)
This includes a recent version of the new rate control, but the RV10 encoder DLL has the bug which ignored the max keyframe interval, so the latest Elysian DLL is needed to fix this.What files exactly do I need to fix in this release, about RV10 and HE-AAC?

phrentec

6th March 2004, 18:11

I think I am falling into another bug here. but just to make sure let me ask.

has anyone tried any 1pass vbr encodes recently? And if you have, has the ouput file's bitrate gone way way too far beyond the average bitrate?

Sirber

6th March 2004, 18:46

1-pass VBR is not as acurate as 2-pass VBR. It depnds on the VBR buffer and other stuff.

How long was your source?

hellfred

6th March 2004, 19:39

Originally posted by phrentec
just a side question, what are two ways to comment inside a .bat file?
thanks.
@phrentec
REM Text
:: Text

@Sirber
I think you only have to exchange the erv4.dll in the codecs folder with the one from rv10_elysian_030104.zip. And you have to put a copy of racp.dll into that folder to be able to encode HE-AAC.

helfmir

Sirber

6th March 2004, 20:27

Thanks hellfred :D

Preview 2 of RealAnime supports all new RV10 features. Get a look in my thread (link in my signature).

hubereevez

8th March 2004, 18:40

What files exactly do I need to fix in this release, about RV10 and HE-AAC?
yep!
how ?
thanks

hubhub

karl_lillevold

8th March 2004, 19:01

hmm, let me see what I missed...

eMotionEstimation: Thanks! P.S. Interesting signature..

would someone be so kind to post a listing of all parameters one can change for rv10 through the registry
Yes, I will, since there are quite a few, and their documentation is more or less spread out over many posts. I just need to find a common readable/editable format such I don't have to re-format for both here and our own internal codec group wiki.

phrentec
has anyone tried any 1pass vbr encodes recently? And if you have, has the ouput file's bitrate gone way way too far beyond the average bitrate?
I can not think of what could have changed. If you accidentally run the new rate control with one pass encoding, it will essentially run the first pass, and you will get a very large file, corresponding the the reference quality it uses for the 1st pass.

Sirber
What files exactly do I need to fix in this release?
With the latest cmd line Helix Producer you need:

Download from the Helix Community Binary download section (https://helixcommunity.org/beula/download/)
latest RealVideo 10 'Elysian' bug fix DLL. This also includes decoder improvements that are not available anywhere else.
helixproducersdk_aac_addon_10_beta2_windows.zip from the Helix DNA Producer SDK section, for HE-AAC encoding in Producer. Instructions included.
rmeditor update for raac and racp, if you need to merge files with different bitrate settings, using AAC or HE-AAC codecs.
for HE-AAC playback in RealPlayer 10, you still need RealPlayer 10 Beta HE-AAC (racp) fix

The Helix Producer racp fix is no longer needed.

karl_lillevold

8th March 2004, 23:34

Originally posted by karl_lillevold
Yes, I will, since there are quite a few, and their documentation is more or less spread out over many posts. I just need to find a common readable/editable format such I don't have to re-format for both here and our own internal codec group wiki.
Done. See http://forum.doom9.org/showthread.php?s=&threadid=72321

hellfred

9th March 2004, 15:51

With the latest cmd line Helix Producer you need:

1. Download from the Helix Community Binary download section
2. latest RealVideo 10 'Elysian' bug fix DLL. This also includes decoder improvements that are not available anywhere else.
3. helixproducersdk_aac_addon_10_beta2_windows.zip from the Helix DNA Producer SDK section, for HE-AAC encoding in Producer. Instructions included.
4. rmeditor update for raac and racp, if you need to merge files with different bitrate settings, using AAC or HE-AAC codecs.
5. for HE-AAC playback in RealPlayer 10, you still need RealPlayer 10 Beta HE-AAC (racp) fix

The Helix Producer racp fix is no longer needed.

Hi Karl
After updating the helix producer beta for windows following the steps you have suggested, i ran into problems encoding with racp.
Seems like sampling rate is too low, the sounds are very low and slow.
Switching back to the racp.dll that came with the 10.0.0.72 SDK (Preview) sound is all fine again.
What info shall i provide?
Intel P4 with HT
WindowsXP Home
10.0.0.195 Command Line App (Beta)
Source is a tv capture feed through AviSynth.
For playback i have tryed RealPlayer10 with suggested patch and MediaPlayerClassic.

Hellfred

karl_lillevold

9th March 2004, 17:19

hellfred: thanks for making me aware of this. My colleague who works on the wrapper code for AAC, told me they made a change in how HE-AAC is signalled (the sampling rate). This means you also need an updated player DLL to match this change. I made this available in the same download section (date 030904).
https://helixcommunity.org/beula/download/

What this means is that with these updated DLLs: Previously encoded content plays fine in RealPlayer 10, at least on my system :) Newly encoded content likewise.

EDIT: this update does not appear to affect how HE-AAC in RM plays in Media Player Classic (RealMediaSplitter). I initially had some problems with the new raac.dll (030904, version 10.0.0.218) when used via RMSplitter, but now it works fine. Let me know if you find otherwise.

hellfred

10th March 2004, 19:07

Originally posted by karl_lillevold

EDIT: this update does not appear to affect how HE-AAC in RM plays in Media Player Classic (RealMediaSplitter). I initially had some problems with the new raac.dll (030904, version 10.0.0.218) when used via RMSplitter, but now it works fine. Let me know if you find otherwise.
Same here:
MediaPlayerClassic v6.4.7.6
racp.dll v.6.0.0.440 (from 030904)
After switching Options->Player->Format->Real <Audio/Media/Script> file to RealMedia MPC was able to play back audio (Under overrides i even blocked CoreAAC, too, to be extra sure that raac.dll is used to decode HE-AAC). But screen kept being black.
I had to switch Options->Playback->Output->RealMediaVideo to DirectX7 to see the video again. (use texture surface and render video in 2d was is ticked)
Strange!
One minor drawback: Before switching to raac.dll i could drop a rmvb file with any extension on MPC and playback started. Now the files do need the rmvb extension, or MPC cannot identify the needed audio codec.
(I made some test encodes with different filter settings of the same file and renamed them to test.rmvb.bak, test.rmvb.bak1 etc... Therefore the additional file extensions, on which MPC is picky now)

damrod

11th March 2004, 13:02

i have a question : what's lossless audio encoding? and the purpose?

Sirber

11th March 2004, 13:27

Description:

Monkey’s Audio is a fast and easy way to compress digital music. Unlike traditional methods such as mp3, ogg, or lqt that permanently discard quality to save space, Monkey’s Audio only makes perfect, bit-for-bit copies of your music. That means it always sounds perfect – exactly the same as the original. Even though the sound is perfect, it still saves a lot of space. (think of it as a beefed-up Winzip™ for your music) The other great thing is that you can always decompress your Monkey's Audio files back to the exact, original files. That way, you'll never have to recopy your CD collection to switch formats, and you'll always be able to recreate the original music CD if something ever happens to yours.

damrod

11th March 2004, 21:24

@sirber : i use ape format so thx ;-)

i ask about ra10 and wma9 lossless audio codec....are they better than ape?? i can see the interest of wma9 since it's natively supported except if you doon't have wmp9 ??

Sirber

12th March 2004, 02:02

APE IMHO is the most used lossless codec. I don't like propritary audio format... (for audio only).

damrod

12th March 2004, 09:00

ra10 lossless audio is cook or aac codec?? i don't remember...

Sirber

12th March 2004, 13:45

neihter. It's RALFY!! ;)

damrod

12th March 2004, 15:18

what's that?????

karl_lillevold

12th March 2004, 18:07

What Sirber means is that the lossless codec had FourCC code 'ralf' (RealAudio Lossless Format) :) I would not think it to be very useful when used along with video, since it would take more space than the video in some cases... I have measured its performance, and all the lossless codecs are pretty close: I found ralf to be inbetween Monkey's Audio and FLAC in compression performance.

damrod

12th March 2004, 19:36

you know i was thinking about a lossless audio format we can use in player (like wma9 but... i don't like it ;-))
and wave... is too big!!! i prefer ape!!

karl_lillevold

14th March 2004, 01:45

I ran an experiment with a downsized version of the Harry Potter trailer (to speed up encoding), to try to find which settings provide the best PSNR with the new rate control. What I found was that using a fixed number of B frames (patternAdaptivity=2), and set rcHighBitrateReduce to 60, works pretty well, with 1/2 dB improvement over default. As you can see, the two codecs with the highest PSNR are very close. Do not ask me which the other codecs are.

I will run some more tests, and also at 640x272 with bitrates 500-1000 kbps. Perhaps I can find a way to improve just a little more. I think this also shows that I may need to add the ability to switch to 2 B frames adaptively as well. Currently, 2 B frames only work when used in a fixed pattern. When the default adaptivity is used, the number of B frames vary between 0, 1, or 3.

Please note that this does not indicate visual quality, only the objective PSNR measurement. In my tests, the default settings for the new rate control seem to work best for visual quality at high bitrates.

Video sequence: Harry Potter trailer, resized to 512x208, 25 fps, 3076 frames, Trim(70,3145)

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

EDIT: I found that using rcBFrameRefQuant=12 increased PSNR a tiny bit more, so I updated the previous post, and here are the results for the 640x272 clip at 500, 750, and 1000 kbps.

Video sequence: Harry Potter trailer, 640x272, 25 fps, 3076 frames, Trim(70,3145)

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

So, to summarize, it seems the best settings for PSNR with the new rate control are:
<rcHighBitrateReduce type="uint">60</rcHighBitrateReduce>
<patternAdaptivity type="uint">2</patternAdaptivity>
<rcPFrameRefQuant type="uint">6</rcPFrameRefQuant>
<rcBFrameRefQuant type="uint">12</rcBFrameRefQuant>

karl_lillevold

16th March 2004, 22:57

Hmm, it seems the Producer Beta build has a framerate rounding problem :(

Beta build:
Diagnostic: Frame Rate: 29.000 FPS
Diagnostic: Format: YUY2
Diagnostic: Duration: 01:00.661

Preview build
Diagnostic: Frame Rate: 29.970 FPS

This is not a codec bug, but was introduced in the Beta build of Producer.

So it seems good I did not yet change the encoder DLL to ignore the rcSourceFramerate parameter, since it is apparently still needed.

EDIT: Here is the bug report, in case anyone wants to check status:
http://helixcommunity.org:8080/show_bug.cgi?id=1892
(may need to log in to Helix Community before accessing)

lilhobo

19th March 2004, 16:28

ok so wheres the dll?

Sirber

19th March 2004, 16:52

Why did you removed other codec names in your PNSR test?

lilhobo

20th March 2004, 00:43

ok u have made me run around the helix commnity website so where is the download of the dlls?

karl_lillevold

20th March 2004, 00:48

lilhobo, see first post in this thread, 4th line, after the words : "here it is: "

lilhobo

23rd March 2004, 13:21

hi, so i installed the .dll, is producer supposed to recognise rv10???

Sirber

23rd March 2004, 13:45

... no. The producer beta already encode in RV10. the new DLL is for RealVideo 10 'Elysian'. Use the right term if you want the corrent answer.

lilhobo

23rd March 2004, 14:02

well, when i try to selct the codec, the only option that comes up is rv9???

Sirber

23rd March 2004, 14:10

still unspecific...

are you using producer "commandline" or RealNetworks GUI?

lilhobo

23rd March 2004, 14:17

hmm, do i sound like i could be using commandline???

this is the basic realmedia GUI u can get from their site

Sirber

23rd March 2004, 14:19

Originally posted by lilhobo
hmm, do i sound like i could be using commandline???

this is the basic realmedia GUI u can get from their site Originally posted by lilhobo
hi, so i installed the .dll, is producer supposed to recognise rv10??? Yes.

karl_lillevold

23rd March 2004, 17:55

lilhobo: if you are using the Producer GUI, and only RealVideo 9 shows up, that sounds like Producer 9, not 10. I suggest you switch to Producer 10.

One little advice: This DLL is a prerelease and is hard to use correctly, unless you use a GUI that already has it built in. Even then some steps are needed to make it work correctly (see AutoRV10 thread (http://forum.doom9.org/showthread.php?s=&postid=462188#post462188)). It assumes the user's willingness to search and read up how to use it and be a little more helpful in their feedback.

May I respectfully suggest you stick with codecs that are easier to use and released products that do not require advanced topics like reading usage information, editing audience files, registry settings, and DLL replacements.

hubereevez

1st April 2004, 12:40

Sorry karl, but I'm a little bit lost

what is this new (31/03/2004) build ?

10.0.0.335 Command Line App (Beta2)

Is this the 195 one with the fixed dll?

Thanks

hubhub

karl_lillevold

1st April 2004, 22:01

hubereevez: The latest Producer should have every new feature and bug fix included, as well as the latest RV10 'Elysian' encoder DLL. I don't have a list of all the Producer changes though, but they for instance fixed the framerate rounding problem.

The only update that is useful now, is the rmeditor rmto3260.dll fix for merging files with different bitrates, but this is not required for normal encoding.

hubereevez

1st April 2004, 22:40

oki thanks
so I do need only the 10.0.0.335 version + the rmeditor dll .....
bye
hubhub
PS : btw thank you for you support in the rm/mkv extract thread

karl_lillevold

1st April 2004, 23:43

Originally posted by hubereevez
so I do need only the 10.0.0.335 version + the rmeditor dll .....

Yes.

Sagittaire

5th April 2004, 15:38

Quant Bframe

I think that quant for bframe is always too high

89120 16 8284 38.08 48344 32.29 41.69 19705 90
89000 21 1468 37.01 11224 32.29 41.69 19701 d 90
89040 22 2960 36.09 13400 32.29 41.69 19698 d 90
89080 21 2000 36.63 12360 32.29 41.68 19695 d 90
89200 15 6936 38.73 51472 32.29 41.68 19709 90
89160 22 1548 36.72 9112 32.29 41.68 19705 d 90
89280 16 7080 38.22 45072 32.29 41.68 19716 90
89240 21 2172 36.76 11696 32.29 41.68 19712 d 90
89360 16 7304 38.26 46128 32.29 41.68 19724 90
89320 21 1992 36.76 11168 32.29 41.67 19720 d 90
89440 18 10752 34.02 104376 32.29 41.67 19758 90
89400 23 2880 32.19 34840 32.19 41.67 19765 d 90
89520 18 6632 34.28 99344 32.19 41.66 19800 90
89480 23 2148 32.09 34632 32.09 41.66 19807 d 90
89600 17 7924 35.37 101128 32.09 41.66 19843 90
89560 23 2644 32.24 37416 32.09 41.65 19851 d 90
89680 17 8456 35.18 105024 32.09 41.65 19889 90
89640 23 3948 32.03 42648 32.03 41.64 19899 d 90
89720 17 7264 35.96 82928 32.03 41.64 19927 90

It's possible to have an command to fix quant of bframes: rcOffsetQuantBframe for exemple ?

for sequence P1 B P2

quant BFrame = ( Quant PFrame1 + Quant PFrame2)/2 + rcOffsetQuantBframe

Closed GOP

Probleme with all sequence P B I B P: a better solution should be B P I P B

23800 22 1792 34.65 21952 34.43 43.15 15692 d 90
23920 17 8896 35.20 109152 34.43 43.14 15848 90
23880 22 3732 32.92 46256 32.92 43.12 15899 d 90
24000 16 10896 40.61 55952 32.92 43.11 15965 Key 90
23960 22 7860 32.72 51760 32.72 43.10 16025 d 90
24080 15 456 40.87 14728 32.72 43.09 16023 90
24040 20 40 40.55 1416 32.72 43.09 15999 d 90

It's possible to have an command to close GOP or obligatory Pframe for reference to Bframes: rcCloseGOP for exemple ?

karl_lillevold

5th April 2004, 22:54

Sagittaire: If you prefer lower quants for B frames, you can use for instance

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

instead of the default 6/10. The relative difference will stay about the same during the 2nd pass.

The only advantage I can think of for closed GOPs is for improved editability, where you can then split the sequence up into many separate scenes, and not lose the last B frame(s), that use the future I frame as reference. Why do you think closed GOPs are better?

When we use adaptive I frames, like in RealVideo, closed GOPs are hard to do, since we then would have had to go back in time, and re-compress a frame saved and scheduled to be encoded as a B frame, as a P frame instead, and re-order everything thereafter. It's not impossible, just a little complicated. Since RealVideo is not generally edited much, such a feature is not something that has been prioritized.

Sagittaire

6th April 2004, 00:12

thanks for Bframe quant tunning ...

For the GOP structure MinPSNR is often in these sequence P B I B P ...

9000 20 36 40.10 1536 40.00 43.21 12711 d 100
9120 14 776 40.47 16104 40.00 43.20 12726 100
9080 20 20 40.33 984 40.00 43.19 12675 d 100
9200 17 10896 40.15 29128 40.00 43.17 12747 Key 100
9160 20 156 39.95 3960 39.95 43.16 12709 d 100
9280 13 10768 44.41 24072 39.95 43.16 12758 100
9240 18 60 41.62 1080 39.95 43.16 12707 d 100

20120 19 180 40.83 2608 34.55 44.23 12920 d 100
20240 14 1396 41.18 24608 34.55 44.22 12944 100
20200 19 232 40.68 3160 34.55 44.22 12924 d 100
20320 18 10896 35.57 131896 34.55 44.20 13158 Key 100
20280 21 4848 34.21 29400 34.21 44.18 13190 d 100
20400 16 2764 35.79 70032 34.21 44.16 13302 100
20360 23 752 34.33 9368 34.21 44.14 13294 d 100

23800 23 1724 34.15 19776 33.98 43.14 15073 d 100
23920 18 8720 34.59 99776 33.98 43.13 15214 100
23880 24 3612 31.89 35416 31.89 43.11 15248 d 100
24000 16 10896 40.60 56008 31.89 43.11 15316 Key 100
23960 24 7284 31.64 40624 31.64 43.09 15358 d 100
24080 16 380 40.60 10712 31.64 43.08 15350 100
24040 22 24 40.21 936 31.64 43.08 15327 d 100

Manao

6th April 2004, 00:44

Sagittaire : you're giving raw figures, you're picking out four examples, but in these four, two aren't relevant ( the first two of the last post ).

And I would bet that the other two can be explained if you look at the video itself, to see what happens. Because when there's an I frame that weights 45 Kb, then a B at 40 Kb, then a P at 10 Kb, there's something strange going on ( could it be a blended scene change ? )

hellfred

2nd June 2004, 06:38

@karl_lillevold
Hi Karl
You state that turning off the Inloopfilter with RealVideo10 Elysian might break compatibility with old decoder dlls. I have tryed to create a incompatible RV40 video using jobfile with those two lines:
<inloopCutOffQuant type="uint">31</inloopCutOffQuant>
<inloopCutOffCompatible type="bool">false</inloopCutOffCompatible>
at a bitrate of 500kbits for a noisy 640 X 384 pixel TV capture of a music video. Afterwards i have viewed the resulting file with RealPlayer10 and RealPlayer9 an tryed to spot the difference/incompatibility, but i did not succeed. For what do i have to look out? Blocks? There where quite a lot with both RP 9 and 10 due to the small bitrate and the fog in the encoded scene. Or is it supposed to stutter?

Hellfred

karl_lillevold

2nd June 2004, 17:27

The only incompatibility is that older decoders will always inloop deblock keyframes, no matter you set the encoder option to. This can result in a slight decoder mismatch compared to the encoder. There will be no stutter. You will have a very hard time finding any example where the problem is visible.