site about video codec comparison?

[lansing]

I remember seeing somewhere in the forum a link to a site that compare all the video codecs. Like there's a picture on top and a list of codec names below it, and when I click on a codec name, it will display its compression quality on the image above.

Anyone still recall the site?

[Dark Shikari]

I remember seeing somewhere in the forum a link to a site that compare all the video codecs. Like there's a picture on top and a list of codec names below it, and when I click on a codec name, it will display its compression quality on the image above.

Anyone still recall the site?This one (http://mirror05.x264.nl/Dark/website/compare.html)?

[lansing]

yes, that's it, thanks

[St Devious]

This one (http://mirror05.x264.nl/Dark/website/compare.html)?

WOW nice !

Btw How would you describe the difference between 1. x264 and Xvid and 2. Divx and Xivd in the "300" image.

I'm thinking 1. is more blocky in Xvid, but don't know if that's the right technical term.

and 2. Divx is softer compared to Xvid.

Is there a software to play these videos side by side to see the difference in motion ?

like AvsP can sort of do for Images.

[Dark Shikari]

WOW nice !

Btw How would you describe the difference between 1. x264 and Xvid and 2. Divx and Xivd in the "300" image.

I'm thinking 1. is more blocky in Xvid, but don't know if that's the right technical term.

and 2. Divx is softer compared to Xvid. This is because Xvid uses a lower deadzone than DivX does, hence the blockiness-softness tradeoff.

[poisondeathray]

Is there a software to play these videos side by side to see the difference in motion ?

like AvsP can sort of do for Images.


You could use avisynth's stackvertical() or stackhorizontal() to play them side by side or on top of each other by playing the .avs in a media player

[St Devious]

You could use avisynth's stackvertical() or stackhorizontal() to play them side by side or on top of each other by playing the .avs in a media player

In a post here (http://forum.doom9.org/showthread.php?p=1296655#post1296655) Dark said,
Never compare by opening two videos at the same time, as usually your graphics card overlay can only accelerate one at a time, so the second one is not always identical.

Would that affect the above Avisynth script in AvsP ?

Oh and instead of a media player, can i do that in AvsP ?

[poisondeathray]

It works fine, because it's only 1 avs script in 1 instance of a media player (so only 1 instance of the video card overlay is used). Dark S.'s comment refers to multiple instances of media players

Yes, you can do it with avsp only as well

[St Devious]

It works fine, because it's only 1 avs script in 1 instance of a media player (so only 1 instance of the video card overlay is used). Dark S.'s comment refers to multiple instances of media players

Yes, you can do it with avsp only as well

got it, thanks :goodpost:

[Ramir Gonzales]

If I remember correctly, Someone very special (http://forum.doom9.org/member.php?u=83421) told us screenshots have no value to compare codecs.:rolleyes:

[Dark Shikari]

If I remember correctly, Someone very special (http://forum.doom9.org/member.php?u=83421) told us screenshots have no value to compare codecs.:rolleyes:Screenshots have value; you just have to be careful.

In particular, the following "gotchas" apply:

1. Do the two encoders you're comparing have different ratecontrol approaches? If so, one might look worse in a high complexity scene but better in a lower complexity one, or the reverse.

2. Are you comparing between different frametypes? A B-frame might look worse than a P-frame, for example. This is easy to avoid in comparisons between one or two encoders, but impossible to avoid in comparisons with many encoders, especially between very different video formats.

3. Does a particular encoder have very bad (or good) temporal stability? It won't show up in a screenshot.

This doesn't make screenshots useless; it just makes them incomplete as a way to compare video encoders. The primary problem is that visual comparisons "in motion" are incredibly hard to do objectively, especially when differences between two encodes are subtle.

One way to avoid this problem is to use many randomly-selected screenshots from the same clip in order to limit the bias effects involved in any particular one.