x264 banding/posterizing (Quick Sync also)

[vhelp]

Hi, can you post the skylake quicksync specs for your 6300 cpu ? I finally received my new mini pc (i7-6600U) but have no monitor to connect and test. (I had one laying around but lost it and working on getting another one, hopefully soon. I wish I could just use my laptop's screen and connect the two that way. I guess that's beyond the scope of things.) Anyway.

The report will show the capabilities of the H264 and H265 features of your 6300 and what it can utilize for the video encoding. The more "X" 's the higher the quality video your 6300 will provide. If you see no "O" 's, the better. "O" means the feature is not available in that SDK version, hence a lower quality video. Also, it will show your current Media SDK API version. The current sdk version is v1.19, I believe. Please use the {code} {/code} tags so the output is flushed and readable. (see example here) I and others will appreciate it, thanks.

QSVEncC.exe --check-features

[ziggy1971]

Thanx for the link to the HD 4600 features.

From the "S05-E06 - Unbowed, Unbent, Unbroken1_QSVEncC.bat" file:

"D:\StaxRip 1.3.7.0\Apps\QSVEncC\QSVEncC64.exe" --quality best --la-quality slow --slices 4 --la-depth 40 --la-window-size 20 --bframes 4 --ref 3 --gop-len 48 --b-pyramid --profile High --level 4 --vpp-detail-enhance 60 --la 14995 -i "F:\My Videos - Working On\S05-E06 - Unbowed, Unbent, Unbroken.avs" -o "E:\My Videos - Rendered\S05-E06 - Unbowed, Unbent, Unbroken.h264"

I have no idea whether the following has any affect in this mode:
--la-window-size 20

I'm assuming that the following are slowing the encode (not that I'm complaining). If it gets better quality, I'll accept the slow down:
--quality best
--la-quality slow
--la-depth 40
--vpp-detail-enhance 60

If you or anyone can help to get better settings, by all means, I'm open to suggestion.

[ziggy1971]

I posted a link for the Quick Sync features zip earlier, but I'll try to post here:

QSVEncC (x64) 2.57 (r1177) by rigaya, Sep 29 2016 23:15:54 (VC 1900/Win/avx2)
 reader: raw, avi, avs, vpy, avqsv [H.264/AVC, HEVC, MPEG2, VC-1, VP8, VP9]
Environment Info
OS : Windows 7 (x64)
CPU: Intel Core i3-6300 @ 3.80GHz (2C/4T) 
RAM: Used 1667 MB, Total 8091 MB
GPU: Intel HD Graphics 530 (23EU) 350-1150MHz [51W] (20.19.15.4416)

Media SDK Version: Hardware API v1.17

Supported Enc features:
Codec: H.264/AVC
             CBR   VBR   AVBR  QVBR  CQP   VQP   LA    LAHRD ICQ   LAICQ VCM  
RC mode       o     o     o     o     o     o     o     o     o     o     o    
Fixed Func    o     o     o     o     o     o     x     x     x     x     o    
Interlace     o     o     o     o     o     o     o     o     o     o     o    
SceneChange   o     o     o     o     o     o     x     x     o     x     o    
VUI info      o     o     o     o     o     o     o     o     o     o     o    
Trellis       o     o     o     o     o     o     o     o     o     o     o    
Adaptive_I    x     x     x     x     x     x     x     x     x     x     x    
Adaptive_B    x     x     x     x     x     x     x     x     x     x     x    
WeightP       x     x     x     x     x     x     x     x     x     x     x    
WeightB       x     x     x     x     x     x     x     x     x     x     x    
FadeDetect    x     x     x     x     x     x     x     x     x     x     x    
B_Pyramid     o     o     o     o     o     x     o     x     o     o     o    
 +Scenechange x     x     x     x     x     x     x     x     x     x     x    
 +ManyBframes o     o     o     o     o     x     x     x     o     x     o    
PyramQPOffset x     x     x     x     x     x     x     x     x     x     x    
Ext_BRC       o     o     o     o     x     x     x     x     o     x     o    
MBBRC         o     o     o     o     x     x     x     x     o     x     o    
LA Quality    x     x     x     x     x     x     o     o     x     o     x    
QP Min/Max    o     o     o     o     o     o     o     o     o     o     o    
IntraRefresh  x     x     x     x     x     x     x     x     x     x     x    
No Debloc     x     x     x     x     x     x     x     x     x     x     x    
No GPB        x     x     x     x     x     x     x     x     x     x     x    
Windowed BRC  x     x     x     x     x     x     o     o     x     x     x    
PerMBQP(CQP)  x     x     x     x     o     o     x     x     x     x     x    
DirectBiasAdj x     x     x     x     x     x     x     x     x     x     x    
MVCostScaling x     x     x     x     x     x     x     x     x     x     x    



Codec: HEVC
             CBR   VBR   AVBR  QVBR  CQP   VQP   LA    LAHRD ICQ   LAICQ VCM  
RC mode       o     o     x     x     o     o     x     x     o     x     o    
Fixed Func    x     x     x     x     x     x     x     x     x     x     x    
Interlace     x     x     x     x     x     x     x     x     x     x     x    
SceneChange   o     o     x     x     o     o     x     x     o     x     o    
VUI info      o     o     x     x     o     o     x     x     o     x     o    
Trellis       x     x     x     x     x     x     x     x     x     x     x    
Adaptive_I    x     x     x     x     x     x     x     x     x     x     x    
Adaptive_B    x     x     x     x     x     x     x     x     x     x     x    
WeightP       x     x     x     x     x     x     x     x     x     x     x    
WeightB       x     x     x     x     x     x     x     x     x     x     x    
FadeDetect    x     x     x     x     x     x     x     x     x     x     x    
B_Pyramid     x     x     x     x     x     x     x     x     x     x     x    
 +Scenechange x     x     x     x     x     x     x     x     x     x     x    
 +ManyBframes x     x     x     x     x     x     x     x     x     x     x    
