Real Video 9 ?

[ookzDVD]

Real Video 9 Codec Released!

Real Networks is now offering Real Video 9. RV 9 is offering 30% improvement over RealVideo 8 and the same quality at half the bit rate of MPEG-4. Furthermore the playback quality has improved significantly:

- ½ screen video at dial up rates
- VHS quality at everyday broadband rates (starting at 160 Kbps)
- Near DVD at 500 Kbps for download or streaming on high speed networks

Is that true ?? ;)
Let's proof it!

[Doom9]

without ever having tested real products I find these statements highly unlikely.. I bet it's the usual marketing blurb. How many times have I shown that what PR department advertises is not exactly true?

[gabest]

See with your own eyes then :)

http://www.realnetworks.com/solutions/leadership/realvideo.html

There are a few clips which look amazing compared to their bitrate. Only if it were not realmedia... :rolleyes:

[Leuf]

First off, the main changes are 2-pass vbr is now really full 2-pass vbr without the registry hack, and support for surround sound. I don't think too many people are looking for surround sound in rms.. The encoder is a command line only preview, pretty much identical to when wmv8 first came out. It doesn't appear to mess with the registry like the regular producer, so that's good.

Installing the codec itself was fun. Realplayer tried to dl the codec, crashed. Reinstalled. Crash. Reboot. It installs, then crashed once more just for good measure. But it works now.

I did a quick comparison of 9 and 8 on a music video, nickelback - how you remind me (all i had handy) and there does appear to be some improvement, even with 8 having the registry hack. Both were done with the 256k preset. The general video quality was more consistent between keyframes with 9, especially in low motion scenes. Some scenes that had large blocks in 8 were smooth in 9, but on some scenes that had moving objects over a static background the background "ripples" around the object - I'm not sure this is preferable to blocks. And the 9 stayed on filesize, whereas the 8 was 500k over (6,712kb vs 6,285kb) due to the hack.

I'd say Real just increased their lead a bit in the low bitrate arena.

[Doom9]

gabest: I believe it when I see it with my own eyes on content I encoded on my own ;)

[gabest]

LOL. Yes, they were probably optimized by hand, frame by frame, in 10 passes :D

[Dali Lama]

Well I gave the new version a spin too. It looks really good to me. No joking. I encoded the Rush Hour trailer in 1000 Kilobits/s. I can't see any blocks. There is a little smoothing of skin tones (as in less detail), but it handles backgrounds excellent. Much better than Divx 5 or Xvid. I think if you test it out Doom9, you will like it. Also, you might find the blurriness to be on par with Divx 5, but no Blocking and better color reproduction.

I also tested out an animation sequence and I really have to say that it does a good job of prevented color smears or blocking or ringing. Really amazing. It seems to be heavily post-processed though (downside). It takes a lot of cpu power to play these clips.

I will try to be more specific when I have more time to compare.

Edit: I am uploading both clips about 18 MB and 10 MB each. I will provide the http server shortly.

Edit again: Ok here are the links:

http://islam4you.hypermart.net/Rush Hour Trailer 1000kbs Real Media 9.zip

http://islam4you.hypermart.net/Final Fantasy X - Kilika Dusk 1000kbs Real Media 9.zip

I hope others test it out too,

Dali

[travis morgan]

dali lama,

i'm testing the new realvideo codec out tonight.

1.5g p4
128mb pc800 rdram
win2000

13 ghosts
91 min

realsystem producer 9 preview (command-line)
realvideo 9 codec
audience: 350k VBR

.avs file settings:
loadplugin("mpeg2dec.dll")
loadplugin("simpleresize.dll")
video=mpeg2source("video.d2v")
audio=wavsource("audio.wav")
audiodub(video,audio)
delayaudio(-.083)
crop(12,8,696,464)
simpleresize(320,176)

will post findings later.
---------------------------------------------------------------------
first test with the new realvideo 9 codec is over and it performed very well...fast vbr encoding, high quality audio/video, and small filesize.

encoding duration:
1st pass (analysis) - approx. 1 hr/15 min
2nd pass (encoding) - approx. 1 hr/15 min

streams:
realaudio - 64Kbps Stereo Music - RA8
realvideo - 285Kbps
24 fps

filesize:
approx. 235 megs

