sample encode vs. full-length encode - quality differences [Archive]

View Full Version : sample encode vs. full-length encode - quality differences

Marin85

24th November 2011, 18:36

Hi,

I am having a very odd problem. Before I start re-encoding a full-lenght HD movie, I make a ~200 MB sample to see if my encoding settings are appropriate. The encoded sample looks transperent to the source sample. However, if I encode the full-lenght movie with the same settings, the resulting encode looks plain awful (very noticaeble differences between encode and source). There are no glitches or similar, just bad encode. It is bugging me because it happens even with 'placebo' settings and plenty of bitrate (so I would not say that my encodes are bit-starved). I am using 2pass x264 encoding in MeGUI, x64 mode enabled. Any ideas what may be causing differences of that magnitude between sample and full encode?

24th November 2011, 18:39

Post command lines and encoder log for both passes.

mp3dom

24th November 2011, 19:47

Try to use the zones parameter. You can use it to specify those parts that get an understimated bitrate so you can force x264 to raise it.

nibus

25th November 2011, 01:13

Your sample may have drastically different footage than the entire film. So it might not need much bitrate, while the rest of the film needs much more.

I would suggest CRF encoding instead. This way if your sample looks good, your full movie should be the same quality. Start with CRF 18 and adjust from there.

hello_hello

25th November 2011, 04:43

I agree, CRF encoding is a much better option. Unless you particularly need to achieve a certain file size, which it doesn't sound like you need to do.

I'd be willing to bet if you encoded the entire movie using a CRF value of somewhere around 18 to 20 and then used the resulting file size/bitrate for your 2 pass encode, the 2 pass encode would look fine and it'd probably prove you just weren't using a high enough bitrate in the first place.
Of course that'd really only be an exercise to prove one way or another if too low a bitrate was the problem, because unless you need to adjust the file size it'd make sense to just keep the CRF encode and not bother with two pass encoding.

Marin85

26th November 2011, 23:01

The problem is not really whether to use CRF or 2pass. Since I am using 2pass, I am obviously trying to hit certain file size. Anyhow, here are the encoding settings and log for both the sample and the full lenght video:

Log and settings for the sample:

---[NoImage] DirectShowSource("C:\HP8-sample.grf",Audio=false)
---[NoImage] Crop(0,140,0,-140)
--[Information] [24.11.2011 23:54:56] Job commandline: "C:\Tools and codecs\MeGUI_2050_x86\tools\x264\x264.exe" --level 4.1 --pass 1 --bitrate 10000 --stats "C:\HP8-sample-bf6-umh64.stats" --threads 6 --deblock -3:-3
--min-keyint 23 --bframes 6 --b-adapt 2 --ref 5 --vbv-bufsize 40000 --vbv-maxrate 45000 --rc-lookahead 250 --merange 64 --me umh --direct auto --subme 11 --trellis 2 --no-fast-pskip --sar 1:1 --output NUL
"C:\HP8-sample.avs"
--[Information] [24.11.2011 23:54:56] Encoding started
--[Information] [24.11.2011 23:59:12] Standard output stream
--[Information] [24.11.2011 23:59:12] Standard error stream
---[NoImage] avs [info]: 1920x800p 1:1 @ 10000000/417083 fps (cfr)
---[NoImage] x264 [info]: using SAR=1/1
---[NoImage] x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
---[NoImage] x264 [info]: profile Main, level 4.1
---[NoImage]
---[NoImage] x264 [info]: frame I:15 Avg QP:13.12 size:300722
---[NoImage] x264 [info]: frame P:360 Avg QP:16.22 size:104433
---[NoImage] x264 [info]: frame B:1612 Avg QP:18.74 size: 34579
---[NoImage] x264 [info]: consecutive B-frames: 0.9% 0.2% 0.6% 15.3% 25.7% 23.6% 33.8%
---[NoImage] x264 [info]: mb I I16..4: 32.2% 0.0% 67.8%
---[NoImage] x264 [info]: mb P I16..4: 34.5% 0.0% 0.0% P16..4: 57.8% 0.0% 0.0% 0.0% 0.0% skip: 7.7%
---[NoImage] x264 [info]: mb B I16..4: 9.1% 0.0% 0.0% B16..8: 29.4% 0.0% 0.0% direct:23.5% skip:38.0% L0:25.2% L1:31.1% BI:43.7%
---[NoImage] x264 [info]: final ratefactor: 16.39
---[NoImage] x264 [info]: direct mvs spatial:99.8% temporal:0.2%
---[NoImage] x264 [info]: coded y,uvDC,uvAC intra: 89.0% 48.6% 24.0% inter: 31.8% 13.3% 0.5%
---[NoImage] x264 [info]: i16 v,h,dc,p: 14% 7% 67% 12%
---[NoImage] x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 16% 10% 19% 9% 9% 9% 8% 11% 9%
---[NoImage] x264 [info]: i8c dc,h,v,p: 67% 13% 18% 2%
---[NoImage] x264 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
---[NoImage] x264 [info]: kb/s:9445.46
---[NoImage] encoded 1987 frames, 7.81 fps, 9445.46 kb/s
--[Information] [24.11.2011 23:59:12] Postprocessing
---[Information] Deleting intermediate files
--[Information] [24.11.2011 23:59:12] Job completed
-[Information] Log for job4 (video, HP8-sample.avs -> HP8-sample-bf6-umh64.mkv)
--[Information] [24.11.2011 23:59:12] Started handling job
--[Information] [24.11.2011 23:59:12] Preprocessing
--[Information] [24.11.2011 23:59:12] Avisynth input script
---[NoImage] DirectShowSource("C:\HP8-sample.grf",Audio=false)
---[NoImage] Crop(0,140,0,-140)
--[Information] [24.11.2011 23:59:12] Job commandline: "C:\Tools and codecs\MeGUI_2050_x86\tools\x264\x264.exe" --level 4.1 --pass 2 --bitrate 10000 --stats "C:\HP8-sample-bf6-umh64.stats" --threads 6 --deblock -3:-3
--min-keyint 23 --bframes 6 --b-adapt 2 --ref 5 --vbv-bufsize 40000 --vbv-maxrate 45000 --rc-lookahead 250 --merange 64 --me umh --direct auto --subme 11 --trellis 2 --no-fast-pskip --sar 1:1 --output
"C:\HP8-sample-bf6-umh64.mkv" "C:\HP8-sample.avs"
--[Information] [24.11.2011 23:59:12] Encoding started
--[Information] [25.11.2011 00:21:24] Standard output stream
--[Information] [25.11.2011 00:21:24] Standard error stream
---[NoImage] avs [info]: 1920x800p 1:1 @ 10000000/417083 fps (cfr)
---[NoImage] x264 [info]: using SAR=1/1
---[NoImage] x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
---[NoImage] x264 [info]: profile High, level 4.1
---[NoImage]
---[NoImage] x264 [info]: frame I:15 Avg QP:16.12 size:234566
---[NoImage] x264 [info]: frame P:360 Avg QP:17.26 size:104027
---[NoImage] x264 [info]: frame B:1612 Avg QP:20.25 size: 37748
---[NoImage] x264 [info]: consecutive B-frames: 0.9% 0.2% 0.6% 15.3% 25.7% 23.6% 33.8%
---[NoImage] x264 [info]: mb I I16..4: 6.4% 69.2% 24.5%
---[NoImage] x264 [info]: mb P I16..4: 0.1% 6.1% 0.3% P16..4: 30.8% 41.8% 16.7% 0.0% 0.0% skip: 4.2%
---[NoImage] x264 [info]: mb B I16..4: 0.0% 1.5% 0.0% B16..8: 40.6% 16.1% 3.8% direct: 6.5% skip:31.4% L0:43.1% L1:45.6% BI:11.2%
---[NoImage] x264 [info]: 8x8 transform intra:89.6% inter:42.6%
---[NoImage] x264 [info]: direct mvs spatial:99.3% temporal:0.7%
---[NoImage] x264 [info]: coded y,uvDC,uvAC intra: 96.6% 78.0% 49.4% inter: 35.0% 13.9% 1.1%
---[NoImage] x264 [info]: i16 v,h,dc,p: 46% 14% 13% 27%
---[NoImage] x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 7% 5% 21% 10% 13% 11% 11% 11% 11%
---[NoImage] x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 12% 7% 13% 9% 12% 12% 10% 12% 13%
---[NoImage] x264 [info]: i8c dc,h,v,p: 46% 23% 19% 12%
---[NoImage] x264 [info]: Weighted P-Frames: Y:0.3% UV:0.0%
---[NoImage] x264 [info]: ref P L0: 43.8% 7.8% 26.9% 9.9% 11.5% 0.1%
---[NoImage] x264 [info]: ref B L0: 76.5% 17.9% 4.1% 1.5%
---[NoImage] x264 [info]: ref B L1: 90.8% 9.2%
---[NoImage] x264 [info]: kb/s:9828.63
---[NoImage] encoded 1987 frames, 1.49 fps, 9828.71 kb/s
--[Information] Final statistics
---[Information] [25.11.2011 00:21:24] Video Bitrate Desired: 10000 kbit/s
---[Information] [25.11.2011 00:21:24] Video Bitrate Obtained (approximate): 9830 kbit/s
--[Information] [25.11.2011 00:21:24] MediaInfo
---[Information] File: C:\HP8-sample-bf6-umh64.mkv
---[Information] General
----[Information] Format: Matroska
----[Information] FormatString: Matroska
----[Information] FileSize: 101835425
----[Information] PlayTime: 00:01:22.874
---[Information] Video
----[Information] ID: 1
----[Information] Width: 1920
----[Information] Height: 800
----[Information] FrameCount: 1987
----[Information] FrameRate: 23.976
----[Information] ScanType: Progressive
----[Information] Codec: V_MPEG4/ISO/AVC
----[Information] CodecString: AVC
----[Information] Format: AVC
----[Information] AspectRatio: 2.400
----[Information] AspectRatioString: 2.40:1
----[Information] Delay: 0
----[Information] Title:
----[Information] Language: en
----[Information] LanguageString: English
--[Information] [25.11.2011 00:21:24] Postprocessing
---[Information] Deleting intermediate files
----[Information] [25.11.2011 00:21:24] Successfully deleted C:\HP8-sample-bf6-umh64.stats
----[Information] [25.11.2011 00:21:24] Successfully deleted C:\HP8-sample-bf6-umh64.stats.mbtree
--[Information] [25.11.2011 00:21:24] Job completed

