RealVideo 9 Information Thread Discussion

[kilg0r3]

@karl

yes it is a slow-cpu issue. R1v1 and R1v2 seem to behave excatly the same way.

my cpu is an athlon 1800+
my video card a matrox g400 dh dualhead disabled

the cpu load is about 85-91%
with the original clip

The reg patch did not help much. I can circumvent the problem with cropping just a little more into the movie. That's also why I hadn't seen it when I tried out anamorphic encoding for the first time.

[Sirber]

85-95% CPU on a 1800+ ?!?!?!

Wasn't RV9 supposed to be optimized? :p

@Karl

What is the resizing algoritm?

[kilg0r3]

my tip is a hyper-filtered version of lanczos.

Seriously, I hope that my video hardware is the culprit here. Probabely 16MB is not enough.

[Sirber]

G400 is 16 MB?

I'll redownload it and try on my 2000+ and GeForce 4 TI 4200 128MB and you know. Maybe your card don't support hardware acceleration...

[Sirber]

On my hardware (see my signature), the clip uses ~50% CPU. It's not too bad, almost the same as DIVX5 DShow at maximum filtering for a lesser rez (can I say that?).

P.S. Sorry for my english :)

[midiguy]

well guys it is pretty much HD resolution.. what do you expect..?

[karl_lillevold]

I will ask someone with an Athlon 1800+ to try it out, but I think one problem might be non-fullscreen playback... You see, as a work-around for old and buggy video cards which could not handle it, the player will drop out of optimized overlay mode, when the video is played at less than 100% size. This will result in a signficant extra load on the CPU. Since this clip is 1024 pixels wide (after resizing), if your screen resolution is 1024x768, and you are not playing full-screen, the video window will be less than 1024 pixels, due to the player borders.

Since this is a pretty common problem for HD clips (for instance 1280 and 1024 pixels wide, exactly matching common screen resolutions), and playing this resolution without overlay is pretty hard, we have fixed this for the next player release.

P.S. in order for the reg key to have any effect, you have to set NoCPUScalability to '1'. Then the codec will not make any shortcuts decoding, but whole frames might be skipped instead.

EDIT:
tried it on a dual PIII 600 MHz, which corresponds to something like a single 950 MHz (since threading is not 100% efficient), and the clip barely plays, with the codec going into CPU scalability mode. Every CPU intensive function in RV9 is MMX optimized, and with Athlon supporting MMX, an 1800+ should be able to handle this clip pretty easily, unless there are other problems, with for instance no overlay, resizing in software etc. Maybe the Matrox G400 can not handle anamorphic resizing too well..

[Sirber]

@Karl

Are you going to include AMD specefic optimizations like 3DNOW and 3DNOW2 in future release?

[kilg0r3]

Ok people,
I have to apologize, partly at least. Why? Well. I realized that having flashed my bios last time, I only loded the defaults and forgot about entering the optimised values. So my 1800+ ran with ram timed asynchronously at 100 MHz. :blush:.

Still, it seems there is a limit of the Matrox overlay to 1024x768. For I had less cpu load at this resolution, and, when disabling the cpu hog DVDmax. I could even play the clip before I entered the proper ram timings. Now, after the adjustments in the bios, I can even use DVDmax at and Task Manager looks like in the attachment. The first curve represents the load when playing the at 99% of its size. The second represents full-screen display; just illustrating Karl’s comments.

At least, we have learned something about the inner workings of real.

Btw, I think the quality is nice but not perfect, you can still see blocks on the cheeks of people and strange behavior of the last man's shadow in the last 'scene' when the walk away.

Yet, I admit that, although the source is extremely clean, due to the new sony digital camera being udsed, for a 720x576 resolution and bright, detailed pictures the bitrate of about 1400Kbps is not plenty.

[karl_lillevold]

Originally posted by Sirber
Are you going to include AMD specefic optimizations like 3DNOW and 3DNOW2 in future release?
No, I am afraid that's not very likely. I don't really know if these instructions sets offer anything that RV9 decoding can make use of in a faster way than it uses MMX.

@kilg0r3:
glad you figured out how to get the speed back into your system.

