Intel Quick Sync video samples

[vhelp]

This thread will probably be a work in progress. It will serve as a resource for samples of Intel's Quick Sync encoded videos. We can call it QS for short-hand.

After these clips in the next segment below, I want to upload a few more, so that people can get an idea of what qs can do and decide for themselves if qs is for them or some other encoder. I myself am starting to lean toward qs because I believe it has potential. The quality is there but qs can be a bit unpredictable, in terms of files size and quality and speed. Plus, I can't wait for slow software encodes. But don't get me wrong. I still believe that software is the ultimate avenue for most processes, mainly because it can be customized easily and quickly and in most cases, no new hardware would have to be purchased. Eventually, hardware will get wise and become eproms that can be updated with latest changes and features. So, until then, lets make the best of what we have and have fun.

I will start off with the following two videos. One was encoded by x264 and the other by Intel's Quick Sync hardware encoder (lets call it, QS).

ok. i found the two compare clips that i wanted to post a few weeks ago that were lost. i'll upload those two and you guys can play around with the idea of which encoder did what. this is not about analyzing the clips in a timeline pausing at frames to review, but to observe on a cheap display (tablets and laptops) versus a decent monitor versus a large screen tv etc. if you attempt to stop to analyze it frame to frame then you ruin the perception--and fun. anyway. to make things worse, i had forgot which one was which, after i labeled them clip A and clip B, and no order of which was encoded first. i also had other clips of this nature but i can't find those files. i will probably redo those again another time. in the mean time, have fun deciding which video came from what encoder. i won't be telling.

[ezcapper]

thanks for uploads. 210 seemed to be slightly poorer quality. More blur and eye agitation in last scene with the movement when the man gets up and moves towards camera. Also some people in background like the man in white helmet sitting down at the control station. I watched each one once at normal speed on laptop. Both seem pretty good quality.

[vhelp]

Re the issue with the eye. He had an eye infection during that time period in that movie sequence. I think the president also had it. It might have been contagious at the time. I don't know. I never did listen to the narration version of the disc. Not sure there was one available. Usually, they mention things like that, 'oh yeah, i had a terrible eye infection...'. Any. try not to over analyze the pixel detail if you can help it. What I am most after is the least amount of image artifact. If the two or more comparable clips have more or less noise, that is ok, it is more about NOT seeing pixelations and macroblocking. And dark scenes we already know will be problems due to color bit-depth limitations. If the video is clean in that respect, that is what matters to me. Don't know about the rest of you. Each have their pros and cons of expectations. Its all good. As for these two clips, they served their purpose well. The film grain (noise to noise people) was pretty heavy in this movie's digital master process. It is obvious why it was so... to provide the level of quality you see on your screen, sharpness and image smoothness, for lack of better term. When I stand more than three feet away the playback is quiet undiscernable--its good quality. But that's all I will say on this subject. Thanks for your review.

So far, Intel's Quick Sync provides the best quality, imho.

[vhelp]

Re Monitors

I believe that part of the problems with members posting pore quality videos from their encoders has to do with the monitors they are working under. Most laptop and desktop pc monitors are cheesy. My Dell Inspiron and newest Acer Aspire E 15 are my own perfect examples of poor quality encoded videos in the past. And most others here are in the same boat. There was an instance where a member here was getting upset because the person couldn't understand why he was being told that his videos were of poor quality, when he was seeing good video, on his end. It was partly explained why. But the main reason why (in addition to the source clip and encoding used at the time) had to do with the lack of a better monitor. One that can show better realistic image detail, to see the small difference between the source clip versus the encoded clip. The weakness is that the monitor probably has a low Gamma and Contrast. And reviewing video will always look very good because the monitors limitation is hiding the true video detail. Thats just one example of many. It took me a while to realize and accept that myself. But now that I have.. anyway.

So as I was saying. I recently picked up a new 22 inch, 1920x1080 monitor, brand name is AOC, model i2269vw series 69V. It is not a professional model but definitely better than an laptop one. Even my newest Acer Aspire 1920x1080 HD laptop display is just as bad. Its not bad, just not a good tool to use to review video with. Laptops are not good tools to use to review video. Plane and simple. But the AOC is better at that. I was surprised to see the difference in the videos that I previously encoded. Very disappointing! So I now use the AOC monitor for all my video work. And since I am not doing color correction work of that level, I have chosen not to make those adjustments. The Gamma and Contrast levels on the AOC is enough for my needs for video work. It allows me to see the true image details and I can make the necessary adjustment(s) necessary in the encoder.

I recommend considering updating to a new monitor, if finance allows. One suggestion, with-in price range, is the $99 AOC (mentioned above). Its got good Gamma and Contrast levels, enough to discern video detail that will reflect your future video encoding settings.