Log and encoding settings for the full lenght encode:

-[Information] Log for job5 (video, HP8encode.avs -> )
--[Information] [25.11.2011 02:18:35] Started handling job
--[Information] [25.11.2011 02:18:35] Preprocessing
--[Information] [25.11.2011 02:18:35] Avisynth input script
---[NoImage] DirectShowSource("C:\HP8encode.grf",Audio=false)
---[NoImage] Crop(0,140,0,-140)
--[Information] [25.11.2011 02:18:36] Job commandline: "C:\Tools and codecs\MeGUI_2050_x86\tools\x264\x264.exe" --level 4.1 --pass 1 --bitrate 10000 --stats "C:\HP8encode-bf6-umh64.stats" --threads 6 --deblock -3:-3
--min-keyint 23 --bframes 6 --b-adapt 2 --ref 5 --vbv-bufsize 40000 --vbv-maxrate 45000 --rc-lookahead 250 --merange 64 --me umh --direct auto --subme 11 --trellis 2 --no-fast-pskip --sar 1:1 --output NUL
"C:\HP8encode.avs"
--[Information] [25.11.2011 02:18:36] Encoding started
--[Information] [25.11.2011 08:59:22] Standard output stream
--[Information] [25.11.2011 08:59:22] Standard error stream
---[NoImage] avs [info]: 1920x800p 1:1 @ 10000000/417083 fps (cfr)
---[NoImage] x264 [info]: using SAR=1/1
---[NoImage] x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
---[NoImage] x264 [info]: profile Main, level 4.1
---[NoImage]
---[NoImage] x264 [info]: frame I:1313 Avg QP:12.16 size:239085
---[NoImage] x264 [info]: frame P:43038 Avg QP:15.53 size: 91452
---[NoImage] x264 [info]: frame B:143307 Avg QP:17.58 size: 37972
---[NoImage] x264 [info]: consecutive B-frames: 3.7% 2.0% 3.4% 28.6% 17.6% 29.5% 15.1%
---[NoImage] x264 [info]: mb I I16..4: 34.6% 0.0% 65.4%
---[NoImage] x264 [info]: mb P I16..4: 40.9% 0.0% 0.0% P16..4: 44.6% 0.0% 0.0% 0.0% 0.0% skip:14.5%
---[NoImage] x264 [info]: mb B I16..4: 12.1% 0.0% 0.0% B16..8: 33.9% 0.0% 0.0% direct:23.2% skip:30.8% L0:28.6% L1:31.3% BI:40.1%
---[NoImage] x264 [info]: final ratefactor: 16.12
---[NoImage] x264 [info]: direct mvs spatial:99.9% temporal:0.1%
---[NoImage] x264 [info]: coded y,uvDC,uvAC intra: 78.6% 40.5% 16.6% inter: 34.7% 13.0% 1.1%
---[NoImage] x264 [info]: i16 v,h,dc,p: 24% 13% 48% 15%
---[NoImage] x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 17% 14% 20% 8% 8% 8% 8% 8% 9%
---[NoImage] x264 [info]: i8c dc,h,v,p: 66% 14% 18% 2%
---[NoImage] x264 [info]: Weighted P-Frames: Y:4.6% UV:2.9%
---[NoImage] x264 [info]: kb/s:9905.79
---[NoImage] encoded 187658 frames, 7.80 fps, 9905.79 kb/s
--[Information] [25.11.2011 08:59:22] Postprocessing
---[Information] Deleting intermediate files
--[Information] [25.11.2011 08:59:22] Job completed
-[Information] Log for job6 (video, HP8encode.avs -> HP8encode-bf6-umh64.mkv)
--[Information] [25.11.2011 08:59:22] Started handling job
--[Information] [25.11.2011 08:59:22] Preprocessing
--[Information] [25.11.2011 08:59:22] Avisynth input script
---[NoImage] DirectShowSource("C:\HP8encode.grf",Audio=false)
---[NoImage] Crop(0,140,0,-140)
--[Information] [25.11.2011 08:59:23] Job commandline: "C:\Tools and codecs\MeGUI_2050_x86\tools\x264\x264.exe" --level 4.1 --pass 2 --bitrate 10000 --stats "C:\HP8encode-bf6-umh64.stats" --threads 6 --deblock -3:-3
--min-keyint 23 --bframes 6 --b-adapt 2 --ref 5 --vbv-bufsize 40000 --vbv-maxrate 45000 --rc-lookahead 250 --merange 64 --me umh --direct auto --subme 11 --trellis 2 --no-fast-pskip --sar 1:1 --output
"C:\HP8encode-bf6-umh64.mkv" "C:\HP8encode.avs"
--[Information] [25.11.2011 08:59:23] Encoding started
--[Information] [26.11.2011 21:09:53] Standard output stream
--[Information] [26.11.2011 21:09:58] Standard error stream
---[NoImage] avs [info]: 1920x800p 1:1 @ 10000000/417083 fps (cfr)
---[NoImage] x264 [info]: using SAR=1/1
---[NoImage] x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
---[NoImage] x264 [info]: profile High, level 4.1
---[NoImage]
---[NoImage] x264 [info]: frame I:1313 Avg QP:15.01 size:194199
---[NoImage] x264 [info]: frame P:43038 Avg QP:16.83 size: 89409
---[NoImage] x264 [info]: frame B:143307 Avg QP:19.37 size: 39598
---[NoImage] x264 [info]: consecutive B-frames: 3.7% 2.0% 3.4% 28.6% 17.6% 29.5% 15.1%
---[NoImage] x264 [info]: mb I I16..4: 11.2% 66.2% 22.6%
---[NoImage] x264 [info]: mb P I16..4: 0.9% 10.9% 1.1% P16..4: 27.3% 34.4% 11.4% 0.0% 0.0% skip:13.9%
---[NoImage] x264 [info]: mb B I16..4: 0.1% 1.9% 0.2% B16..8: 40.1% 20.1% 3.7% direct: 7.0% skip:27.0% L0:44.2% L1:44.4% BI:11.4%
---[NoImage] x264 [info]: 8x8 transform intra:83.1% inter:43.4%
---[NoImage] x264 [info]: direct mvs spatial:98.4% temporal:1.6%
---[NoImage] x264 [info]: coded y,uvDC,uvAC intra: 90.8% 68.8% 39.2% inter: 37.5% 14.0% 1.3%
---[NoImage] x264 [info]: i16 v,h,dc,p: 48% 12% 8% 33%
---[NoImage] x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 7% 7% 12% 11% 14% 12% 12% 12% 13%
---[NoImage] x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 9% 8% 13% 9% 13% 12% 12% 10% 14%
---[NoImage] x264 [info]: i8c dc,h,v,p: 40% 27% 19% 14%
---[NoImage] x264 [info]: Weighted P-Frames: Y:5.4% UV:2.9%
---[NoImage] x264 [info]: ref P L0: 50.9% 7.4% 22.2% 9.5% 8.6% 1.3% 0.0%
---[NoImage] x264 [info]: ref B L0: 83.3% 12.5% 3.2% 1.0%
---[NoImage] x264 [info]: ref B L1: 93.9% 6.1%
---[NoImage] x264 [info]: kb/s:9993.82
---[NoImage] encoded 187658 frames, 1.44 fps, 9993.82 kb/s
--[Information] Final statistics
---[Information] [26.11.2011 21:10:16] Video Bitrate Desired: 10000 kbit/s
---[Information] [26.11.2011 21:10:16] Video Bitrate Obtained (approximate): 9995 kbit/s
--[Information] [26.11.2011 21:10:23] MediaInfo
---[Information] File: C:\HP8encode-bf6-umh64.mkv
---[Information] General
----[Information] Format: Matroska
----[Information] FormatString: Matroska
----[Information] FileSize: 9779155083
----[Information] PlayTime: 02:10:26.896
---[Information] Video
----[Information] ID: 1
----[Information] Width: 1920
----[Information] Height: 800
----[Information] FrameCount: 187658
----[Information] FrameRate: 23.976
----[Information] ScanType: Progressive
----[Information] Codec: V_MPEG4/ISO/AVC
----[Information] CodecString: AVC
----[Information] Format: AVC
----[Information] AspectRatio: 2.400
----[Information] AspectRatioString: 2.40:1
----[Information] Delay: 0
----[Information] Title:
----[Information] Language: en
----[Information] LanguageString: English
--[Information] [26.11.2011 21:10:23] Postprocessing
---[Information] Deleting intermediate files
----[Information] [26.11.2011 21:10:24] Successfully deleted C:\HP8encode-bf6-umh64.stats
----[Information] [26.11.2011 21:10:24] Successfully deleted C:\HP8encode-bf6-umh64.stats.mbtree
--[Information] [26.11.2011 21:10:24] Job completed

