x264 MKV's Look Horrible on New TV

[shanndogg]

I recently went from a Sharp 46D82U LCD tv to a Panasonic TCP55VT30 plasma and a large number of my x264 mkv movies now look horrible. By horrible I mean I tend to see a lot of pixilation and blocks particularly in flat backgrounds and general compression noise.

The mkv’s I am viewing are from my original Bluray or DVD sources. The Bluray’s have been encoded to 720p with a crf of 20 via Ripbot, HD Progressive profile. The DVDs to a crf 18 with Handbrake, high profile. Not all files exhibit the poor quality- at least that I can tell. To my understanding this is normal though as some sources compress better than others.

The above encoding settings were chosen under impression that they would produce transparent (or nearly transparent) files when compared to the source. And they did when viewing them on the Sharp LCD. The Plasma, however, shows nothing even close. I began running tests on the Bluray’s up to 720p crf17, but none of the 720’s really looked that great. So I went to 1080p and at around crf 18 they start to look like they used to on the Sharp.

All this info brings me to my question of what would be considered a minimum setting where almost any encode from Bluray will look practically transparent? Most guides and such simply mention crf 22-20 for HD and crf 20-18 for SD, but as I found out when switching TV’s, this isn’t necessarily true. From doing more research through various forums, it seems like there are two options:

1) Keep increasing the crf to a lower number (18 or lower) until the desired quality is achieved.
2) Use the very slow preset, tune film and desired crf (again, most likely 18 or lower).

In regard to #1, as previously mentioned, 1080p encodes at crf18 are looking pretty good. But, I am concerned that something similar may happen to the experience I had when changing TV’s. So, how low should I go to be “safe” if I can’t immediately see the difference right now when dropping below crf 18 in 1080p?

If #2 is the better route, the crf # comes into question again, but also compatibility. I currently stream through a Boxee Box, but may create some DVD’s of the MKV’s to play through a Bluray player. It is my understanding that the “very slow” preset produces a file with b-frames and reference frames that are not compatible with bluray (or other) players. I am unclear if the compatibility comes into play when you are creating an actual Bluray disc (not MKV), or if it also applies to an x264 encoded mkv file you want to play through a Bluray player. If this is true for the latter, does changing the b and ref frames to within bluray specs negate the benefits of using the “very slow” preset?

I realize this may just come down to be doing a bunch of testing, but any input/clarification to help me out is greatly appreciated.

[nibus]

For complete transparency I usually go somewhere between 16-17, but that's lower than most people go. As you have found, the more accurate the display is, the easier it is to spot artifacts. It all depends on how much storage space you have, how fast your encoding hardware is, and how patient you are. :)

You may also want to experiment with psy-rd and AQ to further tweak your encodes to look transparent.

[Dark Shikari]

If you can see an unusual amount of blockiness in dark areas, this often means you have a badly calibrated and/or low quality LCD screen.

[Blue_MiSfit]

^^ Make sure you do your best to calibrate the TV. You may have the brightness turned up too high, exaggerating blocking that normally wouldn't be visible in dark areas.

Unfortunately, some TVs really exaggerate compression artifacts.

[Ghitulescu]

Panasonic are notoriously known, at least in Europe, to set their defaults to <SARCASM>"vivid" colours</SARCASM>, to stand out from their competitors in the eyes of the Average Joe.
LCDs generally sharpen their image, to look more sharp than the plasmas, so compression artefacts like mosquito are heavily exagerated on them.

Both of them need to be calibrated before use, or the viewer will "tune" himself in time to their defects and tend to see normal images on different TVs as defective.

Of course, it may be a very rare issue (I met it only once), the wrongly negociated EDID which may be set to fallback positions - it looks roughly like converting a JPG into a GIF - it may be your case (blocking, exagerated compression noise). This may be caused by the switching-HDMI circuits, either in TV or in the AVR.

[hello_hello]

Are you still using the same playback device? I'm fairly sure not all playback devices upscale equally, and maybe it also depends on whether it's now the TV doing the upscaling rather than the playback device.

If you happen to be using a media player built into the TV, well who knows what it's doing to the picture. The media player in my Samsung TV is actually fairly good. Much better than the media player in the Sharp LCD TV in this house which even does odd things to the colours at times when playing back something as simple as an Xvid/AVI.

Then there's also any built-in filtering the TV may have. Digital noise filter, dynamic contrast, sharpening, power saving features etc. The first thing I do when setting up any TV is to disable the lot and then when I'm happy with the picture, fiddle with the extra filtering. Most of the time though, I'd end up leaving it all disabled.

