x264 banding/posterizing (Quick Sync also)

[poisondeathray]

I think I have to conclude that this clip is simply an exception where not much, if anything, can be gained.

I've even followed the following guide and reduced the RF to 17 with similar results:
http://www.techspot.com/article/1131-hevc-h256-enconding-playback/page4.html

It took 0:05:44 to encode a 4 minute video on my i7-4930K OC'd to 4.6 GHz (1.464v) and hit a temp of 84 deg C (mind you my cooler was only set on medium).

The x265 version used is 1.9 (almost a year old which is ancient considering the pace of development) . Handbrake is using "general" settings with SAO (which tends to oversmooths), and "low" --psy-rd (2) and psy-rdoq (0) values which are required for grain retention . If you look at the grain preset, the values are 4 and 10.

Basically you want to use grain retention settings. I posted some earlier that were more gentle than --tune grain, but you can use --tune grain it's probably easier. But you need to increase the bitrate

And yes, this clip does need more bitrate than maybe "typical" sources which are brightly lit, less grain. Grain and noise are difficult to compress because they are "random". There are few redunancies between frames than can be utilized to increase compression.

Let me ask it another way - what bitrate range or filesize is acceptable to you ? The original was ~16.3Mb/s. This last one was ~4Mb/s . So ~1/4 the size. Just increase the bitrate or lower the CRF until the quality is acceptable. For example use --tune grain with a lower crf like 13-15. If you were happy with a QS AVC encode with "x" quality at "y" bitrate, I guarentee that x265 will hit that same "x" quality at less than half the bitrate. And yes, it's slow as hell, sucks up the wattage, but look at the bright side it will help warm you up in winter

If you're getting to the point around 8-10MB/s with x265 grain retention settings and still seeing the problems, I going to say that the problems are in the source . I'm going to ask you to take a screenshot and circle what you're actually referring to, or at least describe more clearly the problem you are referring to that isn't in the source already. I was under the assumption that the source looked ok to you, then the encodes did not. Then there are other ways, such as filtering the source, then debanding . Sneaker made some posts about this earlier. Also, 10bit helps with efficiency and clean gradients (but there aren't any clean gradients here) . x264 is a bit different - a larger part of it's "grain retention" is actually noise artifacts . Some people actually prefer the noise look. x265 is "cleaner" at preserving grain with grain settings and able to preserve finer grain with less bitrate

[ziggy1971]

I don't know which version of x265 was used or how to update it. Any suggestions on a better x265 encoder? Settings? Does ffmpeg do x265? I'll have to check.

Actually, I hate Handbrake, I only downloaded and installed it to do a software comparison of x265.
Handbrake doesn't use .avs scripts and that's a requirement for me, so I use MeGUI instead.

Right now, I've kinda ditched a "target" other than just trying different settings to see what comes up, perhaps better settings than I've used in the past, for both x264 and Quick Sync. I guess a ballpark figure would be between 1/8th and 1/3rd of the original size (some compress more)

I was thinking of switching the source file to something like Transformers, higher action, more color, etc. maybe getting a better idea of what to look for and how to achieve my own goals using another source.

Perhaps just accepting the fact that I can't transcode this series due to the way it was created. There's no point in beating this clip to death for minimal gains, right (mercy rule).

Just to give you an idea, the first 5 seasons (50 episodes) on Bluray just ripped to HDD is about 960 GB's. Extracting the episodes has reduced it to about half of that (8-13 GB's each)

Anyway, there's a lot of new stuff in these posts that I'll have to reread and get a better grasp on.
Thanx for you patience

Just found the link for the x265 CLI encoder, will check it out...

[poisondeathray]

Right now, I've kinda ditched a "target" other than just trying different settings to see what comes up, perhaps better settings than I've used in the past, for both x264 and Quick Sync. I guess a ballpark figure would be between 1/8th and 1/3rd of the original size (some compress more)

If that's the case, then you're going to want to read up on filtering, preparing for encoding. This is a different encoding strategy compared to grain and detail retention. You're going to want to denoise and degrain to improve compressibility (I'm talking in general terms, not necessarily for that episode) . The "cons" are it takes a long time to process for high quality denoisers, and then it predisposes you to banding. Vicious circle. So I would also look to move towards 10bit encoding (if not now, in the near future), which is becoming more common place, even in consumer hardware

[ziggy1971]

I used the latest HandBrake-0.10.5-x86_64-Win_GUI for the testing.

I don't know what this is or where you found those settings.

The x265 version used is 1.9 (almost a year old which is ancient considering the pace of development) . Handbrake is using "general" settings with SAO (which tends to oversmooths), and "low" --psy-rd (2) and psy-rdoq (0) values which are required for grain retention . If you look at the grain preset, the values are 4 and 10.

[poisondeathray]

I used the latest HandBrake-0.10.5-x86_64-Win_GUI for the testing.

