x264 vs Quick Sync Comparison

[ziggy1971]

I ran some tests on some clips and decided to post some results.

See if you can guess which was encoded with x264 and which was Quick Sync.

The Quick Sync file size

File sizes:
x264: 122 MB (128,698,912 bytes)
Quick Sync: 126 MB (132,870,731 bytes)

These are the x264 settings I used, I think they provide a reasonable quality encode.

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=18 / lookahead_threads=3 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=8 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=240 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=60 / rc=crf / mbtree=1 / crf=19.9 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00

Sorry about the file size of the screenshots, I didn't want to change anything, just save the screenshot with MS Paint as is.

x264 vs Quick Sync Comparison 1


x264 vs Quick Sync Comparison 2


I found the script used to compare clips somewhere here on VideoHelp forum:

# If Videos start at different frames use frameadjust to align them
frameadjust=0
name1="Source Name"
name2="Compare Name"

# Videos to compare: (v1 is original, v2 is encoded or whatever)

v1 = FFVideoSource("Source File")
v2 = FFVideoSource("Compare File").trim(frameadjust, 0)

sub = v1.subtract(v2) 
substrong = sub.levels(112, 1.000, 144, 0, 255) 

StackVertical(StackHorizontal(v1.subtitle(name1), v2.subtitle(name2)), StackHorizontal(sub.subtitle("Difference"), substrong.subtitle("Difference amplified 8x")))

Let me know if there are any errors or would like me to do some other comparisons. Perhaps some other clips or x264 settings.

I'll be running some HEVC 10-bit on Quick Sync soon.

[jagabo]

The second image is QS. All the small low contrast detail is gone.

[KarMa]

Yeah "x264 vs Quick Sync Comparison 2" is the QS.

[jagabo]

By the way, you should always post the original image along with the encoded images.

[KarMa]

By the way, you should always post the original image along with the encoded images.

It looks like the top left image in both of the images is the source video, as described in the AVS script.

[poisondeathray]

You should post the QS settings used too, and HW configuration (especially for QS, because different Intel generations yield different quality and speed)

Encode time is optional, but often people are sometimes interested in quality/time tradeoffs


And single frame screenshots can be misleading. E.g. b-frame vs. i or p frame comparison

But you've posted some tests another thread, sources, encodes . Or maybe it was from a different disc/ episode but it looks very familiar

[jagabo]

By the way, you should always post the original image along with the encoded images.

It looks like the top left image in both of the images is the source video, as described in the AVS script.

LOL. Sorry. I made a script to A/B flip between the two image and I cropped it to just the top right corner (to fit on the screen). Then I forgot about the rest of the original images!

[ziggy1971]

Thank you for your thoughts/opinions.

I thought the labels in each photo should be self-explanatory; both source and encoded versions, difference and difference amplified.

I didn't see the point in re-uploading another source so I used the same one I used here: https://forum.videohelp.com/threads/381261-Intel-HD-530-%28GT2%29-Quick-Sync-h265-%28HEVC%29

Attached are the resulting clips.

Encode times:
x264: 00:05:19 (with an Intel Core i7-4930K overclocked to 4.6GHz)
Quick Sync: 00:01:56

The Quick Sync settings or other hardware used only become relevant when trying to reproduce the results.

[jagabo]

Now repeat the x264 encode at the veryfast preset and you'll see it's almost as fast as the QS encoding and still looks better.

[ziggy1971]

Well, not clear on what people are looking at, but from what I see, there is little to no difference save for bias opinions.

Without any explanation or clarification pointing out the details (or lack thereof), an opinion is just that, an opinion.

I could say "the sky looks better today." However, without any point of reference as to what it's compared to or what makes it look better, every day the sky could look better...

Saying that x264 looks better than Quick Sync is pointless. Hell, even with my lack of experience, I could go on saying that. Show me exactly where there is such a drastic difference? Suggest some settings, do something...

Standing on the sidelines and pointing out faults, well, please move on. Present useful information based on results and actual data. Perhaps I could suggest using a "circle" to point out differences, I don't know, it's much more work than simply typing "x looks better than y"...

[jagabo]

I already told you what the differences were in my first post.

[poisondeathray]

The Quick Sync settings or other hardware used only become relevant when trying to reproduce the results.

I think it's always relevant , just like x264 settings are always relevant too, or encoder A,B,C, etc... - at least in the context of comparisons. They can help to explain observations.

You posted x264 settings, so why not QS ? QS has quality presets too, and you can use things like more reference frames, more b frames, higher lookahead. Would it be "fair" to use "low" quality for one but "high" quality for another ? Maybe - it depends what you set out to test in the first place. For example, if you put some constraints on like minimum "x" fps processing speed, you might have to use lower quality settings on some encoders. If you set out to test maximum compression / quality, then yes it would matter wouldn't you think ?

For the purposes of transparency and testing, it's always a good idea to post the testing parameters. For example, Sandy Bridge QS (this is 1st gen QS), is much slower and much lower in quality than later generations. Additionally, more encoding features and options were added in subsequent generations, and not available in earlier generations. Those types of details matter because they result in differences

[ziggy1971]

All the small low contrast detail is gone.

Really doesn't mean much without explaining how you determined that.

Without showing how "you" see that or otherwise come to that conclusion, the validity and credibility of your claims become virtually meaningless.

I'm not claiming one codec to be better than the other. I'm just encoding them and offering them up for comparison/review. Just "saying" one is better than the other is nothing more than empty words. Point out "where" on the actual image you see the differences. If you can't explain where to look and what to look for how can others even attempt to see what you apparently do.

I COULD ask how you determined that, but I won't, so never-mind. I actually have other things to do than wander the forums.

[ziggy1971]

The Quick Sync settings or other hardware used only become relevant when trying to reproduce the results.

I think it's always relevant , just like x264 settings are always relevant too, or encoder A,B,C, etc... - at least in the context of comparisons. They can help to explain observations.

You posted x264 settings, so why not QS ? QS has quality presets too, and you can use things like more reference frames, more b frames, higher lookahead. Would it be "fair" to use "low" quality for one but "high" quality for another ? Maybe - it depends what you set out to test in the first place. For example, if you put some constraints on like minimum "x" fps processing speed, you might have to use lower quality settings on some encoders. If you set out to test maximum compression / quality, then yes it would matter wouldn't you think ?

For the purposes of transparency and testing, it's always a good idea to post the testing parameters. For example, Sandy Bridge QS (this is 1st gen QS), is much slower and much lower in quality than later generations. Additionally, more encoding features and options were added in subsequent generations, and not available in earlier generations. Those types of details matter because they result in differences

In this case, I didn't provide QS settings because the video I presented will not change regardless of whether I say I used Sandy Bridge, Ivy Bridge, Haswell, etc.

If I aim to improve the quality, then yes, using newer hardware may yield better results. But still does not change this video I provided.

I haven't read all of this yet; will later, but this is an explanation, some detail, ideas, etc. Not just A is better than B...

Work to do...

[ziggy1971]

I will try altering the B frames, Look ahead depth and maybe some other settings and see what I can come up with.

Just saying something is better than the other, well, that's not useful information. There are several million people, without any encoding knowledge, who could say the exact same thing and mean the same thing.

Yes, I get upset when people answer without actually saying anything. I don't want to read their useless comments, it wastes my time as well as others trying to learn.


Wow, all this and a whopping 1 download of the actual Quick Sync video.

[jagabo]

Wow, all this and a whopping 1 download of the actual Quick Sync video.

Because no one here needs to see it. We've all done this many times ourselves, seen others do it many times, and the result is always the same. And your initial images already show it.

[poisondeathray]

It's basically the same as the other thread . There are some good tips in that thread on how to "see" differences if your eyes are not used to seeing these types of things, or if your display is hiding things or calibrated differently

If you brighten up the encodes , you will see right away, there are significant differences. The fine details, grain are smoothed away in the QS encode . You would need significantly higher bitrate (or perhaps better settings might help a bit ) to be closer

I like to use avspmod, so I can swap between them with the number keys. You can load original, A,B, etc... in different tabs, and they are aligned . You can use something like hdragc or levels to brighten it up if you need to

I posted screenshots in the other thread, it's very similar here. I can redo some if you want, but it's better to learn to do the comparisons yourself so you can apply to other videos, other scenarios, other comparsions too

[ziggy1971]

Wow, all this and a whopping 1 download of the actual Quick Sync video.

Because no one here needs to see it. We've all done this many times ourselves, seen others do it many times, and the result is always the same. And your initial images already show it.

@jagabo
As I figured. Judged without actual evidence.

Based on this type of assessment, according to you, if one black person steals, all blacks are thieves, right?

