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.

[hello_hello]

Couldn't help myself. I ran a quick 720p encode on "Original File-001" using CRF20. I'm getting the same color banding as well. I tried it at 720p using Xvid. It produces the same banding, only worse.

Maybe someone should PM Dark Shikari to see if they can entice him back to the thread to take a look. It's definitely not something I've experienced in any of my encodes yet (least not that I've noticed) so maybe there's something peculiar to some types of video which the encoders don't like.

Edit: Also tried an encode of "Original File-003" and getting the same results as you are.

[smok3]

playing around with Original File-001:

10 bit 420 encode does look decent (regarding lack of blocking on dithered gradients), snap:

http://shrani.si/t/3U/Fi/jDWR6lZ/original-file-00110bit26.jpg (http://shrani.si/?3U/Fi/jDWR6lZ/original-file-00110bit26.png)

and download:
http://www.mediafire.com/?lm3obrj9eycnzio

i just used:
-preset medium -tune film -crf 21 -threads 0

But of course that wont play everywhere. Btw, are "tune" modes working in 10 bit version at all?

----

I have also did various test with 8 bit version, try crf1 -preset medium -tune grain for example and observe violet chroma dance at 16s (that is, besides megahuge filesize).

p.s. using ffmpeg on OS X in all tests.

[hello_hello]

I've sent Dark Shikari a PM asking him to return to the thread if he can. It'll be interesting to get a comment from an x264 developer regarding shanndogg's sample. Hopefully we'll hear from him.

[hello_hello]

playing around with Original File-001:

10 bit 420 encode does look decent (regarding lack of blocking on dithered gradients)

i just used:
-preset medium -tune film -crf 21 -threads 0


Well the 10 bit version still doesn't eliminate all the banding, or blocking, however I should refer to it, but it's certainly a huge improvement over the 8 bit version.

That's the first time I've even tried to play a 10 bit encode. When you say it won't play anywhere, where is it likely to play? Obviously I could convince the PC to use ffdshow and played it fine, but the media player in my TV spat it out while the Sony Bluray player (god bless it) at least played it even if it looked like a mess. Hardware players..... sigh....

[smok3]

not really following the state of 10bitnes, so not sure what exactly will play this.

However i did check some other movies (pretty much anything has a room scene with vigneted wall, done in post or light setup) and none has even a single scene that would look as problematic as this one, so i guess its a pretty lonely problem, a killer sample if you wish.

[hello_hello]

That's why I was surprised when this issue came up. I have seen a similar thing in other people's encodes before and just put it down to odd encoder settings or some type of "user error". This is the first time I've experienced it myself. What's odd is it's not just the "wall scene". The guy's dark jacket in the first scene doesn't encode well, and there's some sort of banding on the woman's back at the 11 second mark. Xvid is no better (actually worse).

I've also rechecked a couple of encodes and can't find anything even resembling the problem here. It'd be interesting to at least learn the "why", even if there's no solution.

[hello_hello]

Well guess what?? It appears not to be the encoder's fault.

I guess largely due to the fact I have no idea what I'm doing, I tried a few different experiments (Original File-001). First I tried using ffdshow to convert the video to RGB and getting the encoder to encode it. Same result. Next I tried using VirtualDubMod to convert it to an uncompressed AVI (via DirectShow again). And there it was. All the artifacts, banding etc which are preset in the encodes also appear when the video is saved as an uncompressed AVI. Encoding it just makes it worse.

Why? Well if I am correct.... it's over my head. But maybe it's a start. Although if the problem is being introduced when decoding, why does the original video display none of the problems when you simply play it?

Edit: Okay, so thinking about it more I went back to the original sample and had a close look again. While it's not obvious, all of the "faults" we're seeing in the encodes seem to actually be present in the source, only to a much lesser degree. There is "banding" on the wall/door behind the couple in the bed, for example. You'd kind of assume a transparent encode wouldn't make it any worse, but I'm still thinking it's not the encoder's fault as the uncompressed AVI version looks far worse than the source. Someone more clever than I am will have to explain why.

Anyway, I might do something different now, like actually watch a video for a change.....

[shanndogg]

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.

I checked out your files and agree completely with your assessment. Crazy, I never saw something like that wobble before.

observe violet chroma dance at 16s (that is, besides megahuge filesize).

Damn, I wish I knew what that meant!

However i did check some other movies (pretty much anything has a room scene with vigneted wall, done in post or light setup) and none has even a single scene that would look as problematic as this one, so i guess its a pretty lonely problem, a killer sample if you wish.

I tried to watch a bunch of my previous encodes again and agree with the statement that this particular sample is unique, but there are others I have seen like this. Why some sources cause the problem more than others is beyond me.

Luckily, from the suggestions and help given here, I have been able to determine that if I encode from now on at 1080p CRF18 or better, I do not see the problems anymore (i.e. the encodes once again become at or near transparent). Thus, the main purpose of my post has been solved and I thank everyone for their help!

To follow up: I was able to view the last few tests of 7ekno's suggestion with a 720p CRF 17 and 1080p CRF 18 both with veryslow, tune film, AQ 1.15, and no DCT decimate. The 720p was much better than previous attempts, but I still saw problem areas at my normal viewing distance. Because of this, 720p is out for me. The 1080p was slightly better than just using veryslow and tune film, which was slightly better than medium (default) preset CRF18. File sizes were 4.2GB for default CRF18, 4.3GB adding veryslow and tune film, and 5.0GB adding AQ1.15 and no DCT decimate. I would say the slight difference veryslow and tune film made was worth it, but I am still trying to decide if I should add AQ1.15 and no DCT decimate.

hello_hello has been kicking ass with his tests and I am curious to see if there is any resolution to this potential decoder/encoder issue.

[nibus]

If you use the default --veryslow profile, you will want to manually specify the reference frames for 1080p if you want to retain DXVA compatibility. For 1920x1080 the maximum reference frames is 4, for 1920x816/800 the max is 5. This will also significantly speed up encoding.

x264 always has the hardest time with keeping details in grainy/dark/gradient areas. It can be a real trick to get it to keep it, but in general there are a few things I use: --no-dct-decimate, raising --psy-rd to around 1.10-1.20, and lowering the CRF to 17 or lower if needed. For AQ I wouldn't recommend over .8 for most 1080p material, as the details in the scenes will look less sharp. --psy-rd and a low CRF is really where it's at for retaining those fine gradient details.

edit:

also, the higher the --me, --subme, and --merange values the better results you'll have (obviously). --me umh --subme 11 is pretty effective at retaining this detail. Obviously the very best would be the placebo --me tesa --subme 11, but the difference is very small and the speed decrease is large.

Setting --merange to 24 or higher can also help with the faster moving grainy areas, but it will also significantly decrease encoding speed. I would recommend trying --me umh --subme 10/11 --merange 24 and see how that does as far as speed and quality.

[QuantumRand]

Great news! Thanks largely to your guys' help, I've figured out my problem. It was all due to the ATI Catalyst Control Center. For whatever reason, settings in the CCC were exaggerating the banding on my TV. On my laptop (which is my main/faster computer and where I fiddle with the encoding settings), the banding would still show up (bright LCD monitor settings), but I could see the different quality settings making a difference. On my TV, the quality settings (and even upping the average bitrate to 8000kbps) made zero difference.

I haven't narrowed down which setting was the culpret quite yet (probably "Edge-enhancement"), but I'm going to try different settings to see. Also, I'll have to re-try various quality settings on my encodes to see just how bad the banding is with the right CCC settings (I was using a 7000kbps sample when I found out what was going on).

I'm not sure if this will help Shanndogg out, since his (her?) source already has banding problems to begin with, but it's worth looking into your driver settings just to make sure.

Edit: Interestingly, it was the "De-noise" setting that did it. All the other settings didn't seem to affect the banding in a negative way.

[Atak_Snajpera]

I always disable everything in CCC
EDGE-Enhancement - OFF
De-Noise - OFF
Dynamic Contrast - OFF

[hello_hello]

Great news! Thanks largely to your guys' help, I've figured out my problem. It was all due to the ATI Catalyst Control Center. For whatever reason, settings in the CCC were exaggerating the banding on my TV.


Ahhhhhh..... I wonder why ATI seems to enable all that stuff by default while Nvidia doesn't. Having an Nvida card it never occurred to me to consider the video card might be the culprit.

Now we just need an explanation as to why shanndogg's sample doesn't even convert to uncompressed video well. Maybe someone clever will still come among.....

[QuantumRand]

Ahhhhhh..... I wonder why ATI seems to enable all that stuff by default while Nvidia doesn't. Having an Nvida card it never occurred to me to consider the video card might be the culprit.

Now we just need an explanation as to why shanndogg's sample doesn't even convert to uncompressed video well. Maybe someone clever will still come among.....

Well, in ATI's defense, I'm the one who turned them on. It was a long while back and I had completely forgotten about it, but turning them on helped immensely for SD content at the time.

[QuantumRand]

Hey Shanndogg, what is the source you pulled your movie from, if you don't mind my asking? 1080p Blu-Ray? Also, what method did you use to chop it into those clips?

When I experimented with your Original File-001, I was able to compress it relatively well without any sort of banding on the walls; however, the refrigerator was an entirely different story. When I looked at your original file, the banding on the refrigerator was actually quite apparent, which is why I'm asking about your source and your remuxing methods.

Lastly, I don't recall if you've mentioned this already, but what are your target results for your encodes? For example, I'm trying to turn my Blu-rays into 720p movies around 5GB (1080p and ~8GB for the more exciting ones).

[shanndogg]

It was all due to the ATI Catalyst Control Center. For whatever reason, settings in the CCC were exaggerating the banding on my TV.

So this looks like it falls into a calibration issue where CCC was "un-calibrating" your TV so the issue was amplified. Whereas, it is usually hidden in the unseen dark areas as it should be.

Hey Shanndogg, what is the source you pulled your movie from, if you don't mind my asking? 1080p Blu-Ray? Also, what method did you use to chop it into those clips?

When I experimented with your Original File-001, I was able to compress it relatively well without any sort of banding on the walls; however, the refrigerator was an entirely different story.

Lastly, I don't recall if you've mentioned this already, but what are your target results for your encodes? For example, I'm trying to turn my Blu-rays into 720p movies around 5GB (1080p and ~8GB for the more exciting ones).

You are correct on the original source and I used mkvToolnix to cut out the short samples. Click the "Global" tab and there is a box you can select to "enable splitting." Then just choose the size, duration, etc. as to how you want to split it and make sure you select the correct number of max files.

Out of curiosity, what settings did you use when you use when experimenting on Original File-001?

I don't have a specific target result in mind, just what ever looks transparent or near transparent to the source. With the Sharp TV that happened to be 720p CRF20 default settings which put files between 2-5gb. With the Panasonic it is now 1080p CRF18 veryslow, tune film which puts files between 6-13+gb (I've only done a couple so far).

