Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Video Encoding > MPEG-4 AVC / H.264

Reply
 
Thread Tools Search this Thread Display Modes
Old 31st March 2009, 21:30   #41  |  Link
dj_tjerk
Registered User
 
Join Date: Jun 2008
Posts: 15
The goal is to be as close to the original as possible right? I don't know how well eyes can compare two videos; I just have a feeling that ears are a lot better at picking out small differences in audio than eyes are at picking out differences in video. Add that eyes only focus on a very small part of the screen (1cm^2 at about 50cm distance). You'd need to compare iamges if you want to compare the quality of the entire frame, but then you get high-motion/slow-motion issues/grain retention/etc..

Comparing images is easier, there have a couple of those here at doom9 before. It's easier to see changes 'happening' when you click an the "original" and it changes to "encode". (And you can do so multiple times).

Anyway, if this comparison judges codecs based on SSIM, then the encoders should just optimize for SSIM. It might give some indication of how much detail (and what kind of) detail it retains and how long an encoder takes to do that.

Last edited by dj_tjerk; 31st March 2009 at 21:35.
dj_tjerk is offline   Reply With Quote
Old 31st March 2009, 21:46   #42  |  Link
Dark Shikari
x264 developer
 
Dark Shikari's Avatar
 
Join Date: Sep 2005
Posts: 8,690
Quote:
Originally Posted by Sagittaire View Post
psy rdo use simply SSD metric for choose better RD decision.
Perhaps if people keep thinking this it'll be longer before another encoder implements something comparable...
Dark Shikari is offline   Reply With Quote
Old 1st April 2009, 09:36   #43  |  Link
Gabriel_Bouvigne
L.A.M.E. developer
 
Gabriel_Bouvigne's Avatar
 
Join Date: Dec 2001
Location: Paris - France
Posts: 276
Quote:
Originally Posted by dj_tjerk View Post
The goal is to be as close to the original as possible right?
Only at mid/high bitrate (1.5Mbps is NOT low bitrate) and if the encoder is only using brute-force RD optims. Once you start adding things like psychovisual frame optimizations, ROI or anti-flickering, then simple frame by frame comparisons using psnr or ssim are starting to be less relevant.

(unless you are not encoding video for human viewers but for stuff like latter-stage segmentation, objects extractions,...)
Gabriel_Bouvigne is offline   Reply With Quote
Old 1st April 2009, 13:04   #44  |  Link
Sharktooth
Mr. Sandman
 
Sharktooth's Avatar
 
Join Date: Sep 2003
Location: Haddonfield, IL
Posts: 11,768
Quote:
Originally Posted by Sagittaire View Post
psy tool for x264 are metric tools by itself ... lol

- AQ measure complexity block
- psy rdo use simply SSD metric for choose better RD decision.

I have impression when I read your thread that psy for x264 is like magical tools. Psy tools use simply other metric tools for better complexity/texture detection.
so you're basically saying the default metrics (PSNR, SSIM) fails miserably and other metrics are needed to enhance the picture. maybe there are some other metrics that will enhance the picture for dogs or cats...
that's again a proof that metrics are not representing perceived quality and a proof there is no metric that can represent the human eye perception.
please, stop... it's been years you're telling always the same things... but you always forget that:
A) a number cant represent a picture.
B) metrics measure differencies, not quality
C) quality IS what please the EYE (details, vivid colors, no artifacts... etc.) not the PSNR or other metrics.

Last edited by Sharktooth; 1st April 2009 at 13:07.
Sharktooth is offline   Reply With Quote
Old 1st April 2009, 21:07   #45  |  Link
dj_tjerk
Registered User
 
Join Date: Jun 2008
Posts: 15
Heh, vivid colors; so if the encoder does tweak(sat=1.1) internally, it's a better encode? (Because the human eye, or rather brain, likes vivid colors.)
dj_tjerk is offline   Reply With Quote
Old 1st April 2009, 21:20   #46  |  Link
Sagekilla
x264aholic
 
Join Date: Jul 2007
Location: New York
Posts: 1,752
Not quite. If one encoder somehow produces a duller looking image than the source, then a comparable encoder that can produce an image with identical saturation to the source would look better than the duller one.
__________________
You can't call your encoding speed slow until you start measuring in seconds per frame.
Sagekilla is offline   Reply With Quote
Old 1st April 2009, 21:42   #47  |  Link
Esurnir
Registered User
 