I don't know what this is or where you found those settings.

The x265 version used is 1.9 (almost a year old which is ancient considering the pace of development) . Handbrake is using "general" settings with SAO (which tends to oversmooths), and "low" --psy-rd (2) and psy-rdoq (0) values which are required for grain retention . If you look at the grain preset, the values are 4 and 10.

You can use mediainfo view=>text to see the metadata and encoding settings in the file, including the binary version
https://www.videohelp.com/software/MediaInfo

here is an excerpt

Writing library                          : x265 1.9:[Windows][GCC 4.9.0][64 bit] 8bit
Encoding settings                        : wpp / ctu=64 / min-cu-size=8 / max-tu-size=32 / tu-intra-depth=1 / tu-inter-depth=1 / me=1 / subme=2 / merange=57 / no-rect / no-amp / max-merge=2 / temporal-mvp / no-early-skip / rdpenalty=0 / no-tskip / no-tskip-fast / strong-intra-smoothing / no-lossless / no-cu-lossless / no-constrained-intra / no-fast-intra / open-gop / no-temporal-layers / interlace=0 / keyint=240 / min-keyint=24 / scenecut=40 / rc-lookahead=20 / lookahead-slices=6 / bframes=4 / bframe-bias=0 / b-adapt=2 / ref=3 / limit-refs=3 / no-limit-modes / weightp / no-weightb / aq-mode=1 / qg-size=32 / aq-strength=1.00 / cbqpoffs=0 / crqpoffs=0 / rd=3 / psy-rd=2.00 / rdoq-level=0 / psy-rdoq=0.00 / signhide / deblock / sao / no-sao-non-deblock / b-pyramid / cutree / no-intra-refresh / rc=crf / crf=17.0 / qcomp=0.60 / qpmin=0 / qpmax=51 / qpstep=4 / ipratio=1.40 / pbratio=1.30

Handbrake nightly builds might include a more recent library, but you might as well use one of the updated daily x265 builds from one of the buildbots
eg.
https://builds.x265.eu/

You might be able to drop and replace the .exe if you're using a GUI like staxrip or megui. But whenever a big API change occurs, the switches change and you can usually no longer just drop in a new replacement . Not sure about staxrip, but I know megui has an update feature, and it used to be pretty up to date if you used the development server

The switches are listed in the x265 documentation. Like x264, there are presets and tunings for the main types of encoding scenarios
http://x265.readthedocs.io/en/latest/

But you have to decide what strategy you want first; if it's smaller filesizes, you probably don't want use grain preserving settings. You probably want to prefilter first

[ziggy1971]

I was using an older version of MediaInfo that didn't show that info.

Correct me if I'm wrong, but I don't see any of those settings in Handbrake. Another reason why I don't like it. The same for x264 in Handbrake, just basic settings.