I have used automatic 2pass in MeGUI for both the sample and the full encode.

Stereodude

26th November 2011, 23:23

MatLz

27th November 2011, 01:43

No need for a sample.Your sample may have drastically different footage than the entire film. So it might not need much bitrate, while the rest of the film needs much more.I can only agree with this. :goodpost:

Marin85

27th November 2011, 03:40

No sample videos for us of your sample encode or full-length encode? Also, where in the 187658 frames did your 1987 frame sample come from?

However, taking a quasi educated guess based on the QP values between the sample and full encode I wouldn't expect them to be that different visually since the QP values are not dramatically different.
The sample from the logs from my previous post above starts ~ after the 6000th frame of the movie. As for including other samples, I don't know how to create matching source sample - encoded sample - sample of the full encode, since mkvmerge cannot cut according to predefined frames and avisynth trim does not help, either, unless one is going to re-encode the video (but lossless re-encode of the trimed encode is kind of pointless...). If anyone has any idea how to create all three matching samples, then I will most happily do it. I can also upload an arbitrary single sample of that movie if you think this could help.

To compensate for that for now, I am including a few screenshots that illustrate the vast differences:

encode from source sample vs. full encode vs. source
http://thumbnails24.imagebam.com/16148/e03f68161475771.jpg (http://www.imagebam.com/image/e03f68161475771) http://thumbnails20.imagebam.com/16148/9acabd161475794.jpg (http://www.imagebam.com/image/9acabd161475794) http://thumbnails30.imagebam.com/16148/f84c6f161475845.jpg (http://www.imagebam.com/image/f84c6f161475845)

http://thumbnails67.imagebam.com/16148/a198ed161476201.jpg (http://www.imagebam.com/image/a198ed161476201) http://thumbnails38.imagebam.com/16148/df1e7e161476232.jpg (http://www.imagebam.com/image/df1e7e161476232) http://thumbnails29.imagebam.com/16148/546a65161476271.jpg (http://www.imagebam.com/image/546a65161476271)

http://thumbnails46.imagebam.com/16148/3d29ea161476239.jpg (http://www.imagebam.com/image/3d29ea161476239) http://thumbnails61.imagebam.com/16148/9f925f161476270.jpg (http://www.imagebam.com/image/9f925f161476270) http://thumbnails45.imagebam.com/16148/3d29ea161476292.jpg (http://www.imagebam.com/image/3d29ea161476292)

To me, these are pretty substantial differences. I have tested with three random samples from this same movie as well as with one sample from another movie - this kind of differences occur each time. I kind of doubt that all these samples were very unlucky and did not represent the movies. BTW, ffdshow (OSD) seems to be having some problems with the trim feature in avisynth.

Stereodude

27th November 2011, 03:46

I can only agree with this. :goodpost:Really? Because I suspect it's wrong. The QP values are lower for the full encode than the sample, so if anything the full encode should look better than the sample.

MatLz

27th November 2011, 04:02

Really? Because I suspect it's wrong. The QP values are lower for the full encode than the sample, so if anything the full encode should look better than the sample.
lol.
How can you compare average qps of different clips and say that ??
The full clip contains the sample but how can you isolate its qps...... :o

Stereodude

27th November 2011, 04:05

To me, these are pretty substantial differences. I have tested with three random samples from this same movie as well as with one sample from another movie - this kind of differences occur each time. I kind of doubt that all these samples were very unlucky and did not represent the movies.Seriously? Those seem like pretty minor differences to me. Even at 200% zoom in the differences between them are not immediately obvious without careful examination. Second, you're not using the same x264 command line options for the two encodes. I would expect some differences.

Marin85

27th November 2011, 04:13

Seriously? Those seem like pretty minor differences to me. Even at 200% zoom in the differences between them are not immediately obvious without careful examination. Second, you're not using the same x264 command line options for the two encodes. I would expect some differences.
The first the second set are pretty obvious IMHO. As for the third one, it is rather subtle, but I was lazzy to make more screenshots, because the first two illustrated my point pretty well (or at least I thought so).

What do you mean by that I am not using the same x264 options. That would be only if I pasted the wrong part of the MeGUI log... As for the screenshots, I am pretty sure they are taken from encodes with the same settings as I had the profile saved and applied to each of them.

Stereodude

27th November 2011, 04:18

How can you compare average qps of different clips and say that ??
The full clip contains the sample but how can you isolate its qps...... :oBecause in general the quantizer value is an indicator of quality. I'm not claiming it's absolute, but in general a numerically lower QP value = high quality. If the sample is representative of the movie the comparison should hold. It would be one thing if his sample had QP values that were significantly lower than the final encode, but that's not the case here.

Stereodude

27th November 2011, 04:23

What do you mean by that I am not using the same x264 options.Sorry, I misread the logs you pasted. They are the same.

Audionut

27th November 2011, 05:38

As has been stated already. Your sample doesn't provide a decent representation of the entire film.

Marin85

27th November 2011, 05:49

As has been stated already. Your sample doesn't provide a decent representation of the entire film.
As already stated, I made three random samples with size ~200 MB at different points of the movie as well as one sample of another movie and the same phenomenon is observed. Of course, there is always the chance that these have been some unlucky samples...

Audionut

27th November 2011, 09:20

Marin85

27th November 2011, 12:59

200MB what? Source, encoded material.

Judging by the stats you posted above, you have used about 1% of the source for your small tests.
Do you honestly expect 1% to be a decent representation of the other 99%. The fact that you choose 2 other 1% points makes no difference.

Look at the b-frame distribution of your encodes.

1 looks easier to encode then the other, and surprise surprise!!!!!

A better representation would be something along the lines of,

selectrangeevery(10000,480)

You then also get the benefit of lots of scene changes which will increase the bitrate requirements of your sample.

If you could be bothered checking out your specific case more thoroughly, run an encode on your sample at qp 20. Then do the same for the full encode.
Feel free to use something like preset faster as the only concern is having the settings the same for both encodes.

Check the final encoded bitrate of your sample to that of the full encode.

ps. I'm not into Harry, but judging by those screen shots above, they look like scenes with static backgrounds and simply talking head in foreground.
Easy to encode.

Ok, will try out those pieces of advice. I guess, implicit part of the question was how to create proper samples.

As for the scenes, indeed, these appear to be rather static scenes, but then they should be easy to encode everywhere. If so, then why would x264 make a difference between the small sample and the full encode? One would expect that such differences would appear only on complex scenes.

Also, see this regarding your deblocking settings.
http://forum.doom9.org/showthread.php?t=163182

It might be useful to apply less aggressive deblocking, but I doubt (-3,-3) as opposed to, say, (-2,-2), gives the troubles. I guess I was following the "old school".

Also, your frame rate is funky.

Why, what is wrong with 23.976 fps? Should it be in infinite precision? :)

Also, --min-keyint is an auto setting. You've ended up with keyint 250 min-keyint 23.
You should set --keyint 240 and let --min-keyint be auto.

As far as I understand, both should be multiple of the frame rate. I admit I kind of forgot about keyint and used the default (but this was also for comparison purposes, see below).

What device are you targeting with that --vbv-maxrate setting?

The settings were borrowed. It is supposed to play on media player or HTPC, but this has no influence on the quality, or?

--merange 64 is silly by itself, combine it with --bframes 6 --me umh and I'm at a loss for words.

Same with your --rc-lookahead setting.
Please elaborate. I don't see the problem here. Certainly, if you care about quality, bigger -merange makes a difference, even with umh. And what's the problem with the 6 b-frames? It gives some freedom for compression to x264, especially when combined with auto b-adapt. As for the lookahead, it too is maxed out. Since it only needs memory, again I don't see what the problem is.

These settings are borrowed from a friend of mine and his encode of HP looks just as transperent as my small samples, but throughout the whole movie. I believe the only difference is the first pass, but AFAIK differences from fast automatic first pass could be only minor, at least in theory, no?

27th November 2011, 13:12

These settings are borrowed from a friend of mine and his encode of HP looks just as transperent as my small samples, but throughout the whole movie.

Regressions are possible. Which x264 build did he use and have you tried the same one?

Marin85

27th November 2011, 13:22

Regressions are possible. Which x264 build did he use and have you tried the same one?I double-checked this, we both were using the same build from the development server of MeGUI.

Audionut

27th November 2011, 13:48

As for the scenes, indeed, these appear to be rather static scenes, but then they should be easy to encode everywhere. If so, then why would x264 make a difference between the small sample and the full encode? One would expect that such differences would appear only on complex scenes.

Because when you only encode those 1900 or so frames from the sample that are easy to compress, x264 doesn't really have to find a way to distribute the bits.

When you are encoding the entire film, there will be plenty of scenes that require a lot more then the final bitrate you are specifying. Those extra bits have to come from somewhere.

edit: Hence why I think the avisynth script I posted earlier will provide much better results. A. more frames being sampled. B. Those extra scene changes require more bitrate. So if anything, the sample encode ends up needing more bitrate then the final encode, and that's a good thing, as then you end up with a final encode that was encoded with more bits then it needed, rather then the situation you have now where the final encode requires more bits then the sample you choose led you to believe.

It might be useful to apply less aggressive deblocking, but I doubt (-3,-3) as opposed to, say, (-2,-2), gives the troubles. I guess I was following the "old school".

I was linking more for broad terms, not directly about this specific case. Having said that. The default deblock settings for --tune film are -1:-1

Why, what is wrong with 23.976 fps? Should it be in infinite precision? :)

I was being a bit pedantic.

The settings were borrowed. It is supposed to play on media player or HTPC, but this has no influence on the quality, or?

If you're only playing back on a PC, personally I wouldn't bother with vbv settings. As far as quality goes, you could actually benefit from reduced vbv settings to stop x264 giving large amounts of bitrates to high motion scenes at the expense of the low motion scenes. Although I suspect that once you fix the other settings you will not need to tweak this.

Please elaborate. I don't see the problem here. Certainly, if you care about quality, bigger -merange makes a difference, even with umh. And what's the problem with the 6 b-frames? It gives some freedom for compression to x264, especially when combined with auto b-adapt. As for the lookahead, it too is maxed out. Since it only needs memory, again I don't see what the problem is.

It's not a problem per se, it's a case of effectively using time vs quality improvement.

Take a look at the default profiles for x264. Not even the placebo preset uses merange 64.

--preset veryslow uses --bframes 8 --me umh --merange 24 --subme 10

--preset placebo uses --bframes 16 --me tesa --merange 24 --subme 11

It's important to remember that the x264 devs actually know their shit. Not like mates and other randoms on the internet.

So instead of going to --preset placebo, you've reduced bframes by 2, and increased merange way to much.
Where as the devs recommend that for the speed loss, you get much better results with double the bframes, the same merage and me tesa

Take a look at this thread. http://forum.doom9.org/showthread.php?p=1538221#post1538221

What I am suggesting is that for those 1.44fps you're happy encoding at, you're more then likely going to see a bigger benefit (better quality), by ditching the crazy merange setting and adopting --preset placebo.

These settings are borrowed from a friend of mine

Your mate doesn't understand what he is doing, nor have the same knowledge and database of results that the x264 devs do.

Please, for the love of God, try --preset placebo and check your results. It is my guess, that you will continue to encode at the same fps (maybe even a little faster) while having a higher quality encode.

Here:

--preset placebo --tune film --level 4.1 --pass 2 --bitrate 10000 --keyint 240 --stats "C:\HP8-sample-bf6-umh64.stats" --output

Marin85

29th November 2011, 00:42

Thank you for the valuable input. I find observation about higher ME range vs. higher b-frames particularly interesting. From what I have tested so far, it actually appears that higher --b-frames can improve the overall quality. I guess, higher number of b-frames (with intelligent b-adapt) gives more flexibility to 2pass encoding so that the encoder can redistribute bits better and retain higher quality where necessary/noticeable. Tesa with range 24 is in all cases slower than umh 64 (at least with 6 threads), but for the love of God I will also make the placebo test for that same particular sample for the sake of speed (and output quality) comparison. It is on the qeue and I will come back when it is done.

Audionut

29th November 2011, 05:56

Thank you for the valuable input. I find observation about higher ME range vs. higher b-frames particularly interesting. From what I have tested so far, it actually appears that higher --b-frames can improve the overall quality. I guess, higher number of b-frames (with intelligent b-adapt) gives more flexibility to 2pass encoding so that the encoder can redistribute bits better and retain higher quality where necessary/noticeable.

Yes, bframes require less bits.

Tesa with range 24 is in all cases slower than umh 64

Indeed, I forgot how slow tesa was.
I guess you could use esa instead. From a quick test I did on just 1 source, esa was slightly faster then merange 64.

I'd guess that esa would be more beneficial then merange 64, but I honestly don't know.

It is on the qeue and I will come back when it is done.

That would be good, cheers.

rahzel

30th November 2011, 02:44

when I do sample encodes, I add selectrangeevery(1440,24), so for a ~24fps film, it takes 1 second (24 frames) for every minute. that should give you a good representation of the entire video.

As far as b-frames, in my newbie opinion, your encode could've benefited from a few more b-frames. But AFAIK, this increases encode time.

Personally, I find tesa and even esa aren't worth the extra time. I'm very new to encoding, but I find umh, subme 11, merange 48 the sweet spot as far as encoding time vs quality gain. But again, I'm very new so I'm curious to know what you experts think.

Gser

30th November 2011, 03:52

Does subme 11 really do anything useful since trellis motion estimation is yet to be released?

rahzel

30th November 2011, 04:03

Dunno. The only comment I've seen regarding subme 11 was Dark Shikari saying there's a max 1-2% gain from subme 11, but maybe he was commenting on his testing from a future build. I think I read somewhere else that you need trellis 2 for subme 11 to work.
It is in the latest stable build of x264 and I have seen a few people use it, so I figured the setting does have an effect. Haven't actually compared the two myself. I just might do it right now...

edit: hmm, you might be right. subme 10 gave me slightly better qp's and a slightly smaller filesize. I'm guessing subme 11 was actually using subme 9; at least with the build I'm using (the latest one meGUI updates to).

Vurbal

30th November 2011, 04:34

when I do sample encodes, I add selectrangeevery(1440,24), so for a ~24fps film, it takes 1 second (24 frames) for every minute. that should give you a good representation of the entire video.
Actually I would advise spacing the sample regions out further and making them longer the way Audionut has them unless you are using a very short GOP length. Otherwise there will be a disproportionately large number of I-frames in your sample encode compared to the real thing.

rahzel

30th November 2011, 05:01

Thanks for the tip.

akupenguin

30th November 2011, 07:30

Actually I would advise spacing the sample regions out further and making them longer the way Audionut has them unless you are using a very short GOP length. Otherwise there will be a disproportionately large number of I-frames in your sample encode compared to the real thing.

For that reason, you should exclude the first frame in each selected range when calculating the bitrate of the sample. Then the fraction of I-frames in the remaining frames will be an unbiased estimate of the fraction in the whole movie (assuming your keyint is large enough that there are few keyframes other than scenecuts). After making that correction, I don't know whether larger selections are better.

But if you don't want to go to the trouble of calculating that, then sure, larger selections reduce the bias.

nibus

1st December 2011, 02:17

infoeater

1st December 2011, 03:33

I double-checked this, we both were using the same build from the development server of MeGUI.

But you used lower file size?
Because same settings, same version, same bitrate and different quality results looks impossible.

infoeater

1st December 2011, 16:25

edit: hmm, you might be right. subme 10 gave me slightly better qp's and a slightly smaller filesize. I'm guessing subme 11 was actually using subme 9; at least with the build I'm using (the latest one meGUI updates to).

Interesting... My subme 11 tests were larger than 10 also.

Reading this I decided to do some small test (used last version from MeGUI - x264 core:116 r2074 2641b9e):
settings:
program --preset placebo --tune ssim --crf 18.0 --threads 1 --keyint 60 --min-keyint 1 --subme xx --psnr --ssim --output "output" "input"

