x264 vs VP70 vs VP62 vs RV10

[Sirber]

23 sec of latest naruto intro at 536kbps, 2pass VBR:

x264
Encoding time: 2m00s
Settings: default (b162 for amd64 (32bit)), 3 ref
Decoder: ffdshow default

x264 exibits squares when the scene focus and unfocus rapidly, motion errors in the yellow background with a fence. The last scene is low in details and seems washed.

VP70
Encoding time: 4m28s
Settings: default, sharpness 2/7
Decoder: vp70 default

Small squares appeir in the first part (yellow scene). Strange shapes appeir at the end.

VP62
Encoding time: 7m04s
Settings: default, sharpness 7/10, spacial resampling
Decoder: adaptive PP, no grain

Last scene is blurier than x264. Whitout PP, it's a field of squares :)

RV10
Encoding time: 2m01s
Settings: default, old RC, EHQ high
Decoder: HFE v2, no sharpening

The fence scene is heavily deblocked, and the last scene is very blur.

Files
Detritus: Source (8MB) (http://www.detritus.qc.ca/files/test.avi) - x264 (2MB) (http://www.detritus.qc.ca/files/test_x264.mkv) - VP70 (2MB) (http://www.detritus.qc.ca/files/test_vp70.mkv) - VP62 (2MB) (http://www.detritus.qc.ca/files/test_vp62.mkv) - RV10 (2MB) (http://www.detritus.qc.ca/files/test.rmvb)

Comments are welcome :D

[Sharktooth]

x264 link doesnt work, and rev169 doesnt exist (maybe 162) :)

[Sirber]

oups :o

Link corrected and build # updated. :D

[LAIN]

Hi,


this should be ok for the x264 link on the mirror, the file was named x246....


Lain

[Selur]

how about also taking neros avc into the comparison?

[Sirber]

I don't have Nero Recode, but if someone want to compress it and send me the file, I will add it.

[Gannjunior]

Sirber, r u sure encoding time of vp codec are correct? i think u have inverted them. ;)

ciao!

[Sirber]

Nope. Encoding time are correct. I heard VP7 had an issue with Athlon CPU, that might explain the filesize.

[Gannjunior]

Something sounds strange: i noticed vp7 1st pass is about 40% faster than vp6 1st pass but vp7 2nd pass is 3 times slower than vp6 2nd pass, so global encoding time is drastically slower for VP7 compared than vp6...and i'm sure many other people has the same feedback about encoding time. And it's strange vp6 in your test performed more than 2 times slower than vp7...:confused:

ciao!!

[*.mp4 guy]

I made a succesful VP7 encode, however its oversized. Luckily its not anymore oversized then the Real Media sample so it shouldn't be a problem