PyramQPOffset x     x     x     x     x     x     x     x     x     x     x    
Ext_BRC       x     x     x     x     x     x     x     x     x     x     x    
MBBRC         o     o     x     x     x     x     x     x     o     x     o    
LA Quality    x     x     x     x     x     x     x     x     x     x     x    
QP Min/Max    x     x     x     x     x     x     x     x     x     x     x    
IntraRefresh  x     x     x     x     x     x     x     x     x     x     x    
No Debloc     o     o     x     x     o     o     x     x     o     x     o    
No GPB        x     x     x     x     x     x     x     x     x     x     x    
Windowed BRC  x     x     x     x     x     x     x     x     x     x     x    
PerMBQP(CQP)  x     x     x     x     x     x     x     x     x     x     x    
DirectBiasAdj x     x     x     x     x     x     x     x     x     x     x    
MVCostScaling x     x     x     x     x     x     x     x     x     x     x    



Codec: MPEG2
             CBR   VBR   AVBR  QVBR  CQP   VQP   LA    LAHRD ICQ   LAICQ VCM  
RC mode       o     o     o     x     o     o     x     x     x     x     x    
Fixed Func    o     o     o     x     o     o     x     x     x     x     x    
Interlace     o     o     o     x     o     o     x     x     x     x     x    
SceneChange   o     o     o     x     o     o     x     x     x     x     x    
VUI info      o     o     o     x     o     o     x     x     x     x     x    
Trellis       o     o     o     x     o     o     x     x     x     x     x    
Adaptive_I    o     o     o     x     o     o     x     x     x     x     x    
Adaptive_B    o     o     o     x     o     o     x     x     x     x     x    
WeightP       o     o     o     x     o     o     x     x     x     x     x    
WeightB       o     o     o     x     o     o     x     x     x     x     x    
FadeDetect    x     x     x     x     x     x     x     x     x     x     x    
B_Pyramid     o     o     o     x     o     x     x     x     x     x     x    
 +Scenechange x     x     x     x     x     x     x     x     x     x     x    
 +ManyBframes o     o     o     x     o     x     x     x     x     x     x    
PyramQPOffset x     x     x     x     x     x     x     x     x     x     x    
Ext_BRC       o     o     o     x     x     x     x     x     x     x     x    
MBBRC         o     o     o     x     x     x     x     x     x     x     x    
LA Quality    x     x     x     x     x     x     x     x     x     x     x    
QP Min/Max    o     o     o     x     o     o     x     x     x     x     x    
IntraRefresh  o     o     o     x     o     o     x     x     x     x     x    
No Debloc     o     o     o     x     o     o     x     x     x     x     x    
No GPB        x     x     x     x     x     x     x     x     x     x     x    
Windowed BRC  o     o     o     x     o     o     x     x     x     x     x    
PerMBQP(CQP)  x     x     x     x     x     x     x     x     x     x     x    
DirectBiasAdj o     o     o     x     o     o     x     x     x     x     x    
MVCostScaling o     o     o     x     o     o     x     x     x     x     x    



Supported Vpp features:

Resize                o
Deinterlace           o
Scaling Quality       x
Denoise               o
Rotate                o
Mirror                x
Detail Enhancement    o
Proc Amp.             o
Image Stabilization   o
Video Signal Info     o
FPS Conversion        o
FPS Conversion (Adv.) o

Correct me if I'm wrong, but I think you have it backwards.
O = supported
X = Not supported

When I enable the WeightB and WeightP check boxes in StaxRip, the following is displayed before encoding:

WeightP is not supported on current platform, disabled.
WeightB is not supported on current platform, disabled.

[ziggy1971]

One thing I don't get, perhaps an error, is that the features show 23EU instead of 24EU as advertised and shown in GPU-Z.
Is that missing EU now being used for the Fixed Function? I don't know.

[poisondeathray]

One thing I don't get, perhaps an error, is that the features show 23EU instead of 24EU as advertised and shown in GPU-Z.
Is that missing EU now being used for the Fixed Function? I don't know.

Not sure but a quick google translate search shows some obscure Russian site

Intel HD Graphics 530 is composed of one piece with the 24 EU (in the budget processors 23EU).

http://efxi.ru/news/news_3321.html

From the "S05-E06 - Unbowed, Unbent, Unbroken1_QSVEncC.bat" file:

"D:\StaxRip 1.3.7.0\Apps\QSVEncC\QSVEncC64.exe" --quality best --la-quality slow --slices 4 --la-depth 40 --la-window-size 20 --bframes 4 --ref 3 --gop-len 48 --b-pyramid --profile High --level 4 --vpp-detail-enhance 60 --la 14995 -i "F:\My Videos - Working On\S05-E06 - Unbowed, Unbent, Unbroken.avs" -o "E:\My Videos - Rendered\S05-E06 - Unbowed, Unbent, Unbroken.h264"

I have no idea whether the following has any affect in this mode:
--la-window-size 20

I'm assuming that the following are slowing the encode (not that I'm complaining). If it gets better quality, I'll accept the slow down:
--quality best
--la-quality slow
--la-depth 40
--vpp-detail-enhance 60

If you or anyone can help to get better settings, by all means, I'm open to suggestion.

Mystery solved - those settings explain the slowdown.

You have to do some tests to see if it's "better" or not, or changing some other settings, or even worth it at all for your goals . Do some tests on speed vs quality. Higher bitrate fixes everything. And if you didn't care about storage space, just use the originals (or copies of the originals) . I can suggest settings that work for x264, but not necessarily for skylake QS. In theory, at lower bitrate ranges having more reference frames, more b-frames should help with compression efficiency . It certainly does with x264. (And there are tunings and other custom settings you can use.) However, other AVC encoders tend to have "poor" b-frames compared to x264, you may even make things worse.