Originally posted by kilg0r3
Btw, I think the quality is nice but not perfect, you can still see blocks on the cheeks of people and strange behavior of the last man's shadow in the last 'scene' when the walk away.
Hmm, i don't really see any blocks on the cheeks, other than when CPU scalability kicks in on my slow system. I see some compression artifacts in the shadows when zooming out though. This kind of high spatial detail at 720x576 is pretty hard to compress during moving zooms, and on such short duration, there is no VBR to take advantage of either. Good test clip.

[Sirber]

I'll check if 3DNOW and 3DNOW2 can apply to video compression / decompression.

[edit]

I'm a dumb ass... I don't understand the docs :(

AMD Extensions to the 3DNow!™ and MMX™ Instruction Sets Manual
http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/22466.pdf

3DNow!™Technology Manual
http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/21928.pdf

AMD Athlon™ Processor x86 Code Optimization Guide
http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/22007.pdf

[Mr_Khyron]

Originally posted by Sirber
I'll check if 3DNOW and 3DNOW2 can apply to video compression / decompression.

[edit]

I'm a dumb ass... I don't understand the docs :(

AMD Extensions to the 3DNow!™ and MMX™ Instruction Sets Manual
http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/22466.pdf

3DNow!™Technology Manual
http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/21928.pdf

AMD Athlon™ Processor x86 Code Optimization Guide
http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/22007.pdf
sh0dan MMX/SSE/3DNOW documentation
http://cultact-server.novi.dk/kpo/avisynth/optimizing/index.html

[Sirber]

@Karl

If I use Constant quality with a maximum bitrate, it the bitrate goes too high, will the codec decrease the quality or drop frames?

[edit]

... or do nothing special?

[CaptainCarrot]

@Sirber:
I thought that the behavior depends upon wether you choose "smooth", "normal" or "sharp", with "smooth" filtering out details (thus decreasing quality), "sharp" dropping frames and "normal" doing a mix of both. But I maybe wrong.

[Sirber]

I set quality 60 and Max Bitrate at 600 and it still goes at 2000kbps sometimes. :confused:

[kilg0r3]

@karl and all

Hi! I did two further anamorphic clips (ca 1000Kbps and 1400Kbps) which i am going to upload somewhere but only sometime tonight (CMT). Beware, those will be about 10mb each plus 7mb for the screen shots of the source material.

In the course if this, I noticed something strange, at least for me. Playing the clip with higher bitrate also consumes more cpu. I always thought that lower bitrate => more Postprocessing => more cpu. Why is that?

[Sirber]

More the bitrate, more information to show, to calculate motion and to redraw pixels.

at 980x, it's kinda normal :)

At smaller bitrate, the codec recycle (verbe recycler en français) it's pixels, so it have less things to update.

[kilg0r3]

@Sirber

Hum, hum, well, hum alright ...

@all

BTW, before burning my dialup isdn connection, are there actually people interested in these clips?.

[Sirber]

I do. I'm interrested in anamorphic encoding :)

You can send them to sirber@webernic.com ou send my a URL.

Thanks!!! :D

[karl_lillevold]

Originally posted by Sirber
If I use Constant quality with a maximum bitrate, it the bitrate goes too high, will the codec decrease the quality or drop frames?

It will decrease the quality to try and stay within your set maximum bitrate. In the unlikely case it can not drop quality enough, it will skip frames, but this rarely happens at the bitrates you operate at.

[karl_lillevold]

Originally posted by CaptainCarrot
I thought that the behavior depends upon wether you choose "smooth", "normal" or "sharp", with "smooth" filtering out details (thus decreasing quality), "sharp" dropping frames and "normal" doing a mix of both. But I maybe wrong.
'Smooth' in the encoder results in HHR = Half Horizontal Resolution for high resolution clips. This means it will resample to half the width before encoding, and have the player stretch back after decoding. It will result in less sharpness.

For the bitrates discussed here, 'normal' and 'sharp' work pretty much the same way. I always use 'normal'. They only differ if the encoder has to drop frames, which it never does at reasonable bitrates. In that case, 'sharp' will rather drop frames, than decrease the quality below a certain threshold.

[karl_lillevold]

Originally posted by kilg0r3
In the course if this, I noticed something strange, at least for me. Playing the clip with higher bitrate also consumes more cpu. I always thought that lower bitrate => more Postprocessing => more cpu. Why is that?
More bits means higher CPU load when the entropy decoder parses the bits. Bit parsing is not very MMX optimizable, since it is hard to do bit wise operations in parallel.

[Sirber]

@Karl

Have you checked the PDFs about 3DNOW?

[karl_lillevold]

Originally posted by Sirber
Have you checked the PDFs about 3DNOW?
Nope, sorry, finally had some time to work on improving RV9 encoding, and there's not much time left over, and to be honest, that's something I'd rather do as well. Improving decoder speed beyond what we have today, is very incremental and time-consuming, especially since none of us know the AMD extensions. I think most would want 20% better compression in RV9, in addition to RV on all sorts of cool devices, which is another large part of what we do, rather than 5% faster decoding on AMD.. Or no?

[p.s. not promising 20%, that was just picked out of thin air]

[Sirber]

I see...

I'd like the 20% in encoding :). I don't care too much about decoding, but some people have problems with speed.

About encoding, it would be great to add "lines" to the codec, for making shapes at low bitrate, for animes. I have one that is mostly blue and white, with lines. Lines are blury at 350kbps and require at least 700kbps to have greats one. If you don't know what I'm talking about, I can make screenshots.

Cya!

hum...

by 20%, do you mean 20% better at the same bitrate, or 20% faster?

[karl_lillevold]

:) Like I said, 20% was just an example, but "x% better" for the encoder would mean x% less bitrate to achieve the same quality. If you like you can send me a screenshot per e-mail.

[Sirber]

That would be great :)