where xx=:

11:
[Information] [2011-12-01 13:11:01] Standard error stream
-[NoImage] avs [info]: 768x432p 1:1 @ 60001/1001 fps (cfr)
-[NoImage] x264 [warning]: --psnr used with AQ on: results will be invalid!
-[NoImage] x264 [warning]: --tune psnr should be used if attempting to benchmark psnr!
-[NoImage] x264 [info]: using SAR=1/1
-[NoImage] x264 [info]: using cpu capabilities: MMX2 Cache64
-[NoImage] x264 [info]: profile High, level 4.0
-[NoImage] x264 [info]: frame I:12 Avg QP:18.52 size: 38557 PSNR Mean Y:46.66 U:48.11 V:48.38 Avg:47.13 Global:47.08
-[NoImage] x264 [info]: frame P:138 Avg QP:23.84 size: 2779 PSNR Mean Y:44.32 U:46.72 V:46.96 Avg:45.01 Global:44.93
-[NoImage] x264 [info]: frame B:540 Avg QP:27.09 size: 378 PSNR Mean Y:44.11 U:46.92 V:47.12 Avg:44.88 Global:44.78
-[NoImage] x264 [info]: consecutive B-frames: 1.7% 0.0% 13.5% 26.7% 6.5% 32.2% 2.0% 3.5% 10.4% 0.0% 0.0% 3.5% 0.0% 0.0% 0.0% 0.0% 0.0%
-[NoImage] x264 [info]: mb I I16..4: 17.4% 31.6% 51.0%
-[NoImage] x264 [info]: mb P I16..4: 1.2% 0.9% 0.5% P16..4: 33.7% 13.3% 3.9% 0.8% 0.1% skip:45.6%
-[NoImage] x264 [info]: mb B I16..4: 0.1% 0.0% 0.0% B16..8: 15.5% 1.5% 0.3% direct: 0.3% skip:82.4% L0:51.2% L1:44.1% BI: 4.7%
-[NoImage] x264 [info]: 8x8 transform intra:32.2% inter:54.9%
-[NoImage] x264 [info]: direct mvs spatial:99.8% temporal:0.2%
-[NoImage] x264 [info]: coded y,uvDC,uvAC intra: 66.8% 66.9% 44.0% inter: 2.0% 1.5% 0.2%
-[NoImage] x264 [info]: i16 v,h,dc,p: 25% 27% 13% 35%
-[NoImage] x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 34% 25% 20% 3% 3% 4% 3% 3% 4%
-[NoImage] x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 37% 33% 9% 3% 3% 4% 3% 3% 4%
-[NoImage] x264 [info]: i8c dc,h,v,p: 19% 41% 27% 12%
-[NoImage] x264 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
-[NoImage] x264 [info]: ref P L0: 45.6% 12.5% 17.6% 4.8% 4.0% 4.2% 3.2% 1.3% 0.9% 1.3% 0.9% 1.0% 0.7% 1.0% 0.7% 0.4%
-[NoImage] x264 [info]: ref B L0: 53.6% 15.1% 13.8% 3.8% 3.4% 2.9% 2.6% 0.9% 0.9% 0.7% 0.6% 0.6% 0.6% 0.4% 0.2%
-[NoImage] x264 [info]: ref B L1: 87.4% 12.6%
-[NoImage] x264 [info]: SSIM Mean Y:0.9856612 (18.435db)
-[NoImage] x264 [info]: PSNR Mean Y:44.201 U:46.901 V:47.114 Avg:44.945 Global:44.845 kb/s:729.86
-[NoImage] encoded 690 frames, 0.41 fps, 730.33 kb/s

11, crf=18.04:
[Information] [2011-12-01 15:23:24] Standard error stream
-[NoImage] avs [info]: 768x432p 1:1 @ 60001/1001 fps (cfr)
-[NoImage] x264 [warning]: --psnr used with AQ on: results will be invalid!
-[NoImage] x264 [warning]: --tune psnr should be used if attempting to benchmark psnr!
-[NoImage] x264 [info]: using SAR=1/1
-[NoImage] x264 [info]: using cpu capabilities: MMX2 Cache64
-[NoImage] x264 [info]: profile High, level 4.0
-[NoImage] x264 [info]: frame I:12 Avg QP:18.59 size: 38438 PSNR Mean Y:46.65 U:48.11 V:48.35 Avg:47.12 Global:47.07
-[NoImage] x264 [info]: frame P:138 Avg QP:23.87 size: 2761 PSNR Mean Y:44.31 U:46.72 V:46.94 Avg:44.99 Global:44.92
-[NoImage] x264 [info]: frame B:540 Avg QP:27.10 size: 377 PSNR Mean Y:44.10 U:46.92 V:47.11 Avg:44.87 Global:44.77
-[NoImage] x264 [info]: consecutive B-frames: 1.7% 0.0% 13.5% 26.7% 6.5% 32.2% 2.0% 3.5% 10.4% 0.0% 0.0% 3.5% 0.0% 0.0% 0.0% 0.0% 0.0%
-[NoImage] x264 [info]: mb I I16..4: 18.3% 30.8% 50.9%
-[NoImage] x264 [info]: mb P I16..4: 1.2% 1.0% 0.5% P16..4: 33.4% 13.2% 3.9% 0.9% 0.1% skip:45.8%
-[NoImage] x264 [info]: mb B I16..4: 0.1% 0.0% 0.0% B16..8: 15.5% 1.5% 0.3% direct: 0.3% skip:82.4% L0:51.4% L1:43.9% BI: 4.7%
-[NoImage] x264 [info]: 8x8 transform intra:31.8% inter:54.8%
-[NoImage] x264 [info]: direct mvs spatial:99.8% temporal:0.2%
-[NoImage] x264 [info]: coded y,uvDC,uvAC intra: 66.5% 66.7% 43.8% inter: 2.0% 1.5% 0.2%
-[NoImage] x264 [info]: i16 v,h,dc,p: 24% 27% 13% 36%
-[NoImage] x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 34% 25% 20% 3% 3% 4% 3% 3% 4%
-[NoImage] x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 37% 33% 9% 3% 3% 4% 3% 3% 4%
-[NoImage] x264 [info]: i8c dc,h,v,p: 19% 42% 28% 12%
-[NoImage] x264 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
-[NoImage] x264 [info]: ref P L0: 45.5% 12.6% 17.8% 4.7% 4.1% 4.1% 3.3% 1.3% 0.9% 1.2% 0.8% 1.0% 0.7% 0.9% 0.6% 0.4%
-[NoImage] x264 [info]: ref B L0: 54.2% 15.6% 13.7% 3.7% 3.0% 2.7% 2.3% 0.9% 0.7% 0.6% 0.6% 0.6% 0.7% 0.4% 0.1%
-[NoImage] x264 [info]: ref B L1: 87.9% 12.1%
-[NoImage] x264 [info]: SSIM Mean Y:0.9856246 (18.424db)
-[NoImage] x264 [info]: PSNR Mean Y:44.186 U:46.899 V:47.097 Avg:44.931 Global:44.832 kb/s:726.74
-[NoImage] encoded 690 frames, 0.35 fps, 727.22 kb/s

10:
[Information] [2011-12-01 13:30:56] Standard error stream
-[NoImage] avs [info]: 768x432p 1:1 @ 60001/1001 fps (cfr)
-[NoImage] x264 [warning]: --psnr used with AQ on: results will be invalid!
-[NoImage] x264 [warning]: --tune psnr should be used if attempting to benchmark psnr!
-[NoImage] x264 [info]: using SAR=1/1
-[NoImage] x264 [info]: using cpu capabilities: MMX2 Cache64
-[NoImage] x264 [info]: profile High, level 4.0
-[NoImage] x264 [info]: frame I:12 Avg QP:18.57 size: 38539 PSNR Mean Y:46.67 U:48.12 V:48.38 Avg:47.13 Global:47.08
-[NoImage] x264 [info]: frame P:138 Avg QP:23.82 size: 2752 PSNR Mean Y:44.30 U:46.71 V:46.93 Avg:44.98 Global:44.91
-[NoImage] x264 [info]: frame B:540 Avg QP:27.09 size: 376 PSNR Mean Y:44.09 U:46.91 V:47.11 Avg:44.86 Global:44.76
-[NoImage] x264 [info]: consecutive B-frames: 1.7% 0.0% 13.5% 26.7% 6.5% 32.2% 2.0% 3.5% 10.4% 0.0% 0.0% 3.5% 0.0% 0.0% 0.0% 0.0% 0.0%
-[NoImage] x264 [info]: mb I I16..4: 17.5% 31.5% 51.0%
-[NoImage] x264 [info]: mb P I16..4: 1.4% 1.0% 0.4% P16..4: 41.7% 5.7% 3.6% 0.4% 0.1% skip:45.8%
-[NoImage] x264 [info]: mb B I16..4: 0.0% 0.0% 0.0% B16..8: 16.2% 1.1% 0.2% direct: 0.2% skip:82.2% L0:52.5% L1:42.9% BI: 4.6%
-[NoImage] x264 [info]: 8x8 transform intra:32.4% inter:58.7%
-[NoImage] x264 [info]: direct mvs spatial:99.8% temporal:0.2%
-[NoImage] x264 [info]: coded y,uvDC,uvAC intra: 66.4% 66.5% 43.5% inter: 2.2% 1.7% 0.2%
-[NoImage] x264 [info]: i16 v,h,dc,p: 23% 27% 13% 38%
-[NoImage] x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 35% 25% 20% 3% 3% 4% 3% 3% 4%
-[NoImage] x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 39% 33% 8% 3% 3% 4% 3% 3% 4%
-[NoImage] x264 [info]: i8c dc,h,v,p: 19% 41% 28% 12%
-[NoImage] x264 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
-[NoImage] x264 [info]: ref P L0: 42.4% 12.6% 18.3% 4.8% 4.5% 4.7% 3.7% 1.5% 1.0% 1.4% 0.9% 1.2% 0.8% 1.1% 0.7% 0.4%
-[NoImage] x264 [info]: ref B L0: 52.8% 15.4% 13.8% 4.0% 3.4% 3.0% 2.6% 0.9% 0.9% 0.7% 0.6% 0.6% 0.7% 0.5% 0.1%
-[NoImage] x264 [info]: ref B L1: 87.3% 12.7%
-[NoImage] x264 [info]: SSIM Mean Y:0.9856127 (18.420db)
-[NoImage] x264 [info]: PSNR Mean Y:44.175 U:46.895 V:47.095 Avg:44.922 Global:44.820 kb/s:726.62
-[NoImage] encoded 690 frames, 0.58 fps, 727.10 kb/s

9:
[Information] [2011-12-01 13:30:56] Standard error stream
-[NoImage] avs [info]: 768x432p 1:1 @ 60001/1001 fps (cfr)
-[NoImage] x264 [warning]: --psnr used with AQ on: results will be invalid!
-[NoImage] x264 [warning]: --tune psnr should be used if attempting to benchmark psnr!
-[NoImage] x264 [info]: using SAR=1/1
-[NoImage] x264 [info]: using cpu capabilities: MMX2 Cache64
-[NoImage] x264 [info]: profile High, level 4.0
[Information] [2011-12-01 13:52:20] Standard error stream
-[NoImage] avs [info]: 768x432p 1:1 @ 60001/1001 fps (cfr)
-[NoImage] x264 [warning]: --psnr used with AQ on: results will be invalid!
-[NoImage] x264 [warning]: --tune psnr should be used if attempting to benchmark psnr!
-[NoImage] x264 [info]: using SAR=1/1
-[NoImage] x264 [info]: using cpu capabilities: MMX2 Cache64
-[NoImage] x264 [info]: profile High, level 4.0
-[NoImage] x264 [info]: frame I:12 Avg QP:17.50 size: 40807 PSNR Mean Y:46.91 U:48.41 V:48.64 Avg:47.39 Global:47.34
-[NoImage] x264 [info]: frame P:138 Avg QP:20.71 size: 3189 PSNR Mean Y:44.48 U:47.02 V:47.20 Avg:45.19 Global:45.11
-[NoImage] x264 [info]: frame B:540 Avg QP:26.33 size: 395 PSNR Mean Y:44.24 U:47.19 V:47.35 Avg:45.03 Global:44.93
-[NoImage] x264 [info]: consecutive B-frames: 1.7% 0.0% 13.5% 26.7% 6.5% 32.2% 2.0% 3.5% 10.4% 0.0% 0.0% 3.5% 0.0% 0.0% 0.0% 0.0% 0.0%
-[NoImage] x264 [info]: mb I I16..4: 18.8% 31.0% 50.3%
-[NoImage] x264 [info]: mb P I16..4: 1.3% 1.0% 0.4% P16..4: 49.4% 5.5% 3.1% 0.4% 0.1% skip:38.7%
-[NoImage] x264 [info]: mb B I16..4: 0.0% 0.0% 0.0% B16..8: 16.5% 1.1% 0.2% direct: 0.2% skip:81.9% L0:51.5% L1:44.0% BI: 4.5%
-[NoImage] x264 [info]: 8x8 transform intra:32.4% inter:57.4%
-[NoImage] x264 [info]: direct mvs spatial:99.8% temporal:0.2%
-[NoImage] x264 [info]: coded y,uvDC,uvAC intra: 69.3% 72.6% 46.8% inter: 2.6% 4.5% 0.2%
-[NoImage] x264 [info]: i16 v,h,dc,p: 25% 25% 14% 37%
-[NoImage] x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 34% 25% 21% 3% 3% 4% 3% 3% 4%
-[NoImage] x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 37% 34% 8% 3% 3% 4% 3% 3% 4%
-[NoImage] x264 [info]: i8c dc,h,v,p: 20% 41% 28% 11%
-[NoImage] x264 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
-[NoImage] x264 [info]: ref P L0: 49.6% 10.9% 18.2% 4.4% 4.0% 3.5% 3.0% 1.1% 0.9% 0.9% 0.7% 0.8% 0.5% 0.7% 0.5% 0.3%
-[NoImage] x264 [info]: ref B L0: 54.4% 15.7% 13.4% 3.7% 3.1% 2.7% 2.3% 0.9% 0.8% 0.6% 0.6% 0.6% 0.6% 0.4% 0.1%
-[NoImage] x264 [info]: ref B L1: 86.8% 13.2%
-[NoImage] x264 [info]: SSIM Mean Y:0.9859956 (18.537db)
-[NoImage] x264 [info]: PSNR Mean Y:44.332 U:47.176 V:47.346 Avg:45.101 Global:44.999 kb/s:794.39
-[NoImage] encoded 690 frames, 0.54 fps, 794.87 kb/s

8:
[Information] [2011-12-01 14:17:25] Standard error stream
-[NoImage] avs [info]: 768x432p 1:1 @ 60001/1001 fps (cfr)
-[NoImage] x264 [warning]: --psnr used with AQ on: results will be invalid!
-[NoImage] x264 [warning]: --tune psnr should be used if attempting to benchmark psnr!
-[NoImage] x264 [info]: using SAR=1/1
-[NoImage] x264 [info]: using cpu capabilities: MMX2 Cache64
-[NoImage] x264 [info]: profile High, level 4.0
-[NoImage] x264 [info]: frame I:12 Avg QP:17.50 size: 40804 PSNR Mean Y:46.90 U:48.41 V:48.64 Avg:47.38 Global:47.33
-[NoImage] x264 [info]: frame P:138 Avg QP:20.72 size: 3190 PSNR Mean Y:44.47 U:47.02 V:47.20 Avg:45.18 Global:45.10
-[NoImage] x264 [info]: frame B:540 Avg QP:26.06 size: 403 PSNR Mean Y:44.23 U:47.17 V:47.33 Avg:45.02 Global:44.92
-[NoImage] x264 [info]: consecutive B-frames: 1.7% 0.0% 13.5% 26.7% 6.5% 32.2% 2.0% 3.5% 10.4% 0.0% 0.0% 3.5% 0.0% 0.0% 0.0% 0.0% 0.0%
-[NoImage] x264 [info]: mb I I16..4: 18.5% 31.1% 50.4%
-[NoImage] x264 [info]: mb P I16..4: 1.4% 1.0% 0.4% P16..4: 49.0% 5.6% 3.1% 0.4% 0.1% skip:38.9%
-[NoImage] x264 [info]: mb B I16..4: 0.0% 0.0% 0.0% B16..8: 16.2% 1.0% 0.2% direct: 0.2% skip:82.3% L0:51.0% L1:44.3% BI: 4.7%
-[NoImage] x264 [info]: 8x8 transform intra:32.0% inter:57.7%
-[NoImage] x264 [info]: direct mvs spatial:99.8% temporal:0.2%
-[NoImage] x264 [info]: coded y,uvDC,uvAC intra: 68.7% 72.3% 46.2% inter: 2.6% 4.7% 0.2%
-[NoImage] x264 [info]: i16 v,h,dc,p: 26% 26% 12% 36%
-[NoImage] x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 35% 25% 21% 3% 3% 4% 3% 3% 4%
-[NoImage] x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 37% 34% 8% 3% 3% 4% 3% 3% 4%
-[NoImage] x264 [info]: i8c dc,h,v,p: 19% 41% 28% 11%
-[NoImage] x264 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
-[NoImage] x264 [info]: ref P L0: 49.8% 11.0% 17.8% 4.5% 4.0% 3.6% 3.0% 1.1% 0.8% 0.9% 0.8% 0.7% 0.5% 0.7% 0.5% 0.3%
-[NoImage] x264 [info]: ref B L0: 56.7% 15.9% 12.9% 3.6% 2.7% 2.4% 2.0% 0.7% 0.6% 0.5% 0.4% 0.5% 0.5% 0.3% 0.1%
-[NoImage] x264 [info]: ref B L1: 88.3% 11.7%
-[NoImage] x264 [info]: SSIM Mean Y:0.9859580 (18.526db)
-[NoImage] x264 [info]: PSNR Mean Y:44.322 U:47.164 V:47.325 Avg:45.090 Global:44.986 kb/s:797.38
-[NoImage] encoded 690 frames, 0.46 fps, 797.86 kb/s