It's important to include end to end details on the test setup, such as intermediates, encoder settings used, etc.. because that impacts whether or not someone can replicate your tests. Certainly cineform at filmscan2 will probably be close enough to "lossless", but not at the lower quality levels. Also the filesize will be several times larger than the original at the higher quality cineform settings. Also, the typical cineform will be 10bit 4:2:2, so it's going to be slower and there will be quality differences because you have to downsample the bit depth and the chroma back to 8bit 4:2:0 like the original . There are dozens of different algorithms and methods of doing that when someone is trying to repeat the tests with same or different encoders - and it can impact the results , both in terms of speed and quality. Too many variables. Better to avoid it completely when doing these types of tests for public consumption. I would have rather you used the original, so we could have compared , say Haswell using same settings to see if there was a quality difference in generations and by how much, or NVenc , or encoder XYZ, etc... also not everyone has, or wants to install cineform. But pretty much everyone can decode the source AVC. Details are important because CPU decoding might take away CPU cycles from primarily CPU encoders (It makes a huge difference at UHD resolutions for example). Likewise, GPU decoding might steal cycles from primarily GPU encoders (actually it doesn't, or it's negligible <0.5% for both Nvidia decoding with NVEnc encoding and QS decoding/encoding at 1080p in my tests)

Different display setups are calibrated differently, etc.. So what you are "seeing" might look different on your computer than your HTPC, or someone else's setup....etc... Some setups are high contrast , so the shadow areas are compressed and obscure many of the problem areas. I'm sure you get the gist what I'm trying to say .

If you want to see how it's really doing in shadow / dark areas, or how much texture detail is lost - when examining it, boost the shadows. This will show the problem areas on a sequence like this much more clearly. Some people don't care, or don't know what to look for , or can't see the difference in motion. "Can't see it on their particular display, so it's not a problem." Others want to know every little detail. But I agree 100% with jagabo - Skylake QSV using your settings tends to smooth away details compared to x264 using the default settings . It's just an observation, I'm not trying to criticize you or anything like that. For me this is a pure exercise in learning and fact finding. I had a little presentation with screenshots prepared earlier (earlier your x264 encode was too large to match bitrates with the first 5Mb/s QS encode) , but now you mentioned cineform, so it sort of invalidates what I prepared. But you can still see the difference in your encodes. It's those fine details like noise and grain that prevent "banding and posterization" that you need to preserve and QSV doesn't do as good of a job of retaining it, but it is faster for sure (and I'm sure much faster on "balanced" but you didn't provide the numbers)

[vhelp]

zippy, thanks for posting the 6300 specs. I was able to figure out a way to view my i7-6600U mini pc using an hdmi-to-svideo-to-ati-600-to-dell laptop. Well, its do'able, for now.

As PDA said, the above is true. But we can compare the two pc's and results and i'm sure others will join in later, as others purchase upgrades between now and the holidays. I also have another laptop on the way, using Kaby Lake, so I will be adding that to the test of things. And last, I am also waiting on the parts for an i7-6700 from the other thread I started with. Anyway. I'm sure we'll all get to the bottom on this x264/quicksync/x265 final outcome. Until then, keep plugin away.

[ziggy1971]

Direct from source

FFVideoSource("path to file\S05-E06 - Unbowed, Unbent, Unbroken (Source).mkv")

Different settings...

I'm currently encoding the entire episode to see overall gains/losses.

[poisondeathray]

Still pretty bad on this test. I'm guessing this last didn't use --vpp-detail-enhance, which really oversharpens and creates splotchy artifacts (such as on the last 9Mb/s QS test) unless you use enough bitrate . Those filtering options are probably going to be counterproductive for you (in general , sharpening requires even more bitrate to achieve a certain level of quality). Looks like QS AVC needs more bitrate, at least with those settings. You're not going to be "saving" much bitrate with QS if your goal was to keep be similar to the original , preserving the grain and fine details. It would be better to just play the originals in that case. Maybe if you have time try QS HEVC instead. x265 or x264 with the proper settings do a better job at much lower bitrate. x265 has really improved recently with the proper settings, it used to drop detail and blur everything too much, similar to QS or x264 in early development .

[ziggy1971]

I don't know how you do the comparison between videos, frame-by-frame, some software testing, actually watching the video in real-time, etc.

Initially, when you asked for the settings I used, I thought you were genuinely interested in whether Quick Sync could be a viable alternative.
Your comments, however, simply say how horrible Quick Sync is and that better can be achieved using x264/x265, yet, you provide no evidence.

If x264 can achieve better results with lower bitrates and within a reasonable amount of encoding time, provide the results or at least provide the settings and workflow used to achieve those results.

Not providing any actual results is simply acting like an elementary school bully.

[poisondeathray]

I don't know how you do the comparison between videos, frame-by-frame, some software testing, actually watching the video in real-time, etc.

Initially, when you asked for the settings I used, I thought you were genuinely interested in whether Quick Sync could be a viable alternative.
Your comments, however, simply say how horrible Quick Sync is and that better can be achieved using x264/x265, yet, you provide no evidence.

If x264 can achieve better results with lower bitrates and within a reasonable amount of encoding time, provide the results or at least provide the settings and workflow used to achieve those results.

Not providing any actual results is simply acting like an elementary school bully.

I am genuinely interested. You don't need super duper slow settings for x264, x265. But "Reasonable" encoding time is very subjective - x264 or x265 will NEVER be as fast as QS. And QS will be much slower than NVEnc. But there are tradeoffs, quality and compression ratio is one of them .

I look at everything, in motion, frame by frame. B to B and P to P comparisons, GOP analysis. Sure, I'll post some results later today, but it's pretty clear from the samples you posted already . It's pretty clear evidence. Have a look at my previous posts, I'm pretty thorough and there is no ulterior motive here. If something sucks, I'll say it sucks (x264 sucks at fades for example ,even with the fade compensate patch). I'm not trying to be a "bully" whatever that means . I just want the truth. So far, it looks like QS AVC is not a viable alternative, if you wanted high quality similar to the original at reasonable bitrates. It drops too much detail, similar to Haswell AVC QS.