This clip has the following settings:

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
      _________ __                __________.__        
     /   _____//  |______  ___  __\______   \__|_____  
     \_____  \\   __\__  \ \  \/  /|       _/  \____ \ 
     /        \|  |  / __ \_>    < |    |   \  |  |_> >
    /_______  /|__| (____  /__/\_ \|____|_  /__|   __/ 
            \/           \/      \/       \/   |__|   

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
                        Environment
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

StaxRip x64 : 1.3.7.0
OS          : Windows 7 Ultimate
Language    : English (United States)
CPU         : Intel(R) Core(TM) i3-6300 CPU @ 3.80GHz
GPU         : Intel(R) HD Graphics 530

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
                   Source file MediaInfo
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

G:\My Videos - Working On\GOT\AVS\S05-E06 - Unbowed, Unbent, Unbroken (Source).avs

General
Complete name : G:\My Videos - Working On\GOT\AVS\S05-E06 - Unbowed, Unbent, Unbroken (Source).avs
File size     : 272 Bytes

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
                           Script
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

LoadPlugin("D:\Applications (Exempt Sync)\$_64-bit\$_SystemBackup_2\StaxRip 1.3.7.0\Apps\Plugins\both\ffms2\ffms2.dll")
FFVideoSource("G:\My Videos - Working On\GOT\S05-E06 - Unbowed, Unbent, Unbroken (Source).mkv")

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
                     Script Properties
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

source frame count : 5749
source frame rate  : 23.976024
source duration    : 00:03:59.7810000
target frame count : 5749
target frame rate  : 23.976024
target duration    : 00:03:59.7810000

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
              Encoding using QSVEncC 2.51 x64
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

@echo off
"D:\Applications (Exempt Sync)\$_64-bit\$_SystemBackup_2\StaxRip 1.3.7.0\Apps\QSVEncC\QSVEncC64.exe" --quality best --la-quality slow --la-depth 100 --bframes 2 --ref 3 --b-pyramid --qp-max 20 --qp-min 19 --profile High --level 4 --videoformat ntsc --colormatrix bt709 --colorprim bt709 --transfer bt709 --la-icq 19 -i "G:\My Videos - Working On\GOT\AVS\S05-E06 - Unbowed, Unbent, Unbroken icq-19a.avs" -o "E:\My Videos - Rendered\S05-E06 - Unbowed, Unbent, Unbroken icq-19a.h264"

cmd.exe /C call "G:\My Videos - Working On\GOT\AVS\S05-E06 - Unbowed, Unbent, Unbroken icq-19a_QSVEncC.bat"

QSVEncC (x64) 2.58 (r1178) by rigaya, Nov  6 2016 21:01:07 (VC 1900/Win/avx2)
OS             Windows 7 (x64)
CPU Info       Intel Core i3-6300 @ 3.80GHz (2C/4T) <Skylake>
GPU Info       Intel HD Graphics 530 (23EU) 350-1150MHz [51W] (20.19.15.4416)
Media SDK      QuickSyncVideo (hardware encoder) PG, 1st GPU, API v1.17
Async Depth    4 frames
Buffer Memory  d3d9, 3 input buffer, 111 work buffer
Input Info     Avisynth 2.60 (yv12)->nv12[AVX2], 1920x1080, 24000/1001 fps
Output         H.264/AVC  High @ Level 4
1920x1080p 1:1 23.976fps (24000/1001fps)
Target usage   1 - best
Encode Mode    LA-ICQ (Intelligent Const. Quality with Lookahead)
Lookahead      depth 100 frames, quality slow
Windowed RC    off
ICQ Quality    19
QP Limit       min: 19, max: 20
Trellis        Auto
Ref frames     3 frames
Bframes        2 frames, B-pyramid: on
Max GOP Length 240 frames
Scene Change   off
encoded 5749 frames, 34.17 fps, 6815.59 kbps, 194.82 MB
encode time 0:02:48, CPU: 66.62, EU: 42.99, GPUClockAvg: 691MHz
frame type IDR   24
frame type I     24,  total size    3.06 MB
frame type P   1916,  total size  117.82 MB
frame type B   3809,  total size   73.94 MB

Start:    5:22:32 PM
End:      5:25:30 PM
Duration: 00:02:58

General
Complete name             : E:\My Videos - Rendered\S05-E06 - Unbowed, Unbent, Unbroken icq-19a.h264
Format                    : AVC
Format/Info               : Advanced Video Codec
File size                 : 195 MiB

Video
Format                    : AVC
Format/Info               : Advanced Video Codec
Format profile            : High@L4
Format settings, CABAC    : Yes
Format settings, ReFrames : 3 frames
Width                     : 1 920 pixels
Height                    : 1 080 pixels
Display aspect ratio      : 16:9
Frame rate                : 23.976 (24000/1001) fps
Color space               : YUV
Chroma subsampling        : 4:2:0
Bit depth                 : 8 bits
Scan type                 : Progressive
Color range               : Limited
Color primaries           : BT.709
Transfer characteristics  : BT.709
Matrix coefficients       : BT.709

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
                        Job Complete
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Start:    5:22:32 PM
End:      5:25:30 PM
Duration: 00:02:58

[ziggy1971]

But you have to decide what strategy you want first; if it's smaller filesizes, you probably don't want use grain preserving settings. You probably want to prefilter first

Since I want smaller file sizes with higher quality, it seems it would make sense to reduce the resolution to 1280x720 with a higher bitrate (3-6 mbps). I'm not likely to be getting a large TV screen in the near future so 1080p for a 40" screen isn't really necessary IMHO.

I know that reducing resolution already reduces quality.

Ideally, I'd want really good settings where the only variable would be the constant quality factor, allowing bitrate to adjust to a target quality.

Having an ideal number of reference frames, B frames, and other settings.
I don't know enough about them to know how to determine optimal results. Yes, simply changing values and running tests is time consuming.

[poisondeathray]

Correct me if I'm wrong, but I don't see any of those settings in Handbrake. Another reason why I don't like it. The same for x264 in Handbrake, just basic settings.

In handbrake, you can access other options, with the command line box

It's not for everyone (I don't like it either) , but consider it from the point of view that it's easy to use. But it's definitely one of the more popular GUI's, especially with Mac users

Megui has a bunch of pages , checkboxes, and to some people - it's too cluttered and complicated when you have it set on "advanced settings" mode, most of the options have checkbox or something in the GUI to access it and it's like reading a phone book to some people. And it also has an extra commandline box for parameters that aren't in the GUI. But IMO, it's a good way to learn about the settings, and doing tests because most of them are laid out . That's how I started with x264 a long time ago

Since I want smaller file sizes with higher quality, it seems it would make sense to reduce the resolution to 1280x720 with a higher bitrate (3-6 mbps). I'm not likely to be getting a large TV screen in the near future so 1080p for a 40" screen isn't really necessary IMHO.