for comparaison preset veryslow:
[Information] [2011-12-01 14:29:29] Standard error stream
-[NoImage] avs [info]: 768x432p 1:1 @ 60001/1001 fps (cfr)
-[NoImage] x264 [warning]: --psnr used with AQ on: results will be invalid!
-[NoImage] x264 [warning]: --tune psnr should be used if attempting to benchmark psnr!
-[NoImage] x264 [info]: using SAR=1/1
-[NoImage] x264 [info]: using cpu capabilities: MMX2 Cache64
-[NoImage] x264 [info]: profile High, level 4.0
-[NoImage] x264 [info]: frame I:12 Avg QP:18.58 size: 38454 PSNR Mean Y:46.65 U:48.12 V:48.36 Avg:47.12 Global:47.07
-[NoImage] x264 [info]: frame P:137 Avg QP:23.73 size: 2591 PSNR Mean Y:44.19 U:46.70 V:46.90 Avg:44.89 Global:44.81
-[NoImage] x264 [info]: frame B:541 Avg QP:27.07 size: 376 PSNR Mean Y:44.04 U:46.90 V:47.07 Avg:44.81 Global:44.71
-[NoImage] x264 [info]: consecutive B-frames: 1.7% 0.0% 13.0% 24.3% 8.0% 33.0% 2.0% 3.5% 14.3%
-[NoImage] x264 [info]: mb I I16..4: 18.3% 30.8% 50.9%
-[NoImage] x264 [info]: mb P I16..4: 1.1% 1.0% 0.5% P16..4: 28.4% 5.3% 3.3% 0.4% 0.1% skip:59.9%
-[NoImage] x264 [info]: mb B I16..4: 0.0% 0.0% 0.0% B16..8: 15.6% 1.0% 0.2% direct: 0.2% skip:82.8% L0:52.8% L1:42.3% BI: 4.9%
-[NoImage] x264 [info]: 8x8 transform intra:32.6% inter:58.2%
-[NoImage] x264 [info]: direct mvs spatial:99.8% temporal:0.2%
-[NoImage] x264 [info]: coded y,uvDC,uvAC intra: 68.3% 67.8% 44.5% inter: 2.1% 1.5% 0.2%
-[NoImage] x264 [info]: i16 v,h,dc,p: 25% 27% 13% 35%
-[NoImage] x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 35% 25% 19% 2% 3% 4% 3% 3% 4%
-[NoImage] x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 37% 34% 8% 3% 3% 4% 3% 3% 4%
-[NoImage] x264 [info]: i8c dc,h,v,p: 19% 42% 27% 12%
-[NoImage] x264 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
-[NoImage] x264 [info]: ref P L0: 50.3% 13.5% 14.5% 4.0% 3.9% 3.2% 2.9% 1.2% 1.0% 1.1% 0.9% 1.0% 0.7% 0.8% 0.7% 0.4%
-[NoImage] x264 [info]: ref B L0: 51.4% 14.8% 13.1% 4.4% 4.0% 3.6% 3.1% 1.0% 0.9% 0.8% 0.7% 0.7% 0.7% 0.5% 0.2%
-[NoImage] x264 [info]: ref B L1: 87.4% 12.6%
-[NoImage] x264 [info]: SSIM Mean Y:0.9855068 (18.388db)
-[NoImage] x264 [info]: PSNR Mean Y:44.111 U:46.884 V:47.060 Avg:44.867 Global:44.763 kb/s:708.74
-[NoImage] encoded 690 frames, 0.96 fps, 709.21 kb/s

To sum up: although CRF has been used instead of 3 pass destination file size it's clear that higher motion estimation is always helping then looking at quality/file size ratio. Difference between --subme 11 and --subme 10 is much smaller then between lower values. Also we see, that CRF is not really so constant as sometimes it can change both quality and file size in the same direction when changing settings.
Definitely --subme 9 is not equal to --subme 11.

Marin85

1st December 2011, 16:43

To sum up: although CRF has been used instead of 3 pass destination file size it's clear that higher motion estimation is always helping then looking at quality/file size ratio. Difference between --subme 11 and --subme 10 is much smaller then between lower values. Also we see, that CRF is not really so constant as sometimes it can change both quality and file size when changing settings.
I think you are overgeneralizing things a little bit here. First of all, you are looking only at some artificial metrics, which in all honesty do not reflect the real quality of the encode, and secondly, your tests are for low resolutions. In all tests with 1080p content I have done so far (and this includes about ~ 1000 samples) I could not see any difference when increasing the motion estimation range from 24 to 64, and I pretend to be picky :p But then again my target bitrates are in the range of 45-55% of the original bitrate. Maybe, you should run some tests with 1080p content, so we can see the "elasticity" of ME range with respect to input resolutions.

infoeater

1st December 2011, 17:20

I think you are overgeneralizing things a little bit here. First of all, you are looking only at some artificial metrics, which in all honesty do not reflect the real quality of the encode, and secondly, your tests are for low resolutions.
(..)
Maybe, you should run some tests with 1080p content, so we can see the "elasticity" of ME range with respect to input resolutions.

I didn't test --merange, only --subme. Testing differences between so similar profiles requires metrics, because nagged eye would not see them.
HD content should benefit more from high me range then SD content. My content should benefit from high me range even less, because it's high fps.

Marin85

1st December 2011, 18:11

I didn't test --merange, only --subme.
Sorry, my bad. By "higher ME settings" I assumed you also meant different ME ranges. I should have read your post more carefully, I see now that you ran through the subme parameters.

Testing differences between so similar profiles requires metrics, because nagged eye would not see them.
Not necessarily. I still think some comparison screenshots would not have hurt. I agree though if the eye really cant make the difference then the only way remains by means of metrics.

HD content should benefit more from high me range then SD content. My content should benefit from high me range even less, because it's high fps.
Yes, it should because the frames are bigger, but does it in practice... Some things about x264 encoding sometimes defy logic: I have somewhere an example with crf encoding where tesa with me-range 64 actually makes things look worse (cet. par.) than simple diamong with range 16... And I have some more counter-examples to "x264 logics" because things are more subtle than they appear. This is why I always prefer visual comparison and then anything else.

rahzel

2nd December 2011, 21:05

Reading this I decided to do some small test (used last version from MeGUI - x264 core:116 r2074 2641b9e):

To sum up: although CRF has been used instead of 3 pass destination file size it's clear that higher motion estimation is always helping then looking at quality/file size ratio. Difference between --subme 11 and --subme 10 is much smaller then between lower values. Also we see, that CRF is not really so constant as sometimes it can change both quality and file size in the same direction when changing settings.
Definitely --subme 9 is not equal to --subme 11.
Maybe it depends on the source? Dunno, but subme 10 was definitely better than subme 11 on my tests.

MatLz

2nd December 2011, 21:47

nibus

2nd December 2011, 23:45

I thought the whole point of going up in subme values was to increase compression and efficiency, not eat up more bitrate.

Marin85

2nd December 2011, 23:54

I thought the whole point of going up in subme values was to increase compression and efficiency, not eat up more bitrate.
Not only. Higher subme enables for Psy-RDO, which is important for grain retention.

The difference is particularly well visible if you compare subme 4 with subme 9. And then you have subme 10 which seems to do same, if not better, job than subme 9 and also saves more bitrate than subme 9. This can be easily seen with crf encoding where you don't have predefined bitrate. BTW, subme 4 saves more bitrate than subme 9, but the encode also looks kind of flat/smoothed out at close inspection if the movie has grain in it.

EDIT: It took me a little bit time to find out how the whole discussion about subme actually started off the original topic :p

MatLz

3rd December 2011, 00:00

I don't know how motion estimation can be related to grain which is random noise.
Please, elaborate.

Marin85

3rd December 2011, 02:23