i will try to post some short video clips soon.
---------------------------------------------------------------------
clip1.zip (http://users2.ev1.net/~warlord/realvideo9/clip1.zip)
clip2.zip (http://users2.ev1.net/~warlord/realvideo9/clip2.zip)

[Leuf]

So I went poking in the audience settings to see if I could improve anything and found something odd. At all of the lower bitrate settings the average and maximum bitrate settings are practically equal, and are the same whether you use the cbr or vbr settings. For example at 384k:

384k cbr 350000/384000
350k vbr 350000/384000

Once you get into 500k they start to widen a bit until finally at 1.5M it's 1500000/8000000. But I don't understand why the 350k vbr max bitrate is so low. I made my own 256k vbr audience and have been messing around with what to put for max bitrate, but it's hard to tell what effect raising it has had - especially since it's so difficult to get screenshots of a specific frame from the real player.

Also I tried doing a 640x480 1M vbr - my 1.2@1.4 athlon couldn't play it fullscreen.

[travis morgan]

leuf,

just a guess, since i haven't had time to look into the audience settings, but the difference between the two could be because of the audio bitrate.

[Leuf]

Originally posted by travis morgan
leuf,

just a guess, since i haven't had time to look into the audience settings, but the difference between the two could be because of the audio bitrate.

If you mean the difference in naming 384 vs 350, that just reflects the strange meaning of "cbr" and "vbr" in real files. "cbr" isn't really constant, it's more like "constant enough to be streamed" as far as I can tell. You can still do 2-pass cbr, there wouldn't be any point to that if that wasn't true. So 384k cbr means it can be streamed on a 384k connection, so they average 350 and allow it to go up to 384 max. The vbr files on the other hand are given a new file extension "rmvb" and are presumably download only, so it doesn't make any sense to limit the maximum bitrate like they do. On my second test clip with a much higher percentage of action scenes I was getting terrible results until I cranked the max way up. I'm doing average 225000 max 1200000 at the moment. Same filesize as 225000/256000 with far superior results.

The quality setting doesn't appear to have any effect in vbrbitrate mode, can anyone verify that?

Also as with previous versions I get much better results with the sharp video mode (-vm sharp)

I'll be able to do a full 1 hr tv encode with it tomorrow which will be the true test for me.

[travis morgan]

leuf,

comparing the two audience files, 350k VBR and 384k, the only difference i can see is the "encodingType". 350k VBR uses "vbrBitrate" and 384k uses "cbr". what this means to me is the 350k VBR will average a 350k bitrate, but will have a minimum bitrate of 0k and a maximum bitrate of 384k. the amount of bitrate used at any time will depend on the amount action for a particular scene. the 384k will use a constant 350k bitrate all the time for every scene. the quality of the two encodings should be the same, but the 350k VBR should produce a smaller file size.

350k VBR being download only? i have done some vbr encodings with realproducer 8.5 and the resulting .rm files streamed great. i haven't tried to stream any .rmvb files, so i'm not sure if they would are not.

here are two clips i produce with the new codec. let me know what you think. (look at previous posts for settings and results)

clip1.zip (http://users2.ev1.net/~warlord/realvideo9/clip1.zip)
clip2.zip (http://users2.ev1.net/~warlord/realvideo9/clip2.zip)

just started uploading the files so you might give it 30 minutes before you try to download.

[Leuf]

Originally posted by travis morgan
leuf,

comparing the two audience files, 350k VBR and 384k, the only difference i can see is the "encodingType". 350k VBR uses "vbrBitrate" and 384k uses "cbr". what this means to me is the 350k VBR will average a 350k bitrate, but will have a minimum bitrate of 0k and a maximum bitrate of 384k. the amount of bitrate used at any time will depend on the amount action for a particular scene. the 384k will use a constant 350k bitrate all the time for every scene. the quality of the two encodings should be the same, but the 350k VBR should produce a smaller file size.

I don't think that's right. Average bitrate should be what is determining filesize, assuming the rate control in vbr mode works properly. What I think is that v9 cbr with 2-pass disabled is the same as v8 1 pass, v9 cbr 2-pass is the same as v8 vbr, and v9 vbr is the same as v8 vbr with the registry hack.

If you aren't familiar with the registry hack, run regedit and change the key HKEY_CLASSES_ROOT\Software\RealNetworks\RealProducer\8.5\Preferences\VBR Latency to a large number - I use 400000. This breaks the rate control, so you may get a larger file but it's not really much worse than divx's rate control. The result probably isn't streamable - never tried it. This is what I'm benchmarking v9 vbr against. On my second test v8 with the hack has been spanking v9 vbr unless I crank up the max bitrate, and even then it's questionable which is better. Note that v9 doesn't allow you to put an out of spec number for vbr latency in the audience file.

350k VBR being download only? i have done some vbr encodings with realproducer 8.5 and the resulting .rm files streamed great. i haven't tried to stream any .rmvb files, so i'm not sure if they would are not.

I think they made the new extension to distinguish the two. All the vbr settings have "download" in the name, I think it's a logical conclusion.

here are two clips i produce with the new codec. let me know what you think.

They do look ok. I'd be curious to see what happens if you raise the max bitrate. Just a warning, when you edit the audience files if you do something wrong producer crashes :)

[travis morgan]

you are correct. average bitrate does determine filesize. i should have caught my mistake before i posted the message. the filesizes should be identical, but the vbr encoding would allow for more bits to be given to a scene that needed them and less bits to a scene that didn't.

from what i understand, the purpose of the vbr latency hack is to allow realproducer to look ahead when assigning the bitrates thus utilizing the bitrates more effectively. but it would also drastically increase the startup time for a video. since i'm mostly concerned with streaming the video, this wouldn't be good for me.

[Leuf]

Originally posted by travis morgan
from what i understand, the purpose of the vbr latency hack is to allow realproducer to look ahead when assigning the bitrates thus utilizing the bitrates more effectively. but it would also drastically increase the startup time for a video. since i'm mostly concerned with streaming the video, this wouldn't be good for me.

FWIW, I've never had any delay at loading playing them locally, but I have no idea what it will do to streaming.

My turn with a clip, this is average 225 kbit/max 1200 kbit vm sharp, with 44 kbit audio. I've mostly been doing 320x240, this one is 320x168 but has loads of action

test clip (http://members.bellatlantic.net/~vze3kkvm/test5.rmvb)

[atracus]

all,
I'm also trying the codec out with a couple of movies on my 2 PCs, and I'm noticing a very slow FPS performance: my 1st pass goes at about 8fps against DivX5 which is norm 12-14 (Athlon 1GB/512KB).

So I thought: am I messing up with the colorspace settings, which I kept unchanged from divx/GKnot procedure, i.e. YUV2?

Do you suggest me to get DVD2AVI frameserve out in RGB?

Sorry for the newbie Q, thanks in advance for your kind advice.

[atx]

[atracus]

btw,
quality of my first movie, "The Watcher", which I also encoded in DivX5 2-pass (single CD), is impressively satisfying to me.

Even on dumb-coloured backgrounds r9 beats divx5 (I encoded in both flavours and compared single scenes): no blockiness at all, no halo effects.

The price in exchange is some more CPU power needed for playback, my old laptop (IBM Thinkpad with a P-700MHz) can't stand the fullscreen repro @ 1024x, and I have to lower the resolution to 640x in order not to have stuttering playback.

This is just my personal feeling, nothing more. My 2 cents.

bye all!

[atx]

[travis morgan]

good clip...would have been better if it was ozzy though. :D

what do you use your clips for?

[Leuf]

I use real to encode tv shows I don't care enough about to do full blown divx encodes on. Real is very forgiving about analog noise, so if I don't feel like doing all the filtering I normally do I can do a quick and dirty encode and have it still come out decent. 75 mb for 40 min running time is nice, 8 episodes on a cd, and it's still very watchable - especially through tv-out.

[Leuf]

"Warning: Startup Latency 0 exceeds minumum allowed value 0. Using default 0"

*blinks*

[31 Flavas]

A few people (myself inclusive) have been discussing RV9 over in the new A/V format forum as well. Some of use are pretty amazed. One person says he's converted from divix to RV9.

So if anyone is looking for more discussion on RV9 stick you head in the New A/V format forum and click on the RV9 topic.

Just from using RV9 I can tell you the samples on RealNetworks.com are not "Golden" samples. They are exactly what I am getting.

-Flavas