[hello_hello]

shanndogg,
I'd still like to know what it is about your sample that's "different". Why it doesn't convert to uncompressed AVI well but you can still get acceptable results with a low enough CRF value, I just don't understand. Thinking about it though, I only tried converting it to uncompressed AVI at 720p so maybe resizing the video has a fair bit to do with it? It still seems somewhat odd though...

[Ghitulescu]

So this looks like it falls into a calibration issue where CCC was "un-calibrating" your TV so the issue was amplified. Whereas, it is usually hidden in the unseen dark areas as it should be.

No, it's not the calibration - it's the black level (or PC vs. TV levels). Some TVs have it disabled from factory, some don't, some have specific inputs for PCs.
On the computer side, one also has the possibility to select the levels in the drivers' settings.
On my first answer I thought you're watching them using a HW player, which by default uses the TV levels, on a TV with PC levels deactivated (normal case). My mistake.
"Blacker than black" levels will cause the issues you noticed.

[QuantumRand]

Out of curiosity, what settings did you use when you use when experimenting on Original File-001?

I don't have a specific target result in mind, just what ever looks transparent or near transparent to the source. With the Sharp TV that happened to be 720p CRF20 default settings which put files between 2-5gb. With the Panasonic it is now 1080p CRF18 veryslow, tune film which puts files between 6-13+gb (I've only done a couple so far).