I'll reencode it (I deleted it) and shoot you a screen by mail. Do you the anime Ghost in the Shell? It's a special about Tachikomas, the blue armored suits, from the serie. It's ~5 MB, so I can shoot it in rmvb format, or a small clip.

[edit]

hum... what's your mail again?

[edit2]

This user's mailbox is currently full, and cannot be sent any messages until it is cleaned out. An email has been sent notifying the user of this. Please try your request at a later time.

Clean it!!! :scared:

[iwod]

Below are the clips from kilg0r3


1400Kbps (http://echo6.dr2.net/~edde/Clip-1400Kbps.rar)

1000Kbps (http://echo6.dr2.net/~edde/Clip-1000Kbps.rar)

SourceFrame (http://echo6.dr2.net/~edde/SourceFrameGrabsAndMisc.rar)


P.s.... how do i do so that there is a count how many times thes link has been clicked??

[Sirber]

@iwod

Check your apache's logs :)

@kilg0r3

I don't see any differences between 1000k and 1400k. 1400k seems to lag sometimes, the sound gets out of sync for 2 ms. Quality is SO GREAT!!!

What tools are you using?

[Sirber]

You are bandwith limited?

Remove the links in 1 or 2 days. So people that really want these and care about RV9 will have it, and the others nOoBs wont :).

[kilg0r3]

Originally posted by Sirber
I don't see any differences between 1000k and 1400k.
Yes, that is what i thought too.

I don't use anything special really but the source is extremely clean since it is sony's new highdef digi video cam.

[Sirber]

@Karl

Since you're not using hotmail, I'll try to upload the whole clip, which is 4.5 MB. Watch the lines on the tachikomas.

Here's the settings:

<?xml version="1.0" encoding="UTF-8"?>
<audience xmlns="http://ns.real.com/tools/audience.1.0">
<avgBitrate type="uint">350000</avgBitrate>
<maxBitrate type="uint">2000000</maxBitrate>
<streams>
<videoStream>
<enableLossProtection type="bool">false</enableLossProtection>
<encodingType type="string">vbrBitrate</encodingType>
<maxFrameRate type="double">24.000000</maxFrameRate>
<maxKeyFrameInterval type="double">10.000000</maxKeyFrameInterval>
<maxStartupLatency type="double">25.000000</maxStartupLatency>
<pluginName type="string">rn-videocodec-realvideo</pluginName>
<quality type="uint">30</quality>
</videoStream>
<audioStream>
<codecFlavor type="uint">21</codecFlavor>
<codecName type="string">cook</codecName>
<pluginName type="string">rn-audiocodec-realaudio</pluginName>
<streamContext type="bag">
<audioMode type="string">music</audioMode>
<presentationType type="string">audio-video</presentationType>
</streamContext>
</audioStream>
<audioStream>
<codecFlavor type="uint">7</codecFlavor>
<codecName type="string">cook</codecName>
<pluginName type="string">rn-audiocodec-realaudio</pluginName>
<streamContext type="bag">
<audioMode type="string">voice</audioMode>
<presentationType type="string">audio-video</presentationType>
</streamContext>
</audioStream>
<audioStream>
<codecFlavor type="uint">21</codecFlavor>
<codecName type="string">cook</codecName>
<pluginName type="string">rn-audiocodec-realaudio</pluginName>
<streamContext type="bag">
<audioMode type="string">music</audioMode>
<presentationType type="string">audio-only</presentationType>
</streamContext>
</audioStream>
<audioStream>
<codecFlavor type="uint">7</codecFlavor>
<codecName type="string">cook</codecName>
<pluginName type="string">rn-audiocodec-realaudio</pluginName>
<streamContext type="bag">
<audioMode type="string">voice</audioMode>
<presentationType type="string">audio-only</presentationType>
</streamContext>
</audioStream>
</streams>
</audience>


Whish me luck :)

[Sirber]

@Karl

Have you got my mail?

[karl_lillevold]

nope, pls use the web based file transfer service I mentioned in my PM, because our attachment limit size is 5 MB (which is less in binary due to ASCII conversion). Also, I still don't have your e-mail, which would be a more efficient way to communicate information not of interest to the rest of this board :scared:

[Sirber]

I'll resend it using your wierd CGI upload :)

Don't have any FTP?

[edit]

Hum... My PM is empty. :( Could you resend it to my PM or mail? Thx :)

[Sirber]

Got it now?

I'm wasting all my bandwith :scared: ;)

[iwod]

I have just deleted some of my useless post in an afford to clean up the post.... i hope other would do the same.... just to make this post stay on topic.

[Sirber]

@Karl

Any news for animes?

[iwod]

@ Karl...

I remember you have said that adjustable post filter would be added. I am having the feeling partly why Rv9 looks so good is because the filter.

I am wondering if it is possible to allow the encoder to have the options to force different level/kind of post processing @ different point of playing??

[Sirber]

Or a Variable Post-Processing Engine :)