So, my response to this is "Don't respond to any of my threads again." Do I need to show any examples or clarify things further for you? Clearly you've seen it all, done it all and, obviously, a "know-it-all". In my experience, "know-it-alls" actually know the least and have the most to learn.

With your vast knowledge, perhaps you could point me to where I could find detailed info with example encodes on the newer Intel UHD 630 Quick Sync? Just point me in the direction, no opinion needed, as I already know what that's worth.

@poisondeathray
The "other thread" you refer to, is that this one? https://forum.videohelp.com/threads/381261-Intel-HD-530-%28GT2%29-Quick-Sync-h265-%28HEVC%29

I just took a quick glance and didn't see any screenshots, will have to read through it again as a refresher, I seem to have missed how to do alternate comparisons as you suggested.

[jagabo]

For serious comparison I like to use:

source = WhateverSource("source.ext")
enc1 = WhateverSource("enc1.ext")
enc2 = WhateverSource("enc2.ext")
Interleave(source, enc1, enc2, source)

Open that in an editor like VirtualDub and you can easily A/B flip between the source and enc1, enc1 and enc2, and enc2 and the source, using the left/right arrow keys. And you can zip around through the video at will. I also use a screen magnifier (Windows' Ease of Access Magnifier). And I work in a dark room when examining dark videos, sometimes lightening them up to make dark details more visible. You can see minute differences this way.

Of course you also need to see the videos in realtime playback:

source = WhateverSource("source.ext")
enc1 = WhateverSource("enc1.ext")
enc2 = WhateverSource("enc2.ext")
StackHorizontal(source, enc1, enc2, source)

If the result is too wide for your display, crop the individual videos before stacking.

One of the big reasons it's important to retain small low contrast detail (aside from the fact that the job of the encoder is to reproduce the source as accurately as possible given whatever constraints are imposed upon it) is to prevent posterization. This can be seen in shallow gradients, especially in long, low motion, shots, harder to see in a bunch of half second high motion shots.

One "weakness" with x264 is that it tends to distort fast moving edges. But this is an intentional tradeoff. The warping is visible when you A/B flip but not during real time playback. If the slight distortion isn't visible with normal viewing, but saves significantly on bitrate, this may be a good tradeoff.

I've also examined motion vectors when comparing QS and x264 videos (some decoders like ffdshow can show them). QS often finds far fewer for some reason. Even at times when you think it should have no trouble seeing them.

[poisondeathray]

And another way is to interleave it in an avs script (this alternates the view as you go frame by frame , A1,B1,A2,B2...), and just step through with mpchc or vdub or avspmod or whatever you use to preview scripts . It's ok when you have maybe 2 maybe 3 to compare; but when you have more than that , interleave method gets difficult and unwieldy . I also like that avspmod tab method, because that also is a way you can tweak scripts and settings - you can compare easily between different settings

It's not like "close" or a few frames here and there that are very close... every frame is substantially worse in the QSV encode . You probably don't even have to label it

e.g. interleave (in this example, I didn't include source, but you should always compare to source at some point too). hdragc is used to boost the levels, brighten the shadows preferentially

q=FFVideoSource("S05-E06 - Unbowed, Unbent, Unbroken.mkv").hdragc().subtitle("quicksync")
x=FFVideoSource("S05-E06 - Unbowed, Unbent, Unbroken x264-19.9.mkv").hdragc().subtitle("x264")

interleave(q,x)

If you wanted to, you can use FFInfo() to get info on , the type of frame (I,B,P) for your analysis . The info can be helpful for comparisions maybe tweaking settings (where is an encoder weak, maybe some I:P:B ratio and/orquantizer can be adjusted, maybe more or fewer B-frames , etc...)

[jagabo]

your initial images already show it.

@jagabo
As I figured. Judged without actual evidence.

You've already shown the evidence in the first post of this thread. And I've seen some of your videos in your other comparison thread.

So, my response to this is "Don't respond to any of my threads again."

You don't get to determine who responds to your posts. You're welcome to add me to your ignore list though.

[ziggy1971]

Again, assuming the same encodes using the same hardware so you provide the SAME answers. What more can I say...

Just so you know, it's NOT THE SAME hardware, software, firmware, or anything else that I've used before.



No, I can't decide who responds. But a proper person would respect the wishes of another when they feel their presence isn't of any benefit and only hindering the process. So I can ask and a good person would respect.

[poisondeathray]

I cross posted with jagabo there , but he suggested the same interleave method

I think you should add the hdragc (or something similar) , because I have a feeling your eyes aren't used to seeing this sort of thing, or your display is setup to crush dark details , maybe it's a lower bit panel, or calibrated a bit funky, or something

[ziggy1971]

I know that my setup isn't IDEAL for video editing; it's not my primary job.

Getting a 100% perfect copy of any video has never been my goal. If I wanted 100%, why waste time re-encoding? Just watch the original and take a nap.

I was going to do some new encodes with HEVC using the Intel UHD 630, but really, what's the point here. Instead of getting suggestions as to what settings one could change and how they affect the outcome, I'd get "QS sucks, x265 rocks". I don't need or want the headache of dealing with people like that.

I know that the Intel UHD 630 does now include all the I, B, and P frames. I don't know what affect that will have though. It seemed that Intel HD Graphics 530 lacked the P frames for HEVC encoding before.

I'll be upgrading much more of my equipment in the near future, as posted in other threads, but I'll keep my encodes to myself. I'll see what effects a dual CPU, 56+ cores and multiple RAID setups will provide in encoding efficiency; JUST FOR FUN AND TESTING!!!

Again, before everyone barks down on me about how too many threads can have negative affects on quality, speed etc. blah, blah, blah. It's not a PC designed specifically for encoding, it's for 3D modeling, CAD and many other software programs that do benefit from such a setup.

[poisondeathray]

I know that my setup isn't IDEAL for video editing; it's not my primary job.

Nobody is "dissing" your setup . Just trying to make it "easier" to see what everyone else is "seeing"

Getting a 100% perfect copy of any video has never been my goal. If I wanted 100%, why waste time re-encoding? Just watch the original and take a nap.

Exactly , lots of options, and many goals (quality, vs . speed, compatibility etc....)

But for AVC encoding, the book is pretty much written and closed . When every test says pretty much the same thing over and over (I mean extensive testing, 1000's , changing each parameter 1 by 1, on many different sources), all those observations make up a very strong conclusion. Remember, not all tests are published or posted in forums; some people do their own testing and there are other forums and circles where people communicate this stuff. It's very mature; and only when something unexpected occurs or some problem that it gets brought up . Otherwise the results are very predictable for AVC ; I don't think some minor revisions or changes to encoder A,B,C...x264 or otherwise, etc... are going to make that much of a difference at this point for AVC

But remember , you just posted 1 limited test (and without published Intel settings) but on the AVC front it appears nothing has changed ; it looks eerily similar to those before. But maybe there are other newer switches/settings ? I doubt it but you never know

I was going to do some new encodes with HEVC using the Intel UHD 630, but really, what's the point here. Instead of getting suggestions as to what settings one could change and how they affect the outcome, I'd get "QS sucks, x265 rocks". I don't need or want the headache of dealing with people like that.

You can do whatever you want; the point is whatever you want it to be . Or don't do anything if you don't want to .

Most people design a test with something "concrete" in mind . There is a defined end point and testing parameters with constraints. What type of questions are you trying to answer ?

I don't know what the new changes or switches are for Intel UHD 630 QS HEVC, so that might be worth investigating . There aren't as many HEVC tests or investigations for many reasons

But thanks for posting again with the updated intel tests . All these are observations (data points, essentially) , they all add up eventually.

I know that the Intel UHD 630 does now include all the I, B, and P frames. I don't know what affect that will have though. It seemed that Intel HD Graphics 530 lacked the P frames for HEVC encoding before.

Not true; older versions had B-frames. Your older QS HEVC encodes in that thread had I,B,P. It's NVEnc HEVC that lacks B-frames




And don't be discouraged from posting; especially if you have some interesting observations to share.

[poisondeathray]

What I'd like to see is HEVC encodes from the Intel Media SDK . They made it free a while back for Windows ( Intel Media SDK 2018 R1, I think there is an R2 now). This is not the same thing as the general quicksync that everyone uses; this is the full version with bells and whistles hardware+software encoder that beats x265 according to PSNR/SSIM tests from MSU (PSNR/SSIM aren't great tests , but the fact that it scores higher would make it interesting to look at) . If you can get that working, that would be interesting. It's supposed to be difficult to get running

[ziggy1971]

In my initial post, I showed two screenshots and a script showing how I compared them.

The initial response was:

The second image is QS. All the small low contrast detail is gone.

For someone like me, who only occasionally works with video, that statement doesn't mean much.


Now, if jagabo's initial response had been something like:

The second image is QS. All the small low contrast detail is gone.

You can see the difference clearly by using the following:

source = WhateverSource("source.ext")
enc1 = WhateverSource("enc1.ext")
enc2 = WhateverSource("enc2.ext")
Interleave(source, enc1, enc2, source)

Or by using some other methods such as the ones described in posts #19 and #20, neither of which I've ever seen before. That would make a much better response than by simply stating what is wrong with it.

A simple explanation on how one derives a conclusion is all that's needed. But that's just me.

Now, the question remains; do I follow any suggestion for comparing clips? For all I know, the scripts could be crap offered up by someone who's messing with me and sending me on a wild goose chase; credibility of that person already in question... why should I trust the advice now?

They made it free a while back for Windows (Intel Media SDK 2018 R1, I think there is an R2 now)

Yeah, I heard about that and was thinking about giving it a try. But just like this post; I have no desire to go through all this again when all I tried to do was offer some samples to get some opinions/advice. Not worth it for me.

[KarMa]

I took a look at the x264 and QS AVC videos, which I made into a lossless comparison. Due to me using lossless video I got rid of 29 out of 30 frames and made it play at 1fps. It comes out to 192 frames. I probably should have done 1 out of 24 frames but whatever. The top left and bottom right squares are QS, and the top right and bottom left is the x264 sample. Encoded with lossless FFV1.

As a AVC Hardware encoder it certainly looks like one of the best around and would certainly use it for realtime streaming or whatever. But if you have the time, x264 will still look better at any given bitrate (assuming you use some of the slower x264 presets).

LoadPlugin(".........LSMASHSource.dll")
A=LWLibavVideoSource("............S05-E06 - Unbowed, Unbent, Unbroken x264-19.9.mkv").crop(962,0,0,-542).AddBorders(2,0,0,2).subtitle(align=9, "x264", text_color=$7CFC00)
B=LWLibavVideoSource("............S05-E06 - Unbowed, Unbent, Unbroken.mkv").crop(0,0,-960,-542).AddBorders(0,0,0,2).subtitle(align=7, "QS")

AA=LWLibavVideoSource("...........S05-E06 - Unbowed, Unbent, Unbroken x264-19.9.mkv").crop(0,540,-960,0).AddBorders(0,0,2,0).subtitle(align=1, "x264", text_color=$7CFC00)
BB=LWLibavVideoSource("..........S05-E06 - Unbowed, Unbent, Unbroken.mkv").crop(962,540,0,0).subtitle(align=3, "QS")



N=StackHorizontal(B,A)
S=StackHorizontal(AA,BB)


StackVertical(N,S).SelectEvery(30, 0).AssumeFPS(1)

[ziggy1971]

I know that the Intel UHD 630 does now include all the I, B, and P frames. I don't know what affect that will have though. It seemed that Intel HD Graphics 530 lacked the P frames for HEVC encoding before.

Not true; older versions had B-frames. Your older QS HEVC encodes in that thread had I,B,P. It's NVEnc HEVC that lacks B-frames

This is what I was referring to:

https://forum.videohelp.com/threads/381261-Intel-HD-530-(GT2)-Quick-Sync-h265-(HEVC)#post2466415

Interesting that the CQP encode has no P frames, just I, P . Normally the CQP ratio for most encoders when using CQP encoding will be set - lower, higher, highest , so that the I frames (which are the key frames) will have the highest quality, then the P, then the B . But not all encoders behave the same way, there might be an optimal ratio for a given encoder

[poisondeathray]

I know that the Intel UHD 630 does now include all the I, B, and P frames. I don't know what affect that will have though. It seemed that Intel HD Graphics 530 lacked the P frames for HEVC encoding before.

Not true; older versions had B-frames. Your older QS HEVC encodes in that thread had I,B,P. It's NVEnc HEVC that lacks B-frames

This is what I was referring to:

https://forum.videohelp.com/threads/381261-Intel-HD-530-(GT2)-Quick-Sync-h265-(HEVC)#post2466415

Interesting that the CQP encode has no P frames, just I, P . Normally the CQP ratio for most encoders when using CQP encoding will be set - lower, higher, highest , so that the I frames (which are the key frames) will have the highest quality, then the P, then the B . But not all encoders behave the same way, there might be an optimal ratio for a given encoder

My mistake, bad memory ; I was referring to the other thread, but they were actually AVC encodes. And the HEVC encode with I,P,B was actually x265, not QS.
https://forum.videohelp.com/threads/381170-x264-banding-posterizing-%28Quick-Sync-also%29