All I can tell you (based on my experience using my 51" Samsung plasma) is when using the PC for playback I really struggle to see any difference between the original video and my 720p CRF20 encodes. Same with my CRF19 DVD encodes. I've even displayed them side by side on my PC monitor and zoomed in on individual frames to look for differences. I can't say I've directly compared my 720p encodes with the original video using the Bluray player for playback, but even using the Bluray player the encodes still look very good to me.

Not that I think it's likely to be something Ripbot's doing (don't use it myself), but maybe use MediaInfo to retrieve the encoder settings from one of your files and post them here. One of the x264 experts might be able to tell you if there's any x264 settings which may be causing problems. Just out of curiosity, what sort of file size would you end up with, on average, when encoding a movie at 720p, CRF 20?

[Atak_Snajpera]

default profile in ripbot is the same with x264 default settings. for start i suggest to disable all useless picture enhancements in your tv.

[shanndogg]

Thank you for the replies! Let me try to fill in the information about the points everyone brought up:

After seeing the poor quality when switching TV's I have only done encodes down to CRF17 for 720p and when those didn't look so great I went to 1080p CRF 20, 16, and 14. The only other change I made from the default settings on one encode of 1080p CRF18 is an AQ 1.2. To me it seemed to make some difference akin to the file looking more like a crf 16 or so. I have not altered anything with psy-rd.

In regard to blockiness in dark areas and calibration, I did see that effect a while back in some encodes and posted in the Ripbot specific forum. At first I thought it was only from VC-1 sources, but later saw it was random from certain Blurays with dark scenes. From that I was made aware that it was related to the display calibration as I saw no blocks on the Sharp, but could on my Dell monitor so I adjusted accordingly.

However, now the blockiness I am seeing is in light or normally illuminated scenes. I have tried adjusting the Panasonic using the Cnet and Dnice suggested calibration settings as well as trying the THX mode (these modes turn off most or all unneeded settings). All still show the problems while watching the encodes so I am not sure if what I am seeing now is related to calibration? Who knows, maybe the TV needs an ISF calibration as I feel Directv doesn’t look as good as it did on the Sharp as well (I can see way more compression artifacts, posterization, and banding).

For playback I am still using the same device(s) as I did with the Sharp: NAS -> Boxee Box -> Receiver -> TV. The Boxee is set to output 1080p and does upscale the 720p files. That is why I was surprised to see such a difference specifically with 720p as even the crf17 encode didn't look that great. I can try feeding the Boxee directly to the TV or trying Panasonic’s built in media player to see if there is any major difference.

Hello_hello: I had the same experience as you with my 720p encodes with the Sharp. I would flip between inputs of the encode and original disc and there was very little difference- if any. It was pretty amazing as the 720p CRF 20 encodes could range from 2-5gb with 3.5gb being the usual average. Unfortunately, I am out of town so I can’t post the MediaInfo of the encoder settings, but as Atak stated I was using the default profile.

[minaust]

Panasonic are notoriously known, at least in Europe, to set their defaults to <SARCASM>"vivid" colours</SARCASM>, to stand out from their competitors in the eyes of the Average Joe.

It's not just Panasonic, and it's not just Europe. I was once informed by a technician in the home theater business that the default setting is also known as "torch mode". It's for use on the retailer's sales floor to make the TV look as good as possible in brightly lighted, less than optimal viewing conditions.

[hello_hello]

The best I can suggest is to maybe upload a few little samples. A sample of the original video and the 720p encoded version, or some screenshots which show the blocking if you can even see it on your PC monitor. Maybe others can look at the encodes to see if they look "normal" although I'm not sure why they shouldn't.

Out of curiosity, I just opened a 720p encode using MPC-HC and ffdshow. I had to use ffdshow to crank up the Gamma and brightness a fair bit before I could see any blocking in dark areas (lighter areas generally looked fine) but it was nothing I'd ever see normally. Admittedly when disabling the brightness boost I could still see a little bit of the blocking in darker areas as the video kept playing (because my eyes were taught to look for it I guess), but that's all sitting four feet from a 51" Plasma. At normal viewing distance the picture looks great.

It still sounds like TV calibration to me. Or does your TV have some sort of film/24p mode which you could try disabling?

[shanndogg]

For complete transparency I usually go somewhere between 16-17, but that's lower than most people go. As you have found, the more accurate the display is, the easier it is to spot artifacts. It all depends on how much storage space you have, how fast your encoding hardware is, and how patient you are. :)

Do you do CRF 16-17 with default settings, or do you use something like "tune film" or "very slow" presets? I have a decent amount of storage space (but not enough to keep an uncompressed version) and I am patient as far as encode times go.

The best I can suggest is to maybe upload a few little samples. A sample of the original video and the 720p encoded version, or some screenshots which show the blocking if you can even see it on your PC monitor. Maybe others can look at the encodes to see if they look "normal" although I'm not sure why they shouldn't.

It still sounds like TV calibration to me. Or does your TV have some sort of film/24p mode which you could try disabling?

The TV does have a film/24p mode (96hz) which I have tried with it on and off, but the same results. I will try to upload a sample or screenshot. In the meantime here is a MediaInfo file of one 720p encode if it helps:

General
Unique ID : 238993510939390026577535409682099051420 (0xB3CC79D61B035CDD877A260989759B9C)
Complete name : C:\720p CRF20 test.mkv
Format : Matroska
Format version : Version 2
File size : 1.64 GiB
Duration : 1h 29mn
Overall bit rate mode : Variable
Overall bit rate : 2 618 Kbps
Movie name : 720p CRF20 test
Encoded date : UTC 2012-01-16 11:11:44
Writing application : mkvmerge v5.2.0 ('I can't explain') built on Dec 29 2011 19:29:57
Writing library : libebml v1.2.3 + libmatroska v1.3.0

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.0
Format settings, CABAC : Yes
Format settings, ReFrames : 3 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 1h 29mn
Bit rate mode : Variable
Bit rate : 1 926 Kbps
Maximum bit rate : 25.0 Mbps
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.087
Stream size : 1.21 GiB (74%)
Writing library : x264 core 120 r2120 0c7dab9
Encoding settings : cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=7 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=6 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=0 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=240 / keyint_min=24 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=crf / mbtree=1 / crf=20.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / vbv_maxrate=25000 / vbv_bufsize=25000 / crf_max=0.0 / nal_hrd=vbr / ip_ratio=1.40 / aq=1:1.00
Default : Yes
Forced : No

Audio
ID : 2
Format : AC-3
Format/Info : Audio Coding 3
Mode extension : CM (complete main)
Codec ID : A_AC3
Duration : 1h 29mn
Bit rate mode : Constant
Bit rate : 640 Kbps
Channel(s) : 6 channels
Channel positions : Front: L C R, Side: L R, LFE
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Compression mode : Lossy
Stream size : 411 MiB (24%)
Language : English
Default : Yes
Forced : No

Menu
00:00:00.000 : en:00:00:00.000
00:03:15.946 : en:00:03:15.946
00:05:26.451 : en:00:05:26.451
00:10:56.656 : en:00:10:56.656
00:14:44.550 : en:00:14:44.550
00:19:56.904 : en:00:19:56.904
00:24:33.055 : en:00:24:33.055
00:31:34.392 : en:00:31:34.392
00:36:18.510 : en:00:36:18.510
00:39:51.681 : en:00:39:51.681
00:43:52.046 : en:00:43:52.046
00:48:43.045 : en:00:48:43.045
00:56:59.583 : en:00:56:59.583
01:01:41.031 : en:01:01:41.031
01:06:43.124 : en:01:06:43.124
01:10:38.693 : en:01:10:38.693
01:16:10.274 : en:01:16:10.274
01:20:33.871 : en:01:20:33.871
01:23:55.280 : en:01:23:55.280
01:27:01.341 : en:01:27:01.341

[burfadel]

Use r2146 instead of r2120 :)

I'd say the main caused of the issues are:
- Incorrectly calibrated TV.
- Try me=umh, me_range=24, and subme of say, 9. Won't result the issue, but should increase encoding efficiency.
- Remove the qpmin of 0 and qpmax of 69
- Try a larger rc lookahead than 40, say 80.
- Try aq-mode 2 (this would probably have a larger effect than anything else)

[Lyris]

The Panasonics have a THX picture mode which is the next-best thing you can get do doing a full calibration. Are you using that mode?

One other question: you own one of the best Plasma displays currently available... why not use original Blu-ray Discs with it instead of 720p recompressed files?

[nibus]

Do you do CRF 16-17 with default settings, or do you use something like "tune film" or "very slow" presets? I have a decent amount of storage space (but not enough to keep an uncompressed version) and I am patient as far as encode times go.

The "slow" and "very slow" presets are very good as far as time/quality goes. However I have a fast enough CPU that I actually bump everything up to "placebo" settings (:eek:) I don't use the tunings, but I do tweak with psy and AQ settings for each encode.

[TPoise]

1900kbps is pretty low for a 720p encode that wants to get near Bluray-like quality.

To give you a yard stick, I use 1750kbps encodes for my wife's Droid RAZR smartphone. For my 46-inch TV, I do 4500kbps backups usually.

Also, depending on your original source aspect ratio, do proper cropping to ensure you're encoding only the "movie" part of the frame, and not the entire frame with the black bars. And if possible, remove the credits from the film so you can bump up your bitrate while keeping the filesize nearly the same (if file size is your limiting factor). Makes a tiny bit of difference but I've never gotten good luck from <2000kbps encodes using standard presets on a large high-def TV set.

[Sparktank]

File size : 1.64 GiB
Duration : 1h 29mn
Bit rate : 1 926 Kbps
Maximum bit rate : 25.0 Mbps
Bits/(Pixel*Frame) : 0.087

Writing application : mkvmerge v5.2.0 ('I can't explain') built on Dec 29 2011 19:29:57

The Bits/(Pixel*Frame) looks rather low for a 90~min movie at 720p http://i.imgur.com/02MFa.gif

For that time length and resolution, I'd at aim just a little over .175 and not much more than .250.

For converting my BD/BDVD's to a small 480p, I try to keep it around 2gb for file size.

I like using Xvid4PSP as it has some estimated filesizes and B/(P*F) ratios as you play with settings.

I agreee with burfadel's suggestions, especially the me/subme settings.

Overall I prefer encoding to file size rather than CRF (most of the time).
480p: 1.5gb-3gb
720p: 2.5gb-6gb
1080p: remux... usually do 480p or 1080p.

[hello_hello]

- Try me=umh, me_range=24, and subme of say, 9. Won't result the issue, but should increase encoding efficiency.
- Remove the qpmin of 0 and qpmax of 69
- Try a larger rc lookahead than 40, say 80.
- Try aq-mode 2 (this would probably have a larger effect than anything else)

Using CRF encoding, would any of them effect quality much or would they more effect file size and slow the encoding? I ask, because using the x264 "slower" preset seem to use the same "me" and "subme" values you recommend.

Looking at recent encodes it appears 0 and 69 are the defaults for qpmin and qpmax. Assuming that's correct, aside from changing their values, how do you actually get rid of them?

1900kbps is pretty low for a 720p encode that wants to get near Bluray-like quality.

It does seem to be, but wouldn't the bitrate required basically be decided by the CRF value used? I wonder if that particular video was particularly easy to compress? My CRF 20 720p encodes do generally end up using much higher bitrates. I looked at a few encodes, and the bitrate for Pirates of the Caribbean (for example) is 3515kbps using a CRF value of 20.
I did find one 720p encode of a 16:9 aspect ratio video where I'd bumped the CRF value up to 21, if memory serves me correctly because the file size was fairly large at CRF 20 and it's not one of my favorite movies, but it's bitrate is higher than the CRF 20 encode I mentioned, at 4312kbps.

To give you a yard stick, I use 1750kbps encodes for my wife's Droid RAZR smartphone. For my 46-inch TV, I do 4500kbps backups usually.

So taking a guess, if you'd encoded the above two videos I referred to, at 720p you probably would have achieved something around CRF18 to CRF19 for the first, and CRF21 for the second (assuming the same x264 settings). That's why I struggle a little with the 2-pass encoding philosophy.

Also, depending on your original source aspect ratio, do proper cropping to ensure you're encoding only the "movie" part of the frame, and not the entire frame with the black bars.

I can understand what you're saying if you're using 2 pass encoding and don't really know what the quality will be, but if you're using CRF encoding is the actual movie portion of the video going to look any different either way?

The Bits/(Pixel*Frame) looks rather low for a 90~min movie at 720p
For that time length and resolution, I'd at aim just a little over .175 and not much more than .250.

Once again I'd agree, but doesn't a lower Bits/(Pixel*Frame) go hand in hand with a lower bitrate? How do you judge quality by Bits/(Pixel*Frame)?
Out of curiosity, in what way does it relate to the duration of the movie?

I'm not having a go at the settings anyone uses by the way, and I do agree the OP's encode does seem to be of an unusually low bitrate etc for a 720p, CRF20 encode. I'm just trying to understand a little more regarding why people recommend and use the settings they do.

[hello_hello]

From MeGUI's log file, here's my encoder settings for a 720p encode I did yesterday. I basically use the x264 defaults with any additions required for Bluray compatibility. I used the CRF19 preset I created instead of changing the CRF value to 20 as by the time I realized I'd forgotten to, it was obvious the file size wasn't going to end up overly large.
Despite the final size being 2.7GB including the audio, it looks fine. Obviously, it was easier than average to compress.

Job commandline: "C:\Program Files\MeGUI\tools\x264\x264.exe" --level 4.1 --tune film --crf 19.0 --keyint 24 --open-gop --b-pyramid strict --ref 4 --slices 4 --vbv-bufsize 30000 --vbv-maxrate 40000 --aud --nal-hrd vbr --sar 1:1 --output "D:\movie.mkv" "E:\movie.avs"


MediaInfo:
Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 3 frames
Format settings, GOP : M=4, N=24
Codec ID : V_MPEG4/ISO/AVC
Duration : 1h 56mn
Bit rate mode : Variable
Bit rate : 2 657 Kbps
Maximum bit rate : 40.0 Mbps
Width : 1 280 pixels
Height : 534 pixels
Display aspect ratio : 2.40:1
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.162
Stream size : 2.16 GiB (79%)
Writing library : x264 core 120 r2146 bcd41db
Encoding settings : cabac=1 / ref=4 / deblock=1:-1:-1 / analyse=0x3:0x113 / me=hex / subme=7 / psy=1 / psy_rd=1.00:0.15 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-3 / threads=6 / sliced_threads=0 / slices=4 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=1 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=1 / weightp=2 / keyint=24 / keyint_min=2 / scenecut=40 / intra_refresh=0 / rc_lookahead=24 / rc=crf / mbtree=1 / crf=19.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / vbv_maxrate=40000 / vbv_bufsize=30000 / crf_max=0.0 / nal_hrd=vbr / ip_ratio=1.40 / aq=1:1.00

[Atak_Snajpera]

haha... since when 1280x534 is blu-ray compatible???

[poisondeathray]

Maybe just using the preset, not intended for blu-ray (not sure why... ? )

But if he was intending for blu-ray, in addition to the frame dimension issue, bluray_compat=0 = bad , and open-gop should be 1 for blu-ray (some players will "barf" with 2 , but it should be fixed with --bluray-compat )

[MatLz]

And mkv output isn't bluray compatible, right ?

[7ekno]

After running thru a heap of dark / color gradient / generic movies, I have settled on a default commandline for 720p (post grain removal) of:
--crf 17 --aq-strength 1.15 --no-dct-decimate --preset veryslow --tune film

For 1080p I go to --crf 18 and for 480p I go to --crf 16 ... After stepping thru 10-12 movies frame by frame and comparing to the original, the above setting is what looks "transparent" to me on a 54" 1080p plasma ...

7ek

[Sparktank]

Once again I'd agree, but doesn't a lower Bits/(Pixel*Frame) go hand in hand with a lower bitrate? How do you judge quality by Bits/(Pixel*Frame)?
Out of curiosity, in what way does it relate to the duration of the movie?

^__^
I notice when I remux a movie and check it with MediaInfo it shows the original bitrate/Bits/(Pixel*Frame).

And then from there, I just judge that the encoded movie should in thirds of that.
480p=1/3 of original movie
720p=2/3 of original movie
1080p=3/3 of original movie
It's quite silly and lazy.

But that's just for bitrate.

As for judging visual quality, I prefer to use the slower settings to encode overnight.

I don't do too much in the way of removing film grain.
I tend to like it as it reminds me of older movie styles.

The most I'll do is tweak brightness/contrast settings if I know the movie to be relatively dark. But only marginal settings.

For the time-relevance, it's mostly for.... crap, i forgot.
(i just woke up)
I think it was more or less something about converting to DVD rather than a container file :p
(movies longer than 2h10min to DVD9)
###Scratch the whole idea of time-relevance for container files; completely different subject/topic (now that I've had my coffee)###

[hello_hello]

Regarding my encoder settings (sorry shanndogg, I didn't mean to be taking over your thread)....

Atak_Snajpera,
I possibly don't really need to use any Bluray compatibility settings, but I started out with the logic that if a Bluray player could be guaranteed to play a video stream created with the necessary encoder restrictions using a standard Bluray format, then if it's MKV capable there's no reason why it shouldn't play the same stream inside an MKV. So far taking it for granted that for an MKV file the usual resolution restrictions wouldn't apply doesn't seem to have been an incorrect one.
I actually started a thread ages ago asking about MKV capable Bluray players and what encoder settings would be best for MKV, but in the absence of an answer from any of the locals I went with what I thought would be safe.

These days there's a few different types of Bluray players in this house and I've been meaning to experiment with dropping the Bluray settings to see if any of them would have a particular problem playing those encodes, but I just haven't got around to it yet. I've also been meaning to test the media players in the TVs. I suspect the Sony Bluray players won't have problems because I'm fairly sure they're yet to refuse to play anything, but the other players mightn't be so co-operative.

poisondeathray,
If bluray_compat=0 = bad then please tell me how to stop x264 from writing it to the video stream and/or why a Bluray player would care if it's there as long as the video is encoded within the required restrictions. I don't add anything to the command line to cause it to be added and I'm fairly sure MeGUI doesn't add it either.

When selecting Blu-ray as the target playback device in MeGUI's options, MeGUI adds --open-gop to the command line just as I have done. According to MediaInfo, open_gop=1 is what was used when encoding the above video, so what the issue is there I'm not sure. I don't know the difference between open-gop=1 and open-gop=2, or if I did I've forgotten. I thought open-gop was either enabled, or it's not. Feel free to refresh my memory.

For the record, I add the appropriate settings manually rather than use "--bluray-compat" because either x264 or MeGUI (I think it's the latter) enforces Bluray compatible aspect ratios in some circumstances which aren't relevant when using an MKV container (ITU aspect ratios when encoding 720x480 anamorphic video, for example). At one stage it was also enforcing them incorrectly, for example anything with a 720x576 resolution had the aspect ratio set to ITU 4:3 (if I remember correctly). As a result I had to research which parameters to use in the absence of "--bluray-compat".

Anyone else with any concerns???? :)

[hello_hello]

^__^
I notice when I remux a movie and check it with MediaInfo it shows the original bitrate/Bits/(Pixel*Frame).

And then from there, I just judge that the encoded movie should in thirds of that.
480p=1/3 of original movie
720p=2/3 of original movie
1080p=3/3 of original movie
It's quite silly and lazy.

But that's just for bitrate.

Yeah, I'm not sure I understand the logic. There's no guarantee the bitrate used on the original video was "just right". It may have been fairly excessive, or two different discs may use different flavours of mpeg, or different encoder settings etc.
Personally I think it's more logical to ignore how the original video was encoded, and simply concentrate on the most efficient way to re-encode it, and for me that's picking a CRF value I'm happy with and letting x264 do it's thing.

Back in the Xvid days there may have been people who encoded in a similar fashion, but quite often the practice was to run a compression test and then a 2 pass encode. If you wanted quality "x" you used the file size/bitrate determined by the compression test. Whether the original vob files totaled 2GB in size or 7GB, it wasn't a consideration.
These days it seems to me CRF encoding is just the modern version of that, only there's no compression test required and you don't need to run 2 passes.

As for judging visual quality, I prefer to use the slower settings to encode overnight.

Which lets you judge the visual quality better how? ;)

I don't do too much in the way of removing film grain.
I tend to like it as it reminds me of older movie styles.

Me neither. Aside from resizing and cropping, I'm an "encode it as it is" kind of guy.

The most I'll do is tweak brightness/contrast settings if I know the movie to be relatively dark. But only marginal settings.

I'm way too indecisive for something like that. I'd end up encoding the same video 37 times with 37 different brightness/contrast tweaks and not be able to decide which 19 to keep. As I use a PC for playback, it's easy to tweak when playing the encode. I also scrapped the TV's inbuilt presets and created a few of my own. All identical pretty much, except for brightness/contrast.

[hello_hello]

After running thru a heap of dark / color gradient / generic movies, I have settled on a default commandline for 720p (post grain removal) of:
--crf 17 --aq-strength 1.15 --no-dct-decimate --preset veryslow --tune film

I'll confess I had to look up --aq-strength and --no-dct-decimate to see what they do, but they're a couple of tweaks which to me at least appear to make sense. I'll give them a spin myself.

[TPoise]

I can understand what you're saying if you're using 2 pass encoding and don't really know what the quality will be, but if you're using CRF encoding is the actual movie portion of the video going to look any different either way?



Cropping the black bars probably won't make a hill-of-beans difference, but when you're already at that low of bitrate, every little bit helps. For a 2.40:1 aspect movie where I'm targeting a smartphone, I'll do something like an AR of 960x400, so all the extra bitrate goes towards the main "movie frame" itself rather than anything else, but x264 is already pretty good at compressing black. I also crop out intro and outro credits to allow more bitrate for the same file target size. Removing 7-10 minutes worth of video is like getting a 5-10% free bitrate bump on most movies.

TLDR?: Bump up your bitrate to 4500-6000k and you should be fine even with the Faster/SuperFast presets.

[hello_hello]

TPoise,
My point was, with CRF encoding there's no bitrate to bump up. Encoding when using a CRF value and including the black bars would, I imagine (well it does as I've tested it by comparing encodes with and without the black bars), use a higher bitrate compared to cropping them before encoding because they've also got to be compressed. The same applies to including the credits. With CRF encoding the encoder isn't needing to save bits it would otherwise use for the movie on encoding the credits, because it's encoding to a set quality, not a fixed number of bits.

Likewise the OP has no bitrate to increase when using CRF encoding, only an option to change the CRF value.

I do agree though, when using CRF encoding, including the black bars doesn't increase the file size by very much at all so it obviously don't require a huge number of bits to compress them.

[shanndogg]

Use r2146 instead of r2120 :)

I'd say the main caused of the issues are:
- Incorrectly calibrated TV.
- Try me=umh, me_range=24, and subme of say, 9. Won't result the issue, but should increase encoding efficiency.
- Remove the qpmin of 0 and qpmax of 69
- Try a larger rc lookahead than 40, say 80.
- Try aq-mode 2 (this would probably have a larger effect than anything else)

Like Hello_Hello, I am not sure how to remove qpmin and qpmax as well. The other suggestions are pretty much in line with the "slower" preset, but I did another test file with "veryslow" which I will describe below.

The Panasonics have a THX picture mode which is the next-best thing you can get do doing a full calibration. Are you using that mode?

One other question: you own one of the best Plasma displays currently available... why not use original Blu-ray Discs with it instead of 720p recompressed files?

I have used THX mode as well as suggested calibration settings from Cnet and Dnice- all cause some of the previously encoded 720p files to look bad.

I definitely use the original Blurays with the TV, but I also like having my library easily accessible via digital copies for a number of reasons. The encodes I currently have are mostly 720p CRF20 for the fact that when I first started this (when I had the Sharp TV) I did tests of 720p CRF 20-18 and 1080p CRF 20-18. On the Sharp, they all looked nearly identical so I went with the one that saved the most space. However, now with the Panasonic, the 720p's are exposed with a poor picture quality.

After running thru a heap of dark / color gradient / generic movies, I have settled on a default commandline for 720p (post grain removal) of:
--crf 17 --aq-strength 1.15 --no-dct-decimate --preset veryslow --tune film

For 1080p I go to --crf 18 and for 480p I go to --crf 16 ... After stepping thru 10-12 movies frame by frame and comparing to the original, the above setting is what looks "transparent" to me on a 54" 1080p plasma ...

7ek

This is mostly in line with the tests I have been running. As mentioned, the 720p's just don't look good on the Panasonic, so I have been sticking with 1080p and ran encodes of CRF18 with default (medium) settings, the same with AQ1.2 added, then the same with "veryslow" and film tune. I also did CRF16 and 14 with default settings. To me, the CRF16 and 14 were very hard to tell apart with CRF18 very close behind. The CRF 18 with AQ1.2 and the other with veryslow/film tune were slightly better than just the defaults and looked nearly the same as CRF16/14 with the veryslow one slightly better than AQ1.2.

What this all boils down to is it looks like 1080p CRF18 is the minimum I need for the encodes to look good on the new TV. But, as I experienced before, I don't want to stick with the minimum if it might cause me problems in the future. I know some sources can compress better than others (as some of my 720p's still look good), but if source "A" looks great at 1080p CRF 18, but source "B" needs CRF 17 I would rather encode everything at CRF 17.

My whole goal is to find a wide enough setting that should have every encode come out good (I know there are always exceptions, but you guys know what I mean). From a lot of the responses in regard to the MediaInfo I posted on the 720p encode it seems pretty certain that file does not have enough "juice" too look good (too small, not enough bitrate, etc.). I fully understand that, and obviously see the lower quality now. But, which setting is "big" enough where only in the rarest of cases might I expect a problem? I know something like CRF 10 would work, but realistically, I think somewhere around CRF17-16 is what I need (and this seems to line up with a lot of the suggestions). I am also trying to figure out if I need to go lower than the default preset if I go under CRF18. Right now I am leaning towards 1080p CRF17 veryslow, tune film. Think that should fit my bill?

[hello_hello]

I'd still be interested to see a sample of one of these "bad" 720p encodes.

[QuantumRand]

I'm having what sounds like a similar issue to OP.

I suppose I have a slightly pickier eye for detail and typically prefer a CRF setting of 16-17 for my 720p BD rips. All of the movies I've transcoded have come out looking great, except for one: Thor. The night-sky scenes look absolutely awful, even when I drop the RF down to 13. I've even tried a CBR of 5000 with 2-pass encoding and got essentially the same result as RF ~16. DCT-Decimate didn't seem to help either. I tried playing with the Psychovisual Trellis, but I must not know what I'm doing because that resulted in a corrupt video.