It would be nice to see a clip whitout and one with...

[wing1]

@karl

OK, play around enough with all the options in the audience file: I don't understand exactly what the quality setting does when you are using vbrbitrate for encoding. How does that get into effect? The only time I am seeing it doing anything is by using qualityvbr for encoding.

[karl_lillevold]

@wing1: you are right, the Quality setting does not affect anything in vbrBitrate mode.

[kilg0r3]

is there any way to do sth like a compressibility check with producer?

[Sirber]

Maybe with Quality-based encodes...

[karl_lillevold]

AutoRV9 1.3b1 has a compressibility test.

The following requires an understanding of how the compressbility test works: The compressibility test requires a number of bits corresponding to "max quality". The problem is that the best possible quality with XviD (QP=2) is very different from the best quality in RV9. In RV9 a higher maximum fidelity is possible, but this also requires more bits, so if a max quality if vbrQuality=100 was used as the comp test reference, the compressibility test number would be way too small, like 10% or less.

So the challenge was to find a suitable reference quality for RV9. I ran some experiments using the compressibility calculations, and found that vbrQuality=83 with no limit on max bitrate, is a good starting point. However, I have not tried AutoRV9 1.3b1 on enough samples to see how accurate it is. It is, however, a nice first step, so do give it a try and provide feedback as appropriate. Thanks!

[slavickas]

@Karl , is helixcommunity site fully working? i can't access binaries & servers mailng list archve

[karl_lillevold]

it is working right now, monday morning, US Pacific time.
If you still have trouble, please send email to feedback@helixcommunity.org, and include your user id.
Thanks!

[slavickas]

hmm, seems to be working now, probably somewhere were dns errors, thx anyway for reply

[31 Flavas]

For ATI users:

Catalyst 3.4 drivers have been posted at ATI.com

[slavickas]

@Karl

does m3 have updated encoder?