I don't know how motion estimation can be related to grain which is random noise.
Please, elaborate.
Smoothness on a sub-pixel level as opposed to the so called pixel-locking (which creates "step" effects on images) is crucial for accurate motion estimation. Basically, in order to achieve some reasonable sub-pixel precison, one starts with a minimization of some matching cost function. Since it only does an approximation, a noisy environment ineviteably has impact on the outcome of this minimization problem. I can't really speak for the case of x264 since I don't know which algorithms are hidden behind the cryptic names "subme xx", but from the standpoint of the general image processing theory you can classify these procedure in two kinds, and then again in two other kinds. The first two kinds are whether your minimization problem is robust with respect to noise. The second two kinds are whether the output (i.e. the ME based on this sub-pixel refinement) will be noisy or not. Again, from the standpoint of image processing, such minimization problem will be good if it is robust to noise because this will guarantee more accurate ME. However, it could lead to de-noising. Noise-robust sub-pixel refinement techniques are often probabalistic/statistical in nature: they are able to (more or less) accurately take account of the noise by determining suitable distribution (in the probabalistic sense of the word) over the scanned area. But because they are probabalistic, the output could too be noisy, which we subjectively experience as "retaining grain".

You can understand it this way: take some small neighbourrhood on the image that contains pixels that visualize part of some structure/pattern (i.e. that are not noise) and that also contains certain amount of noise. If the proportion of noise relative to "amount of pattern" is sufficiently big, the sub-pixel smoothing within this small neighbourhood can fail bad. However, if you work probabalistically and create (somehow derived) distribution of the noise vs. not-noise vs. this area of the image, you may get output with, say, 90% chance for accuracy. Actually, the neat thing about this is that you can give lower bounds on the likelihood to get an output that actually makes sense to the human brain (but don't get your hopes too high, such lower bounds are not that good as we may wish).

So, based on this, my guess is that subme 4 hides one of those minimization problems that produce less noise (not sure about noise-robustness here, though), and subme 10 is probabalistic (because it is noise-robust) with high chance for accuracy (because MeGUI claims that it gives better quality :p ). Please note that I am talking only about subme 4 vs. subme 9/10. I don't have observations on the other subme algorithms regarding grain/noise.

BTW, this is also a reason why, at least in theory, with higher subme one should also go with higher ME, that is to say, that subme 10 should be run paired with esa ME just to assure constant results throughout the movie.

Having said that, I am wondering if the x264 developers have considered or are considering ME beyond SAD, like p-power-metrics (SAD is basically p=1, variants of p=2 seem to be well-known), maybe alone for geometrical reasons.

I also have some images to support the grain-retaining effect of subme 4 vs. subme 9/10:

http://thumbnails25.imagebam.com/16250/7323a8162495771.jpg (http://www.imagebam.com/image/7323a8162495771) http://thumbnails46.imagebam.com/16250/4df0a7162495782.jpg (http://www.imagebam.com/image/4df0a7162495782) http://thumbnails42.imagebam.com/16250/03463e162495788.jpg (http://www.imagebam.com/image/03463e162495788) http://thumbnails47.imagebam.com/16250/fae449162495799.jpg (http://www.imagebam.com/image/fae449162495799)

The differences are more visible in areas with solid color.

3rd December 2011, 02:38

Sorry, but I don't think you are making much sense there.

The reason why you get better grain retention with subme >= 6 is because Psy-RDO gets activated. It doesn't work with subme 5 and lower.

Marin85

3rd December 2011, 03:01

Sorry, but I don't think you are making much sense there.

The reason why you get better grain retention with subme >= 6 is because Psy-RDO gets activated. It doesn't work with subme 5 and lower.

Maybe, you would care to elaborate what does not make sense to you. Because I have a few things to support my claim (though admittedly not necessarly in the specific case of x264).

This is possible. Also, indeed, I did not think of Psy-RDO and also I don't know why Psy-RDO is activated only for some of the sub-pixel refinement algos in x264. As already stated, I don't know what particular algorithms are behind the sub-pixel refinements implemented in x264.

However, in general, sub-pixel refinement is often closely connected with grain/noise, both on the input and the output side. For instance, this can be seen from this paper (http://ifile.it/1y64w7i) as well as from a few others concerning NASA's image processing techniques for space images.

EDIT: Also, this topic drifted way to much from the original topic. I would be thankful if a mod could separate the whole subme discussion from the original topic.

3rd December 2011, 03:32

This is possible. Also, indeed, I did not think of Psy-RDO and also I don't know why Psy-RDO is activated only for some of the sub-pixel refinement algos in x264.

Because it needs RDO, which subme 6 and above do at increasing level.

As already stated, I don't know what particular algorithms are behind the sub-pixel refinements implemented in x264.

Check http://mewiki.project357.com/wiki/X264_Settings#subme or x264 --fullhelp (and the source code for details).

However, in general, sub-pixel refinement is often closely connected with grain/noise, both on the input and the output side. For instance, this can be seen from this paper (http://ifile.it/1y64w7i) as well as from a few others concerning NASA's image processing techniques for space images.

That paper is about sub-pixel matching of noisy images, which is all good for motion estimation but doesn't have much at all to do with grain retention.

I'd say that the compression gain of better motion estimation under grainy conditions is relatively small. It would not be clearly noticeable as better grain retention, which is all about throwing bits at the problem unless you do psychovisual tricks such as psy-rd.

Or in other words, the more noise you want to keep, the less you need good motion estimation.

Of course you can test this yourself by turning Psy RDO off and then comparing all the subme modes.

Marin85

3rd December 2011, 03:58

Because it needs RDO, which subme 6 and above do at increasing level.
This became a circular argument, but ok. Maybe someone could shed some more light as to why sub-pixel refinement is then interconnected with psychovisual hacks.

Check http://mewiki.project357.com/wiki/X264_Settings#subme or x264 --fullhelp (and the source code for details).

With all due respect, mewiki is kind of useless in such type of discussions. It would have been nice if x264 had separate documentation with short descriptions as to what/which algorithms are behind the cryptic names. My opinion only ;)

That paper is about sub-pixel matching of noisy images, which is all good for motion estimation but doesn't have much at all to do with grain retention.

Yes, maybe it was not the best reference here, but still it includes one small part that is relevant here, which is about sub-pixel refinement which is needed for sub-pixel matching. It has to do with grain retention only in so far as different sub-pixel refinement techniques may in general have denoising after-effects. Maybe these are negligeable? After all, what happens if you sub-pixel-refine noise? Something, nothing? But in all cases, it has something to do with grain retention.

Or in other words, the more noise you want to keep, the less you need good motion estimation.
Is that to say that if I want to keep the original level of grain, I won't see any (or only negligeable) improvement in quality (meaning improvement of transperancy) when going from something like diamond with range 8 to tesa with range 64?

Of course you can test this yourself by turning Psy RDO off and then comparing all the subme modes.
I would not test all subme modes. First of all, I would like to see what kind of sub-pixel refinement techniques in detail are used for the various subme modes and then draw my conclusions whether it makes sense at all to test certain subme modes against each other. But this would be the hypothetical scenario. In reality, I trust the more experienced users here: if you say that all subme modes (cet. par.) will cause the same level of grain, then I believe you :)

poisondeathray

3rd December 2011, 04:11

In the adequate bitrate range , psy settings are probably the most important for grain retention for vanilla x264

This is what D.S had to say about grain:

If you're looking for options to muck with for grain retention, basically everything that matters is wrapped up in Psy-RD and Psy-Trellis. These algorithms are the magic that makes x264 retain grain well (especially when using --tune grain, which is optimized for relatively even grain retention across a video, at the cost of absolute quality).

http://forum.doom9.org/showthread.php?p=1472261#post1472261

As mentioned earlier, your tests should be 2passes for an exact bitrate, or adjust the crf until it results in the same filesizes. You cannot draw valid conclusions comparing encodes that have different bitrates.

Marin85

3rd December 2011, 13:36

Thanks for the link. Also, I have completely abondened the idea of subme vs. noise. On a clear head, there does not seem to be any reasonable connection between both, I guess. It was the psy-rdo that did the "magic". I changed my post about suggesting higher subme for grain retention accordingly to reflect this. BTW, these tests were not mine.

I will be thankful if a mod splits the subme discussion from the original discussion.

infoeater

3rd December 2011, 17:37

You are doing it wrong.

CRF is not constant quality, it is quality based.

So you can NOT say "eh I changed a setting and the file size is different, so it is better/worse than"

If you want compare different settings, adjust crf to get same sizes or use two pass.

I see your point. This is why I adjusted --subme 11 to get the same bitrate as --subme 10. Comparaison between the two, and making sure, that --subme 11 differs from --subme 9 on last available for MeGUI version of x264 was major reason for test.

When you will look at other --subme you can also estimate the average SSIM db change vs kbps change. I know, that it is inaccurate, but it was not major reason for test. Treat it's as bonus. It's my wrong, that I didn't clearly write it in test.

You can also see how changing settings affect quality with constant CRF.

And above all this was just quick test on my slow computer to check surprising statements about --subme 9-11 for which it is response to.