[vhelp]

While browsing for blurays at walmart and then bestbuy, I couldn't but help to over-hear the audio sound playing in another section of the store. It had the familiar feeling of Starwars. So I went to take a look, thinking back about the bluray movie, "The Fifth Element" and how noisy (film grain) was added and why they processed it that way. I had the huntch that it somehow helps in the encoding quality aspect. Anyway. It was playing on one of the big screen and I walked up really close to it to see if it had similar film grain the TFE, and sure enough, it did. So, I suspect that that movie also has similar (heavy) film grain, to bring the highest quality out, and I suspect that a select number of movies have this type of grain. So, I made it part of my purchase and plan on ripping it to finally see if it has the same film grain, and will encode some scenes to review and ponder over. But I will first watch it before I do any ripping/processing to it. I will post samples of select scenes. If anyone has suggestions for certain scenes, please let me know and I will add them. I didn't stay to watch the movie. I saw about 5 minutes or so and said, I got to get out of here and watch it at home. The last scene I saw was when Harrison Ford entered the ship and was saying to Chewbackee that he found his ship, or something alone those lines. I believe that I was watching the beginning of the movie. Anyway. can't wait to watch. So, until then..

[ezcapper]

It may be an oddity, but I like it when there is visible grain on a motion picture blu ray encode, it makes it look like a movie to me. Bluray encoded to clearly is too much like being in the room where the characters are for me. It doesn't feel like a movie.

edit: quote edited out

[vhelp]

Here are a couple of files from a scene in the Starwars 'The Force Awakens' bluray.

note: if you could please not copy the whole posts when responding, it would save space on the pages, plus I may add or remove text from those posts for various reasons--thanks.

These are encodes made on my to laptops, and old one and new one:

* Dell Inspiron laptop, 1366x768, i3-2370M cpu, sandybridge, intel media sdk api v1.4
* Acer Aspire E 15, 1920x1080, i3-7100U cpu, kabylake, intel media sdk api v1.19

software front-end to intel's quick sync hardware encoder: QSVEnc v2.60

The clips include the relative frame positions as well as current frame position and count so that anyone can follow and encode the segment on their own. If you do follow this way, then you will need to use only the "00153.m2ts" 38GB file and script.

Bluray disc file location

..\The_Force_Awakens\BDMV\STREAM
00151.m2ts <== this is the familiar opening scene file, it is 641MB, egnore this file.
00153.m2ts <== use this one for the encoding.

Avisynth script used to encode the segment

  v = "g:\src\src.video.starwars.ep.vii.TheForceAwakens.1920x1080.00153.m2ts"
  LoadPlugin( "c:\PLUGINS\LSMASHSource.dll" ) 
  LWLibavVideoSource(v, cache=true , seek_mode=0 )
  a=trim( 12844, 13453 ) # position in the "00153.m2ts" file to encode
  last=a
  trim( 0,0 )            # option--because sometimes vdub won't open w/out this line.

original file names (videohelp chops off for space reasons) to rename back to:

PSNR 31.262415 SSIM 16.970038 "video.20161230.Starwars.TFA.VII.bluray.Acer.Aspire.E15.kabylake_QSVenc2.60_api-1.19_[u1.br6.ref4.schange_1920x1080].0425.h264.mkv"
PSNR 31.186456 SSIM 16.559968 "video.20161230.Starwars.TFA.VII.bluray.Acer.Aspire.E15.kabylake_QSVenc2.60_api-1.19_[u1.br6.ref4.schange_1920x1080].0426.hevc.mkv"
PSNR 31.105938 SSIM 16.608251 "video.20161230.Starwars.TFA.VII.bluray.Dell.Inspiron.Sandybridge.i3-2370M_QSVenc2.60_api-1.4_[u1.br6.ref4.schange_1920x1080].0427.h264.mkv"
PSNR 32.359589 SSIM 17.251190 "video.20161230.Starwars.TFA.VII.bluray.Dell.Inspiron.Sandybridge.i3-2370M_x264-r2338_[slow.crf18_1920x1080].0429.h264.mkv"

EDIT: added one more encoded clip, this time encoded with x264, added to the list above, last file, # 0429

[easyfab]

could you run some metrics ( PSNR and SSIM) on these files with ffmpeg ?

ffmpeg -i source -i file_to_test -lavfi ssim;[0:v][1:v]psnr -f null -

