Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
24th February 2021, 19:48 | #3943 | Link | |
Registered User
Join Date: Jun 2002
Location: On thin ice
Posts: 6,837
|
Quote:
__________________
https://github.com/stax76/software-list https://www.youtube.com/@stax76/playlists |
|
24th February 2021, 19:55 | #3944 | Link |
Registered User
Join Date: Oct 2018
Posts: 33
|
Ice Lake QuickSync update
Not specifically StaxRip related, but I do use StaxRip for encoding using Intel's QuickSync.
I have been using an Ice Lake laptop (i7-1065G7) for about a year now and wanted to provide an update. I've re-encoded quite a few of my blu rays (ripping with MakeMKV), and here are my observations. 1. "Fixed-function" CQP encode using HEVC 10-bit is superb. The quality I get with this method is very close to the original. There may be the odd frame here and there where there may be very slight differences in the really fine facial details, but these are few and far between and to my eyes, the differences are difficult to spot and are completely unnoticeable during normal viewing. 2.This method is also very fast - I normally get from 240fps to 340fps (source material dependent) when re-encoding to 1080p from blu ray source. If downscaling to 720p, the speeds can get up to 600fps!! 3. CQP fixed-function file sizes are very reasonable. I generally compare file sizes with the CQP fixed-function method to x265 10-bit CRF 24 encodes. The CQP encodes are usually 5-15% bigger. To me, this is very acceptable - for example a CQP 2.2gb file vs 2gb file with x265 etc. Differences are non-existent during normal viewing. 4. I use the following settings (using QSV hardware as decoder gives a big speed boost and also keeps CPU usage low):- --avhw --codec hevc --quality best --profile main10 --open-gop --async-depth 4 --fixed-func --cqp 36:36:36 --qp-offset 2:6:8 --output-res 1920x1080 Sometimes I might lower the cqp i,p,b settings to 35 or 34 if I want a little more quality, but I have found these settings give excellent quality with very reasonable file sizes. Apparently, with Tiger Lake CPU, you can also use b-frames and b-pyramid with CQP fixed-function mode to get even better quality at the same file size (or same quality at lower file sizes). With Ice Lake, b-frames and b-pyramid are disabled for fixed-function, but are available when encoding using GPU execution units - i.e. turn fixed-function off in the settings. I find that I can get approx. the same file size as fixed-function CQP 36 by using CQP 33 or 34 with 16 b-frames and b-pyramid on. However, the encode speed is about 6 times slower. 5. ICQ (Intelligent Constant Quality) mode is kind of broken for 10-bit HEVC. Fixed-function ICQ does work, but the file sizes tend to be 30-50% higher than CQP with no noticeable improvement in quality. Also, changing the ICQ "quality" has no effect (with CQP, changing quality does affect quality and size). 6. CPU usage is very low compared to x265 (always at 100% usage). Actually when using the GPU EU to encode (6x slower than fixed-function, but still getting 45-60fps for 1080p encodes), my CPU drops to 3 or 4% usage!! Crazy but true. When using fixed-function, it can range from 15-40%, but the encode is about 6x faster than using GPU EU and about 12x faster than x265. You can get a faster speed using GPU EU by setting the quality to "balanced" (the default), from "best". This will raise the CPU usage to around 15%, increase the speed by around 3x to approx 150fps and also increase the file size by around 5-10%. Changing quality to balanced from best also works with fixed-function encoding and increases speed by approx a further 50% (say from around 300fps to 450fps), with the same 5-10% increase in file size. Video quality is identical between best and balanced, but balanced has the 5-10% higher bitrate to compensate for increased encoding speed. I'm really impressed with QuickSync HEVC 10-bit encoding and no longer use x265. My one caveat is this. I have found that if your source is "low" quality, like a low bit-rate file, then x265 yields significantly better results, but with blu rays, I can't see any purpose in using x265. Last edited by ukmark; 24th February 2021 at 23:09. |
24th February 2021, 20:35 | #3945 | Link | |
Registered User
Join Date: Nov 2019
Posts: 25
|
Quote:
So will also be interested if anyone has anything further on this. |
|
24th February 2021, 20:56 | #3946 | Link | |
App Digger
Join Date: Sep 2018
Posts: 411
|
Quote:
Thank you for the info. Let's see if this update changes the game. |
|
24th February 2021, 21:55 | #3947 | Link |
App Digger
Join Date: Sep 2018
Posts: 411
|
@DavidRyan is right.
1. I updated MedianBlur2 to the most recent version. 2. Converted an 8-bit source to 10 bits. 3. Added Contrasharp=true option and force loaded MedianBlur2.dll right before SMDegrain as follows: So the script code is as follows: Code:
LoadPlugin("D:\Utilities\StaxRip\Apps\Plugins\AVS\DFTTest\dfttest.dll") Import("D:\Utilities\StaxRip\Apps\Plugins\AVS\Dither\dither.avsi") LoadPlugin("D:\Utilities\StaxRip\Apps\Plugins\AVS\Dither\dither.dll") Import("D:\Utilities\StaxRip\Apps\Plugins\AVS\NNEDI3\edi_rpow2.avsi") Import("D:\Utilities\StaxRip\Apps\Plugins\AVS\LSFmod\LSFmod.avsi") LoadPlugin("D:\Utilities\StaxRip\Apps\Plugins\AVS\masktools2\masktools2.dll") LoadPlugin("D:\Utilities\StaxRip\Apps\Plugins\AVS\mvtools2\mvtools2.dll") LoadPlugin("D:\Utilities\StaxRip\Apps\Plugins\AVS\RgTools\RgTools.dll") Import("D:\Utilities\StaxRip\Apps\Plugins\AVS\Zs_RF_Shared\Zs_RF_Shared.avsi") Import("D:\Utilities\StaxRip\Apps\Plugins\AVS\SMDegrain\SMDegrain.avsi") LoadPlugin("D:\Utilities\StaxRip\Settings\Plugins\Dual\DGDecNV\DGDecodeNV.dll") DGSource("D:\Work\tmp\tst\test_1-audio-track_temp\test_1-audio-track.dgi", deinterlace=0, fieldop=0) ConvertBits(10) LoadPlugin("D:\Utilities\StaxRip\Apps\Plugins\AVS\MedianBlur2\MedianBlur2.dll") SMDegrain(tr=2, thSAD=250, Contrasharp=true) 4. And I see no errors. Here's the Preview window: --- So @stax76, updating MedianBlur2 and loading MedianBlur2.dll when SMDegrain is used seems to help solve the incompatibility issue with the Contrasharp=true option. |
25th February 2021, 02:39 | #3949 | Link |
App Digger
Join Date: Sep 2018
Posts: 411
|
I guess it's more desirable to leave contrasharp as an option so that users can make a choice themselves.
It doesn't matter whether it's false or true as long as MedianBlur2 is loaded. Let's think of it as a reminder or a placeholder. |
25th February 2021, 04:34 | #3951 | Link |
Registered User
Join Date: Dec 2014
Posts: 666
|
Guys,
Is there a formula or best practice when upscaling 2k bluray to 4k? I usually use 2pass VBR. I'm not sure how much bitrate to use. I don't want it to bloat or lose too much details. There must be an ideal solution. I also upscale the colorspace from 420 to 44416bit using z convert with dithering. Then downscale it to 4448bit when encoding thanks
__________________
Asus ProArt Z790 - 13th Gen Intel i9 - RTX 3080 - DDR5 64GB Predator - LG OLED C9 - Yamaha A3030 - Windows 11 x64 - PotPlayerr - Lav - MadVR |
25th February 2021, 08:27 | #3952 | Link | |
Registered User
Join Date: Nov 2019
Posts: 25
|
Quote:
|
|
25th February 2021, 11:57 | #3954 | Link |
Acid fr0g
Join Date: May 2002
Location: Italy
Posts: 2,582
|
There is almost no gain in speed to have SMDegrain working in 10 bits instead of 16. I suggest you to use
SMDegrain (whatever, n16_out=true) and then dither down in x265 (or whatever you use).
__________________
@turment on Telegram |
25th February 2021, 17:32 | #3955 | Link |
Registered User
Join Date: May 2020
Posts: 188
|
This is strange. Beta 2.1.8.4 is out with updated medianblur2 to latest version that @Jkyle has tested, yet the error is still there when using contrasharp=True
@JKyle: updating Medianblur2 does not FIX the contrasharp issue in SMDegrain :=( I tried to reproduce it in 2.1.8.3, and it didn't work. You must have done something else that you forget to mention maybe... In the mean time, I'm still insvestigating. Please do not update to 2.1.8.4 yet... Last edited by 44vince44; 25th February 2021 at 18:00. |
25th February 2021, 18:29 | #3957 | Link |
Registered User
Join Date: May 2020
Posts: 188
|
yes Thanks @Jkyle, I've read it. And I've provide proof to @Stax76 that the requirement is OFFICIAL. Because the docs do not mention it, but it is mentionned in the header of the SMDegrain avsi file. (see the issue tracker :-))
EDIT: this is being currently fixed by Stax76 :-) EDIT2: @Stax76 has commited the mods and released a hotfix. I've tested it, and it works, the SMDegrain issue has been finally addressed. Thanks @Stax76 and again @Jkyle and @DavidRyan. So please feel free to download beta 2.1.8.4 then to overwrite StaxRip.exe with the hotfix, from the same beta repository. Last edited by 44vince44; 25th February 2021 at 20:35. |
26th February 2021, 08:16 | #3958 | Link |
App Digger
Join Date: Sep 2018
Posts: 411
|
If you updated to 2.1.8.4 Beta and overwrote StaxRip.exe with the hotfix exe file in @stax76's beta archive, you need to check if --selective-sao 4 has sneaked into all your x265 profiles. It's what I'm experiencing now.
This is because the default value for --selective-sao has been corrected to 0 per @tkozybski's issue report, and it seems that somehow the wrong old default parameter setting has popped out and sneaked into the profile. But I don't know exactly why this kind of phenomenon happens. Some of you may remember the --rskip 0 happening a while ago (v2.1.3.8 Beta and above). Because of this unexpected parameter setting, many users experienced a significant performance loss and reported this as an issue. I guess the same mechanism worked at that time: the default value of --rskip was adjusted and the old value popped out and sneaked in. Maybe we need to study why this phenomenon happens. But in the meantime, remember that your parameter settings should always be checked out after an update without a reset. |
26th February 2021, 11:37 | #3959 | Link |
Registered User
Join Date: Jun 2002
Location: On thin ice
Posts: 6,837
|
I currently try to fix it.
__________________
https://github.com/stax76/software-list https://www.youtube.com/@stax76/playlists Last edited by stax76; 26th February 2021 at 14:56. |
26th February 2021, 21:51 | #3960 | Link | |
App Digger
Join Date: Sep 2018
Posts: 411
|
While trying to see if issue #548 is fixed, I've found that all my custom video encoder profiles are lost and reset to the factory settings with the hotfix StaxRip.exe. This is also true of the video encoder settings in my custom templates.
I believe this happens because of the fix of issue #546. I can reconstruct my custom video encoder profiles and templates, but I guess most users will be embarrassed if they encounter this situation without prior info. So I strongly believe that the next version, 2.1.8.5 Beta, should come with this warning: Quote:
--- [UPDATE] I see that custom video encoder profiles are saved as the submenus in Backup category. So you just need to restore your custom templates. Last edited by JKyle; 26th February 2021 at 22:23. |
|
|
|