RealVideo 10 'Elysian'

[phrentec]

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]

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

[phrentec]

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]

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]

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]

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]

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]

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]

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

[Sirber]

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]

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]

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]

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]

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]

Thanks hellfred :D

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

[hubereevez]

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

hubhub

[karl_lillevold]

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]

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]

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]

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]

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]

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

[Sirber]

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]

@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]

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

[damrod]

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

[Sirber]

neihter. It's RALFY!! ;)

[damrod]

what's that?????

[karl_lillevold]

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]

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]

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]

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]

ok so wheres the dll?

[Sirber]

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

[lilhobo]

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

[karl_lillevold]

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

[lilhobo]

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

[Sirber]

... 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]

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

[Sirber]

still unspecific...

are you using producer "commandline" or RealNetworks GUI?

[lilhobo]

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

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

[Sirber]

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]

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]

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]

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]

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]

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

Yes.

[Sagittaire]

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]

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]

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