There is significant texture and detail loss with QS , even compared with x264 "defaults" that you posted. Some people might not be able to "see" it, especially in motion. But pay attention to details like fur, walls, hair, stubble. If you can't "see" it - just boost the shadows a bit as I mentioned earlier. I'll post some screenshots later. It might be your setup isn't calibrated, or your HTPC is crushing shadows. For some people, youtube is "great quality" . That's "good enough" for them. Nothing wrong with that. I'm not making judgements on what is suitable for their purposes or goals. But the facts are significant QS texture loss (at least with the samples you provided) and it isn't sufficient even at 9Mb/s. The facts are QS is much faster, and NVEnc is even faster.

Those fine grain and noise details are what prevents "posterization and banding". This is what prompted you to make this thread in the first place. An encoder needs to retain it to prevent the "banding" . In fact, the original acquisition footage from the Alexa (pre blu-ray) doesn't have it to that extent, they actually add grain in post for blu-ray .

[ziggy1971]

I'm more of an "average" user, not a video professional by any means. In all likelihood my PC setup is far from professional quality also. My A/V equipment isn't top of the line either (my TV is a Samsung 40", about 12 years old now. Works flawlessly, so no need to junk it just yet.) Even when I use my HTPC, I'm sure the settings aren't optimal, but they are "good enough" for me when I want to relax and enjoy.

Yes, there are some YouTube videos with really good quality, IMHO

Probably, because of my lack of experience in video, I don't "see" the details your talking about. When you say "just boost the shadows a bit", I have no idea how to do that. Don't even get me started colors, luma, chroma, etc. If the color in the original is green, I want to see green in my encodings, it's that simple.

If I were a professional and/or had intentions of distributing the material, my standards would clearly be much higher and I would seek proper education.

I read through this a few years ago, so that's about all the training I have:
http://www.animemusicvideos.org/guides/avtech/index.html

Thus far, the most frustrating part of QS has been the lack of documentation.
Everything I've done is trial & Error. (Apparently more on the ERROR side)

For instance:
When using the LA-VBR setting, what other parameters are available for it to use? Max bitrate, LA window size,, b-pyramid, direct bias adjust, scenechange, and the list goes on. Not to mention that I don't know what most of those things mean.

I've searched for information on what parameters are relevant to which settings. StaxRip shows all features are available no matter what preset you choose, so that doesn't help anything.

Basically, it boils down to choosing options, run a test and hope for the best.

[jagabo]

Your comments, however, simply say how horrible Quick Sync is and that better can be achieved using x264/x265, yet, you provide no evidence.

You've already provided the evidence. In every one of your uploads x264 has kept more low contrast detail and grain than QS. Here's example using your source in post #14, your QS encoding in post #16, and x264 encoding in post #16, with a 3x gain so all the dakr grain is much more visible (obviously, the brights are blown out).

source:

[Attachment 39420 - Click to enlarge]

qs:

[Attachment 39421 - Click to enlarge]

x264:

[Attachment 39422 - Click to enlarge]

You may find x264's clumpier grain more distracting but it's closer to the source than the overly smoothed image produced by QS.

[ziggy1971]

I'll accept defeat as I have no desire to fight a battle where I'm ill advised and equiped.

Yes, you provided screenshots, yay. But which videos did you choose to exploit? For all I know, you chose the best x264 and the worst Quick Sync.

Both codecs and workflows will result in LOSSES since they are lossy codecs. What's an acceptable level of loss is person/target dependent.

One image from one video based on one set of presets and bitrate and declare one the victor over the other???

Perhaps the 2 different codecs implement algorithms differently and deem different aspects of the video more important than the other.
Perhaps one image happens to be an I frame while the other a B frame?

How much of what is over-exaggerated in these photos actually make a difference while watching the video in the "normal" fashion?
I can't imagine anyone blowing out the colors like that to watch their movie, but hey, to each their own.

All that's shown here is a difference between 3 photos of 3 videos, nothing else is known.
Looking at a single image among many thousands does not declare one a winner and the other a loser.

Declaring a winner:
- one encodes much faster than the other
- one requires more bitrate than the other for quality
- more questions
- etc.



I've seen how some people make their comparisons:
https://forum.videohelp.com/threads/368914-24-fps-and-very-fast-STELLAR-DVD-rips-in-Han...=1#post2363323

veryfast.mkv

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

slow.mkv

cabac=1 / ref=5 / deblock=1:0:0 / analyse=0x3:0x113 / me=umh / subme=8 / psy=1 / fade_compensate=0.00 / 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 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=50 / rc=crf / mbtree=1 / crf=18.0000 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00

Really, if you're going to compare a "slow" preset to a "veryfast" preset, shouldn't all other factors be equal? Begs credibility?

[poisondeathray]

Are you sure you want to go down this path ... If it's "good enough" for you now, and you are content - then maybe you shouldn't open this can of worms. I find myself analyzing TV shows/ movies even commercials for camera angles , production values, set design, compression issues , etc... and not "enjoying" the content as much . An analogy is if I'm content with my Honda Civic in my happy little world, then one day test drive a Porsche 911 Turbo, suddenly my Civic doesn't fare so well.

I'll post some screenshots and the settings used, it's up to you if you want to take a look. What I'm saying is when you examine it critically and objectively, you're going to be dissatisifed with QS. It's not "close to the original source", even at bitrates 1.3-1.5x that of what x264 requires, or 2-2.5x what x265 requires. Just because you can't see it on your display setup doesn't mean the problems aren't there. You can "stick your head in the sand" but the problem is still there. The main problem in this set for QS is lack of grain retention, detail and texture loss. (It has other problems on other sources, but no encoder is perfect. But it can be good on some sources too... it's not all bad). Maybe QS HEVC might fare better, if you have time later maybe post some of those that would be great. Intel has pretty much said as much that it can't compete with x264 AVC. However, it's MSS HEVC encoder (which is hardware/software based) supposedly beats x265 in the MSU comparisons, at least according to SSIM (which means nothing essentially)

There are many ways to look frame by frame, or to boost shadows. If you don't know how to on your player / HTPC setup, you can setup postprocessing such as with ffdshow, or some software players have options. Or you can use a NLE with curves to boost the shadows for example, and toggle the visibiltiy on tracks back and forth. This way it's easy to see how much detail is being lost. Another way is avisynth. You can use avspmod and flip between encodes with the number keys. Or another way is interleave(a,b) and it swaps between encodes as you step. Keep in mind, just because you can't see the problems on your particular display, doesn't mean other people with calibrated displays cannot.

No, you don't boost it to watch, but since your setup/eyes weren't sensitive enough to pick the problems up, this is method you can use to visualize the problem. If you "see" the problem better, then that gives you a chance to do something about it. That problem is what prompted you to start this thread in the first place. Once you get those fine grain details retained, then it will look like the source without the banding issues .

I can tell you right now, tweaking a few QS settings might help a tiny bit, but not enough to put it over the top where it becomes good enough at a decent bitrate to be similar enough to the original (Or at least what I would call "similar to the original") . You're basically wasting your time. There isn't some magic bullet for QS AVC. I had hoped skylake QS AVC would be significantly better quality wise than Haswell QS AVC, but it doesn't look like it (or if it is, it's marginally better). If the original was ~16.3Mb/s , you probably going to need something close to that to retain the details and grain with QS AVC. Why even bother ? Just use the original . IMO it's not a viable alternative if you want something truly close to the original (at least on this source). And it's not something insignificant like a dot or a spec of grain being lost. Critical elements like facial details, wrinkles on skin, stubble, fur on a coat, textures on a wall - become blurred away.

These aren't "cherrypicked" examples, it's representative sample, every frame is noticably worse in QS, every frame has significant texture loss, and it just can't retain the grain even at 9Mb/s. The screenshots for QS were taken from your most recent one post#37 . I used hdragc(max_gain=2, coef_sat=0.8) to "boost" the shadows

The x264 encode in this example resulted in 6470kbps , the x265 resulted in 3503kbps. The settings are nothing special, nothing super slow relative to default, just the medium default setting with some b-frames, an added reference. Nothing like using --preset very slow or something like that . For x265, they are just modified grain retention settings. I didn't upload the encodes but you should be able to reproduce it easily. If you're having problems encoding I can upload them

x264 --crf 19 --ref 4 --tune film --bframes 8 -o output.ext input.ext

x265 --crf 18 --deblock -4:-4 --no-sao --psy-rd 4.0 --psy-rdoq 10.0 --bframes 6 --ipratio 1.2 --pbratio 1.1 -o output.ext input.ext

Actually, even at default settings at a given bitrate, it's not that much different. Those extra b-frames are actually used in this scenario (there are a lot of static sections with close ups of a face talking etc...) but it might only improve compressibility a few % in reality

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

Screenshot comments


333. This is a b-frame comparison
QS loss of grain pattern , some texture loss in the beard, hair, forehead. x264 is "noisy", but it retains a coarser grain pattern. x264 retains the finer pattern, but mild detail loss, but at 3.5Mb/s that is to be expected

1543. This is a b-frame comparison
Look at the QS texture loss everywhere. The fireplace, the wall textures, the "fur" pelt looks like a blob, dress shadows, QS has low quality b-frames, typical for most encoders. But if you elmininate b-frames for QS, the compression suffers. x264 retains most of the grain/noise, but it's a coarse retention. Again we see x265 with a grain finer pattern more similar to the original

2796. This is a P-frame comparison
x264 retains the grain pattern, but it's coarse, but still more similar in characteristics to the original. QS drops details in the dark hair, stubble, skin textures. x265 is missing some fine details, but the grain pattern is finer , more like the original. But keep in mind x265 was only 3.5Mb/s - not bad for that bitrate. QS probably still needs a lot more bitrate to be "close to the original" , and x264 and x265 need a bit more as well, albeit less. A year ago x265 would have had problems with this type of scene, but it's improved dramatically. It still has problems with some types of motion smearing, other scenarios, and still much slower than x264, but it's maturing very nicely. x264 took many years to mature as well.

[KarMa]

I've seen how some people make their comparisons:
https://forum.videohelp.com/threads/368914-24-fps-and-very-fast-STELLAR-DVD-rips-in-Han...=1#post2363323

veryfast.mkv

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

slow.mkv

cabac=1 / ref=5 / deblock=1:0:0 / analyse=0x3:0x113 / me=umh / subme=8 / psy=1 / fade_compensate=0.00 / 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 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=50 / rc=crf / mbtree=1 / crf=18.0000 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00

Really, if you're going to compare a "slow" preset to a "veryfast" preset, shouldn't all other factors be equal? Begs credibility?

He was showing the quality difference between very fast and slow, for a given CRF. Jagabo's point would still ring true if both had the same bitrate, via ABR or 2-Pass.

He even went out of his way a few posts down to add a veryfast video with the same bitrate as the slow. So he did in the end provide a more equal test.
https://forum.videohelp.com/threads/368914-24-fps-and-very-fast-STELLAR-DVD-rips-in-Han...=1#post2363344

[vhelp]

zippy, did you supply the original source that you are encoding from ? I didn't see it. Can you upload it here. Thanks.

EDIT: never mind. I found it. Its on page 1, post # 14.

[jagabo]

He was showing the quality difference between very fast and slow, for a given CRF.

Yes, that's what the original poster in that thread was discussing. I provided a sample where the difference between the two is obvious so he would have some idea what to look for.

[KarMa]

The weirdest thing about the provided QS encodings (I've only looked at the 5000kbps) is the sharpening. The x264 version doesn't seem to have gone through any sharpening, but the QS version has been blatantly sharpened throughout the entire video. Now if you want that, then that's a preference. But the purpose of the test is to retain as much of the source as possible.

Source vs CRF x264 (~5000kbps, Preset Medium)
http://www.screenshotcomparison.com/comparison/190421

Source vs QS 5000kbps
http://www.screenshotcomparison.com/comparison/190422

[poisondeathray]

The weirdest thing about the provided QS encodings (I've only looked at the 5000kbps) is the sharpening. The x264 version doesn't seem to have gone through any sharpening, but the QS version has been blatantly sharpened throughout the entire video. Now if you want that, then that's a preference. But the purpose of the test is to retain as much of the source as possible.

The other 5Mbps QS version in post 16 isn't sharpened. It looks like the ones in post 22 have vpp enhance enabled (I only downloaded the 9Mbps one ,but judging from your screenshot of the 5000kbps one, I'd assume the 6000kbps one is too) . The most recent 9Mbps in post 37 doesn't appear to be either (as mentioned in post 38)

To be fair, he's just playing with the settings, but as mentioned any sharpening is going to be detrimental, requiring even more bitrate. But it would have been nicer if he explicitly posted the settings used for each

[ziggy1971]

Sure, having Civic is nice till you drive Porsche 911 Turbo, however, that doesn't mean I'd BUY the Porsche 911 Turbo. The Civic provides me a means to get from point A to point B just the same as the Porsche 911 Turbo would. If, by chance, I had a Porsche 911 Turbo, I'd sell it and try to help others in need instead of parading my wealth and acting like an idiot trying to prove I'm better than everyone else. I have no need for approval nor do I need others to masquerade my accomplishments.

I, like you, have much experience in certain areas.

If it was complete lossless I was asking, I'd encode to a lossless format. Easy right?

Question was about banding/posterinzing.

I know now both codecs have the same issue to varying degrees, END OF STORY...

[poisondeathray]

Sure, having Civic is nice till you drive Porsche 911 Turbo, however, that doesn't mean I'd BUY the Porsche 911 Turbo. The Civic provides me a means to get from point A to point B just the same as the Porsche 911 Turbo would. If, by chance, I had a Porsche 911 Turbo, I'd sell it and try to help others in need instead of parading my wealth and acting like an idiot trying to prove I'm better than everyone else. I have no need for approval nor do I need others to masquerade my accomplishments.

I, like you, have much experience in certain areas. Just because I know the anatomy of the human being, doesn't mean I'm going around imagining the size of every guys penis, or the shape of each woman's breast.

The fact that 1 1/2 pounds of copper (among other slight changes) changes the metallurgy from a Ductile D-65 to a D-80, which is a harder type of cast iron. It really doesn't matter as it's not that type of detail I was asking.

If it was complete lossless I was asking, I'd encode to a lossless format. Easy right?



Question was about banding/posterinzing.

I know now both codecs have the same issue to varying degrees, END OF STORY...

Wow. Why so antagonistic and personal ? We're just discussing encoders and analyzing the results. I'm not saying anything personal about you . You're not the software or hardware encoder. Try to be a little objective, and analyze the results along with everyone else . My point with the analogy was that sometimes I wish I didn't learn about codecs, because I enjoy things less now. If you're happy with the way things are, just leave it be. If I offended you in some way, I apologize, it was not my intent

I wanted to see how skylake AVC performs. That is my personal interest. Is is any better than the previous generations? And by how much ? And it's not that good in this sample (That doesn't mean it's terrible on other sources, in fact it's quite good on some sources, or at least Haswell QS AVC is) .

Understand that this discussion IS all about banding/posterization . The analysis leads you to understand what is going on. ie. Why is QS prone to banding, or x264 to a lesser extent, but something like x265 looks fine at half or a third of the bitrate ? But you seem to want to ignore what is going on. If you can't see the difference in those screenshots I don't know what to say...

You're the one asking for help. Understand this : An encoder needs to keep fine details, grain to prevent banding. That is why "banding" occurs in the first place. There are 2 principle types of banding. One is from 8bit gradients , the other is from poor compression, high quantizers. You're seeing primarily the latter here. Grain and debanding dithering filters add noise and grain. You can think of it as "covering up" the defects. But that requires more bitrate to retain the dither. You're seeing the effect of high quantizers and macroblock edges that's what those blocky ugly artifacts in the shadows are there.

Yes, all lossy codecs will have those sorts of problems . The important question is at what bitrate range will the codec retain enough of the grain and details to prevent the posterization . In this sample, there is no question QS AVC performs the worst by far. It's just an observation on this 1 sample. It's not the end of the world. 1 sample doesn't mean it's terrible across the board. (Do you work for Intel or something ?) . x264 is bad at some things too. Same with x265. All codecs have problem areas or areas they could improve on

Historically, this is one of x264's weak areas that everyone complains about - the posterization and banding along dark areas. But if you compare it to other AVC encoders such as QS, NVEnc, Mainconcept, Ateme, etc... to put things into perspective, they are far worse

If you have time could post some QS HEVC encodes, that should perform better in theory than x264 and QS AVC. Thanks

[ziggy1971]

I guess it's personal because not one other person has provided any other proof, evidence, uploads or other testing. I'm the one doing the testing, I'm the one taking the criticism, I'm the one defending the fact that QS is not perfect and NEITHER it x264.

It's not "close to the original source", even at bitrates 1.3-1.5x that of what x264 requires, or 2-2.5x what x265 requires. Just because you can't see it on your display setup doesn't mean the problems aren't there.

"1.3-1.5x that of what x264" Where's the proof? Where are the uploads?

I took a risk of uploading copyrighted material (exactly how many other people here are risking a $250,000 fine and/or 5 years in prison for violating copyrights?)
So, instead of others doing their own testing using this source video, all I get is speculation and criticism. Yeah, it's a little personal...

Several people have commented on the quality (or lack thereof) of both the QS and x264 files. NOT one person has uploaded anything better. Sure, you've said x264 was better, where's the upload or at least provide the settings so I can do my own testing. Not even the settings have been provided.

Yes, this is a very challenging source, that's why I chose it.

There are literally millions of other CPU's that have this capability, why am I the only one working with it? I've read many threads and I know that others ask a lot of questions regarding QS and the quality it produces. Why don't any of those people download the source and help with the testing and possibly come up with better settings? Why can't any of those people help?

I think this thread has blurred entirely into what x264 IS, and what QS ISN'T, nothing more, nothing less. So, I more or less skim over the posts because they don't say anything I don't already know.

Don't show me what's wrong. I know what's wrong, show me how to fix/change it.



Yes, I could provide some h265 uploads using the Intel encoder, but for what purpose? I have no idea what settings to use, so, chances are, my encodes would receive the same criticism as the rest I've uploaded.

Never mind... I'll delete the source files and testing clips I uploaded. Prison doesn't interest me...

[poisondeathray]

I guess it's personal because not one other person has provided any other proof, evidence, uploads or other testing. I'm the one doing the testing, I'm the one taking the criticism, I'm the one defending the fact that QS is not perfect and NEITHER it x264.

Nobody is criticising you as a person . Don't take things so personally. We are just commenting on how an encoder performs, that's all . We are criticising the testing design . If you have invalid testing methodology, the observations and conclusions you draw from those observations are not necessarily valid. That's why I didn't post my earlier little demo, because I had made it before you mentioned cineform. So I wasted all that time, but it was invalidated.

I made some suggestions as to include settings, and details, that's all . You, by your own statement said you're not serious into video stuff. Nothing wrong with that. That's why those suggestions were made . Maybe you didn't know those sorts of things about testing design, that's why everyone is here to learn

It's not "close to the original source", even at bitrates 1.3-1.5x that of what x264 requires, or 2-2.5x what x265 requires. Just because you can't see it on your display setup doesn't mean the problems aren't there.

"1.3-1.5x that of what x264" Where's the proof? Where are the uploads?

I posted the screenshots and settings. Your own videos demonstrate this trend

I took a risk of uploading copyrighted material (exactly how many other people here are risking a $250,000 fine and/or 5 years in prison for violating copyrights?)
So, instead of others doing their own testing using this source video, all I get is speculation and criticism. Yeah, it's a little personal...

Yes, that's your choice

Several people have commented on the quality (or lack thereof) of both the QS and x264 files. NOT one person has uploaded anything better. Sure, you've said x264 was better, where's the upload or at least provide the settings so I can do my own testing. Not even the settings have been provided.

Again, I posted the settings, I posted the screenshots.

All this "boosting" the shadows business was so you can understand the problem. If you cannot even see it on your setup, how can you even go about fixing it? You made some comments that they look the same, when clearly they are different. I'm telling you, once you retain that fine grain, that's the "holy grail." That means you have something close to the source in terms of banding (or lack there of)

There are literally millions of other CPU's that have this capability, why am I the only one working with it? I've read many threads and I know that others ask a lot of questions regarding QS and the quality it produces. Why don't any of those people download the source and help with the testing and possibly come up with better settings? Why can any of those people help?

Probably Skylake QS AVC isn't capable. Certainly Haswell AVC isn't capable enough, I know because I've done 100's of tests on various types of material . I've analyzed all the switches, adjusted GOP lengths, limited frametypes, adjusted types, everything. There's only so much it can do. But at least it's fast

Don't show me what's wrong. I know what's wrong, show me how to fix/change it.

Increase the bitrate. Bitrate fixes everything. Or use a more efficient encoder. It's already been suggested

Yes, I could provide some h265 uploads using the Intel encoder, but for what purpose? I have no idea what settings to use, so, chances are, my encodes would receive the same criticism as the rest I've uploaded.

Why take things so personally ? You're not the encoder (software) . I don't understand where this is coming from ?

Try using default settings , and HQ settings. Those are the 2 main scenarios

[ziggy1971]

Let's just say that me taking things personally is something you'll never understand. Even if I explained it to you and tried to show you, as you have with photos, you'd never see it.

[poisondeathray]

Cheers, but I really don't get it. I'm being genuine here.

It's like a carpenter getting all worked up about the brand of hammer he uses. All we are doing is analyzing how good that hammer is, and what can be done to improve it

ie. These are just tools (well, hardware and software) . If you were selling the tool or something, then I might understand why you're getting all worked up...

[ziggy1971]

Great analogy, though...

It's more like the new guy/girl on the job. Someone hands them a new tool (ie. hammer) and everyone stands around laughing, mocking and even criticizing the person instead of helping him/her. Usually, only once the new person has a suffered a severe accident or even dies, do people realize something was wrong.

Just my own analogy. Perhaps a little over-dramatic, but maybe you'll get the point...

Like I said, you won't see it. Very few people do, and I'm not going to explain any further.

I'm tired...

[KarMa]

I took a risk of uploading copyrighted material (exactly how many other people here are risking a $250,000 fine and/or 5 years in prison for violating copyrights?)
So, instead of others doing their own testing using this source video, all I get is speculation and criticism. Yeah, it's a little personal...

Did you take a risk, yes. Are you in any real danger of being sued, not really. When there's a decent argument that you were using it legally under Fair Use (for research purposes) which the US and Canada share similar laws or precedents on. Especially when you uploaded a random 90 second clip of some random episode. I think there are plenty of people out there sharing full copies of this show, with zero possible Fair Use defense, easy for the suing if they wanted.

For testing situations like this, I upload encrypted files to 3rd party sites like dropbox or jumpshare. Both services offer 2GB free. Like i did in this thread. I still need to post my x265 results in that hijacked thread.

[ziggy1971]

See, I don't do this often so I don't really know what's allowable and what's not. (Fair Use, I guess) Not to mention finding people who will support each other as to whether or not the copyrighted material was used for testing/research purposes only. In my experience, when the tough gets going, everyone gets going and I'm left with the fallout. (Probably didn't need to explain that by now)
Sharing stuff like this on a public forum obviously makes me uncomfortable, but really, what other ways can one simply show examples?