Test-VP7-2 (http://x4.putfile.com/videos/6920132020.avi)

Hosting by Putfile (http://www.putfile.com)

[Sirber]

you encoded my test.avi? What are your CPU specs?

[SpaceV]

ha, finally people are experiencing the same thing I was
posting yesterday. VP7 file size is HUGE.

I think it also depends on the encoding app.

VDubMod seems to work but DVDx does not.

Btw I have an Athlon64 3500+ (overclocked).

Is there any more info on the VP7 Athlon bug?

[Sirber]

I had it with avs2avi 1.39x. I heard the VP7 clip was full of iframes, high Q one and low Q one. Should be fixed soon.

[dragongodz]

VDubMod seems to work but DVDx does not.
i pass sizes fine with DVDx as i said back in the VP7 thread. will try 2 pass soon aswell.

I think it also depends on the encoding app.
but of course is not really the encoding apps fault. this is a bug in the codec since its the codec thats deciding what frames at what size to encode.

[*.mp4 guy]

My cpu is an Athlon xp 2800 @ stock clockrate. I think the issue is the encoding app because I've only used it with virtualdub and it's always worked correctly and given close to the set bitrate for the output.

[dragongodz]

I think the issue is the encoding app because I've only used it with virtualdub and it's always worked correctly and given close to the set bitrate for the output.
oh so i missed the memo about the Virtualdub way being the only correct way then ?

so you THINK its the other apps fault ? hmm so the fact that other codecs such as Xvid, Divx and even VP6 all work fine ,means nothing right ? no of COURSE it couldnt be the codecs fault could it. riiiight.

[dwrbudr]

I cannot play the x264 movie at all on my P3-733 Mhz @work. It loads, plays about 1 sec and gives me an exception using the latest Media Player Classic 6.4.8.3 + ffdshow-20050303-sse.exe. Yeah, I know that the CPU is old, but is SSE capable. Maybe something wrong with that ffdshow. From the 1 second I saw, I can say that x264 picture is very blocky like the old DivX 3.11 days :cool:

[SpaceV]

Guys,
I downloaded 6.4.8.3 of Media Player Classic
and its file size is 4,696KB.

My older 6.4.8.2 is only 1,309 KB.

Why is the new version 3 times larger.
They both seem to work fine.

The I frame thing sounds reasonable, the quality of the "encode"
is pretty good but I also saw the jumpyness.

Hope we have the fix next week.

[Sharktooth]

Originally posted by *.mp4 guy
I made a succesful VP7 encode, however its oversized. Luckily its not anymore oversized then the Real Media sample so it shouldn't be a problem

Test-VP7-2 (http://x4.putfile.com/videos/6920132020.avi)

Hosting by Putfile (http://www.putfile.com)
It seems it tops the other codecs with this clip. However re-encode the x264 clip with the new rev 164.

[*.mp4 guy]

I think the issue is the encoding app because I've only used it with virtualdub and it's always worked correctly and given close to the set bitrate for the output

oh so i missed the memo about the Virtualdub way being the only correct way then ?

so you THINK its the other apps fault ? hmm so the fact that other codecs such as Xvid, Divx and even VP6 all work fine ,means nothing right ? no of COURSE it couldnt be the codecs fault could it. riiiight..

Wow talk about being misquoted/understood. This codec obviously still has some issues to work through (cough cough speed) I was only pointing out that the problem with the CODEC only manifests itself in SOME programs and that a good workaround is to use virtualdud.

Furthermore I don't apreciate you infering that I was saying anymore then was specifically stated, all I was saying was that the problem doesn't occur in every encoding app, and therefore there are a lot of diffeerent possibilities. Maybe I should have worded my post more clearly.

[On2Tech]

Originally posted by dragongodz
so you THINK its the other apps fault ? hmm so the fact that other codecs such as Xvid, Divx and even VP6 all work fine ,means nothing right ? no of COURSE it couldnt be the codecs fault could it. riiiight.


Our working assumption is that with some applications and in certain situations the encode parameters are getting corrupted. At least a couple of people now have seen similar odd behavior and we are taking fixing this problem very seriously. Sirber has kindly supplied us with details of his test environment and settings, for which we are grateful. In his case the clip got coded “all key frames” (which may explain the high encode speed as well, as with key frames there is no motion searching to be done).

If anybody else has similar problems please feel free to post details to On2Tech@on2.com. We want the codec to work in the widest possible range of environments and the more information you can give us on any problems you observe the better.

Regarding speed. Since the first beta we have already improved speed quite a lot (almost doubled) and will be working hard to get further speed improvements ASAP.

Thanks to everyone for giving the codec a shot, and for your patience as we address some of these issues.

On2Tech

[Sirber]

Good. Can't wait for the next build :D

[dragongodz]

Wow talk about being misquoted/understood.
there was no misquote and as for misunderstanding that would be hard with what you wrote.
I think the issue is the encoding app
hard to misunderstand that part isnt it ? you say its the app and not the codecs fault.
because I've only used it with virtualdub and it's always worked correctly
and this is what you base it on, so long as it works in virtualdub then it is the other apps fault. again a bit hard to misunderstand.

Furthermore I don't apreciate you infering that I was saying anymore then was specifically stated, all I was saying was that the problem doesn't occur in every encoding app, and therefore there are a lot of diffeerent possibilities. Maybe I should have worded my post more clearly.
first i did not try and say you said more than you did. if you fail to say what you really mean and mean other than what you do say then thats not my fault.

On2Tech - i already sent a bug report to support but i will email you a copy aswell.

[mikeson]

Originally posted by SpaceV
Guys,
I downloaded 6.4.8.3 of Media Player Classic
and its file size is 4,696KB.

My older 6.4.8.2 is only 1,309 KB.

Why is the new version 3 times larger.
They both seem to work fine.


MPC 6.4.8.3 is compressed by UPX.

[Selur]

can't add neros codec since the recode only allows a minimum target size of 30mb :(

[celtic_druid]

You could always untick fit to target.

[Selur]

doh,...
encoded with 'Nero - Standard AVC' + max reference frames 2
(encoded a with a datarate of 536 (=>1.6MB) and of 716 (=>2MB))
grab it here:
http://rapidshare.de/files/854293/Nero_Recode.zip.html
(scroll down, press 'free')

Cu Selur

[Sagittaire]

Nero with best setting: Nero AVC + HE-AAC (http://multimediacom.free.fr/Video/NDAVC-600.mp4)

Video Elementary stream: 535 Kbps
Audio Elementary stream: 65 Kbps
Size Files: 1771 Ko

[Sirber]

Cool! I will check it and add it to my main post :D

[Sharktooth]

x264 encode @ 536kbps (5 refs, 2 b-frames -> pyramid & w-pred. enabled)
Removed

[Sagittaire]

Don't active bref frame with x264: it's buggy with ateme and ffdshow dec and 100% CPU peak with Nero AVC dec ...

[celtic_druid]

Plays ok here, just not via haali's splitter.

[Sirber]

I removed haali's splitter. It crashes Helix Producer when encoding audio MKVs.

[Sirber]

Originally posted by Sharktooth
x264 encode @ 536kbps (5 refs, 2 b-frames -> pyramid & w-pred. enabled)
http://www.aziendeassociate.com/test_x264_r169.mkv Doesn't work on my system. I get squares then it crash.

[buzzqw]

i can play video it only demuxing from mkv (avi,mp3)
and disabling in ffdshow h264 (and so using nero decoder)

BHH

[Sirber]

Originally posted by Sagittaire
Nero with best setting: Nero AVC + HE-AAC (http://multimediacom.free.fr/Video/NDAVC-600.mp4)

Video Elementary stream: 535 Kbps
Audio Elementary stream: 65 Kbps
Size Files: 1771 Ko I don't know why, but I can't play it back now :confused:

[celtic_druid]

Well I would have been using this version of ffdshow:
http://www.aziendeassociate.it/cd//ffdshow/ffdshow-20050312.exe
and this version of MPC:
http://hp.vector.co.jp/authors/VA022257/misc/mplayerc2005.03.14.2kxp.7z

Also works fine with mplayer.

[Sharktooth]

OT: Media player Classic is being mirrored.

[Palikrovol]

I have installed MPC_20050314

I can view "test_x264_r169.mkv" only with the internal matroska MPC splitter, if i use Haali's, MPC's minutes counter keeps in 00:00.

I can't view the "Nero AVC + HE-AAC" from Sagittaire with ffdshow_20050312, if i use ffdshow _20050303 or Nero decoder, it works.

[Sharktooth]

Originally posted by Palikrovol
I have installed MPC_20050314...
It crashes for me :(

BTW, new rev171 encode (same settings as the previuos rev169 encode + 15 refs): http://www.aziendeassociate.com/test_x264_r171.avi

[celtic_druid]

Yeah, looks like I screwed something up with libavcodec in the last ffdshow build.

[Sirber]

Tryed beta 4, still getting huge files :( Encoding is 30% faster though :D

[Sagittaire]

Nero with best setting: Nero AVC + HE-AAC (http://multimediacom.free.fr/Video/NDAVC-600.mp4)
Video Elementary stream: 535 Kbps
Audio Elementary stream: 65 Kbps
Size Files: 1771 Ko

RV10 with best setting: RV10 + HE-AAC (http://multimediacom.free.fr/Video/RV10-600.rmvb)
Video Elementary stream: 536 Kbps
Audio Elementary stream: 64 Kbps
Size Files: 1783 Ko


IMO with real ~536 Kbps for VES NDAVC is very better than RV10: less block, less ring, more sharp for NDAVC. If you want real comparison in high quant (low quality) you must use the same bitrate. With +/-1% for real EVS bitrate the visual quality difference must be very important because average high quant encoding is in high variability quality zone.

[huang_ch]

Originally posted by Sagittaire
IMO with real ~536 Kbps for VES NDAVC is very better than RV10: less block, less ring, more sharp for NDAVC. If you want real comparison in high quant (low quality) you must use the same bitrate. With +/-1% for real EVS bitrate the visual quality difference must be very important because average high quant encoding is in high variability quality zone. [/B]

It seems that, my eyes are really not suitable for making this kind of comparison:o I can't see major difference between these 2, can you point out when is the 2 videos show the most obvious difference? Thanks.:)

[Amdh]

:)
Well .. I'm not an expert .. I haven't red all the replies however I have made a very small test on an MPEG2 Slow motion material !
x264 and H264 Codecs seem to give better quality than VP7 even if VP7 seems to be better than VP 6.2 !

[Sirber]

Updated VP7 clip with latest beta 4.1. Size is now normal.