Log in

View Full Version : help interpreting x264 samples drf analysis

Kumo
15th February 2008, 16:11
i'm trying to convert to x264 via megui a dvd.i did 2 samples,avinaptic reports this stats from them.

[ About file ]

Name: 01 def sample.mkv
Date: 13/02/2008 23:27:08
Size: 16,370,977 bytes (15.613 MB)

[ Generic infos ]

Play duration: 00:01:22 (82.082 s)
Container type: matroska
Number of streams: 1
Type of stream nr. 1: video (V_MPEG4/ISO/AVC)
Audio streams: 0
Muxing Application: Haali Matroska Writer b0
Writing Application: x264

[ Relevant data ]

Resolution: 720 x 480
Width: multiple of 16
Height: multiple of 32
Average DRF: 18.652947
Standard deviation: 1.194491
Std. dev. weighted mean: 0.668083

[ Video track ]

Codec ID: V_MPEG4/ISO/AVC
Resolution: 720 x 480
Frame aspect ratio: 3:2 = 1.5
Pixel aspect ratio: 1:1 = 1
Display aspect ratio: 3:2 = 1.5
Framerate: 23.976024 fps
Stream size: 16,342,323 bytes
Play duration: 00:01:22 (82.081999 s)
Bitrate: 1592.780208 kbps
Qf: 0.192222

[ About H.264 encoding ]

User data: x264
User data: core 58 svn-736M
User data: H.264/MPEG-4 AVC codec
User data: Copyleft 2003-2008
User data: http://www.videolan.org/x264.html
User data: cabac=1
User data: ref=16
User data: deblock=1:0:0
User data: analyse=0x3:0x113
User data: me=esa
User data: subme=7
User data: me-prepass=0
User data: brdo=1
User data: mixed_ref=1
User data: me_range=16
User data: chroma_me=1
User data: trellis=2
User data: 8x8dct=1
User data: cqm=0
User data: deadzone=21,11
User data: chroma_qp_offset=0
User data: threads=3
User data: nr=0
User data: decimate=0
User data: mbaff=0
User data: bframes=16
User data: b_pyramid=1
User data: b_adapt=1
User data: b_bias=0
User data: direct=3
User data: wpredb=1
User data: bime=1
User data: keyint=250
User data: keyint_min=25
User data: scenecut=40(pre)
User data: rc=2pass
User data: bitrate=1580
User data: ratetol=1.0
User data: rceq='blurCplx^(1-qComp)'
User data: qcomp=1.00
User data: qpmin=10
User data: qpmax=51
User data: qpstep=4
User data: cplxblur=20.0
User data: qblur=0.5
User data: ip_ratio=1.40
User data: pb_ratio=1.30
User data: aq=1:0.5:13.0
SPS id: 0
Profile: High@L5.1
Num ref frames: 16
Aspect ratio: Square pixels
Chroma format idc: YUV 4:2:0
PPS id: 0 (SPS: 0)
Entropy coding type: CABAC
Weighted prediction: No
Weighted bipred idc: B slices - implicit weighted prediction
8x8dct: Yes
Number of frames: 1968
Drop/delay frames: 0
Corrupted frames: 0

P-slices: 937 ( 47.612 %) ############
B-slices: 1007 ( 51.169 %) #############
I-slices: 24 ( 1.220 %)
SP-slices: 0 ( 0.000 %)
SI-slices: 0 ( 0.000 %)

[ DRF analysis ]

Average DRF: 18.652947
Standard deviation: 1.194491
Max DRF: 21

DRF<15: 0 ( 0.000 %)
DRF=15: 1 ( 0.051 %)
DRF=16: 25 ( 1.270 %)
DRF=17: 314 ( 15.955 %) ####
DRF=18: 671 ( 34.096 %) #########
DRF=19: 353 ( 17.937 %) ####
DRF=20: 513 ( 26.067 %) #######
DRF=21: 91 ( 4.624 %) #
DRF>21: 0 ( 0.000 %)

