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.

 

Go Back   Doom9's Forum > Capturing and Editing Video > Avisynth Development

Reply
 
Thread Tools Search this Thread Display Modes
Old 25th January 2022, 23:31   #201  |  Link
StvG
Registered User
 
Join Date: Jul 2018
Posts: 301
Quote:
Originally Posted by Boulder View Post
If the process chain is denoise -> downscale -> deband, is it better to leave dithering out of the downscaling phase, since debanding also does some sort of dithering (f.ex. f3kdb)?
It depends. If your source is 10-bit (it will be valid for any bit depth < 16-bit):
a) if denoise in source bit depth (10-bit), downscale w/o bit depth change (10-bit->16-bit->10-bit - how internally avsresize will scale), deband w/o bit depth change (assume f3kdb: 10->16-bit->10-bit - how internally f3kdb will deband)
b) convert to 16-bit, denoise, downscale, deband, convert to source bit depth (10-bit)

For a) it's better to apply dither after the downscaling.
For b) 16-bit->10-bit is done only once at the end - dither.

If the speed penalty of b) isn't the bottleneck, it should be always the preferred option imo.
StvG is offline   Reply With Quote
Old 26th January 2022, 06:05   #202  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Finland
Posts: 5,429
Quote:
Originally Posted by StvG View Post
It depends. If your source is 10-bit (it will be valid for any bit depth < 16-bit):
a) if denoise in source bit depth (10-bit), downscale w/o bit depth change (10-bit->16-bit->10-bit - how internally avsresize will scale), deband w/o bit depth change (assume f3kdb: 10->16-bit->10-bit - how internally f3kdb will deband)
b) convert to 16-bit, denoise, downscale, deband, convert to source bit depth (10-bit)

For a) it's better to apply dither after the downscaling.
For b) 16-bit->10-bit is done only once at the end - dither.

If the speed penalty of b) isn't the bottleneck, it should be always the preferred option imo.
For 8- or 10-bit sources, I do the denoising part in 16 bits. Then that is fed to the downscaling part, where it's converted to linear RGBPS, downscaled and converted to YUV420P16. Then debanding without any bitdepth change, fed to the encoder (x265) as 16-bit and the internal dithering is enabled to get the final 10-bit output. So based on your answer, I think it's best that dithering is disabled wherever possible and allow it only at the encoder phase.

By the way, what is the difference between converting the format and resizing in the same z_ConvertFormat call and doing it in two different calls (resizing first, then converting to the final format)? I tested it yesterday and there seems to be a rather noticable performance drop if you use two calls.
__________________
And if the band you're in starts playing different tunes
I'll see you on the dark side of the Moon...
Boulder is offline   Reply With Quote
Old 26th January 2022, 10:20   #203  |  Link
FranceBB
Broadcast Encoder
 
FranceBB's Avatar
 
Join Date: Nov 2013
Location: Metropolitan City of Milan, Italy
Posts: 2,273
Quote:
Originally Posted by Boulder View Post
[...] fed to the encoder (x265) as 16-bit and the internal dithering is enabled to get the final 10-bit output.
I do exactly the same.
No matter if the source is 8bit, 10bit or 12bit planar, I always bring everything to 16bit planar, filter everything out and feed the encoder with the 16bit input.

My outputs are always 10bit, so x264 will dither it down using the Sierra-2-4A algorithm, while x265 will use... something else.

Speaking of which, what will x265 use with --dither? I mean, which algorithm?
I know we've been having this conversation before but I forgot xD
FranceBB is offline   Reply With Quote
Old 26th January 2022, 10:51   #204  |  Link
Reel.Deel
Registered User
 
Join Date: Mar 2012
Location: Texas
Posts: 1,453
I try to do everything in one go (if possible). Sometimes doing 2 steps can be detrimental. For example, I saw this script in another thread:

Quote:
Originally Posted by ErazorTT View Post
Code:
LWLibavVideoSource("video.uhd.rmx.mkv",cachefile="video.lwi",format="YUV420P16",decoder="hevc_qsv",prefer_hw=2) # hw

# (avsresize.dll)
z_Spline36Resize(1920,1080) # FHD

# Converting format (avsresize.dll)
z_ConvertFormat(pixel_type="RGBP16",colorspace_op="2020:st2084:2020:l=>rgb:st2084:2020:f",dither_type="none")

# Apply LUT (vscube.dll)  input full / output full  HLG
Cube("hlg-tools65.cube",fullrange=true) # max-cll 1000

# Converting format (avsresize.dll)
z_ConvertFormat(pixel_type="YUV420P16",colorspace_op="rgb:std-b67:2020:f=>2020ncl:std-b67:2020:l",dither_type="error_diffusion")
The source is 4k and it's getting resized down to 1920x1080 YUV420 and then converted to RGB16. Here the chroma is going from 1920x1080 down to 960x540 and then scaled back up to 1080p when converted to RGB. Sure, after applying the LUT it is converted back to YUV420 and the chroma size is back again down to 960x540. Most wont even be able to tell the difference but it still does unnecessary processing. source.z_ConvertFormat(1920,1080, pixel_type="RGBP16",...) would be higher fidelity. At least that is how dither works when you resize and change format at the same time. In this scenario you can even go from UHD YUV4:2:0 down to FHD YUV4:4:4 without even resizing the chroma planes. Provided that the luma channel gets independently resized with src_left=-0.50, src_top=-0.50 to account for the chroma placement shift (top left in this case, assuming source is uhd bluray). After that, merge the luma with the original chroma planes, convert to RGB and proceed .

Edit: re-reading the last few post, seems my comment is somewhat not related to the discussion. But, I'll leave it here since it's still relevant to the thread. I should be asleep lol.

Last edited by Reel.Deel; 26th January 2022 at 11:03. Reason: Wrong quote
Reel.Deel is offline   Reply With Quote
Old 26th January 2022, 11:35   #205  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Finland
Posts: 5,429
Quote:
Originally Posted by FranceBB View Post
I do exactly the same.
No matter if the source is 8bit, 10bit or 12bit planar, I always bring everything to 16bit planar, filter everything out and feed the encoder with the 16bit input.

My outputs are always 10bit, so x264 will dither it down using the Sierra-2-4A algorithm, while x265 will use... something else.

Speaking of which, what will x265 use with --dither? I mean, which algorithm?
I know we've been having this conversation before but I forgot xD
From api.cpp: "The dithering algorithm is based on Sierra-2-4A error diffusion." It's probably identical to x264, why re-invent the wheel since they ported other stuff as well.
__________________
And if the band you're in starts playing different tunes
I'll see you on the dark side of the Moon...
Boulder is offline   Reply With Quote
Old 27th January 2022, 01:51   #206  |  Link
StvG
Registered User
 
Join Date: Jul 2018
Posts: 301
Quote:
Originally Posted by Boulder View Post
By the way, what is the difference between converting the format and resizing in the same z_ConvertFormat call and doing it in two different calls (resizing first, then converting to the final format)? I tested it yesterday and there seems to be a rather noticable performance drop if you use two calls.
If you mean something like this:
Code:
z_ConvertFormat(pixel_type="rgbps", colorspace_op="709:709:709:l=>rgb:linear:709:f", chromaloc_op="left=>left")
z_BicubicResize(x, y)
z_ConvertFormat(pixel_type="yuv420p16", colorspace_op="rgb:linear:709:f=>709:709:709:l", chromaloc_op="left=>left")
Code:
z_ConvertFormat(pixel_type="rgbps", colorspace_op="709:709:709:l=>rgb:linear:709:f", chromaloc_op="left=>left")
z_ConvertFormat(x, y, pixel_type="yuv420p16", colorspace_op="rgb:linear:709:f=>709:709:709:l", chromaloc_op="left=>left")
These variants give identical results. The first one have some overhead that could have some penalty for the final speed. My quick test shows ~7% difference. If frame properties are involved I would say there is no speed difference.
StvG is offline   Reply With Quote
Old 15th April 2022, 04:52   #207  |  Link
StvG
Registered User
 