Here is a screenshot of one of the scenes at RF 16 (note the top right corner): http://quantumrand.net/misc/Thor%20Quality.png
And here is a shot of my Handbrake settings: http://quantumrand.net/misc/Handbrake%20settings.png

Please advise. Thanks :)

[hello_hello]

QuantumRand,
I'm replying to your other thread (http://forum.doom9.org/showthread.php?p=1553771#post1553771) here also, just to keep the topic in a single thread.

The only time I've ever tried playing a disc on my PC is with AnyDVD running and the background and using MPC-HC. That works fine.

If you want a GUI I'd give MeGUI a vote. It's updated quite regularly and I find it offers a nice combination of "GUI ease of use" while allowing you to experiment by modifying the scripts it creates etc. If you change it's options and use the development update server rather than the standard one it's updated even more regularly.

Personally I use MeGUI to encode all my discs at 720p using CRF 20 and I think they look very good on my Plasma. I still don't understand why the majority of people (including an x264 developer judging by his comment in this thread) seem to think CRF values of 18 to 22 should look fine while for a few the result is unsatisfactory. I really don't think it's because some people are overly picky. If I saw blocking in my encodes I'd complain too, it's just that I don't.

For the record, the color banding in your screenshot is noticeable when viewing the image on my TV. I'm not sure whether the image was created using TV or PC levels, but it's not that my TV is hiding the colour banding because I can see it in yours.
I've seen quite a bit of banding when looking at other peoples encodes but not when encoding stuff myself. If you do happen to try a 720p CRF 20 encode using MeGUI could you report back as to how you think the quality compares with what you're getting now? There's no logical reason why the result should be any different if the encoder settings are the same and you're not using any filters, but I'd be interested to see if you get the same colour banding when using MeGUI. There's got to be a reason....