I wish anyone luck trying to explain all the details, which can easily be shown in a photo or short clip.

Since it was requested, I'll start a new thread with Quick Sync h265 (HEVC)

[poisondeathray]

It's more like the new guy/girl on the job. Someone hands them a new tool (ie. hammer) and everyone stands around laughing, mocking and even criticizing the person instead of helping him/her. Usually, only once the new person has a suffered a severe accident or even dies, do people realize something was wrong.

Just my own analogy. Perhaps a little over-dramatic, but maybe you'll get the point...

Like I said, you won't see it. Very few people do, and I'm not going to explain any further.

I'm tired...

Yea.. I really don't see it. Sorry.

Nobody is mocking you, can you point out some posts that "mock" you? . Believe it or not I'm trying to help - those last few posts were me trying to explain why "banding" occurs in the first place. But probably failing miserably... But the gist of it is - IF an encoder can not retain fine details and grain, you're going to get posterization and banding.


What do you need help with ? More bitrate fixes everything . Better encoder fixes everything (at lower bitrates) .

Another approach suggested was to use 10bit (not supported by QS). And another was filter it, to dither it - but that requires even more bitrate to retain the dither . x264 and x265 have --tune grain and film tuning presets that can help with this scenario , but QS doesn't have anything like that. But these were already suggested, I'm just repeating the suggestions