ffmpeg -i youravsfile.avs -i video.20161230.Starwars.TFA.VII.bluray.Acer.Aspire .E15.kabylake_QSVenc2.60_api-1.19_[u1.br6.ref4.mkv -lavfi ssim;[0:v][1:v]psnr -f null -

[vhelp]

If you have the movie, you can actually do it yourself. I mean, who doesn't have this movie? I let my eyes tell me that I see. But for stats purposes, I can provide that info moving forward. I think I got it, how to perform it through ffmpeg, but its not working for me. give me a moment to try and figure it out and I'll update my post above.

edit: to simplify, i renamed the video file.

c:\tools\ffmpeg\ffmpeg -i "i:\tools\movie.avs" -i "m:\dst\video1.mkv" -lavfi ssim;[0:v][1:v]psnr -f null -

throws this message: "i:\tools\movie.avs: Unknown error occurred"

edit 2: still not able to to get it working.

[poisondeathray]

32bit avisynth requires 32bit ffmpeg binary with avs support compiled . Commonly distributed builds like zeranoe's have avs support compiled

[easyfab]

For the error, did you use ffmpeg 64bit or 32bit, if 64bit perhaps an incompatible plugins with 64bit.

edit : poisondeathray was faster than me

[vhelp]

how do i know if i have a 32bit or 64bit ?
ffmpeg does not tell you in the output. and i've never had trouble opening .avs scripts through ffmpeg. i do it regularly.

ffmpeg version N-82092-g89ec4ad Copyright (c) 2000-2016 the FFmpeg developers
  built with gcc 5.4.0 (GCC)
  configuration: --enable-gpl --enable-version3 --disable-w32threads --enable-dxva2 
  --enable-libmfx --enable-nvenc --enable-avisynth

[poisondeathray]

Check your avs to see if it opens in vdub, or avspmod, or mpchc

Can you encode your .avs alone in ffmpeg ? Do a short 5sec test

ffmpeg -i "i:\tools\movie.avs" -c:v libx264 -preset:v faster -an -t 00:00:05 test.mp4

[vhelp]

it opens fine, only that due to its 38GB size, and conversion, it takes 28 seconds to come into view. it bombs w/ same error message with with:
{ ffmpeg -i "i:\tools\movie.avs" } alone. The script used, is posted above post # 7 and works fine in vdub. edit: script never worked in MPC-HC. ok. maybe it is 64bit. i'll search for a 32bit and download it. all this could have been avoided and unwaisted space if ffmpeg would just freak'en tell somewhere, damnit.

[vhelp]

ok. got it working. which number to give, it has a lot posted in last two lines.

[easyfab]

The more important are :

For SSIM -> All:0.XXXXXXX (X.XXXXX)
For PSNR -> average:XX.XXXXXX

[vhelp]

Thank you for your assistance with ffmpeg, easyfab / pdr.

In looking at the scenario a bit more, it seems, there is just no way to get a psnr/ssim stats in the favor of any two sources, not as long as the source has fine grain in it because the encoder will smooth out those pixels. If two sources are clean, then the psnr/ssim will be in sync with near matches. As for my encoding's in post # 7 they were way off. Way off. But that doesn't mean the encoding were bad. The encoding I am shooting for is to keep as much or all of the image detail, and that includes the grain. I don't want to smooth the grain out, like they for online videos and trailers. For instance, that batman trailer has absolutely no grain. But if you load bluray, the grain is there. Anyway. I will continue to try and find the formula for obtaining near-lossless perception in qs encodes.

Just for kicks, I went ahead and encoded the same sample clip, this time in { x264-r2338 --preset slow --crf 18 --output outvideo.mkv "movie.avs" } and got 24 MB size file, but very similar psnr/ssim report. However, the clip encodes very similarly to what I use for qs because I use a template-idea that { --slow --crf 18 } is a good bases, (the encoded output quality and filesize) are good base gauges to measure by. I mentioned this in another thread elsewhere. The point is about obtaining as similar quality as x264 would, at those x264 encoding parameters with qs. Grain is very important to maintain, especially if that is what was in the original source. Anyway.

See post # 7 for the updates and the *new* x264-encoded file upload for those details.

[poisondeathray]

In looking at the scenario a bit more, it seems, there is just no way to get a psnr/ssim stats in the favor of any two sources, not as long as the source has fine grain in it because the encoder will smooth out those pixels. If two sources are clean, then the psnr/ssim will be in sync with near matches. As for my encoding's in post # 7 they were way off. Way off. But that doesn't mean the encoding were bad. The encoding I am shooting for is to keep as much or all of the image detail, and that includes the grain. I don't want to smooth the grain out, like they for online videos and trailers. For instance, that batman trailer has absolutely no grain. But if you load bluray, the grain is there. Anyway. I will continue to try and find the formula for obtaining near-lossless perception in qs encodes.

Just for kicks, I went ahead and encoded the same sample clip, this time in { x264-r2338 --preset slow --crf 18 --output outvideo.mkv "movie.avs" } and got 24 MB size file, but very similar psnr/ssim report. However, the clip encodes very similarly to what I use for qs because I use a template-idea that { --slow --crf 18 } is a good bases, (the encoded output quality and filesize) are good base gauges to measure by. I mentioned this in another thread elsewhere. The point is about obtaining as similar quality as x264 would, at those x264 encoding parameters with qs. Grain is very important to maintain, especially if that is what was in the original source. Anyway.

Yes, they are not very good measures - only weak to moderate correlation with subjective perception. It's a big topic discussed in detail in other threads. If you used --tune SSIM or --tune PSNR , the results look terrible on typical live action footage, but the scores are higher. But it's still a tiny bit of information, as long as you know how to interpret it with all the other analysis and information. The one thing they are really good for is testing lossless vs. lossy. But there are several newer more advanced categories of metrics, but not implemented in ffmpeg yet

[Roph]

If you could do some runs of this source file (at the top) with kaby lake's quicksync at various bitrates and in H264/5, that'd be a big help

[easyfab]

thanks for the metrics,

Yes PSNR/SSIM aren't perfect metrics to show quality but It give you an idea. What I was looking for is the difference between QS AVC and QS HEVC. HEVC could in theory use 50% less bitrate for the same quality.
And I'm not very impressed with QS HEVC for the moment with API 1.19.

[vhelp]

agreed. from a branding name stand-point, it should be a better or improved, Kabylake should be better than Skylake, but I am not seeing that, at all. I am seeing the same performance, that is, both are equal. And that makes no sense. From my understanding, the developer said he would not update QSVenc since he does not have a Kaylake cpu and feels its not out yet. I tried to demonstrate it has been out for a while now. I made mention that the app reads kabylake as skylake and that it appears the encoding features has less 'O's (to indicate active features) -- they are not showing as active and available in QSVenc. His latest version is 2.60 currently, just checked yesterday. But if in fact the two 6th/7th gen cpu's have not changed, then that would mean that Intel is comfortable with the features their Quick Sync has and that they have no plans to further improve it. Their next branding is Canonlake, slated for 2017. I guess that will be their 8th Generation chips. I checked their ARK website but so far I have not seen anything listed there. They have a slew of 6th Gen cpu's (Skylakes) but their 7th Gen (Kabylake) is scares: m3-7Y30 // i3-7100U (my laptop) // i5-7Y54, i5-7200U // i7-7Y75, i7-7500U are all that are listed there. Why so few? Anyway. This probably explains why the two cpu types are the same. I searched around for any info, but it appears that API 1.19 is their highest and final version. No plans for upgrade or improvement. If their 8th gen, Canonlake turns out to be the same specs as 6th and 7th gen, I'm quitting Intel. Intel has a track record of being lacks-a-dazy in their belief that they are the best. I guess they feel they are better than AMD and NVidia, all-the-while, they are still improving their encoders while Intel sleeps inside their pride. Oh well. I'll continue posting my samples until I get tire or bore or hear the official bad (Intel) news about their quick sync features.

[easyfab]

With the latest beta driver (20.19.15.4568) for my braswell, I have now API 1.20 but no changes in features for AVC with qsvencc. I don't know is qsvencc must be updated to use what new in the api. I hope intel will make some changes when kabylake (7700k ...) will be out.

[vhelp]

Well, as a programmer myself, qvsencc would have to be updated to the newest api. I heard of no update greater than 1.19 so i will have a look. I do know that cpu's are capped. So, quiet sure no update for my i3-2370M (sandybridge) which is seared at 1.4 after many searches. It was originally 1.3 but no difference in features between those version for h264 encoding. I'll give a search for my kabylake and run a new { --check-features } in qsvencc and compare the features though I doubt they'll be any difference.

[coolaqua81]

This is a really nice thread!!!

I am quite a big fan of QS and am planning to rip my entire Bluray collection to x265 mkv's using Handbrake.

I currently have a Skylake system and wanted to check if there is any difference in the QS encode quality (for same bitrate/size) amongst Skylake and Kaby Lake. If there is a substantial difference in quality or speed then I'll plan to upgrade by Skylake system to Kabylake.

Possible to do a encode comparison for any suggested source file?? Plan to use same source file, same version of Handbrake with similar encode settings with the only difference being the processor.

I will be happy to provide Skylake versions of the x264 & x265 QS or normal CPU encodes for any source file that the group suggests with Handbrake 1.0.3 using any suggested profile. Can someone do the same with Kaby Lake?

Let me know if a encode comparison can be done...