The best 720p result I got was with a CRF of 16. The settings I used are pretty much the VerySlow settings with the Film tuning. CRF 16 was pretty much transparent compared to the source. There was still banding, but it was only a tiny bit worse than the source's.

From what I've seen, CRF16 is still enough to get your file sizes down to around 5GB for the typical 720p movie. I personally like to do my 720p transcodes at CRF17, and I'll go as low as 16 for the movies that have issues. But I also think that I have a pickier eye for detail than most.

For my favorite movies, I'll keep them in 1080p and use a CRF of 18 or 19. The Dark Knight, for example, compressed down to 7GB at 1080p and CRF19, and it's a 2.5 hour long movie.

Your clip is almost entirely transparent with the source if I transcode it at 1080p with a CRF of 18 (19 exaggerates the banding slightly more).

In my (very limited) experience, if you're squeezing a full-length 720p movie into files smaller than 4GB, you're probably losing a lot of detail.

Just out of curiosity, how long is the entire movie, and how big is the original source? I only ask because I have yet to come across a Blu-ray that had noticeable banding like this one.

[ramicio]

It's called copping. When backing up their own stuff, some people prefer full 16:9 with black bars, and some people prefer to crop. It's in no way an indication of "piracy".

[hello_hello]

In my (very limited) experience, if you're squeezing a full-length 720p movie into files smaller than 4GB, you're probably losing a lot of detail.

I don't know.... it depends on how large the audio stream is too, but my CRF 20 720p encodes range between 2.5 and 5 GB. Dark Night (just for reference) is 3.3GB. Obviously it's not hard to compress.

Up until this thread I've been perfectly happy with the quality and don't seem to have lost much detail.... but then this thread and problem samples came along....

Just out of curiosity, how long is the entire movie, and how big is the original source? I only ask because I have yet to come across a Blu-ray that had noticeable banding like this one.

I know the movie is one hour, 30 minutes long but don't recall how large the original video is.

[diogen]

In my (very limited) experience, if you're squeezing a full-length 720p movie into files smaller than 4GB, you're probably losing a lot of detail.From my just as limited experience you need about 1GB/hour to get a transparent DVD encode and 4GB/hour for a BD.
Video only, 1080p, 2.35. Error bars +/- 20%.

It takes more for a full 16:9.

Diogen.

[nibus]

Bitrate requirements are much more film specific. Toy Story in 1080p could be done in <4gb while Transformers needs 15-20.

[hello_hello]

No, it's not the calibration - it's the black level (or PC vs. TV levels). Some TVs have it disabled from factory, some don't, some have specific inputs for PCs.
On the computer side, one also has the possibility to select the levels in the drivers' settings.

No, it's not the calibration. That's why shanndogg described it as the ATI card "un-calibrating" the TV.

It's probably not TV vs PC levels either, or I'm sure QuantumRand would have mentioned the levels changing. According to QuantumRand it was simply the noise filter making the banding look worse.

Why is ramicio talking about cropping and piracy? Did he post in the wrong thread or am I missing something?

[shanndogg]

I'd still like to know what it is about your sample that's "different".

So would I, but until I hear otherwise I am just going to take it as some films (or just scenes within films) aren't authored that great (as seen in my example) and require higher settings than other films. That's why I was trying to find a good base. Of course, many of my encodes will probably be overkill now, but I would rather loose a little space than have poor quality.

Just out of curiosity, how long is the entire movie, and how big is the original source? I only ask because I have yet to come across a Blu-ray that had noticeable banding like this one.

Thanks for the info Quantum- glad to see your findings match up with mine. The orginal is an hour and 30 minutes as hello_hello mentioned and is around 17.5gb.

[diogen]

Bitrate requirements are much more film specific.Very much so.
Animated features are generally much more compressable.

Older movies with lots of grain are the worst.
I could not make anything remotely decent (with smaller sizes) out of the Dollars trilogy of Eastwood.

Diogen.

[hello_hello]

So would I, but until I hear otherwise I am just going to take it as some films (or just scenes within films) aren't authored that great (as seen in my example) and require higher settings than other films. That's why I was trying to find a good base. Of course, many of my encodes will probably be overkill now, but I would rather loose a little space than have poor quality.