Join Date: Jun 2008
Posts: 143
Quote:
Originally Posted by Sharktooth View Post
so you're basically saying the default metrics (PSNR, SSIM) fails miserably and other metrics are needed to enhance the picture. maybe there are some other metrics that will enhance the picture for dogs or cats...
that's again a proof that metrics are not representing perceived quality and a proof there is no metric that can represent the human eye perception.
please, stop... it's been years you're telling always the same things... but you always forget that:
A) a number cant represent a picture.
B) metrics measure differencies, not quality
C) quality IS what please the EYE (details, vivid colors, no artifacts... etc.) not the PSNR or other metrics.
A number certainly can represent a picture, my picasa's album is entirely made of number and they are well satisfied of the quality of it,

B) Metric in the end is the -only- way you can make choice in an encoders save if you want to place every single motion vectors and do every single quantisation by hands you'll have to use a metric somewhere, and even the Sum of Average Difference is enough to reject the most obvious bad choices.

C) The aim of an encoder is to make a picture that is "high-fidelity" that is the nearest of the original pictures as possible, no matter how crappy the source was. If the source was a youtube .flv file blocky as hell with washed out colors then the best encoders will output a picture blocky as hell with washed out color. To make a picture that please is the job of the pre-processing which can adjust saturation, enhance contrast, remove noise and sharpen things. After that on the picture I showed, it is clear than psy-rdo preserve details better than the blurrier murkier pictures of other h.264 encoder, even if the psnr could be lower, even if the grain is not where it should be and some grain could very well be ringing, it's still grainy, and that's what my eyes will remember.
Esurnir is offline   Reply With Quote
Old 1st April 2009, 22:03   #48  |  Link
Sagekilla
x264aholic
 
Join Date: Jul 2007
Location: New York
Posts: 1,752
Esurnir: That's not news that you need to use metrics to make decisions. This is well known. There is no known metric out there that can accurately provide a mathematical model of how the human eye perceives images. Therefore, we can't optimize for a metric that is visually pleasing.

If such a metric existed, we could simply try to encode for whatever provides the highest value for that hypothetical metric. Until then, we have only poor approximations that consider soft images to look better than sharper ones. (Read: no psy-rd vs psy-rd)
__________________
You can't call your encoding speed slow until you start measuring in seconds per frame.
Sagekilla is offline   Reply With Quote
Old 2nd April 2009, 01:20   #49  |  Link
Sharktooth
Mr. Sandman
 
Sharktooth's Avatar
 
Join Date: Sep 2003
Location: Haddonfield, IL
Posts: 11,768
Quote:
Originally Posted by Esurnir View Post
A number certainly can represent a picture, my picasa's album is entirely made of number and they are well satisfied of the quality of it,

B) Metric in the end is the -only- way you can make choice in an encoders save if you want to place every single motion vectors and do every single quantisation by hands you'll have to use a metric somewhere, and even the Sum of Average Difference is enough to reject the most obvious bad choices.

C) The aim of an encoder is to make a picture that is "high-fidelity" that is the nearest of the original pictures as possible, no matter how crappy the source was. If the source was a youtube .flv file blocky as hell with washed out colors then the best encoders will output a picture blocky as hell with washed out color. To make a picture that please is the job of the pre-processing which can adjust saturation, enhance contrast, remove noise and sharpen things. After that on the picture I showed, it is clear than psy-rdo preserve details better than the blurrier murkier pictures of other h.264 encoder, even if the psnr could be lower, even if the grain is not where it should be and some grain could very well be ringing, it's still grainy, and that's what my eyes will remember.
A) i didnt say "numbers"... i said "a number" meaning a single number of (in our case) 2 digits and some decimals.

B) using metrics for decisions is "optimizing". that's usually done for encoding speed. instead of taking into account all the "candidates", some get discarded. that, for sure, hurts quality. how much quality is loss depends on the algos.

C) wrong. the aim of an encoder is to reach the best quality/compression ratio. so if an encoder can, for example, sistematically reconstruct details from an artifact and keep a reasonable compression, then it's a good encoder. that's why ppl use filters before encoding... a similar reason justifies the use of psy-trellis in x264 (it doesnt "keep" the grain exactly as in the source, it just fools the eyes... and in most cases, when it's needed, it does it damn good...).

Last edited by Sharktooth; 2nd April 2009 at 01:26.
Sharktooth is offline   Reply With Quote
Reply

Tags
codecs, comparison, h.264/avc

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 06:34.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2017, vBulletin Solutions Inc.