encoding bluray with minimal quality loss

[gav1577]

Hi guys i am quiet new to the world of x264 and would like some help please with a problem i am having with certain parts of movies
usually sky/clouds or dark foggy parts of a movie get patchy bands of colour its hard to explain please take a look at my screen shots all my encodes look great in light areas just get problems in areas stated above please don't get to technical as i said i have only been doing x264 encodes a few months here are some screen shots of a bluray movie i ripped and encoded btw i am trying to keep the movie as close as possible to
its original quality and size give or take a few mb thanks reason being vc1 and stutter issues

http://aycu02.webshots.com/image/46681/2001918751886822092_rs.jpg
http://aycu10.webshots.com/image/44449/2001946317775382256_rs.jpg

here are my settings
--pass 2 --bitrate 14583 --stats ".stats" --level 4.1 --keyint 25 --min-keyint 1 --ref 3 --mixed-refs --no-fast-pskip --bframes 2 --bime --weightb --direct auto --trellis 1 --analyse p8x8,b8x8,i4x4,i8x8 --8x8dct --ipratio 1.1 --pbratio 1.1 --vbv-bufsize 14475 --vbv-maxrate 25000 --qcomp 0.5 --me umh --threads auto --thread-input --cqmfile "C:\Program Files\megui\extra\eqm_avc_hr.cfg" --progress --no-dct-decimate --no-psnr --no-ssim --output "output" "input" --mvrange 511 --aud --nal-hrd --sar 1:1

[Guest]

Fix your title to comply with rule 9 real fast or you could get struck. Thank you.

[gav1577]

Thanks neuron2

[*.mp4 guy]

Disable trellis, set luma inter deadzone to 6, luma intra deadzone to 4, set b prediction mode to "none". If you have an x264 build with vaq, enable it at strength 0.6, if not you should probably get one. From the screenshots you posted (I'm assuming the first one is from your source) your source is not in perfect condition, there is borderline banding, that will cause problems for any re-encoding; it can be made less troubling by using the gradfun2db plugin in your avisynth script.

for example:
directshowsource("c:\movie", fps=23.976024)
gradfun2db(1.51)

[gav1577]

@*.mp4 guy thanks for the help much appreciated ;) one more question would crf give better quality than two pass and is there any way to roughly estimate output file size using constant quality
thanks again

[cogman]

@*.mp4 guy thanks for the help much appreciated ;) one more question would crf give better quality than two pass and is there any way to roughly estimate output file size using constant quality
thanks again

yes and no to the first question. if your bitrate is the same as CRF comes up with, then they are the same. if it is lower then CRF will be better, if it is higher, then 2 pass will be better. ;)

There is no way to predict how much bitrate CRF will use, but you can be confident that the quality will be what you wanted it to be. in very few cases does CRF fail for me. Most agree that a CRF of 18 will give you a near perfect encode, but the bit rate can be up to half the origional.

BTW, is that 300? if so, you might want to do a search on it, from what I have read it is a beast to encode.

[nm]

is there any way to roughly estimate output file size using constant quality
thanks again
This has been discussed here: http://forum.doom9.org/showthread.php?t=116773

[gav1577]

thanks cougar :) no its not 300 its harry potter and the order of the phoenix ive heard 300 was a beast to encode i will have to try
300 looking forward to the challenge :scared:

[cogman]

This has been discussed here: http://forum.doom9.org/showthread.php?t=116773

correct me if I'm wrong, but I believe that method basically stated that CRF scales well. However, you needed to do an initial encode in order to know where the bitrate would fall on the scale.

The biggest problem you run into with predicting the bitrate CRF will use is the fact that each film is very unique from the last. So a high motion random flashing colors video (SeizureTV!) will have a much higher bitrate output then a low action anime clip. Given they are basically the two extremes, but I just don't think there is any way to really know.

Though, I do have several episodes of mash that I have been ongoing encoding and they have all ended up around the same file size (+-10 mb) with the same CRF settings used, so I guess it can somewhat be predicted that way.

Anyways, sorry for the short highjack.

[gav1577]

set b prediction mode to "none" im not sure where to find this in megui do yo mean b frame mode from auto to none ?

[nm]

correct me if I'm wrong, but I believe that method basically stated that CRF scales well. However, you needed to do an initial encode in order to know where the bitrate would fall on the scale.
DDogg's idea was that for any target bitrate, you can estimate the CRF value to use by iteratively encoding small samples of the video (~1% of the frames, consisting of short, separate sequences). I couldn't find a post that summarizes it well, but here's one comment that may clarify the process a bit: http://forum.doom9.org/showpost.php?p=894725&postcount=101
If you are interested in this, just read the thread through.

The biggest problem you run into with predicting the bitrate CRF will use is the fact that each film is very unique from the last. So a high motion random flashing colors video (SeizureTV!) will have a much higher bitrate output then a low action anime clip. Given they are basically the two extremes, but I just don't think there is any way to really know.
That is the problem if you don't encode samples or at least look at the video, but this method/process does that for you.

[nurbs]

set b prediction mode to "none" im not sure where to find this in megui do yo mean b frame mode from auto to none ?

Yes, that is the option.

[gav1577]

thanks nurbs ;)

[gav1577]

I found gradfun2db combined with addgrainc has helped allot removing banding and now looks great thanks