Alternatively, if you can split of a sample of the original video in your screenshot and upload it somewhere I'd like to try re-encoding just to see what results I get.

[QuantumRand]

Hello hello_hello. Any recommendation on how to split off a sample for you? I've been using Handbrake to transcode a 30 second portion that shows the banding issues very clearly, but I'm just telling it to process a small portion of the full movie. Off of the top of my head, I can't think of any tools that would allow me to clip the movie without it getting re-encoded in the process. Any ideas?

Edit: I went ahead and just encoded a 20 second clip with a RF of 0. It's probably a lot bigger than it needs to be, but it should be identical to the source. Link: File Removed.

[hello_hello]

You could probably use MKVToolnix to split it into segments while muxing it as an MKV, or maybe using tsmuxer. I'm not sure what the best tool for the job would be as it's not something I've had to do with Bluray files myself. Your lossless encode should suffice. I'm downloading it now to have a play.

[hello_hello]

QuantumRand,
Well maybe I've not examined dark sections of video this closely before, so after watching them a few times I could start to pick up compression artifacts more easily, although having said that....
The source itself is actually blocky in places, however they're small enough that I've got to get a little closer to the TV than normal viewing distance to really see them. Obviously when re-encoding as the CRF value increases, the blocks in the dark areas which already contain them increase in size which makes them easier to spot.