I know that reducing resolution already reduces quality.

Ideally, I'd want really good settings where the only variable would be the constant quality factor, allowing bitrate to adjust to a target quality.

Having an ideal number of reference frames, B frames, and other settings.
I don't know enough about them to know how to determine optimal results. Yes, simply changing values and running tests is time consuming.

Yes, and there are time tradeoffs with setting higher , more computationally intensive settings . IMO, there are steep diminishing returns . If you add in filtering it can be slow

GPU encoding is attractive because it's so fast (especially with NVEnc), it's just a shame that the quality isn't quite there yet, at least not with consumer options (The $5K Intel MSS Encoder scored higher than x265 in SSIM tests, but those types of tests don't necessarily correlate all that well with human perception)


Many BD's actually don't have that high frequency details, or full 1080 lines of vertical resolution (or if not 16:9, not 800 lines or something for letterboxed titles) . A rough test you can do is a downscale,upscale test. You resize to 720p and back to 1080p to simulate what you would see (not encoding , just previewing, for example in avisynth or megui or something) . A lot of the time you might only notice some minor softening - so for those downscaling has almost no negative effects. But some titles do have lots of detail and real resolution, so beware it varies

It really boils down to what you want in terms of quality (and compression) vs speed tradeoff . Some people don't mind spending 10x as long for 1% better compression using "placebo" settings. For me, that's a %^$%D waste of time, but the choice is up to the user of course.

Having more b-frames aid in compression , especially in the lower bitrate ranges, especially for x264 and x265. Their cost is very low and they are fantastic in quality compared to other encoders. But you don't want to dial in the max 16 everytime because not all sources can use them, it's content dependent, and the penalty is encoding time, especially if you are using --b-adapt 2, which is poorly multithreaded (slower presets use it, medium preset still uses --b-adapt 1) . If you look at an earlier post, I posted an excerpt from an x264 log file. It showed consecutive b-frames in percentages. Those % represent strings of is zero, one, two, three, etc...consecutive b-frames. If you have fast moving action scenes, there will be almost no b-frames (x264 and x265 have very good frametype decisions). Because this example was mostly slow moving (head shots, faces talking etc...) , it was able to use many b-frames. That last 56% means 56% of the b-frames were contained in strings of 8 . You could have set 9 or 10 and still used a signficant amount. It's unusual. Most "movies" from hollywood might only be able to use runs of 3-4.

x264 [info]: consecutive B-frames: 19.6%  1.1% 12.3%  0.3%  1.2%  0.9%  5.6%  2.8% 56.0%

But even optimizing b-frames , reference frames etc... might only get a few % compression here and there. Sure it adds up when you combine everything, but IMO for general use, I typically default settings with tunings (e.g. if it's animation use --tune animation), at least as a starting point. I almost always use 4 reference frames (it's compatible with L4.1 High, which almost every device in the world supports now, like phones, tablets etc...) . choosing b-frames vary, because it's very content dependent . A slideshow or lecture could very well use the max 16 for example. So you should select appropriately. Start looking at the log files and understanding what the stats mean. There is a guide posted somewhere by dark shikari many years ago explaining what everything meant , but I don't have the link handy. It should be archived in the wayback machine somewhere

[ziggy1971]

Been looking at the specs of Kaby Lake. Maybe I'll wait to see what that has to offer for h265

[ziggy1971]

Either I'm looking in the wrong places or I'm simply in the minority when it comes to using Quick Sync.

I'm having trouble finding info on the parameters and which ones are available for certain modes.

Frustrating....

[vhelp]

agreed, very frustrating indeed. quicksync is Intel's mystery whore. And those who write the front-end (cli) apps don't know either. they are just repeating what is already said as found in the sdk arena. it is up to the end-user to figure them out what each param/function/feature can do, and hopefully build a document eventually. in addition to the standard qvsencc {-help} there is also the slightly more help info at this site (link below), (if you are in chrome, select that funny looking translate icon on the url bar at the far right). it kind of gives you a little bit more info, i think. also, in my opinion, a testing source should include:

A) clean source, free of compression artifacts (that was not prevously encoded to another format)
B) a source that contains a good amount of grain, preferreably with minimal compression artifacts (like the one you posted in this discussion)

each offer some advantage and unique outcome. testing on one type will only cause confusion.

http://rigaya34589.blog135.fc2.com/blog-entry-337.html

[stonesfan129]

It's always a tradeoff. Speed, quality, file size. Pick two. What will you be watching them on? I've found that if I'm just watching on a laptop, tablet or my phone; x264 Very Fast is fine. Yes the files are big. External HDDs are cheap. Encoding speed is fast and it puts less strain on my computer. At home on my big display where picture and audio quality count, I have the Blu-ray disc.