P-slices average DRF: 17.692636
P-slices std. deviation: 0.555826
P-slices max DRF: 19

B-slices average DRF: 19.602780
B-slices std. deviation: 0.773899
B-slices max DRF: 21

I-slices average DRF: 16.291666
I-slices std. deviation: 0.610953
I-slices max DRF: 18

[ Profile compliancy ]

Profile to check: MTK PAL 6000
Resolution: Ok
Framerate: 23.976024 <> 25
Min buffer fill: 54%

This report was created by AVInaptic (18-11-2007) on 15 feb 2008, h 16:09:24

[ About file ]

Name: 01 def sample+dub.mkv
Date: 15/02/2008 14:39:18
Size: 16,389,546 bytes (15.63 MB)

[ Generic infos ]

Play duration: 00:01:22 (82.082 s)
Container type: matroska
Number of streams: 1
Type of stream nr. 1: video (V_MPEG4/ISO/AVC)
Audio streams: 0
Muxing Application: Haali Matroska Writer b0
Writing Application: x264

[ Relevant data ]

Resolution: 720 x 480
Width: multiple of 16
Height: multiple of 32
Average DRF: 18.224085
Standard deviation: 1.223536
Std. dev. weighted mean: 0.716260

[ Video track ]

Codec ID: V_MPEG4/ISO/AVC
Resolution: 720 x 480
Frame aspect ratio: 3:2 = 1.5
Pixel aspect ratio: 1:1 = 1
Display aspect ratio: 3:2 = 1.5
Framerate: 23.976024 fps
Stream size: 16,361,073 bytes
Play duration: 00:01:22 (82.081999 s)
Bitrate: 1594.607649 kbps
Qf: 0.192443

[ About H.264 encoding ]

User data: x264
User data: core 58 svn-736M
User data: H.264/MPEG-4 AVC codec
User data: Copyleft 2003-2008
User data: http://www.videolan.org/x264.html
User data: cabac=1
User data: ref=16
User data: deblock=1:0:0
User data: analyse=0x3:0x113
User data: me=esa
User data: subme=7
User data: me-prepass=0
User data: brdo=1
User data: mixed_ref=1
User data: me_range=16
User data: chroma_me=1
User data: trellis=2
User data: 8x8dct=1
User data: cqm=0
User data: deadzone=21,11
User data: chroma_qp_offset=0
User data: threads=3
User data: nr=0
User data: decimate=0
User data: mbaff=0
User data: bframes=16
User data: b_pyramid=1
User data: b_adapt=1
User data: b_bias=0
User data: direct=3
User data: wpredb=1
User data: bime=1
User data: keyint=250
User data: keyint_min=25
User data: scenecut=40(pre)
User data: rc=2pass
User data: bitrate=1580
User data: ratetol=1.0
User data: rceq='blurCplx^(1-qComp)'
User data: qcomp=1.00
User data: qpmin=10
User data: qpmax=51
User data: qpstep=4
User data: cplxblur=20.0
User data: qblur=0.5
User data: ip_ratio=1.40
User data: pb_ratio=1.30
User data: aq=1:0.5:13.0
SPS id: 0
Profile: High@L5.1
Num ref frames: 16
Aspect ratio: Square pixels
Chroma format idc: YUV 4:2:0
PPS id: 0 (SPS: 0)
Entropy coding type: CABAC
Weighted prediction: No
Weighted bipred idc: B slices - implicit weighted prediction
8x8dct: Yes
Number of frames: 1968
Drop/delay frames: 0
Corrupted frames: 0

P-slices: 1112 ( 56.504 %) ##############
B-slices: 832 ( 42.276 %) ###########
I-slices: 24 ( 1.220 %)
SP-slices: 0 ( 0.000 %)
SI-slices: 0 ( 0.000 %)

[ DRF analysis ]

Average DRF: 18.224085
Standard deviation: 1.223536
Max DRF: 21

DRF<15: 0 ( 0.000 %)
DRF=15: 5 ( 0.254 %)
DRF=16: 58 ( 2.947 %) #
DRF=17: 608 ( 30.894 %) ########
DRF=18: 549 ( 27.896 %) #######
DRF=19: 374 ( 19.004 %) #####
DRF=20: 316 ( 16.057 %) ####
DRF=21: 58 ( 2.947 %) #
DRF>21: 0 ( 0.000 %)

P-slices average DRF: 17.419064
P-slices std. deviation: 0.625245
P-slices max DRF: 19

B-slices average DRF: 19.362980
B-slices std. deviation: 0.840944
B-slices max DRF: 21

I-slices average DRF: 16.041666
I-slices std. deviation: 0.610953
I-slices max DRF: 17

[ Profile compliancy ]

Profile to check: MTK PAL 6000
Resolution: Ok
Framerate: 23.976024 <> 25
Min buffer fill: 48%

This report was created by AVInaptic (18-11-2007) on 15 feb 2008, h 16:09:10

can anyone tell me if the encodings are correct and wich one is suppose to be better?there's any other way to understand if the quality of resulting x264 encoded videos is good?
Dark Shikari
15th February 2008, 16:19
DRF is not a valid measure of quality to begin with.

With adaptive quantization now popular, its even less valid than before, because Avinaptic (AFAIK) reports frame quantizers, not even the average of macroblock quantizers.

Use your eyes, or perhaps the SSIM value reported by x264.
cogman
15th February 2008, 18:43
exactly as Dark said, your Eyes > SSIM > PRSM > anything else. Use a combo of your eyes and SSIM to get a fairly good Idea of how good the video is. Unfortunately, everyone has different tastes, that means that what I think is crap you might think looks great (or visa versa).

For me, I Find the SSIM value to be pretty close to what I think the video looks like, so it is usually a good measure of what my video looks like
Don_Genaro
15th February 2008, 20:14
Agreed with Dak Shikari and Cogman.

You should try using MSU Video Quality Measurement Tool from www.compression.ru/ to compare the original and coded samples and establish the simm and psnr factors of the coded samples.
Avenger007
18th February 2008, 02:17
With adaptive quantization now popular, its even less valid than before, because Avinaptic (AFAIK) reports frame quantizers, not even the average of macroblock quantizers.
Is that why the DRF distribution doesn't appear as a normal distribution (statistically speaking)?

DRF<15: 0 ( 0.000 %)
DRF=15: 1 ( 0.051 %)
DRF=16: 25 ( 1.270 %)
DRF=17: 314 ( 15.955 %) ####
DRF=18: 671 ( 34.096 %) #########
DRF=19: 353 ( 17.937 %) ####
DRF=20: 513 ( 26.067 %) #######
DRF=21: 91 ( 4.624 %) #
DRF>21: 0 ( 0.000 %)

A normal distribution might ideally look like:

DRF=14: #
DRF=15: ##
DRF=16: ###
DRF=17: ######
DRF=18: #######
DRF=19: ######
DRF=20: ###
DRF=21: ##
DRF=22: #

That's the type of DRF distribution I get when using x264 svn-736.
x264 svn-736M seems to restrict DRF values based on the type of frame, thus resulting in a smaller range of DRF values. In the example above, it appears that almost all I-frames get DRF=16, almost all P-frames get DRF=17.7 (+-0.5) and most B-frames get DRF=19.8 (+-0.7). The x264 [info] in the MeGUI log file would give more accurate QP values.

I've encoded about 10 clips comparing svn-736 with svn-736M and all 736M DRF distribution look weird and restricted as above but all 736 have a normal distribution and a wider range. That's why I'm still using svn-736 instead of svn-736M.:p

can anyone tell me if the encodings are correct and wich one is suppose to be better?there's any other way to understand if the quality of resulting x264 encoded videos is good?
A lower DRF is generally better, but yeah, SSIM is probably the best objective way to tell if the quality of resulting x264 encoded videos is good.
Dark Shikari
18th February 2008, 02:22
I've encoded about 10 clips comparing svn-736 with svn-736M and all 736M DRF distribution look weird and restricted as above but all 736 have a normal distribution and a wider range. That's why I'm still using svn-736 instead of svn-736M.:pThis is nonsensical; you're looking at frame QP instead of macroblock QP, even though frame QP is totally meaningless when using AQ.

"DRF" is not a valid measure of quality, period. A "bad DRF distribution" is not a reason to avoid using a better build.

The QP distribution is *NOT* supposed to be a normal distribution, because I-frames are supposed to have lower quantizers than P-frames, and B-frames are supposed to have higher quantizers than P-frames.
Sharktooth
18th February 2008, 04:32
so true, so true...
DRF is meaningless as well as other measures that does not take into consideration the source compressibility.
Avenger007
18th February 2008, 05:14
This is nonsensical...
No need to get emotional:rolleyes:, I was just making an observation. But I think I'll still stick with whatever is the current revision on x264.nl/ (http://www.x264.nl/):cool:
Dark Shikari
18th February 2008, 05:22
No need to get emotionalI'm not, I'm simply stating the facts.
I was just making an observation. But I think I'll still stick with whatever is the current revision on x264.nl/ (http://www.x264.nl/):cool:So if I upload the latest AQ build to x264.nl (http://mirror05.x264.nl/Dark/force.php?file=./x264.736.AQ.exe), you'll use it? ;)

There are some very good reasons (http://i32.tinypic.com/x3ibh1.gif) to use AQ, but if you don't want to, that is of course your choice.
survivant001
18th February 2008, 15:03
I'm not, I'm simply stating the facts.
So if I upload the latest AQ build to x264.nl (http://mirror05.x264.nl/Dark/force.php?file=./x264.736.AQ.exe), you'll use it? ;)

There are some very good reasons (http://i32.tinypic.com/x3ibh1.gif) to use AQ, but if you don't want to, that is of course your choice.

wow, good example. does the sample use the default values for AQ witht the latest build ?
Dark Shikari
18th February 2008, 17:27
wow, good example. does the sample use the default values for AQ witht the latest build ?That's AQ strength 1.0; I lowered the default to 0.5 primarily because 1.0 seemed to be too strong for some sources, as it would tend to blur out sharp edges.
survivant001
19th February 2008, 02:24
That's AQ strength 1.0; I lowered the default to 0.5 primarily because 1.0 seemed to be too strong for some sources, as it would tend to blur out sharp edges.

your build contain the patch AQ 0.48 ?

I got my build from the post. http://forum.doom9.org/showthread.php?p=1095545#post1095545

should I use this in my command line
--aq-strength 0 --aq-sensitivity 0
or
nothing
or
--aq-strength 0.5 ?
Dark Shikari
19th February 2008, 02:25
your build contain the patch AQ 0.48 ?

I got my build from the post. http://forum.doom9.org/showthread.php?p=1095545#post1095545

should I use this in my command line
--aq-strength 0 --aq-sensitivity 0
or
nothing
or
--aq-strength 0.5 ?For AQ on, use nothing; its on by default. To turn it off, just set aq-strength to zero.

My build is Techouse's, from x264.tk.
survivant001
19th February 2008, 02:31
@Dark Shikari

the image you send for an example.. did you did that by a script ?

I would like to have a script that extract few images from the original and generate a comparaison after the output file..
Dark Shikari
19th February 2008, 02:37
@Dark Shikari

the image you send for an example.. did you did that by a script ?

I would like to have a script that extract few images from the original and generate a comparaison after the output file..No, I did it manually.
survivant001
22nd February 2008, 14:51
@Dark Shikari

there is a software that will scan the original movie and compare it witht eh encoded and output the frame that's look bad ?

i try MSU Perceptual Video Quality tool but it doesn't stop craching on my XP 64bit :(

I try avs : selectEvery(..) but it's hard to compare the image in png