What would bother me more than anything is the shot of the vehicle from above where the camera rotates, and as the CRF value increases the scenery is more likely to "wobble", mainly at 720p. If that single shot was my one and only benchmark, I'll confess at 1080p I'd not go higher than CRF 20 and at 720p I'd probably not go higher than CRF 18. At 720p, CRF 20 it looks acceptable using a Bicubic re-sizer (it doesn't "wobble" even though it's still not transparent) while at 720p, CRF 22 it just looks terrible.

I had to remux your sample and remove the last few second of it before I could index it for some reason, just in case you're wondering why the encodes are slightly shorter.

Anyway, here's the encodes I made as I guess the idea is to see how they look to you and compare them to yours. All using x264 defaults and the medium speed preset. To be honest, in the context of the whole movie I'd still be happy with CRF 20 at 720p. I'll admit compared to the CRF 16 and 18 encodes it's not transparent using your source, but on my TV at normal viewing distance it still looks quite good.
http://ifile.it/onz7cvk/encodes.zip

I'm splitting off a sample of an encode for you to look at and I'll post a link shortly.

[hello_hello]

QuantumRand (and shanndogg),
Here's a section of one of my 720p encodes and I promise you it was encoded using a CRF value of 20 (the encoder settings seem to be lost when splitting off a section). It was encoded about a year ago using x264 core 112 r1867, which is actually on older version than used to encode the video shanndogg posted the info for.

This was the video I spent the most time with when testing different CRF values because the source is fairly artifact free. Maybe this type of source is the reason why a CRF value of 20 at 720p has always seemed perfectly acceptable to me. This is a pretty dark scene, and to my eyes, the quality of this encode is better than the quality of the 1080p source you (QuantumRand) uploaded as a sample. Tell me what you think.
http://ifile.it/roc6kie/sample.zip

[shanndogg]

Looks to me like the problem QuantumRand is experiencing is the display calibration issue with dark scenes. On both the Sharp and Panasonic TV, I don't see any problems in dark areas unless I totally mess up the picture settings (contrast, brightness, etc.). But, on my Dell monitor I can see them much more easily.

The problem I experienced when switching from the Sharp to the Panasonic wasn't in dark areas, but in lighter/normal areas. Still not sure if this is calibration related as the problems areas seem to go away with the higher settings I have been trying (1080p CRF18 or better). But, when I was trying to get rid of the dark area blocks by trying higher quality settings in the past- they still never really went away. So, I just wrote that off as a calibration issue as I didn't see it on my main displays.

I will try to get some samples of one of my 720p encodes up later today.

[hello_hello]

Oddly enough, I find it's the other way around (comparing a TV to my CRT monitors). Because a monitor isn't as bright as a TV and doesn't have the same gamut, I find it harder to see compression artifacts on the monitor than on a HD TV. Unless I try to brighten the image up on the monitor to match the TV's output, then I can't see anything but blocking.

Using QuantumRand's sample as an example, on my CRT monitor it looks perfect. It's not bright enough for me to see any blocking.

[7ekno]

I'm having what sounds like a similar issue to OP.

Please advise. Thanks :)

Boost --aq-strength from it's default of 1.0 ;)

--aq-strength > 1.0 will give a bit more bitrate to the background of an image ...

Keep your usual settings and try a snippet of that scene with --aq-strength 1.1, 1.2 and 1.3 ...

Also try to keep --no-dct-decimate, it did reduce some of those "dancing blocks in dark scenes" that I got with my trial encodes (but aq-strength made a much bigger difference, but I didn't want to go to high, so I used aq-strength 1.15 combined with --no-dct-decimate) ...

7ek

[shanndogg]

Ok here is a link to a chapter from one of the problematic 720p encodes I have been referring to:

720p CRF20 default test (http://www.mediafire.com/download.php?jnxawg94jkcpb90)

I couldn't figure out how to cut out a scene from my Ripbot encode so I just did a chapter using Handbrake which shows nearly the same results. Here's what to look for:

00:34 - It starts to cut back and forth between a wide shot of the guy and girl on a bed. On the left hand side there is vertical banding with some pixelation dancing. In the middle above the dresser there is a lighter "circle" of dancing pixelation. In the upper right I see curved banding.

00:37 - On the wall to the left of the woman talking on the phone above the stove there is blocking/dancing pixels.

01:50 - The white walled background on the right of the woman is blocking/dancing pixels.

I am going to try adding aq-strength 1.15 combined with --no-dct-decimate to a 1080p CRF18 veryslow, tune film encode as 7ekno suggested as the one I did without adding those two parameters looks nearly perfect. And, as the test I did with AQ1.2 cleaned up the problem pretty well, I think this may just be what I have been looking for.

[shanndogg]

After running thru a heap of dark / color gradient / generic movies, I have settled on a default commandline for 720p (post grain removal) of:
--crf 17 --aq-strength 1.15 --no-dct-decimate --preset veryslow --tune film

7ek

7ekno - what profile do you use? I noticed when I ran a 1080p CRF18 veryslow, tune film, I got ref=4, when veryslow calls for ref 16. I see profile high@L4.0 has a max of ref 4 for 1080p. Does this negate any or some of the benefits of using veryslow? Here is the MediaInfo from my encode:

General
Unique ID : 243884632332536987748751875448098855379 (0xB77A78BD4D29E25A901B1716EA5519D3)
Complete name : C:\1080 crf18 very slow film.mkv
Format : Matroska
Format version : Version 2
File size : 4.16 GiB
Duration : 1h 29mn
Overall bit rate mode : Variable
Overall bit rate : 6 621 Kbps
Movie name : 1080 crf18 very slow film
Encoded date : UTC 2012-01-24 20:29:52
Writing application : mkvmerge v5.2.0 ('I can't explain') built on Dec 29 2011 19:29:57
Writing library : libebml v1.2.3 + libmatroska v1.3.0

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.0
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 1h 29mn
Bit rate mode : Variable
Bit rate : 5 849 Kbps
Maximum bit rate : 25.0 Mbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.118
Stream size : 3.67 GiB (88%)
Writing library : x264 core 120 r2120 0c7dab9
Encoding settings : cabac=1 / ref=4 / deblock=1:-1:-1 / analyse=0x3:0x133 / me=umh / subme=10 / psy=1 / psy_rd=1.00:0.15 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-3 / threads=6 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=8 / b_pyramid=0 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=240 / keyint_min=24 / scenecut=40 / intra_refresh=0 / rc_lookahead=60 / rc=crf / mbtree=1 / crf=18.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / vbv_maxrate=25000 / vbv_bufsize=25000 / crf_max=0.0 / nal_hrd=vbr / ip_ratio=1.40 / aq=1:1.00
Default : Yes
Forced : No

Audio
ID : 2
Format : AC-3
Format/Info : Audio Coding 3
Mode extension : CM (complete main)
Codec ID : A_AC3
Duration : 1h 29mn
Bit rate mode : Constant
Bit rate : 640 Kbps
Channel(s) : 6 channels
Channel positions : Front: L C R, Side: L R, LFE
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Compression mode : Lossy
Stream size : 411 MiB (10%)
Language : English
Default : Yes
Forced : No

Menu
00:00:00.000 : en:00:00:00.000
00:03:15.946 : en:00:03:15.946
00:05:26.451 : en:00:05:26.451
00:10:56.656 : en:00:10:56.656
00:14:44.550 : en:00:14:44.550
00:19:56.904 : en:00:19:56.904
00:24:33.055 : en:00:24:33.055
00:31:34.392 : en:00:31:34.392
00:36:18.510 : en:00:36:18.510
00:39:51.681 : en:00:39:51.681
00:43:52.046 : en:00:43:52.046
00:48:43.045 : en:00:48:43.045
00:56:59.583 : en:00:56:59.583
01:01:41.031 : en:01:01:41.031
01:06:43.124 : en:01:06:43.124
01:10:38.693 : en:01:10:38.693
01:16:10.274 : en:01:16:10.274
01:20:33.871 : en:01:20:33.871
01:23:55.280 : en:01:23:55.280
01:27:01.341 : en:01:27:01.341

[hello_hello]

I couldn't figure out how to cut out a scene from my Ripbot encode so I just did a chapter using Handbrake which shows nearly the same results. Here's what to look for:

Nearly the same results?
Did you use exactly the same encoder settings, filtering etc?

[shanndogg]

^ There are some differences, here are the Handbrake settings:

Encoding settings : cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=7 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=6 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=240 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=50 / rc=crf / mbtree=1 / crf=20.0 / qcomp=0.60 / qpmin=3 / qpmax=51 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00

I can redo it with exactly the same settings as Ripbot, but as the result looks basically the same, I thought the point was to show what I was talking about and to see if it was reproduced when you viewed it?

[smok3]

shanndogg, did you try with 10 bit version of x264, any difference?

[Ghitulescu]

I think the only way of settling this thing is that shanndogg would provide an unprocessed part of a bluray (short enough not to infringe the copyright) that poses problems on his new TV when reencoded. The people willing to help would then reencode this piece in a quality considered by them as "transparent" (on their TV + player, eyes, expectations). If the problem persists then it's definitely the TV (wrong settings - Panasonic made a reputation built on this, or a calibration issue), or simply a defective player, as the paths for different codecs might be different in a real player.

[hello_hello]

shanndogg,
Yeah, I can see what you're referring to. It's horrible. Well at least the banding is. I managed to have a look at another encode of that movie and it's almost as bad as your sample, so it doesn't appear to be your encoding. If you can manage to split off a sample of the original video and upload it (I assume MKVtoolnix will do it) I'd still like to have a shot at re-encoding it just to see if I get the same result. If I do.... well I'll have to eat my words regarding CRF 20 being fine, but before I snack on them I'd like to try it myself. If not, at least it seems to be unlikely what you're seeing is being caused by bad TV calibration (cause I'm happy with my TV picture too). Interesting......

Did you happen to look at the sample of the 720p CRF20 encode I uploaded (post #32)? That's the sort of result I've come to expect with a good quality source. Maybe I do need to go back and look at some older encodes more closely... although I'm sure the sort of banding you're experiencing with some of your encodes isn't something which would escape my attention, and I don't recall any banding when I re-encoded QuantumRand's sample. Maybe I've just been lucky....

Edit 1: If I get the same results as you I'd be keen to see if we can get Dark Shikari to take a look and offer his opinion.

Oh well, at least we're slowly getting to the same page..... samples definitely help.

Edit 2: I just spent a bit more time looking at my sample again, as well as a fair bit of the rest of the video and there's no doubt standing close to the TV there's compression artifacts (mainly a bit of blocking in darker areas), but nothing I'd see at normal viewing distance. I even hunted through scenes where the background was a fairly solid color (lots of blue sky, that sort of thing) and there's nothing which resembles the banding in your encode.
I was think about your dancing pixels.... unlike the horrible banding they don't jump out at me too badly (I can see them though) but I wonder if using x264's "--tune film" or "---tune grain" would clean that up? There's no doubt my Pirates encode has dancing pixels in places too where the film is grainy but they seem to look more natural.

[QuantumRand]

So I have some potentially interesting news. The section hello_hello had to remove from my sample was the exact section I'm having issues with. I've found that with one of my computers, it's not capable of playback when I drop the RF too low (closer to lossless). It sounds like hello-hello had that same problem with the clip I uploaded.

I think there is something with that scene in particular that confuses either x264 or HandBrake. I thought it was strange that bringing the RF all the way down to 13 still wouldn't fix the banding issue, but perhaps it's actually a bug?

I've gone ahead and remuxed the original source (the right way this time), so you guys can see the specific clip that's giving me difficulty. I'd particularly like to know if MeGUI (or just straight up x264.exe) can encode it successfully without the bad banding issue (and which settings are used to accomplish that). This ought to help me figure out if it's a problem with HandBrake specifically.

Here's the video clip: http://quantumrand.net/misc/ThorSampleRemux.mkv

[hello_hello]

QuantumRand,
I tried quite a few test encodes of your sample. To me at 1080p it's acceptable at CRF 20 or lower (x264 defaults, medium speed) but CRF 18 or lower would be ideal. At 720p even CRF 16 doesn't look transparent, however CRF 16 and 18 still looked good to me (it wouldn't jump out at me while watching the movie) while I think I'd notice the blocking at CRF 20 whether I was looking for it or not.

I tried 7ekno's recommendations of --aq-strength 1.15 and --no-dct-decimate, once again using the medium speed preset while leaving everything else at default. One thing's for sure they offer a huge file size penalty (at 1080p and CRF 18, the encodes were 3.5MB vs 12.2MB) however they're quite effective, especially as the CRF value increases.
Personally, I'd not bother with the tweaks when encoding at 1080p and using a CRF value of 16 or 18 because to me the file size increase is too great for what to me seems a fairly minor quality increase (I'm really not talking about transparency so much, but rather what looks good). At a CRF value of 20 the files sizes were 1.9MB vs 7.2MB but I'd still wonder whether it'd simply be better to reduce the CRF value instead as the file size increase mightn't be so great.
At 720p it's probably a whole different story. 7ekno's tweaks made a difference even with a CRF value as low as 16, although once again given the file size difference I'd probably not start using them until at least CRF 18. At CRF 20 the encode still looked acceptable to me using 7ekno's tweaks but once again the file sizes were 805KB vs 2.0MB.

Having said all that, I'm on the slow computer at the moment (the other one is actually busy encoding) so I'm yet to experiment with adding the very slow preset into the mix. I did a quick encode at CRF18, 720p and the file sizes were 1.2MB (defaults), 2.2MB (tweaks and very slow preset), and 3.4MB (tweaks only). I also want to try all the encodes again to compare the very slow preset with and without the tweaks, and maybe while backing the --aq-strength value off a bit to see how much I can reduce the file size while still being happy with the quality at different CRF values.

It did occur to me to try a different resize method when encoding at 720p as I wondered how much of the bad stuff could be caused by the resizer rather than it being the encoder. I might experiment there later too.

Anyway, having a fairly slow internet connection I've only uploaded the standard encodes using x264's defaults. At least you can look at them to see if your encodes look any different. http://ifile.it/gby3rjh/ThorSampleRemux.zip
So far I've not had any comments on the samples I've already uploaded so I'll admit the conversation is starting to feel a little one sided. :)

[shanndogg]

shanndogg, did you try with 10 bit version of x264, any difference?

I have only tried the 8 bit version, but have finally figured out how to split the source file, so here is it in two small parts that contained the problems detailed in post #40:

Original File-001 (http://www.mediafire.com/download.php?9x7fp6zgm0hr8dy)

Original File-003 (http://www.mediafire.com/download.php?pf2klkp7q2aizfu)

Get this- after looking very closely at them- with my face almost plastered to the screen, or severely altering the contrast/brightness I can make out the problems in the source! So it seems to be coming together now: It appears that some films, or just scenes within the film are not that great to begin with and those parts are amplified when shrinking down and encoding. This makes sense as to why some of my current 720p's look fine and why the ones that don't look good are only within certain parts or scenes.

There are two things at play here: the settings of the encode and the display. For whatever reason, the Sharp would display all of my 720p encodes nearly transparent to the source. I switch displays (still using the same equipment and viewing distance) and all of a sudden the problem areas pop out which now causes me to increase the encode settings.

So it still boils down to what settings will allow for the entire file to look good on hopefully any display and it appears to me the answer, as previously mentioned, is a minimum of 1080p CRF18. That setting is near transparent to me, but as I want to go one step further to be sure, I believe I need to add veryslow/tune film, a higher AQ, or a combination thereof. Later today I am going to compare a 1080p and 720p encode with 7ekno's suggestion to the ones I already have to once and for all solve this situation.

I am curious to see if any of those able to test out the original files will come to the same conclusion. I also will be able to check out the samples from Hello_Hello tonight to see how they match up.

Lastly, does anyone have an answer about High@L4.0 only using ref=4 instead of 16 like veryslow calls for (post #41)?

[hello_hello]

Here's a fun fact. I just tried re-encoding QuantumRand's "ThorSampleRemux" sample using Xvid (target quantizer 2). It's definitely not as good as x264 in general, except for the shot of the sky where x264 has problems. Compared to x264 at CRF 20 or 22 especially, Xvid seems to do a better job.

I've got to get some sleep. I'll have a go at encoding shanndogg's new samples later on.