Join Date: Jul 2018
Posts: 301
avsresize_r13 (pass: f0MNKlTxVxl5):
- zimg@dd4c4df;
- use_props= -1: If frame properties are supported - if every option of colorspace_op and chromaloc_op (for src/dst colorspace with subsampling w/h > 0) are specified and different than "auto", 0, otherwise 1.
StvG is offline   Reply With Quote
Old 15th April 2022, 08:29   #208  |  Link
FranceBB
Broadcast Encoder
 
FranceBB's Avatar
 
Join Date: Nov 2013
Location: Metropolitan City of Milan, Italy
Posts: 2,273
Quote:
Originally Posted by StvG View Post
ffms2_6ad7738 (pass: u7Uezbh3fTHM):
- ffms2@90975ec;
- ffmpeg n5.1@1764a6887b;
- zlib 1.2.12;
- dav1d 1.0.0;
- AviSynth: set Dolby Vision RPU data in frame props.
Thanks, works perfectly on Windows 11 x64 and Windows Server 2019 x64.

Quote:
FFMpegSource2("\\mibctvan000.avid.mi.bc.sky.it\Ingest\MEDIA\temp\test_PCM_DolbyE_PCM_PCM.mxf", atrack=-1)

propClearAll()

#From 4:2:0 16bit planar Narrow Range to RGB Planar 16bit Full Range
z_ConvertFormat(pixel_type="RGBP16", colorspace_op="709:709:709:limited=>rgb:709:709:full", dither_type="error_diffusion")

#From BT709 SDR to BT2020 HDR HLG with 16bit precision
Cube("C:\Program Files (x86)\AviSynth+\LUTs\5a_BT709_HLG_UPCONVERT_DISPLAY_mode-nar_in-nar_out-nar_nocomp.cube", fullrange=true)

#From RGB 16bit planar Full Range to YUV422 10bit planar Narrow Range with dithering
z_ConvertFormat(pixel_type="YUV422P10", colorspace_op="rgb:std-b67:2020:full=>2020:std-b67:2020:limited", resample_filter_uv="spline64", dither_type="error_diffusion")

to deliver a cool nice 75% ref white HLG output.



Cheers,
Frank
FranceBB is offline   Reply With Quote
Old 18th April 2022, 15:44   #209  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Finland
Posts: 5,429
Using props=4 causes an access violation on my system. Tested with this:

z_ConvertFormat(pixel_type="RGBPS", chromaloc_op="auto=>same", colorspace_op="auto:auto:auto:auto=>rgb:linear:same:full", approximate_gamma=true, cpu_type="AVX2", use_props=3)
z_ConvertFormat(pixel_type="YUV420P16", chromaloc_op="auto=>same", resample_filter="Bicubic", resample_filter_uv="Bicubic", filter_param_a=0, filter_param_b=0.6, width=960, height=720, cpu_type="AVX2", dither_type="none", approximate_gamma=true, use_props=4)
__________________
And if the band you're in starts playing different tunes
I'll see you on the dark side of the Moon...
Boulder is offline   Reply With Quote
Old 19th April 2022, 06:00   #210  |  Link
StvG
Registered User
 
Join Date: Jul 2018
Posts: 301
avsresize_r14 (pass: QOvyNpMf5TyF) - fixed regression (r12) when reading frame properties (use_props=3/4).
StvG is offline   Reply With Quote
Old 19th April 2022, 07:10   #211  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Finland
Posts: 5,429
Quote:
Originally Posted by StvG View Post
avsresize_r14 (pass: QOvyNpMf5TyF) - fixed regression (r12) when reading frame properties (use_props=3/4).
Still the same problem with this one.
__________________
And if the band you're in starts playing different tunes
I'll see you on the dark side of the Moon...
Boulder is offline   Reply With Quote
Old 19th April 2022, 12:25   #212  |  Link
StvG
Registered User
 
