StaxRip - Page 198

thomy21 · 24th February 2021, 18:02

Quote:

Originally Posted by JKyle

@thomy21,

Can you try the hotfix StaxRip.exe in @stax76's Beta archive and see if it resolves your issue?
It seems to be working alright for me.

Thanks, it works now.

44vince44 · 24th February 2021, 18:09

I don't understand what you think is wrong in the crop window @Atlantis. The "active" border is highlighted in a very visible way...

stax76 · 24th February 2021, 19:48

Quote:

Originally Posted by JKyle

BTW, TIVTC is updated to 1.0.26.

Will be updated.

ukmark · 24th February 2021, 19:55

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.

DavidRyan · 24th February 2021, 20:35

Quote:

Originally Posted by 44vince44

Can you please provide any experience/knowledge with that.
If you use the SMDegrain Light grain or SMDegrain hard grain, and add inside it the parameter "Contrasharp=true" it will fail, but NOT if you add "Contrasharp = 30" or any number. The difference is that with "Contrasharp=true", RGTools is called, whereas with "Contrasharp=number" LSFMod is called.

Then, browsing in the forums, I don't think I saw a single recent example with Contrasharp=True. Although the official docs give many examples with Constrasharp=True, the discussions in the forums display Contrasharp=false.

This is why, Contrasharp=True was removed.
This is a tool issue. If anyone has reliable information about it, please share it with us.

Thanks for the response. The only thing I had seen was a reference to contrasharp=true failing with higher bit depth sources due to medianblur2 not being updated to handle them (eg: https://forum.doom9.org/showthread.p...17#post1845417 ) , but medianblur2 was updated in mid-2020 to handle HBD ( http://avisynth.nl/index.php/MedianBlur2 ) so I guess that would no longer be an issue if staxrip includes the newer version?

So will also be interested if anyone has anything further on this.

JKyle · 24th February 2021, 20:56

Quote:

Originally Posted by DavidRyan

...medianblur2 was updated in mid-2020 to handle HBD ( http://avisynth.nl/index.php/MedianBlur2 )...

As a matter of fact, MedianBlur2 is updated to 1.1 about a month ago.

Thank you for the info.
Let's see if this update changes the game.

JKyle · 24th February 2021, 21:55

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

44vince44 · 25th February 2021, 02:27

Thanks @DavidRyan and @JKyle. Great find !! So do you prefer the presets to include Contrasharp = True ?

JKyle · 25th February 2021, 02:39

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.

44vince44 · 25th February 2021, 02:41

Ok so as soon as I see the Medianblur2 update commit, I'll add it to the profiles!

Magik Mark · 25th February 2021, 04:34

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

DavidRyan · 25th February 2021, 08:27

Quote:

Originally Posted by JKyle

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.

Quote:

Originally Posted by 44vince44

Ok so as soon as I see the Medianblur2 update commit, I'll add it to the profiles!

Thanks for looking into it

44vince44 · 25th February 2021, 10:54

You're welcome. Thanks to you and to JJKyle !
@Stax76 has updated Mediablur2, and I've updated the filter profiles. You'll see it in next beta hopefully!

tormento · 25th February 2021, 11:57

Quote:

Originally Posted by JKyle

2. Converted an 8-bit source to 10 bits

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

44vince44 · 25th February 2021, 17:32

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

JKyle · 25th February 2021, 18:17

@tormento,

Thanks for the info, but I was just testing if `contrasharp=true` option was working in a high bit depth situation.

@44vince44,

The answer is in the GitHub issue tracker.

44vince44 · 25th February 2021, 18:29

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.

JKyle · 26th February 2021, 08:16

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.

stax76 · 26th February 2021, 11:37

I currently try to fix it.

JKyle · 26th February 2021, 21:51

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:

"All custom video encoder profiles and video encoder parameter settings in custom templates are reset in the version.
Please back up your custom settings before update."

And in the meantime, if you are one of those who want to use the hotfix StaxRip.exe in @stax76's beta archive (as of now), don't forget to back up your custom settings before overwriting the StaxRip.exe file.

---

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

24th February 2021, 19:55	#3944 \| Link
ukmark 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.

25th February 2021, 04:34	#3951 \| Link
Magik Mark 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, 17:32	#3955 \| Link
44vince44 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
44vince44 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, 11:37	#3959 \| Link
stax76 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.

24th February 2021, 18:09	#3942 \| Link
44vince44 Registered User Join Date: May 2020 Posts: 188	I don't understand what you think is wrong in the crop window @Atlantis. The "active" border is highlighted in a very visible way...

25th February 2021, 02:27	#3948 \| Link
44vince44 Registered User Join Date: May 2020 Posts: 188	Thanks @DavidRyan and @JKyle. Great find !! So do you prefer the presets to include Contrasharp = True ?

25th February 2021, 02:39	#3949 \| Link
JKyle 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, 02:41	#3950 \| Link
44vince44 Registered User Join Date: May 2020 Posts: 188	Ok so as soon as I see the Medianblur2 update commit, I'll add it to the profiles!

25th February 2021, 10:54	#3953 \| Link
44vince44 Registered User Join Date: May 2020 Posts: 188	You're welcome. Thanks to you and to JJKyle ! @Stax76 has updated Mediablur2, and I've updated the filter profiles. You'll see it in next beta hopefully!

25th February 2021, 18:17	#3956 \| Link
JKyle App Digger Join Date: Sep 2018 Posts: 411	@tormento, Thanks for the info, but I was just testing if `contrasharp=true` option was working in a high bit depth situation. @44vince44, The answer is in the GitHub issue tracker.

26th February 2021, 08:16	#3958 \| Link
JKyle 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.

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode