[TEST] Visual, PSNR, SSIM, VQM tests with RV9, XviD ,DivX, WMV9 ... [Archive] - Page 4

temporance

21st August 2003, 13:17

Originally posted by SeeMoreDigital
I have to agree with you on this. For me I still prefer to look at a WMV9 720x576 image (.wmv or .avi) when encoding at a bitrate of 900kbps or below. The whole image just seems to be more engaging!IMHO, the DivX betas with slow modes, new PV and new PP work very well at these bitrates - they produce more detail and no more artifacts than WMV9.
But high bitrate encodes would run alot better at a true 1.77:1 'square pixel' PAL frame size of 1024x576... Don't know if the 1.77:1 'square pixel' NTSC frame size of 854x480 would work! Disagree. There is no point going to a higher horizontal resolution than 720 when encoding for SDTV, for two reasons: 1, SDTV source only ever had 720 horizontal pixels when originated on professional kit, and 2. When you output to a TV, image is resampled to 13.5MHz = 720 visible pixels / line. Perfectly square pixels don't really help a codec.

SeeMoreDigital

21st August 2003, 13:23

Originally posted by temporance
@SeeMoreDigital: I've edited my post to include a datapoint at resoultion 1024x480. As expected, PSNR is worse (blocks are smaller though Sorry temporance 1024x480 will not work properly. If your PAL source image is 1.77:1 you can resize this to 1024x576.
If your PAL source image is 1.85:1 you can crop and resize to 992x554.
If your PAL source image is 2.35:1 you can crop and resize to 768x436.

I normally just leave them at 1024x576. On a PC they look great. Like you say smaller blocks!

But these frame sizes don't work on my Xcard. Bummer!

SeeMoreDigital

21st August 2003, 13:34

Originally posted by temporance
... Disagree. There is no point going to a higher horizontal resolution than 720 when encoding for SDTV, for two reasons: 1, SDTV source only ever had 720 horizontal pixels when originated on professional kit, and 2. When you output to a TV, image is resampled to 13.5MHz = 720 visible pixels / line. Perfectly square pixels don't really help a codec. Yes, encoding 720 horizontal pixels to 1024 shoul'nt make much improvement. But as you've said yourself, it does produce smaller blocks which makes a high speed scene look much better!

It's a strange one for sure!

Another one of these... 'Why bees should not be able to fly, but they can'. Conundrums!

Cheers

EDIT
In my opinion a PAL DVD should never have used a pixel frame size of 720x576. It should have used a true 16:9 (1.77:1) frame size 1024x576 to begin with. Just as HD broadcasts use a true 1.77:1 pixel frame size. Anamorphic re-framing is a good idea but a poor substitute for the true frame size.

A 'stand alone' DVD player could quite easily have coped with the electronics required to make such an idea possible. That said it could have also coped with 'film speed' 24fps DVDs!

Anyway it looks like this will arrive with Blu-Ray!

Sagittaire

21st August 2003, 14:18

Little PSNR test: Blur influance ...

Source

source=Mpeg2Source("D:\Mes dossiers\B.A\Les deux tours\azerty.d2v")
source=Crop(source,24,88,-24,-72)
source=LanczosResize(source,640,272)
return source

Test with blur 0.3

source=Mpeg2Source("D:\Mes dossiers\B.A\Les deux tours\azerty.d2v")
source=Crop(source,24,88,-24,-72)
source=LanczosResize(source,640,272)
source=Blur(source,0.3,0.3)
return source

PSNR test

# --> Video Opening <--

source=AviSource("D:\Mes dossiers\B.A\Les deux tours\source.avs")
source=ConvertToYV12(source)

video=AviSource("D:\Mes dossiers\B.A\Les deux tours\test.avs")
video=ConvertToYV12(video)

# --> PSNR analysis <--
CompareYV12(video,source,"","test-Bilinear.txt")

blur 0.1: 54.5353 dB
blur 0.2: 50.1381 dB
blur 0.3: 47.4559 dB
blur 1.0: 39.6771 dB

temporance

21st August 2003, 14:19

Originally posted by SeeMoreDigital
Sorry temporance 1024x480 will not work properly. If your PAL source image is 1.77:1 you can resize this to 1024x576.I'm not sure I know what you're saying. I started with a progressive clip 640x304, just wanted to do some PSNR tests encoding at different resolutions, maintaining approximate aspect ratio.

In my opinion a PAL DVD should never have used a pixel frame size of 720x576. It should have used a true 16:9 (1.77:1) frame size 1024x576 to begin with. Just as HD broadcasts use a true 1.77:1 pixel frame size. Anamorphic re-framing is a good idea but a poor substitute for the true frame size.

A 'stand alone' DVD player could quite easily have coped with the electronics required to make such an idea possible. That said it could have also coped with 'film speed' 24fps DVDs!The resolutions used for SDTV (and interlace) are the result of a long history of developments in the TV industry. Using a non-standard video format would not have been easy.

temporance

21st August 2003, 14:24

Originally posted by Sagittaire
Little PSNR test: Blur influance ...

blur 0.1: 54.5353 dB
blur 0.2: 50.1381 dB
blur 0.3: 47.4559 dB
blur 1.0: 39.6771 dB Yes, nice experiment, expected results. What's the conclusion?

Sagittaire

21st August 2003, 14:34

It's just test for observing blur influence on PSNR ... no conclusion ...

CruNcher

21st August 2003, 14:37

@Sagittaire

i dont have the space nor the traffic to do this right now but i will cut out samples from both if i know how to cut .rmvb so if you help me here i can provide smaller clips :) both trailers are 20 mb so i would need 40 mb for both + traffic if someone would sponser this no problem but i doubt somebody will.

Sagittaire

21st August 2003, 14:41

If I were to make a conclusion it is that in general test PSNR, SSIM and VQM consolidate my visual impressions ...

SeeMoreDigital

21st August 2003, 14:45

I'm not sure I know what you're saying. I started with a progressive clip 640x304, just wanted to do some PSNR tests encoding at different resolutions, maintaining approximate aspect ratio. If you encode from an 720x576 anamorphic source (instead of an 640x304 source) you may 'see' what I mean!

It's too bad there aren't many DVD's that occupy all of the 720x576 'anamorphic' image pixel frame size (ie 1.77:1). Most are ofcourse 1.85:1 or 2.35:1 which have far less active pixels.

But please stay with it and give it a go, as I would like another opinion.

I've generated a few full frame 1024x576 1.77:1 using DivX and WMV9 (VCM) encodes at 674kbps and 950kbps. And I was quite surprised 'visually' at what happened!

Cheers

Sagittaire

21st August 2003, 14:56

I think pixel format for 720*576 isn't 1.77:1 but 1.45:1 (16/11 in fact) ...

1.77:1 is video format for 16/9 but not pixel format for 720*576 anamorphic ...

You can make anamorphic wmv9 encoding with WMEncodeur in wmv format ...

SeeMoreDigital

21st August 2003, 15:12

Originally posted by Sagittaire
I think pixel format for 720*576 isn't 1.77:1 but 1.45:1 (16/11 in fact) ...
1.77:1 is video format for 16/9 but not pixel format for 720*576 anamorphic ... True. 720x576 is actually 1.25:1. I've ammended my previous post accordingly.

Sagittaire

21st August 2003, 16:13

Here anamorphic 720*432 demo in the most powefull format (it's my opignon ...)

http://jfl1974.free.fr/Video/RV9-RA8.rar
http://jfl1974.free.fr/Video/WMV9-WMA9.rar

Sagittaire

22nd August 2003, 08:53

@ CruNcher and all

http://jfl1974.free.fr/Video/RV9-RA8.rar
http://jfl1974.free.fr/Video/XviD-MP3.rar

I made test with the quicktime source for matrix reloaded with this avs script ...

LoadVFAPIPlugin("C:\Program Files\AviSynth2\plugins\QTReader.vfp", "QTReader")

Clip1=QTReader("D:\Mes dossiers\Mes fichiers reçus\trailer_final_1000_dl.mov")
Clip1=FlipVertical(Clip1)
clip=ConvertToYV12(Clip1)
Clip1=SelectEvery(Clip1,25,1)
Clip1=LanczosResize(Clip1,640,344)
Return Clip1

XviD Devapi4
640*344 950 kbps H263, Ultra high, VHQ4, bframe 1/1.50/0.75
MP3 VBR 96 Kbps (ultra high quality encoding)

RV9
640*344 950 kbps EHQ 85, MSL 60
RA surround 96 Kbps

download and compare: RV9 EHQ winner

Sirber

22nd August 2003, 13:10

RV9 is really the winner. Q is 2 times better IMHO in RV9 for this clip.

Teegedeck

22nd August 2003, 14:07

ehe. I like reencoding quicktime-trailers myself, but it's hardly a good idea to reencode an MPEG4-encoding with an MPEG4-codec now, is it?

Judging from your SW2-encodes only, RV9 still can't denounce it's streaming-origin; WMV9 beats it very easily with the level of details. Sadly WMV9 doesn't play smoothly for me with WMP 6.4.

MP3 VBR 96 Kbps (ultra high quality encoding) :)

Sagittaire

22nd August 2003, 14:33

ultra high quality setting for encoding with MusicMatch Converter ... sorry but Quality isn't bad for MP3 96 Kbps ... ?

RV9 EHQ Winner and in order WMV9, Kaukura and final XviD ... allways same result for me ...

Note: real bitrate is 939 kbps for RV9 and 960 for XviD but rmvb must have a strong header ... this probleme don't exist with mkv container ... :-)

CruNcher

22nd August 2003, 14:51

@Sagittaire

640*344 look @ it closely again dont you see something ?

CruNcher

22nd August 2003, 15:42

@ all
here is a sample of a lowmotion followed by highmotion clip @ 550 kbps
it was hard to hit (almost) the same 550 kbps with Rv9 but useing this was the best result after 6 encodes

<audience xmlns="http://ns.real.com/tools/audience.2.0">
<avgBitrate type="uint">480000</avgBitrate>
<maxBitrate type="uint">481000</maxBitrate>
<streams>
<stream xsi:type="videoStream">
<pluginName type="string">rn-videocodec-realvideo</pluginName>
<codecName type="string">rv9</codecName>
<codecProperties type="bag">
<encoderComplexity type="uint">80</encoderComplexity>
<noisyEdgeFilter type="bool">false</noisyEdgeFilter>
<calcPSNR type="bool">true</calcPSNR>
<customPacketSize type="uint">16000</customPacketSize>
</codecProperties>
<encodingType type="string">vbrBitrate</encodingType>
<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">28</codecFlavor>
<streamContext type="bag">
<presentationType type="string">audio-video</presentationType>
<audioMode type="string">music</audioMode>
</streamContext>
</stream>
</streams>
</audience>

<encoderComplexity type="uint">80</encoderComplexity> is 80 as suggested by karl_lilevold and used his .dll for producer as gui HPG was used

http://www.mufflastig.com/CruNcher/XviD/phagain/

argh sorry i ran out of diskspace so please download the xvid first i will let it up for severall hours and then i finish the rv9 one sorry :(

Sagittaire

22nd August 2003, 16:12

The profil is very strange ...
<avgBitrate type="uint">480000</avgBitrate>
<maxBitrate type="uint">481000</maxBitrate>

and
<quality type="uint">100</quality>

setting are not compatible: it's an encoding with bitrate or quality. For bitrate encoding ton must have avgBitrate x 2.1 = maxBitrate. Use AutoRV9 or RMFactory for better encoding RV9 ...

<?xml version="1.0" encoding="UTF-8"?>
<audience xmlns="http://ns.real.com/tools/audience.2.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://ns.real.com/tools/audience.2.0 http://ns.real.com/tools/audience.2.0.xsd">
<avgBitrate type="uint">550000</avgBitrate>
<maxBitrate type="uint">1200000</maxBitrate>
<streams>
<stream xsi:type="videoStream">
<pluginName type="string">rn-videocodec-realvideo</pluginName>
<codecName type="string">rv9</codecName>
<codecProperties type="bag">
<encoderComplexity type="uint">85</encoderComplexity>
<customPacketSize type="uint">16000</customPacketSize>
</codecProperties>
<encodingType type="string">vbrBitrate</encodingType>
<maxStartupLatency type="double">60</maxStartupLatency>
<maxFrameRate type="double">30</maxFrameRate>
<maxKeyFrameInterval type="double">10</maxKeyFrameInterval>
<enableLossProtection type="bool">false</enableLossProtection>
</stream>
</streams>
</audience>

karl_lillevold

22nd August 2003, 16:17

this setting:

<avgBitrate type="uint">480000</avgBitrate>
<maxBitrate type="uint">481000</maxBitrate>

pretty much disables VBR, effectively making it CBR. No wonder the high action would look a little smooth. Please set maxBitrate to something like 2.1X avgBitrate. Most tools do this automatically.

EDIT: Adjust maxBitrate in HPG's audience generator. It is default to 4X average bitrate, but I recommend 2.1X or so. Either is fine, and should not make a huge difference, but it's important that maxBitrate is at least 2X avgBitrate, to not limit the VBR operation.

CruNcher

22nd August 2003, 17:03

@ karl_lilevold

i did it now with the script sagittaire posted but still im alot off from the XviD size
i used encoding complexity 80 btw not 85

8,30 MB (8.710.412 bytes) RV9
7,73 MB (8.112.498 bytes) XviD

temporance

22nd August 2003, 17:14

@Sagittaire, I like your Matrix compare, but maybe the bitrate's a bit on the high side. I also did a DivX Kaukura encode and, IMHO, that looks better than RV9:

1st pass: -bvn1 950 -psy 0 -log "c:\divx.log" -w -b -pq 5
2nd pass: -bvnn 950 -mod 0.25 -psy 2 -log "c:\divx.log" -w -b -pq 192

However, I think your RV9 encode came in undersized.. so that might be why it looks a bit soft(?)

Sagittaire

22nd August 2003, 17:42

@ Cruncher

The real bitrate of your XviD Sampler is 536 Kbps not 550 kbps ...

SeeMoreDigital

22nd August 2003, 17:54

This is begining to get interesting now!

I think many of you will agree that DivX begins to superseed WMV9 at around 950kbps. However, my own tests show that WMV9 begins to overtake DivX again at around 1500kbps. But once you get to above 3000kbps I really don't think there's much difference!

It would be most helpful to learn if RV9 has 'dead zones' where other codecs begin to look better!

I recently generated some very high bitrate (8000kbps) 720x576 anamorphic tests using Xvid, RM9, DivX & WMV9. And they all looked the same to me! I used Contact Chapter 33 as my source.

However when you try and encode using larger frame sizes such as 1280x720 or 1440x816 things get wierd. As only WMV9 and RV9 can cope.

Cheers

Sagittaire

22nd August 2003, 18:32

In the very high bitrates all the codecs are worth visually and even the MPEG2 is very powerful ...

but me what interests to me is the zone 570~950 Kbps and in this zone RV9 EHQ is the best for a normal encoding ...

In the zone 1000-1500 Kbps the WMV9 is little better for me but all the codecs are very good visually and even DivX3. It's thus useless to try to make comparative in this zone ...

With 3000 Kbps and more we can make MPEG2 720*576 with a very good quality then why use another codec?

The use of advanced codec (MPEG4 for example) in the very high bitrate is justified only if one uses very strong resolution (1024*704 or 1280*880 anamorphic for example)

For me what makes the power of a codec it's its encoding capacity in the weak BPF bit/(fps*pix) and in this zone RV9 EHQ is the best. More BPF is better and more the codecs are equivalent ...

CruNcher

22nd August 2003, 18:35

@ Sagittaire

yes my fault again XviD also didnt hold the 550 kbps as i wanted it

but with 536 kbps

7,90 MB (8.291.299 bytes) RV9 is still a little of :P

SeeMoreDigital

22nd August 2003, 19:21

Thanks for the reply Sagittaire.

I totally agree with you with regard to your interests. As I've always been interested in generating low bitrate encodes!

I've been very impressed with the new DivX beta's, as they really do seem to be able to offer much better quality 'low bitrate encodes' over DivXPro 5.0.5.

Unfortunately I think the Mp3 audio (.avi container) will let DivX down in the end, especially now, as RMV9 and WMV9 (.wmv) offer much better quality sounding audio at low bitrates (say 64kbps) and even 6Ch surround sound at 128kbps!

Also, yes, why bother encoding above 5000kbps with XviD, DivX RM9 and WMV9 when Mpeg2/AC3 DVD does a good job. Personnaly I think we should be experimenting with high-def type encodes at this bitrate. It's just a shame there is'nt very much in the way of 'source material' to experiment on. Well not in Europe anyway!

Cheers

CruNcher

22nd August 2003, 19:30

@ SeeMoreDigital

the bitrate saving is sure not in WMA or Real Audio its in AAC+

http://www.codingtechnologies.com/products/aacPlus.htm

sound test have shown that its far more advanced then Vorbis, WMA or RA in low bitrate conditions :)

btw

7,83 MB (8.219.912 bytes) RV9 im nearing the target :) i think 2 encodes more and i will hit almost the same size :)

SeeMoreDigital

22nd August 2003, 19:57

CruNcher

What you say may be right. I'll follow your link and give it a read!

But I as I have an Xcard I have to generate Mpeg4 (DivX) encodes. I've currently been testing Sorenson Squeeze 3.5 and creating 2pass VBR Mpeg4/AAC files which also play on the Xcard.

But as yet AAC+ does not appear to work on the Xcard. And it also can't be placed within an .avi container!

CruNcher

22nd August 2003, 20:38

@ All

ok im finished i didn't hit the size 100% RV9 has some bits more :P

7,75 MB (8.136.704 bytes) RV9
7,73 MB (8.112.498 bytes) XviD

the used script was the one from Sagittaire modified avg bitrate to hit the correct size

<?xml version="1.0" encoding="UTF-8"?>
<audience xmlns="http://ns.real.com/tools/audience.2.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://ns.real.com/tools/audience.2.0 http://ns.real.com/tools/audience.2.0.xsd">
<avgBitrate type="uint">515000</avgBitrate>
<maxBitrate type="uint">1200000</maxBitrate>
<streams>
<stream xsi:type="videoStream">
<pluginName type="string">rn-videocodec-realvideo</pluginName>
<codecName type="string">rv9</codecName>
<codecProperties type="bag">
<encoderComplexity type="uint">80</encoderComplexity>
<customPacketSize type="uint">16000</customPacketSize>
</codecProperties>
<encodingType type="string">vbrBitrate</encodingType>
<maxStartupLatency type="double">60</maxStartupLatency>
<maxFrameRate type="double">30</maxFrameRate>
<maxKeyFrameInterval type="double">10</maxKeyFrameInterval>
<enableLossProtection type="bool">false</enableLossProtection>
</stream>
</streams>
</audience>

the AVS used

low=MPEG2Source("pearlharbor.d2v",idct=5).crop(2,74,716,428).LumaFilter().UnDot().trim(17500,19000).LanczosResize(640,272)
high=MPEG2Source("pearlharbor.d2v",idct=5).crop(2,74,716,428).LumaFilter().UnDot().trim(7540,8980).LanczosResize(640,272)
low+high

ok its up same addres

http://www.mufflastig.com/CruNcher/XviD/phagain/

now you can compare my result is clear for me :)

especialy look in the faces not only in the static scene also in the shaky cockpit scene

SeeMoreDigital

22nd August 2003, 22:09

CruNcher

Your Pearl Harbour encode is most impressive.

Has it been encoded using RV9 EHQ or just RV9?

And can you confirm the source please. Was it PAL or NTSC as it looks a little speeded up?

Cheers

CruNcher

22nd August 2003, 23:17

@SeeMoreDigital

its the PAL Version :)
the sample up on the site is RV9 EHQ as you can see from the script that was used.

And this is no Sample from a Full Encode its a special test clip i did to gurantee real conditions and not some fuzzy theatrical trailer compare like Sagittaire like to do them

and you should also watch the XviD one if you not got it pm me :)

superdump

23rd August 2003, 09:36

From viewing the two clips, RV9 shows motion on the white background during the slow section and also appears to over compress the skin and make it look weirdly semi-flat in some areas rather than shapely as the faces should be. To its credit the line of the eye-test lady's cheek against her hair is absolutely immaculate and the detail preserved isn't too bad.

dev-api-4 exhibits what we call "block soup" on the sky during the high motion section and there are quite visible blocks elsewhere, but there is also more detail.

Both are good, neither are excellent. :) Personal preference once again.

SeeMoreDigital

23rd August 2003, 12:18

Both are good, neither are excellent. Personal preference once again.

Well I think when you take into consideration that CruNcher's RV9-EHQ clip was encoded at an average bitrate of just 545kbps. It's excellent!

Well done

Sigmatador

23rd August 2003, 12:50

RV9-EHQ is more plaisant for my eyes, sure ^^. MPEG-4 ASP can't really do anything against rv9 at this bitrate.

well, this is the expected results, but i'm sure PSNR-Man (aka Sagittaire) wants to do another (again) codec comparaison at low bitrate which allow him to say is jingle: "perroquet mode enabled: RV9-EHQ is the winner"

Sagittaire

23rd August 2003, 13:44

Not i am a little to tire and i don't know any more what to make to convince ...

One tells me XviD is better with the trailer of Matrix II ... I makes the encoding and I prove that RV9 EHQ is much better ...

Then one says to me with Pearl Harbour Xvid is much better ... but it's a very slow scene and thus very compressible thus all the codecs are powerful ...

Me I use trailer where see all the types of scenes (slow, fast, sinks, luminous...) and which are thus representative of films that we encode ...

Sirber

23rd August 2003, 13:50

Originally posted by Sigmatador
well, this is the expected results, but i'm sure PSNR-Man (aka Sagittaire) wants to do another (again) codec comparaison at low bitrate which allow him to say is jingle: "perroquet mode enabled: RV9-EHQ is the winner" IIRC the same thing was done for XviD vs DivX... :p

CruNcher

23rd August 2003, 15:24

@ Sagittaire
you can surely call my name you dont have to use "one" for that, but i didn't wanted to offend you in any way or you beliveings everyone has his own personal preferences as for me i like it sharp first reason for that is the filttering of TVS i have an old LG one and if i watch a RV9 clip on it i can see that the blurry gets blurrier, becuase of that a XviD looks like a RV9 on TV, so i don't want to loose anymore detail. I allways trie to preserve as much details as possible and RV9 can't guarantee that as you can see on the Skins of the Actors and this scene as i said it before is a real condition scene low motion is followed by high motion if you see 2 low motion scenes here Sagittaire sorry to say you must be blind. Read what Superdump wrote it's by far the most professional analysis of what i did and what i saw when this all started. And i hope tonight we can end it ;)

RV9
+ dont blocks
+ dont looks as washy as wavelets
+ clear lines
- stil looses details

XviD (MPEG4)
+ preserves details
- blocks (most times only really visible in high motion situations)
- lines are crapy

and i dont say RV9-EHQ clear winner its not at least not for me a mix up of them both would be a Clear Winner for me ;)

btw i uploaded the XviD sequence again for the people that missed it :)

Peters

23rd August 2003, 15:37

Originally posted by Sagittaire

Me I use trailer where see all the types of scenes (slow, fast, sinks, luminous...) and which are thus representative of films that we encode ...

It's noy very fair and you know that...
Because of his streaming origine, RV9 is almost a CBR codec (it's funny to see maxbitrate to 2x averagebitrate, i think it's useless)

So the power of RV9 works (also) with a short clip but the situation is very different for Xvid(or Divx) who are really VBR and who needs more than 2 mns to work

So a trailer isn't really representative of a whole movie encoding ...

For this reasons, Doom9 made his codecs comparisons whith full encodings

Sagittaire

23rd August 2003, 15:37

@ Cruncher

Sorry for "one" but i use an autotomatic traductor for french -> English sometimes ...

@ Peter

Peal Harbor has some scenes with very high motion (japones attack and boat explosion ...) and with this scenes and with this bitrate i'am curious to see result with XviD and RV9 with full encoding ...

Peters

23rd August 2003, 16:05

Originally posted by Sagittaire

@ Peter

Peal Harbor has some scenes with very high motion (japones attack and boat explosion ...) and with this scenes and with this bitrate i'am curious to see result with XviD and RV9 with full encoding ... [/B]

Understand me, even if you're right (probably) in your conclusion, i was discussing of the method, a trailer is not correct for making comparisons.

In fact, even if i found less details in RV9, this codec is very impressive. I dream of what we can expect if it will be a true VBR!

And it's a shame there are not( and never i'm afraid) RV9 Hardware players

superdump

23rd August 2003, 22:16

Originally posted by Sagittaire
i'am curious to see result with XviD and RV9 with full encoding ...

Then do it! Maybe then the differences between the codecs will become clearer and we won't have an excuse to criticise your results.

I wholely agree with Peters. RV9 is a very good codec as are XviD and WMV9. However, you cannot judge the absolute performance of the codecs solely on one encode, let alone a theatrical trailer. It does however give a fair idea and I understand that it isn't feasible or legal to upload full film encodes.

Sirber

23rd August 2003, 22:48

Originally posted by Peters
And it's a shame there are not( and never i'm afraid) RV9 Hardware players IIRC, Karl said that there were some people working of RV9 hardware players...

karl_lillevold

23rd August 2003, 22:56

@CruNcher: thanks for creating such a good comparison of some of the trade-offs that are being made, and how these affect video quality. First of all, this is a tough sequence for VBR, and like I have said a few times now, there is room for improvement in the current RV9 implementation. Then, with such a long sequence of high action at a low bitrate, on one side you have the blockiness/details of MPEG-4, on the other side the smoothing of RV9. Try to enable enough PP in MPEG-4 to remove all the blocks, and check the detail level then. I don't want to start an argument over what's more preferable, blocks/details or no artifacts/less details, but will simply accept that preferences vary, just like viewing conditions. Just like you mentioned, my 5 yr old TV is so much more forgiving than my LCD computer screen, but blocks still tend to show up. Ringing, however, not so easily. So an adjustable amount of post-processing is a nice property. As you all know by now, this is not available in RV9, and some will know why. Maybe we can come up with an adjustable post-enhancer, or maybe it will have to be a bitstream change for the next RV version.

@all: Thanks again for all the useful feedback. Considering the amount of resources we have in the video codec team at RealNetworks for comparisons and experiments, doom9 is our most resourceful input forum for suggestions.

@Peters: there is nothing specifically CBR about the RV9 codec. The rate control lives outside the codec, and the current VBR implementation is not bad, it's just not as tuned and tweakable as the VBR control included with other codecs.

Take a look at a plot of the RV9 bitrate over time (http://www.lillevold.com/files/png/bitrate.png) for the Pearl Harbor extract. This was obtained by DC's RMVB analyzer tool (http://forum.doom9.org/showthread.php?s=&threadid=55392). When I have some more time I will google for a similar tool for AVI files..

Re: RV9 in h/w players. Still a little ways off, but being worked on:
http://www.realnetworks.com/company/press/releases/2002/helix_client.html
for instance by ALi Corporation, a division of Acer, and a manufacturer for decoder chips in DVD players.