Join Date: Jul 2018
Posts: 301
Quote:
Originally Posted by Boulder View Post
Still the same problem with this one.
Download again the r14. You will see error that chromaloc_op (colospace_op too) must be not specified when use_props=4.
StvG is offline   Reply With Quote
Old 19th April 2022, 14:40   #213  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Finland
Posts: 5,429
Quote:
Originally Posted by StvG View Post
Download again the r14. You will see error that chromaloc_op (colospace_op too) must be not specified when use_props=4.
Thanks, works now
__________________
And if the band you're in starts playing different tunes
I'll see you on the dark side of the Moon...
Boulder is offline   Reply With Quote
Old 6th July 2022, 01:26   #214  |  Link
Stephen R. Savage
Registered User
 
Stephen R. Savage's Avatar
 
Join Date: Nov 2009
Posts: 344
Released r2:
  • Update to z.lib 3.0
  • Enable 64-byte alignment
  • Support real Spline64Resize
  • Support alpha-aware resizing
  • Implement multi-threading

Last edited by Stephen R. Savage; 7th July 2022 at 15:59.
Stephen R. Savage is offline   Reply With Quote
Old 6th July 2022, 04:44   #215  |  Link
kedautinh12
Registered User
 
Join Date: Jan 2018
Posts: 1,271
Hmm, 2 version?
kedautinh12 is offline   Reply With Quote
Old 6th July 2022, 13:12   #216  |  Link
FranceBB
Broadcast Encoder
 
FranceBB's Avatar
 
Join Date: Nov 2013
Location: Metropolitan City of Milan, Italy
Posts: 2,273
What do you mean by "real" Spline64Resize?
FranceBB is offline   Reply With Quote
Old 6th July 2022, 14:34   #217  |  Link
Reel.Deel
Registered User
 
Join Date: Mar 2012
Location: Texas
Posts: 1,453
Quote:
Originally Posted by FranceBB View Post
What do you mean by "real" Spline64Resize?
Up until 2 years ago or so, Spline64Resize was just an alias for Spline32Resize. z.lib added the spline64 filter in v2.9.3.
Reel.Deel is offline   Reply With Quote
Old 6th July 2022, 14:41   #218  |  Link
tormento
Acid fr0g
 
tormento's Avatar
 
Join Date: May 2002
Location: Italy
Posts: 2,243
Quote:
Originally Posted by kedautinh12 View Post
Hmm, 2 version?
First number major buiid, second number minor release?
__________________
@turment on Telegram
tormento is offline   Reply With Quote
Old 6th July 2022, 15:18   #219  |  Link
Reel.Deel
Registered User
 
Join Date: Mar 2012
Location: Texas
Posts: 1,453
Quote:
Originally Posted by tormento View Post
First number major buiid, second number minor release?
Stephen R. Savage is the original author of avsresize (and z.lib). He released the first version of avsresize (r1) back in 2016 and then some periodic updates. The last update was r1d in March of 2018. StvG then continued updating the plugin ever since, up to r14 now.
Reel.Deel is offline   Reply With Quote
Old 6th July 2022, 16:07   #220  |  Link
kedautinh12
Registered User
 
Join Date: Jan 2018
Posts: 1,271
Quote:
Originally Posted by Reel.Deel View Post
Stephen R. Savage is the original author of avsresize (and z.lib). He released the first version of avsresize (r1) back in 2016 and then some periodic updates. The last update was r1d in March of 2018. StvG then continued updating the plugin ever since, up to r14 now.
And r2 is continued update of r14??
kedautinh12 is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 12:27.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2022, vBulletin Solutions Inc.