I can help you understand the settings for Haswell AVC QS is that what you want ? The assumption is it will be applicable to Skylake AVC QS (and the encodes do look about the same)

But I thought I would save you hours or days of testing - because there is no combination of settings that will increase the QS AVC compression efficiency to where it will achieve quality similar to source without extremely high bitrates (perhaps even larger than the source. ). It simply can't compete in certain scenarios quality/compression wise. These are serious issues, have you looked at the screenshots I posted? You said you were an "average" user, so please listen to someone who deals a lot with various codecs - that pattern of loss is difficult to overcome. If at 9Mbps (and it's the same on Haswell AVC), it still looks like that... let's just say you're going to need about 14-15 or even larger than the original 16Mps to keep the details and grain. When you fiddle with settings, you might get a a few % better compression here or there, but in this test , a few % is several magnitudes too small . There is also the idea of "good enough" - that level is different for different people. But I'm using the definition where there isn't noticable detail, grain or texture loss, that it really looks like the source, not spotchy textureless patches.


Here are short explanations of some of the settings: If you need clarification just ask, or if I missed one you want to learn about just ask.

You're already using --quality best. I already mentioned it gives negligible benefits for serious penalty in speed, at least on haswell (about 1/2 speed, about 1-2% better compression) . Basically nobody uses it in reality. It's analgous to using something like very slow or placebo for x264. The gains are not worth it . It might be different on Skylake but I doubt it.

LA is look ahead. It's basically a pre analysis pass supposed to be a substitute for a 2pass encode. The farther the look ahead, the higher the quality in theory (with diminishing returns), but at the expense of speed (it takes more time to look ahead) . Also scenechange* is disabled (see below). The depth can be set up to a max of 100 (I think you were using 40, so you have room to go up)

LA quality is self explanatory, you're already using slow (fast, medium, slow are the choices)

Max bitrate is the maximum bitrate according to VBV rules. It's primarily used for device restrictions (e.g. some devices might choke on a big bitrate spike) . Don't use it unless you have a target limitation , because setting an upper limit can only decrease quality, never increase.

Scenechange means scene detection. This is disabled in LA mode. When enabled, if a new scene is detected, it will place an IDR frame, signalling a new GOP. IDR frames "cost" a lot to encode, because they are self inclusive - they do not rely on other frames for information (ie. no temporal compression). But placing a IDR frame on a new scene is usually the right thing to do both for seeking/playback purposes and for efficiency purposes. The short explanation is these types of codecs store the differences between frames, and a large difference like a new scene will end up costing a lot more in the end than placing a new IDR frame and having the new GOP filled with lower cost b and p frames

Trellis quantization is an algorithm that is supposed to optimize the residuals from motion estimation, making compression more efficient (lower residuals mean less to store, at the cost of being slower). In reality it may or may not . In some scenarios it does. Eitherway the effect is very small. It can be set for I only, IP or IPB frames

b-pyramid means b-frames can be used as references. In general this is a good idea compression efficiency wise. Some older devices might have problems with decoding this. You had it disabled. As mentioned earlier, more have b-frames definitely helps with some encoders (they are lower cost) , but other encoders it actually make the quality worse. It definitely helps with x264, x265 in the lower to normal bitrate range.

QP Min/Max sets lower and upper limits on the quantizer values. The relationship is inverse - lower QP's mean higher quality. You generally don't want to touch this, because you want flexibility in the encoder . Placing limits usually only worsens potential quality. But it can be set to a single value for all frame types, or I:P:B to affect the min/max I:P:B frame QP values . For example , if you notice the B frames were always terrible in comparison to I and P, you might set the max QP a bit lower

slices 4 is usually only for device (such as BD) compatibility. The picture is divided up into segments. The more slices the lower the quality, it's true of every encoder. It's negligible at 4, maybe 0.1-0.2% quality penalty. If you don't need it , don't use it.


Cheers

[ziggy1971]

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).