There's probably nothing else you can do unless the reason they require higher settings is discovered, but I still think there's something else going on and it's not just that the encoder requires a higher quality setting to get it correct. If it was just the encoder your sample would convert to uncompressed AVI and look fine, but it doesn't.

Very much so.
Animated features are generally much more compressable.

Older movies with lots of grain are the worst.
I could not make anything remotely decent (with smaller sizes) out of the Dollars trilogy of Eastwood.

Which is why, as a general rule, I find the practice of file size based encoding somewhat hard to understand.

[Ghitulescu]

Which is why, as a general rule, I find the practice of file size based encoding somewhat hard to understand.

That is EXACTLY the argument/answer given when asked why they reencode :) :p ;)

[QuantumRand]

Just out of curiosity, is there anything inherently bad about Target Average Bitrate encoding, other than it taking a long time?

I can't imagine ABR would be very useful without two-pass encoding, but with the Turbo First-Pass, the total encoding time is fairly tolerable. Plus from what I've seen, turbo first-pass didn't have that huge of an effect on file size.

I've found that a 720p backup with an ABR around 5000kbps gives a pretty consistent ~2.2GB/hour. And at 5000kbps, you can use the Normal preset and Turbo First-Pass and still get the same file size while still maintaining essentially transparent quality as you would with 16CRF. Turbo First-Pass, Normal preset takes like 25% longer than CRF16 on VerySlow but you get the same quality results. The file size is typically larger, but always consistent.

[diogen]

Just out of curiosity, is there anything inherently bad about Target Average Bitrate encoding, other than it taking a long time?I think all those different methods of encoding have more of an historical significance than anything else.

When the hidef optical media was introduced - HD DVD and BD - the encoding workflow has changed.
With DVDs it was a hardware box with one dial - bitrate.
That took care of DVD creation (at least most of it).

With HD/BD this process became manual.
And since the players were limited in horsepower, there was a need to limit complexity of the encode.
So it became a 2-pass automatic encode with manual tuning afterwards.

All this is moot by now.
BD is the sole hidef optical standard for 4 years. H.264 has improved quite a bit.
Some of those improvement are withing the BD standard, some - outside.

The silicon running in those players - hardware or software - are 5+ times faster. Even more so with PC playback (GPU assistance).

Diogen.

[hello_hello]

That is EXACTLY the argument/answer given when asked why they reencode

When "they" are asked why "they" re-encode (who are they?) the answer given is they find the practice of file size based encoding hard to understand?

What on earth are you talking about?

[sneaker_ger]

Just out of curiosity, is there anything inherently bad about Target Average Bitrate encoding, other than it taking a long time?

No, two pass encoding is totally fine. Single pass ABR on the other hand has lower quality than CRF and two pass.

Plus from what I've seen, turbo first-pass didn't have that huge of an effect on file size.

What else did you expect? ABR (both single and two pass) aims for a defined bitrate, so not having "that huge of an effect on file size" is totally meaningless in these modes.

I've found that a 720p backup with an ABR around 5000kbps gives a pretty consistent ~2.2GB/hour.

Again: what else did you expect?
1h * 5000 kbit/s = 60s*60*5000kbit/s = 18,000,000 kbit ~= 2.2 GB

And at 5000kbps, you can use the Normal preset and Turbo First-Pass and still get the same file size while still maintaining essentially transparent quality as you would with 16CRF. Turbo First-Pass, Normal preset takes like 25% longer than CRF16 on VerySlow but you get the same quality results. The file size is typically larger, but always consistent.

Frankly put, you're not making any sense. Don't use fast first pass if you only want to do only a single pass, use a faster preset instead.

[smok3]

how would this work (staring at libvpx docs):
-crf 21 -max-rate 5000 -preset variable-reencode-with-slower-preset-if-bitrate-limit-is-reached:else:lower-the-crf-and-tell-that-to-the-user ?

[QuantumRand]

Frankly put, you're not making any sense. Don't use fast first pass if you only want to do only a single pass, use a faster preset instead.

I guess what I was getting at is that CRF mode seems to reduce the bitrate a little too much in some spots, exaggerating imperfections. This means you have to lower the CRF to points where the majority of the movie doesn't benefit, or you have to waste time experimenting with different CRF levels.

Assuming it actually does act this way, going the ABR route could avoid degraded quality in those situations, sacrificing some compression, but with a calculable result. But like I've said, I'm pretty new to the transcoding game, so I'm just making guesses.

[Asmodian]

This means you have to lower the CRF to points where the majority of the movie doesn't benefit, or you have to waste time experimenting with different CRF levels.

Assuming it actually does act this way, going the ABR route could avoid degraded quality in those situations, sacrificing some compression, but with a calculable result. But like I've said, I'm pretty new to the transcoding game, so I'm just making guesses.

This is an odd assumption, if some regions need a little more bitrate and lowering CRF "wastes" bits on regions that don't need it going ABR will make this even worse; it isn't as good at moving bits to where they are needed.

I think you want to play with psy settings and aq-strength instead of dropping crf.

[hello_hello]

QuantumRand,
For the sake of full disclosure I discovered, due to participating in another thread, I'd been sending the wrong levels to the TV from my PC. I thought being a TV sending it TV levels would be correct, and the picture certainly looked fine to me, but after changing the levels and then adjusting the brightness to get it roughly back to where it was (I haven't tried to calibrate it properly yet) I had a look at the encodes I made of your samples again.
Most of the problems I could see before I can now no longer see because the dark areas are darker. Even the shot from above where the camera slowly turns and I said it appears to wobble..... the difference now between 1080p CRF 16 and 720p CRF 20 is fairly minimal. Not enough to really notice unless I compare the two. Even the scene of the sky where the blocking looked really obvious, well at 720p CRF 20 I can still see it if I look for it but during the process of watching a movie I'm not sure it's anything which would jump out at me.

shanndogg's samples are still a different matter. The darker areas now look pretty good but the banding in the lighter areas and the problem with dancing pixels is still something I can see fairly easily and still something which seems to get worse when encoding.

[QuantumRand]

QuantumRand,
For the sake of full disclosure I discovered, due to participating in another thread, I'd been sending the wrong levels to the TV from my PC. I thought being a TV sending it TV levels would be correct, and the picture certainly looked fine to me, but after changing the levels and then adjusting the brightness to get it roughly back to where it was (I haven't tried to calibrate it properly yet) I had a look at the encodes I made of your samples again.
Most of the problems I could see before I can now no longer see because the dark areas are darker. Even the shot from above where the camera slowly turns and I said it appears to wobble..... the difference now between 1080p CRF 16 and 720p CRF 20 is fairly minimal. Not enough to really notice unless I compare the two. Even the scene of the sky where the blocking looked really obvious, well at 720p CRF 20 I can still see it if I look for it but during the process of watching a movie I'm not sure it's anything which would jump out at me.

shanndogg's samples are still a different matter. The darker areas now look pretty good but the banding in the lighter areas and the problem with dancing pixels is still something I can see fairly easily and still something which seems to get worse when encoding.

My issues with the banding were solved when I disabled the De-Noise feature in the Catalyst Control Center. CRF 17 did a good job compressing everything down, and the problem areas, while still visible, are certainly tolerable in a normal watching scenario. I'm happy with the result, especially since I don't think Thor is worth that much of my time, lol.

But like you said Shanndogg's issues are a different matter. The source itself has the banding issues. I think what he (she?) needs to do is focus on optimize the display settings, since the old TV didn't have the issue. I'd use the uncompressed sample as a guide for tuning in the settings to the best possible.

Maybe the TV's motion enhancement is screwing with things? Since I have my TV connected to my PC, I have all of the extra features turned off since the computer is capable of handling all of that better anyway.

[Ghitulescu]

I think what he (she?) needs to do is focus on optimize the display settings, since the old TV didn't have the issue. I'd use the uncompressed sample as a guide for tuning in the settings to the best possible.
A TV is not calibrated using uncompressed sources. It is calibrated using special patterns and methods to single out each element, then tune it accordingly.
Maybe the TV's motion enhancement is screwing with things? Since I have my TV connected to my PC, I have all of the extra features turned off since the computer is capable of handling all of that better anyway.
The "extra features" are there for stupid people (sorry) that are more than happy to set them once and forget. With the notable exceptions of masochists and pros (who are anyway paid to do this, like it or not), nobody likes to fiddle the settings for each movie, show or whatever programme they watch. They also pay more for the TVs incorporating them, only to find out (if :)) that the image is better without them activated.

[hello_hello]

But like you said Shanndogg's issues are a different matter. The source itself has the banding issues. I think what he (she?) needs to do is focus on optimize the display settings, since the old TV didn't have the issue. I'd use the uncompressed sample as a guide for tuning in the settings to the best possible.

I still don't think shanndogg's issues are related to calibration. I can see the banding on my PC monitor and I can see it on the TV both before and after changing the levels. It may be his old TV was hiding the problem somehow, or had some sort of built in deblocking or debanding which masked the problem. My TV has a digital noise filter and an mpeg noise filter and although I've not been able to determine exactly what they filter, one of them did reduce the blocking on a poor quality AVI I was using for testing. However when using the PC I have them turned off and they're set to "low" for the Bluray player.

And of course there's still the question as to why when converting his sample to uncompressed RGB, it makes the banding a lot worse. That doesn't make sense to me.

[hello_hello]

The "extra features" are there for stupid people (sorry) that are more than happy to set them once and forget. With the notable exceptions of masochists and pros (who are anyway paid to do this, like it or not), nobody likes to fiddle the settings for each movie, show or whatever programme they watch. They also pay more for the TVs incorporating them, only to find out (if ) that the image is better without them activated.

Just to clarify....
Is it the stupid people who pay more for a TV with extra features which they then happily set and forget while somehow still managing to discover the image looks better without them, or is it the non-stupid people paying paying more for TVs with "extra features" they're not going to use so they can be even less happy about fiddling with the settings for every movie? :)

[Ghitulescu]

The first category. It's the power of marketing.

[7ekno]

7ekno - what profile do you use?


I use WDTV Lives and HTPCs, so not restrained to profile (yes, I have extensively tested my settings on a WDTV Live with level 5.1 and 5.0 profiles!) ...

Also note that I stated I degrained first before using those settings (so filesize is naturally reduced from degraining) ...

Personally I would use:
- Crop & Spline36 resize to 720p (or leave as 1080p)
- MCTemporalDenoise(settings="low", enhance=true)

Then encode with my previous settings (for 720p):
--crf 17 --tune film --preset veryslow --no-dct-decimate --aq-strength 1.15

Here is how I would have done the 720p versions:
http://www.teknosrealm.com/examples/001_720p.mkv
http://www.teknosrealm.com/examples/003_720p.mkv

7ek

[Didée]

The "extra features" are there for stupid people (sorry) that are more than happy to set them once and forget.
According to your tunnel vision, I'm in the category of "stupid people", too. :)

To keep it compact, here's a wall-of-text:

The strongest point, to me, indeed is the motion interpolation feature. I would not want to miss it from my TV anymore. Note that I do not, repeat: NOT like "soap opera" effects. But the problem is that it's not possible to really reproduce the so-called "film look" on any modern flatpanel display. Not without the help of additional "tools". Yes, film look is intended to show a kinda "rough" motion (and I like it.) But if you have e.g. a panning scene with a house front running through the frame, you are NOT supposed to see double- or, more likely, even triple- or quadrouple-contours on wall corners, windows,etc. But that's exactly what you get without motion interpolation. Necessarily, it can not be any other way. If each picture "stands" for 40 ms, but the eye is continuously moving as it is tracking any image feature, you necessarily get motion blur on the eye's retina. (And worse, it's even inverse motion blur, that is building up "backwards" during the integration time of one frame. But this gets a bit too far for this thread.) Is it so that self-conceived videophilists have "declared" such artifacts as being "the" film-look? To me, this simply is an optical artifact that should not be.... - Granted, I'm not sure how "all the various manufacturers" individually implement the feature. Anyhow, on my TV (Samsung) there is a rather fine-granulated control over the strength of the motion interpolation feature, and at low settings it does a mostly splendid job at reducing retina-motion-blur, while leaving the "rough" film look mostly intact.

[Ghitulescu]

[QUOTE=Didée;1555695]According to your tunnel vision, I'm in the category of "stupid people", too. :)/QUOTE]

Not at all, I like it too to have this kind of setting. But it should work correctly.

Unfortunately the one that decides what "improvements" are implemented and which not, is someone with the rot pencil, that listen more the marketing dept. than the engineering one. The customer['s opinion] doesn't count, if he doesn't buy, just lower a bit the prices and he will. Eventually. Because he has no real alternatives, or they cost way too much.

[ramicio]

A film is NOT intended to show a rough motion. It was the limits of film reacting to light almost a century ago, and we haven't left it yet. If film was invented today, we would be going with hundreds of FPS and no one would say boo about the smooth motion looking too realistic. If you want your old movies to be choppy, then fine, but I don't think new movies should still suffer from it. They're new, and they should look new. By your logic, movie audio should just be mono so we know it's a movie, yet we strive to realism in the sound. But oh no!...once you get into specs on the picture, it's taboo to be new.

[hello_hello]

Unfortunately the one that decides what "improvements" are implemented and which not, is someone with the rot pencil, that listen more the marketing dept. than the engineering one. The customer['s opinion] doesn't count, if he doesn't buy, just lower a bit the prices and he will. Eventually. Because he has no real alternatives, or they cost way too much.

The nothing like following up a post of silly generalizations with another one even sillier.

Sure the marketing department can do it's job well, but have you heard of competition? Is a manufacturer going to ignore the engineering department when they announce they've found a way to do feature X better than everyone else if they think it'll help them sell more TVs? And yes of course new features are generally added to the more expensive models first, but it doesn't mean they can't trickle down to be included as standard on the average smart phone in a few years time.

I don't know who ramicio is arguing against. Who said film shouldn't be allowed to use higher frame rates?

[Ghitulescu]

Sure the marketing department can do it's job well, but have you heard of competition? Is a manufacturer going to ignore the engineering department when they announce they've found a way to do feature X better than everyone else if they think it'll help them sell more TVs? And yes of course new features are generally added to the more expensive models first, but it doesn't mean they can't trickle down to be included as standard on the average smart phone in a few years time.

There is no competition, my dear.

Or maybe who against whom? JVC versus Technics versus National versus Panasonic versus whatever-subsidiary-Matsushita-corp might have? Or maybe between the 101 companies Harman-Kardon fully owns?

Or maybe the 5 bigs in cellphone technology suddenly began to compete, ending a 20 years period of cartell-dealings?

There is definitively competition in electric toothbrushes industry, yes! But, no, wait, Philips sold everything except medical and lighting, no way... :) gosh, I almost found one ... :)

[Didée]

I don't know who ramicio is arguing against.
The "who" is not important. Important is the "against". :D

[hello_hello]

There is no competition, my dear.

No..... at least not for offering generalizations and confabulations

[shanndogg]

QuantumRand,
For the sake of full disclosure I discovered, due to participating in another thread, I'd been sending the wrong levels to the TV from my PC.

After reading your post and the other thread about black levels, I went and reexamined all of my settings and found something interesting:

The Boxee Box which plays my MKVs was outputting RGB Low (16-235). On another site for the Panasonic VT30 series, it was indicated to have your Bluray player output YCbCr 4:2:2 (this is what I have my Bluray player set to). So I tried setting the Boxee Box to output YUV 4:2:2 (I assume it's the same as the Bluray player YCbCr?). Guess what? The original 720p file that looked really bad to me know looked way better... almost transparent and definitely acceptable. The 1080p's still looked better, but I could probably live with the 720p. Does this make sense?

Previously, I had the Bluray player and Boxee both outputting RGB low to the Sharp LCD and never had a problem. I remember I tried YCbCr on the bluray before with the Sharp, but it caused a weird flickering in the letterboxed portion of Blurays/DVDs.

Now, with the Panasonic, it looks like I need 4:2:2. I tried 4:4:4 but couldn't tell an immediate difference. With the difference so big between RGB and 4:2:2 on the Panasonic, I am wondering how the hell are you supposed to know what to use (RBG low/high, 4:2:2, 4:4:4) for which source/display?

[Asmodian]

Now, with the Panasonic, it looks like I need 4:2:2. I tried 4:4:4 but couldn't tell an immediate difference. With the difference so big between RGB and 4:2:2 on the Panasonic, I am wondering how the hell are you supposed to know what to use (RBG low/high, 4:2:2, 4:4:4) for which source/display?

4:2:2 = low bandwidth 4:4:4. 4:4:4 is just better and doesn't change anything vs 4:2:2. Not that you can tell and your source content is almost surly 4:2:0 anyway but I wouldn't do much testing of 4:2:2 vs 4:4:4.

RGB low/high is one of those terrible names. Is RGB low = 16-235 or 0-255? I assume low = 16-235 because if you just switch back and forth between 16-235 and 0-255 using 16-235 looks darker.

EDIT: This is wrong! 0-255 looks darker (expanding 16-127 to 0 to 127 streaches more values into the "darker" range, 128-235 -> 128-255 does the same, makeing bright seens brighter but this is less noticable)

Anyway the YCbCr spaces (i.e. 4:4:4) allow your TV to do the conversion to RGB while if you set RGB out you need to pick the right one (16-235 for normal blurays etc.). How your TV does the convertion from YCbCr to RGB is up to it.

[diogen]

I am wondering how the hell are you supposed to know what to use (RBG low/high, 4:2:2, 4:4:4) for which source/display?Consumer digital video is always 4:2:0, 16-235 (DVD, BD, satellite, cable, etc.).
Computer graphics is 4:4:4, 0-255.

If conversion is needed make sure the most competent device does it.

Diogen.

[hello_hello]

So I tried setting the Boxee Box to output YUV 4:2:2 (I assume it's the same as the Bluray player YCbCr?). Guess what? The original 720p file that looked really bad to me know looked way better... almost transparent and definitely acceptable. The 1080p's still looked better, but I could probably live with the 720p. Does this make sense?

Yes.

Now, with the Panasonic, it looks like I need 4:2:2. I tried 4:4:4 but couldn't tell an immediate difference. With the difference so big between RGB and 4:2:2 on the Panasonic, I am wondering how the hell are you supposed to know what to use (RBG low/high, 4:2:2, 4:4:4) for which source/display?

I don't think there should be any difference between YCbCr 4:2:2 and 4:4:4 (my video card only outputs the latter) so it really comes down to RGB vs YCbCr and/or TV levels vs PC levels.

I can't speak for every device but a PC natively outputs PC levels (0-255) and RGB so that's what I'm sticking with.

When using a PC as the playback device (RGB output), if you want everything else in Windows to display correctly (images, browser, etc) then I'm fairly certain the HDMI black level needs to be set to normal (on my TV the choices are low or normal, but it might be low or high etc). Using the low setting seems to get the TV to expand everything, not just video.
So for a PC outputting RGB, I think you'd always want to set the video card to expand the video levels to full (0-255). Using a VGA input there should be nothing else to worry about, using HDMI the TVs black level should be set to "normal" (or high).
I think if the renderer is already expanding the video to PC levels, the video card's RGB output levels should make no difference. At least that seems to be how it works for me but I've only tested it using the Haali renderer and XP and only while connected via VGA.

When any device outputs YCbCr (either 4:2:2 or 4:4:4) I'm pretty sure the TV will then always expect limited levels (16-235). The TV probably won't give you an option to change the HDMI black level anymore and if it's a PC, the video output should also be set to (16-235).

I know nothing about the Boxee Box but from what you describe it makes sense. Getting it to output YCbCr it'd probably be outputting TV levels (16-235), the TV would be expecting TV levels and everything would be fine. As it was previously outputting limited RGB (16-235) I'd guess changing the TV's HDMI black level to "low" would be correct, or leaving the black level on normal (or high) while changing the Boxee's output to RGB 0-255.

[hello_hello]

Unbelievable!!

I just discovered the source of my problem with TV vs PC levels. I was almost certain I'd changed the video card's output to RGB 0-255 when I first connected it to the TV via VGA, but when I checked recently and discovered it was set to 16-235, I assumed I'd just imagined doing so. Now I discovered my video card, in it's infinite wisdom, is ignoring my RGB setting for the TV and defaulting to "use the video player settings" every time I reboot, which for me effectively means it's resetting back to 16-235. And I thought I was going mad....
I'm not sure why.... It happens whether the TV is connected via VGA or HDMI, so it must be a "secondary monitor" issue. Hopefully when I update the drivers for the video card later, that problem with go away....

[QBhd]

ATI/AMD or Nvidia?

QB

[hello_hello]

Nvidia (8600GT).
I've updated the drivers but still have the same problem. If I only ever enable a single monitor the setting seems to survive a reboot, but once I've enabled two....
I've got a spare card lying around so I'll probably use it to run the TV and hopefully a separate card for each monitor will fix the problem. The way the video card is setup the DVI out and therefore the TV is the primary monitor, while the VGA out and therefore my CRT is the secondary monitor. At least until Windows loads and swaps them around. Two video cards will fix at least that annoyance.

[diogen]

I thought to post the link to this (really interesting, I believe) thread started by Stacey Spears and related to the 4:2:0 vs. 4:2:2 issues
http://www.avsforum.com/avs-vb/showthread.php?t=1011359
As has been mentioned by the encoding pros numerous times, encoding 4:2:2 video would probably
end up in same size files despite the original being larger: mainly because of dithering not needed.

As a side note: 4:2:2 video is easy to notice.
For a few years around 2005 some NA satellite providers were hacked and computers could be used as a satellite receiver.
If you knew where to look, you could tune into an 4:2:2 NBC feed for their affiliates (the ad spots were empty).
None of the satellite receivers could play them (they support only 4:2:0), but the PCs with the right satellite cards were able to show them.
The difference was immediately noticeable!

Diogen.

EDIT:
The dithering tool Stacey talks about was used in the production of Ratatouille (http://www.imdb.com/title/tt0382932/) (2007).
That animated feature won the Oscar that year.

[shanndogg]

So it appears that my TV likes to receive YCbCr (YUV) instead of RGB, but I am still somewhat confused regarding black level. Here is my understanding of the output setting of the Boxee Box (and in general): YCbCr (YUV) 4:2:2 and 4:4:4 are 16-235, RGB Low is also 16-235. RGB High is 0-255. When using RGB High, the picture becomes darker whereas all of the other settings seem to maintain the same level of "lighter" darkness.

Shouldn't this effect be reversed according to this article (http://www.audioholics.com/tweaks/calibrate-your-system/hdmi-black-levels-xvycc-rgb): "If you mismatch and play back with RGB (0-255) settings, you'll clip off the black and white levels and black will look "dark gray"?

[Asmodian]

That is the expected behavior.

Using RGB Low 16=Black and using RGB High 0=Black. If your TV is already black at 16 than everything 16 and below is also black. If you expand 16-235 content to 0-255 and then display it on your TV which is expecting 16-235 the video looks darker. The clipping and streaching of the whites is much less obvious than clipping and streaching of the blacks in most real life video content.

Edit: If you recalibrate your TV to 0=Black and 255=White and output RGB High than the video should look about the same (as it would with the TV calibrated to 16=Black and outputing RGB low). Any BtB or WtW would be clipped but you shouldn't be able to see them in limited range video anyway. If you have computer or video game video sources they will look bad with black and white clipped. This can get odd if you have a full range video that your player thinks is limited range; if it is set to output RGB Low it will probably clip any out of range values and if set to output full range it will still clip but also expand the ranges messing up the video a lot.

If you send YCbCr to the TV you just pass this issue on to the TV and let it deal with it however it will. The key is a smart player that expands limited range videos but doesn't expand full range sources and always sending full range RGB to the TV. This way you at least know what is happening to the video, the TV doesn't mess with it, and you can use one calibration of the TV for all video sources.

I explained this wrong in my previous post, I have edited it too. I hate the Low/High names. :o

[diogen]

Chroma subsampling (http://en.wikipedia.org/wiki/Chroma_subsampling) (4:2:0, 4:4:4, etc.), black levels (0-255, 16-235) and
colorspace (http://en.wikipedia.org/wiki/Color_space) (RGB, YCbCr, YPbPr, etc.) are different characteristics of a video stream and very loosely connected.

Diogen.

[Asmodian]

Chroma subsampling (http://en.wikipedia.org/wiki/Chroma_subsampling) (4:2:0, 4:4:4, etc.), black levels (0-255, 16-235) and
colorspace (http://en.wikipedia.org/wiki/Color_space) (RGB, YCbCr, YPbPr, etc.) are different characteristics of a video stream and very loosely connected.

Yes, and what are you trying to point out?

[hello_hello]

So it appears that my TV likes to receive YCbCr (YUV) instead of RGB, but I am still somewhat confused regarding black level. Here is my understanding of the output setting of the Boxee Box (and in general): YCbCr (YUV) 4:2:2 and 4:4:4 are 16-235, RGB Low is also 16-235. RGB High is 0-255. When using RGB High, the picture becomes darker whereas all of the other settings seem to maintain the same level of "lighter" darkness.

It sounds correct, although I assume when outputting RGB the TV is defaulting to RGB low, which is why it looks the same as YCbCr. I wish manufacturers would drop the "normal", "high" or "low" labels and use something a bit more initiative such a "full" or "limited".

Shouldn't this effect be reversed according to this article (http://www.audioholics.com/tweaks/calibrate-your-system/hdmi-black-levels-xvycc-rgb): "If you mismatch and play back with RGB (0-255) settings, you'll clip off the black and white levels and black will look "dark gray"?

What they're saying there is correct and you should be able to duplicate it using your TV, but the description "clip off the black and white levels" is probably counter-intuitive.
If your TV is set to expect 0-255 (as a computer monitor would be) and you feed it 16-235 levels.... 16 is supposed to be black but the TV expects 0 to be black, so 16 appears a dark grey instead, therefore the black level could be said to have been "clipped".

Doing it the other way around, where the TV expects black to be 16 but you feed it video where black is 0, black will still be black so it hasn't been "clipped", but anything between 0 and 16 will also display as black.

To work out what's "correct" try to find a video which contains black bars as they can be used to determine what's "black". Feed the TV RGB 16-235 and make a note of how "black" the black bars are. Change the output to 0-255. If the black bars get blacker then the TV expects 0-255. If the black bars were already black but the video itself gets darker, then the TV expects 16-235.

Going by my TV alone.... when receiving YCbCr the TV will always expect 16-235 and not give you an option to change the black level. I don't know if the Boxee Box lets you change the levels when the output is YCbCr. If it doesn't I think it'd be safe to assume 16-235 also, but anything's possible.

[shanndogg]

Got it, I had a feeling I was misinterpreting the article somewhat. So now I found two solutions to my initial problem: 1) Use YCbCr instead of RGB as output and 2) If outputing RGB, I have to use a much high encode setting (1080p CRF 18 instead of 720p CRF 20).

But how can this be? A lot of you experienced the same problems I did when testing the files, and everyone can't have the same setup as me (TV needing YCbCr, etc). Why does YCbCr hide the exaggerated blocking, pixel, and banding artifacts on the 720p making it look near the original, whereas RGB shows it. With RGB, why does a larger encode remove the problems?