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 12th August 2020, 22:00   #121  |  Link
Losko
Registered User
 
Join Date: Dec 2010
Posts: 65
Added a few tiny fixes, and now I can run avsresize filer as a dynamic library libavsresize.so with avs+ 3.6.1-git natively on my debian box.
I checked resize and color space conversion, everything seems to be fine.

Code:
how to build:
g++ -Wall -Wextra -O2 -std=c++17 -fPIC -c -o avsresize.o avsresize.cpp
g++ -s -shared -o libavsresize.so avsresize.o -lzimg

===============================================================================
--- avsresize.orig.cpp	2020-04-23 19:48:21.000000000 +0200
+++ avsresize.cpp	2020-08-11 21:22:33.716137465 +0200
@@ -9,7 +9,22 @@
 #include <regex>
 #include <string>
 #include <malloc.h>
+#ifdef _WIN32
 #include "avisynth.h"
+#else
+#include <avisynth/avisynth.h>
+#define _aligned_free      free
+#define __int64         int64_t
+/* gnu libc offers the equivalent 'aligned_alloc' BUT requested 'size'
+   has to be a multiple of 'alignment' - in case it isn't, I'll set
+   a different size, rounding up the value */
+#define _aligned_malloc(s,a) (     \
+    (s%a)?                         \
+    aligned_alloc(a,(s/a+1)*a)     \
+    :                              \
+    aligned_alloc(a,s)             \
+    )
+#endif
 #include "zimg++.hpp"
 
 namespace {
Losko is offline   Reply With Quote
Old 26th August 2020, 15:59   #122  |  Link
StvG
Registered User
 
Join Date: Jul 2018
Posts: 465
avsresize_r1f - added @Losko patch, zimg v3.0.1, added support for frame properties.
StvG is offline   Reply With Quote
Old 26th August 2020, 17:05   #123  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 4,852
Thank you!
hello_hello is offline   Reply With Quote
Old 26th August 2020, 18:17   #124  |  Link
kedautinh12
Registered User
 
Join Date: Jan 2018
Posts: 2,160
Thanks
kedautinh12 is offline   Reply With Quote
Old 2nd October 2020, 18:44   #125  |  Link
real.finder
Registered User
 
Join Date: Jan 2012
Location: Mesopotamia
Posts: 2,588
Quote:
Originally Posted by StvG View Post
avsresize_r1f - added @Losko patch, zimg v3.0.1, added support for frame properties.
pinterf said that frame properties are just copyied not really used https://github.com/AviSynth/AviSynth...ment-701993847
__________________
See My Avisynth Stuff

Last edited by real.finder; 2nd October 2020 at 18:56.
real.finder is offline   Reply With Quote
Old 3rd October 2020, 07:49   #126  |  Link
StvG
Registered User
 
Join Date: Jul 2018
Posts: 465
Quote:
Originally Posted by real.finder View Post
pinterf said that frame properties are just copyied not really used https://github.com/AviSynth/AviSynth...ment-701993847
I didn't mention anything specific than a general support (copying of frame properties).

avsresize_r1g - added parameter prefer_props; read and set _ChromaLocation, _ColorRange, _Matrix, _Transfer, _Primaries frame properties; added chromaloc_op parameters - bottom_left and bottom.
For more info check the included README.md.
StvG is offline   Reply With Quote
Old 6th October 2020, 18:27   #127  |  Link
real.finder
Registered User
 
Join Date: Jan 2012
Location: Mesopotamia
Posts: 2,588
Quote:
Originally Posted by StvG View Post
I didn't mention anything specific than a general support (copying of frame properties).

avsresize_r1g - added parameter prefer_props; read and set _ChromaLocation, _ColorRange, _Matrix, _Transfer, _Primaries frame properties; added chromaloc_op parameters - bottom_left and bottom.
For more info check the included README.md.
thanks, and I think there are no source call support frame properties yet, even ffms2 (it still use old global) except https://github.com/Asd-g/RawSource_2...53af08a4ccb7d3
__________________
See My Avisynth Stuff
real.finder is offline   Reply With Quote
Old 8th October 2020, 08:31   #128  |  Link
real.finder
Registered User
 
Join Date: Jan 2012
Location: Mesopotamia
Posts: 2,588
can we have "auto" in colorspace_op input and "same" in output?

colorspace_op="auto:auto:auto:auto=>same:same:same:f"

the "auto" see if there are frame properties first and if there are no frame properties for the parameter it will use presupposed value based on video informations like resolution and fps

and "same" will use the input value
__________________
See My Avisynth Stuff
real.finder is offline   Reply With Quote
Old 9th October 2020, 10:41   #129  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 2,322
Quote:
Originally Posted by StvG View Post
I didn't mention anything specific than a general support (copying of frame properties).

avsresize_r1g - added parameter prefer_props; read and set _ChromaLocation, _ColorRange, _Matrix, _Transfer, _Primaries frame properties; added chromaloc_op parameters - bottom_left and bottom.
For more info check the included README.md.
Great news, thanks!
pinterf is offline   Reply With Quote
Old 13th October 2020, 18:57   #130  |  Link
StvG
Registered User
 
Join Date: Jul 2018
Posts: 465
Quote:
Originally Posted by real.finder View Post
can we have "auto" in colorspace_op input and "same" in output?

colorspace_op="auto:auto:auto:auto=>same:same:same:f"

the "auto" see if there are frame properties first and if there are no frame properties for the parameter it will use presupposed value based on video informations like resolution and fps

and "same" will use the input value
"auto" is unnecessary. Any source value with "same" destination would lead to no conversion.
StvG is offline   Reply With Quote
Old 14th October 2020, 01:48   #131  |  Link
real.finder
Registered User
 
Join Date: Jan 2012
Location: Mesopotamia
Posts: 2,588
but "auto" make things easier for user
__________________
See My Avisynth Stuff
real.finder is offline   Reply With Quote
Old 14th October 2020, 18:39   #132  |  Link
StvG
Registered User
 
Join Date: Jul 2018
Posts: 465
avsresize_r2 - added keyword 'same' for destination matrix, transfer, primaries, range, chromaloc_op.
When it's used the source value (argument or frame property) is used for destination too.
StvG is offline   Reply With Quote
Old 15th October 2020, 03:15   #133  |  Link
real.finder
Registered User
 
Join Date: Jan 2012
Location: Mesopotamia
Posts: 2,588
Quote:
Originally Posted by StvG View Post
avsresize_r2 - added keyword 'same' for destination matrix, transfer, primaries, range, chromaloc_op.
When it's used the source value (argument or frame property) is used for destination too.
thanks, so since auto not added, I think prefer_props need to be set to true so user can set something like this

colorspace_op="709:709:709=>709:709:709", prefer_props=true

and since prefer_props=true the it will use the frame properties and ignore the input 709:709:709=>

right?
__________________
See My Avisynth Stuff
real.finder is offline   Reply With Quote
Old 15th October 2020, 05:32   #134  |  Link
StvG
Registered User
 
Join Date: Jul 2018
Posts: 465
Sorry for avsresize_r2. I was negligent.

avsresize_r3: - removed parameter prefer_props;
- added keyword "auto" for source matrix, transfer, primaries, range. When it's used the corresponding input frame properties are used, if such frame properties don't exist either an error is raised or default matrix and color range are used;
- added keyword "auto" for source chromaloc_op. When it's used the corresponding input frame property is used, if such frame property doesn't exist default chromaloc is used.

If colorspace_op is not defined and there are frame properties, they are used for default source values.
If colorspace_op is not defined and there are no frame properties or they are not supported, default values are used as before (there are default values for matrix, range and chromaloc).
If colorspace_op is defined and you want to use the frame property for a source value, use "auto".
If colorspace_op is defined and you use "auto" without frame property, the default value for that argument will be used if exist.
If you use "auto" for argument with frame property that has value of 2 (unspec) and use anything different than "same" for destination, error will be raised.
If you use "auto=>same" for matrix/transfer/primaries with frame property 2 (unspec) and you want to make colorspace conversion, error will be raised. For example:
Code:
#transfer property has value of 2
#primaries 709 (1)
#input yv12
z_convertformat(pixel_type="rgbp", colorspace_op="auto:auto:709=>rgb:same:470bg") # error raised
#z_convertformat(pixel_type="rgbp", colorspace_op="auto:709:709=>rgb:709:470bg") # ok
#z_convertformat(pixel_type="rgbp", colorspace_op="auto:709:auto=>rgb:same:470bg") # ok
#z_ConvertFormat(colorspace_op="auto:auto=>same:470bg") # error
#z_ConvertFormat(colorspace_op="auto:auto:auto:auto=>same:same:same:f") # ok

Last edited by StvG; 15th October 2020 at 05:49. Reason: More examples.
StvG is offline   Reply With Quote
Old 15th October 2020, 07:18   #135  |  Link
real.finder
Registered User
 
Join Date: Jan 2012
Location: Mesopotamia
Posts: 2,588
thanks! the changes seems ok, and I will test and see
__________________
See My Avisynth Stuff
real.finder is offline   Reply With Quote
Old 15th October 2020, 09:06   #136  |  Link
zambelli
Doom9ing since 2001
 
zambelli's Avatar
 
Join Date: Oct 2001
Location: Seattle, WA, USA
Posts: 2,002
I was thinking it would be helpful to simplify the current list of enum values for matrix/transfer/primaries by indicating in the documentation that certain standards actually use the same matrix/transfer/primaries values.

For example:
  • Matrix coefficients: "470bg", "170m" and "601" use identical coefficients (and "fcc" isn't too far off either)
  • Matrix coefficients: "2020ncl", "2020cl" and "2020" use identical coefficients
  • Transfer characteristics: "709", "601", "2020_10", "2020_12" and "2020" use the same transfer function
  • Transfer characteristics: In order to match FFmpeg Zscale values it'd be nice to add "170m" as alias for "601"
  • Color primaries: "170m" and "240m" use identical primaries (also, it's strange that the standard is called "240m" here but called "240" under matrix coefficients)
  • Color primaries: "709" and "470bg" aren't identical, but they are VERY close, which is useful to know when dealing with PAL video

The reason I mention it is because it's easy for someone to lose a lot of time sweating over the details of whether an old video capture is ST 170M or BT.601, only to realize after many hours of research that they're essentially the same thing.
zambelli is offline   Reply With Quote
Old 15th October 2020, 12:13   #137  |  Link
real.finder
Registered User
 
Join Date: Jan 2012
Location: Mesopotamia
Posts: 2,588
StvG, what about interlaced parameter and frame properties?
__________________
See My Avisynth Stuff
real.finder is offline   Reply With Quote
Old 18th October 2020, 10:11   #138  |  Link
StvG
Registered User
 
Join Date: Jul 2018
Posts: 465
@zambelli, I will add comments.
@real.finder, currently video with frame property _FieldBased = 1/2 is processed but it shouldn't be. I'll change that later.
StvG is offline   Reply With Quote
Old 18th October 2020, 16:59   #139  |  Link
mp3dom
Registered User
 
Join Date: Jul 2003
Location: Italy
Posts: 1,135
Just asking, but does R3 works fine for everyone? I'm converting a 1920x1080 4:2:2 10bit clip from 709 to 601 and I get a system exception (without any additional infos) on x64 while on x86 Vdub2 crash and close without any warning. The same script works with R1g.
mp3dom is offline   Reply With Quote
Old 18th October 2020, 20:58   #140  |  Link
zambelli
Doom9ing since 2001
 
zambelli's Avatar
 
Join Date: Oct 2001
Location: Seattle, WA, USA
Posts: 2,002
Quote:
Originally Posted by StvG View Post
@zambelli, I will add comments.
Thanks!

One more documentation suggestion: I think the current definition of nominal_luminance could also benefit from some clarification. It says, "Nominal peak luminance in cd/m^2 when converting HDR content to RGB Linear". However, I don't think HDR conversion is the only scenario in which this parameter can be used. To the best of my understanding, what nominal_luminance really does is determine the scale of conversion between linear and non-linear transfer functions. It defines which luminance value (in cd/m^2) in a non-linear colorspace should be mapped to 1.0 in the floating point linear RGB colorspace, regardless of whether one is converting to or from linear RGB. For example, if I am converting from HLG ("std-b67") to linear RGB and want to capture the full BT.2100 HLG range (0-1000 nits) in 0.0-1.0 linear RGB, I'd set the nominal_luminance value to 1000. Does that sound right, or is my own understanding of the parameter incorrect?

Thank you for bringing this great plugin to AviSynth - it's much appreciated!
zambelli 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 18:35.


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