AviSynth+ thread Vol.2

[DTL]

Recommended edits for https://avisynthplus.readthedocs.io/...ddborders.html :

Param name "string "resample"": Typically resample means changing of samples count. Here we have only changed samples values by filtering. It also looks like some 'resampling' though. Maybe it is better to name the param 'filter' or '(filter_)kernel'.

Current text: "When r radius is not zero, then determines which resampler is used in the transient filtering. All AviSynth resizers are allowed: ("point", "bilinear", "bicubic", "lanczos", "lanczos4", "blackman", "spline16", "spline36", "spline64", "gauss" and "sinc", "sinpow", "sinclin2" and "userdefined2")."

Recommended text: When r radius is not zero, then determines which resampler' kernel is used in the transient filtering. All AviSynth resizers' kernels are allowed: ("point", "bilinear", "bicubic", "lanczos", "lanczos4", "blackman", "spline16", "spline36", "spline64", "gauss" and "sinc", "sinpow", "sinclin2" and "userdefined2"). Most useful are "gauss", "sinpow" and "userdefined2". Where "gauss", "sinpow" are easier to control and "userdefined2" can provide best quality (especially if r=2 or more with param3 (support) adjusted from default 2.3 to higher values like 5 or more. See also Notes below).


Current text: "These 'float' type parameters can be the additional parameters for the resampler. Some resizer algorithms would need and can be fine tuned with up to 3 parameters. Their default values depend on the selected chromaresample resizer kernel."

Recommended text: These 'float' type parameters can be the additional parameters for setup the used filtering kernel and convolution (support-size parameter). Some filtering algorithms would need and can be fine tuned with up to 3 parameters. Their default values depend on the selected filtering kernel.


Current text: "When r radius is not zero, transient filtering occurs. Even r=1 is giving sufficient protection for some next processing stages."

Recommended text: When r radius is not zero, transient filtering occurs. Even r=1 is giving sufficient protection for some next processing stages. Max used r-parameter value may reach 4 or 5 for some types of filtering if higher quality is required (total number of changed samples created by filtering process to 'describe' or 'encode' the transient's shape is r*2). See Note below. Also high values of r-parameter may be used for artistic intent to make transient to added border more visibly soft.


Current text: # Add 20 black pixels around the clip, filters (blurs) 1 pixel with the default "gauss" method
AddBorders(20, 20, 20, 20, r=1)

Recommended text: # Add 20 black pixels around the clip, filters (blurs) 1 pixel around new created transient (2 pixels total) with the default "gauss" kernel
AddBorders(20, 20, 20, 20, r=1)

Recommended Notes: As noted in Japan ARIB STD-B28 https://www.arib.or.jp/english/html/...B28v1_0-E1.pdf A.5 : The number of samples to be used for the transient shall be 6 to 9, in the case of 1920 horizontal samples, although it may depend upon the scale of hardware, process performance and the so-called “make up”. It means the max used value of the r-parameter may reach 4 or 5 (9/2=4.5 but only integers are valid for current implementation).

[pinterf]

Originally Posted by DTL

Recommended edits for https://avisynthplus.readthedocs.io/...ddborders.html :

I wait a bit with the edit, your earlier modifications are already integrated (not commited yet - only together with this batch)

[DTL]

Recommended edits to https://avisynthplus.readthedocs.io/...rs/resize.html

Current text: When resizing images, convolution filters help in smoothing or sharpening the image to avoid artifacts like aliasing, which can occur when the image is scaled up or down.

Recommended text: When resizing images, convolution filters help in smoothing or sharpening the image to avoid artifacts like aliasing, ringing, which can occur when the image is scaled up or down.

Current text: The set of SinPower/UserDefined2 and Sinc/SincLin2/Lanczos/Blackman resizers form a complementary set for a sinc-based workflow in digital imaging, allowing controlled sharpness and ringing. SinPowerResize or UserDefined2Resize are used for content creation as downscaling (compressing), while any sinc-based resizer can be used for upscaling for display or intermediate processing (interpolation, decompressing).

Recommended text: The set of SinPower/UserDefined2 and Sinc/SincLin2/Lanczos/Blackman resizers form a complementary set for a sinc-based workflow in digital moving imaging, allowing controlled sharpness and ringing. Digital moving imaging is a subset of general digital imaging for processing of moving (or, in general, any transforming in time like rotating/scaling/skewing and other) objects' views in digital form with as low distortions as possible. SinPowerResize or UserDefined2Resize are used for content creation as downscaling (compressing), while any sinc-based resizer can be used for upscaling for display or intermediate processing (interpolation, decompressing). Other resize kernels (Bicubic, Spline, Point, Gauss) come from general purpose digital imaging (typically static or pixel-based images) and can be used when sinc-based workflow can not serve good or static images processing is required. Though Gauss kernel can also be used as a good quality anti-Gibbs ringing filter for sinc-based workflows.


Current text: Optionally, when a filtering radius is given, a custom resizer can be added to AddBorders and LetterBox. In these filters the transient areas (boundary of the new borders) are filtered, in order to prevent ringing e.g. in a subsequent upscale.

Recommended text: Optionally, when a filtering radius is given, a custom convolution filtering with given resizer's kernel can be applied to new transients created by AddBorders and LetterBox filters. In these filters the transient areas (boundary of the new borders) are filtered, in order to prevent ringing e.g. in a subsequent upscale or also as additional artistic intent.

Current text: Everything is the same as mentioned above in Resizers in ConvertToXXXX section, except, that 'gauss' default parameters are tunes for blurring:

Recommended text: Everything is the same as mentioned above in Resizers in ConvertToXXXX section, except, that 'gauss' default parameters are tuned for anti-ringing processing for subsequent sinc-based interpolation giving 'flat/film' 'look/make up' of the filtered transient:


Current text: SincLinResize (clip, int target_width, int target_height,
float "src_left", float "src_top", float "src_width", float "src_height",
int "taps", int "force")
Typing error - SincLin2Resize

Current text: Internally, it is based on a sum of weighted sinc functions by b and c parameters. With b = c = 16, it is equivalent to SincResize with the given support size by the s parameter.

Recommended text: Internally, it is based on a sum of weighted sinc functions by b and c parameters. The weighting coefficients for second and third kernel members are computed as weight=(paramrter_value - 16) / 219 to be directly compatible with classic 8-bit narrow video levels range mapping. While the first kernel member weighting coefficient (virtual a-parameter) is internally fixed to 1.0. With b = c = 16, it is equivalent to SincResize with the given support size by the s parameter.

Current text: The default values of b and c (121/19) create a soft film-like look/makeup. It may be better to use sharper values like 80/-20 with higher 'sharpness/acutance'

Recommended text: The default values of b and c (121/19) create a soft film-like look/makeup. In the use cases where higher 'sharpness/acutance' is required for 'video' look/makeup - the values like 80/-20 may be recommended.

Current text: p
Parameter for GaussResize and SinPowerResize only.
Sharpness. Range from about 1 to 100, with 1 being very blurry and 100 being very sharp.
GaussResize
Default: 30.0

Recommended text: p
Parameter for GaussResize and SinPowerResize only.
Sharpness.

GaussResize

Default: 30.0. Range from 0.01 to 100, with 0.01 being very blurry and 100 being very sharp. Values below about 5 require manually increasing the support-size (s-parameter) or setting s-parameter to zero (auto-computed support size internally). If support-size is left too small with low p-parameter values it will cause non-linear distortions.

Recommended Notes addition:
All AVS+ core resizers use the same highly optimized 1 Dimensional convolution and resampling engine supporting all sample formats and bit depths. In 'no-resize' modes it is used as a convolution only engine. The only difference between different 'Resizers' is kernel function sent to the resampler and 'support' size set for processing. This causes all these resizing methods to produce some different output result in comparison with single-pass 2 Dimensional resampling engines (typically used in JincResize or typically EWA-prefixed resize methods) even if the same kernel functions is used.

For information 'support' size for different 'Resize' methods used:
PointResize - support 0.0001 (expect = 0)
BilinearResize - support 1.0
BicubicResize - support 2.0
LanczosResize, BlackmanResize, SincResize, SincLin2Resize - support=taps
Spline16Resize - support 2.0
Spline36Resize - support 3.0
Spline64Resize - support 4.0
GaussResize - support 4.0 (or defined by s-parameter or auto-calculated)
SinPowerResize - support 2.0 (fixed by design)
UserDefined2Resize - support is user-defined by s-parameter (default is 2.3)

[DTL]

It looks we have some issue with the resampling engine at handling 'edge conditions' -

Test script:

BlankClip(100, 100, 20, color=$7F7F7F, pixel_type="YV12")

near=AddBorders(0, 2, 0, 2, r=2)
far=AddBorders(0, 20, 0, 20, r=2)
far_crop=Crop(far, 0, 18, 0, -18)
near_black_expanded=AddBorders(near, 0,18, 0, 18, r=0)

StackVertical(near, far, far_crop, near_black_expanded)

LanczosResize(width*2, height*2, taps=16)

The created transient of radius=2 at the edge of frame should be valid for non-ringing resize. But sinc-based resizer still shows lots of ringing. If we add border length > taps number - the same created transient gives about non-ringed result at sinc-upsize to 2x.
Expected action of resampler at handling this edge case conditon - make extension of the last edge sample (duplicate) to the total kernel size of the resampler (make it equal to large-length added border). As last example.

Current workaround if resize required somewhere inside AVS - add border of enough size (to be comparable with resizer kernel size ?) and crop after resizing.

Addition: Tested with avsresize - it process edges as expected without ringing. So it is an issue in AVS+ resampler:


The use case of very small filtered borders transients: Add smoothing of top and bottom of the image of the wide-screen movies (like 2:35:1 cinema frame format) for playback at the TV-formatted 16:9 displays. Without smoothing we got some distraction of too sharp top and bottom edges of the frame if display's scaler do not provide service of some top+bottom image smoothing. Also the designer of the content may adjust smoothing to match internal image sharpness/look/makeup more precisely in comparison with some average image edges smoothing at playback device. 2 methods possible:

1. Add some new borders to the frame to save max useful samples but somehow increase frame size:
AddBorders(0,2,0,2,r=2, ... possible filter params to match image sharpness/look/makeup better)

2. Add internal small transient to black to top and bottom parts of frame. It more degrades original frame content but keep frame size unchanged:
LetterBox(2,2,0,0,r=2, ... possible filter params to match image sharpness/look/makeup better)

Example with wide-screen cinematic movie playback on 16:9 display:


Same applicable to left and right frame borders if adapt 4:3 old content to new 16:9 displays.

[Z2697]

Due to mirrored outside pixels perhaps?

[DTL]

Testing of padded-AVS+ resize vs avsresize and fmtconv with internal edge handling:

LoadPlugin("avsresize.dll")
LoadPlugin("fmtconv.dll")

Function Padded2xLanczosResize(clip c, int pad)
{
  padded=AddBorders(c,pad,pad,pad,pad, r=0)
  res_2x=LanczosResize(padded, padded.width*2, padded.height*2, taps=16)
  return Crop(res_2x,pad*2,pad*2,-pad*2,-pad*2)
}

Function Diff(clip src1, clip src2)
{
  return Subtract(src1.ConvertBits(8),src2.ConvertBits(8)).Levels(120, 1, 255-120, 0, 255, coring=false)
}

BlankClip(100, 200, 100, color=$7F7F7F, pixel_type="YV12")

AddBorders(2, 2, 2, 2, r=2, param1=8)


pad=50

std=LanczosResize(width*2, height*2, taps=16).Subtitle("AVS+ Std 2xLanczosResize taps=16", align=5)

avs_p=Padded2xLanczosResize(last, pad).Subtitle("AVS+ Padded2xLanczosResize taps=16", align=5)
avsr=z_ConvertFormat(width=width*2, height=height*2, resample_filter="lanczos", filter_param_a=16).Subtitle("avsresize lanczosResize taps=16", align=5)
fmtconv=fmtc_resample(w=width*2, h=height*2, kernel="lanczos", taps=16).Subtitle("fmt_conv lanczosResize taps=16", align=5)

d1 = Diff(avs_p,std)
#d2 = Diff(avs_p,avsr)
d2 = Diff(avsr,fmtconv)
d3 = Diff(avs_p,fmtconv)

StackHorizontal(StackVertical(std, avs_p, avsr), Stackvertical(d1, d2, d3))

The avsresize vs fmtconv is about equal (with about 1LSB difference at some corner samples) but all slightly different from 'padded resize'. The worst at r4246 is unpadded AVS+ (std) resize.

The padded versions of both avsresize and fmtconv also make some different outputs in comparison with unpadded resize by same engines. So different edges conditions handling workarounds (in different resize engines) gives still different results (vs padded method). It looks changing of kernel of resize filter in the 'resampling program' for handling edge conditions is not perfect way (but may give best performance because resampler process lowest data size).

LoadPlugin("avsresize.dll")
LoadPlugin("fmtconv.dll")

Function Padded2xLanczosResize(clip c, int pad)
{
  padded=AddBorders(c,pad,pad,pad,pad, r=0)
  res_2x=LanczosResize(padded, padded.width*2, padded.height*2, taps=16)
  return Crop(res_2x,pad*2,pad*2,-pad*2,-pad*2)
}

Function Padded2xLanczosResizeAVSR(clip c, int pad)
{
  padded=AddBorders(c,pad,pad,pad,pad, r=0)
  res_2x=z_ConvertFormat(padded, width=padded.width*2, height=padded.height*2, resample_filter="lanczos", filter_param_a=16)
  return Crop(res_2x,pad*2,pad*2,-pad*2,-pad*2)
}

Function Padded2xLanczosResizeFMTC(clip c, int pad)
{
  padded=AddBorders(c,pad,pad,pad,pad, r=0)
  res_2x=fmtc_resample(padded, w=padded.width*2, h=padded.height*2, kernel="lanczos", taps=16)
  return Crop(res_2x,pad*2,pad*2,-pad*2,-pad*2)
}


Function Diff(clip src1, clip src2)
{
  return Subtract(src1.ConvertBits(8),src2.ConvertBits(8)).Levels(120, 1, 255-120, 0, 255, coring=false)
}

BlankClip(100, 200, 100, color=$7F7F7F, pixel_type="YV12")

AddBorders(2, 2, 2, 2, r=2, param1=8)


pad=50

std=LanczosResize(width*2, height*2, taps=16).Subtitle("AVS+ Std 2xLanczosResize taps=16", align=5)

avs_p=Padded2xLanczosResize(last, pad).Subtitle("AVS+ Padded2xLanczosResize taps=16", align=5)
avsr_p=Padded2xLanczosResizeAVSR(last, pad).Subtitle("avsresize Padded2xLanczosResize taps=16", align=5)
fmtc_p=Padded2xLanczosResizeFMTC(last, pad).Subtitle("FMTC Padded2xLanczosResize taps=16", align=5).ConvertBits(8)
avsr=z_ConvertFormat(width=width*2, height=height*2, resample_filter="lanczos", filter_param_a=16).Subtitle("avsresize lanczosResize taps=16", align=5)
fmtconv=fmtc_resample(w=width*2, h=height*2, kernel="lanczos", taps=16).Subtitle("fmt_conv lanczosResize taps=16", align=5)

d1 = Diff(avs_p,std)
#d2 = Diff(avs_p,avsr)
#d2 = Diff(avsr,fmtconv)
#d2 = Diff(avsr,avs_p)
#d3 = Diff(avs_p,fmtconv)

d2 = Diff(avsr,avsr_p)
d3 = Diff(fmtconv, fmtc_p)


StackHorizontal(StackVertical(std, avs_p, avsr), Stackvertical(d1, d2, d3))

[pinterf]

AviSynth plus 3.7.3 r4269

Topic of last wek: resizers.

https://github.com/pinterf/AviSynthP...ag/v3.7.3.4269

memory overread fix - heavy refactor/rewrite in almost all resizers (C/SSEx/AVX2 x 8/10-16/32bit x Horizontal/Vertical)
no more size limit ("image height is too small for this resizing method" errors are gone)
Fix artifacts on boundaries.
respect chroma location (fixes chroma shift on downsize with non-centered chroma locations)
new placement and keep_center parameters
C-only version a bit more vectorizable by smart compilers

and many fixes and additions to the documentation.

Visit our online docs for

Change list:
https://avisynthplus.readthedocs.io/...gelist374.html

Resize filters:
https://avisynthplus.readthedocs.io/...rs/resize.html

[tormento]

Originally Posted by pinterf

Topic of last wek: resizers.

Could you consider adding the dithering methods included in fmtconv?

I find them useful, such as mode 8 that gives pleasant result and is resilient to compression.

[Jamaika]

Does LWLibavAudioSource work with the added fixes for avisynth f7b5954?

[DTL]

"Fix artifacts on boundaries."

It is also important addition to the Bugfixes section of https://avisynthplus.readthedocs.io/...gelist374.html

[Z2697]

Originally Posted by tormento

Could you consider adding the dithering methods included in fmtconv?

I find them useful, such as mode 8 that gives pleasant result and is resilient to compression.

why not just use fmtconv?

[pinterf]

Originally Posted by tormento

Could you consider adding the dithering methods included in fmtconv?

I find them useful, such as mode 8 that gives pleasant result and is resilient to compression.

No

[tormento]

Originally Posted by Z2697

why not just use fmtconv?

As it's slow compared to other resizers/ditherer, at least on my machine.

[qyot27]

AviSynth+ 3.7.4 has been released. Full changelog on the Github release page. The macOS installer will come later.

New to this release is a full installer for Windows on ARM, so any of you with Snapdragon X Elite laptops (or maybe even one of those Ampere workstations) can use a native build instead of running it through the x64 emulation layer.

[DTL]

It is good. Next step to the nice future of digital moving pictures in 3.7.4-postXX is precise (float) control of placement of transient (its center of 0.5 level) in both AddBorders and LetterBox. Will try to prepare some simple script-based simulation how it can work.

So that finally we can run Animate(LetterBox()) with smooth slow-motion of the border in or out at any speed (from 0.000+ samples/frame). In current version we can have only integer control of placement and even worse - for 4:2:0 formats its granularity is 2.0. So with 4:4:4 formats animation can run, but the placement is only integer positions and jumps.

The real valuable use case of the float-precision control of the position of the transient is better quality of the very thin borders added. Currently AddBodrers or LetterBox(2,r=2) can not be precisely fine tuned (like we want something about LetterBox(2.5..2.8, r=2.8)) and for 4:2:0 formats next working is (4,r=4) that is too large step. When we make transient full-blooded Digital Motion Picture Object we can place it at any position (float-addessed) without distortion and in any chroma-subsampled format. As we have with any other objects in real digital moving pictures.

In 3.7.4 generation of good conditioned transients is working, but limited to integer positions placement only.

[pinterf]

Originally Posted by qyot27

AviSynth+ 3.7.4 has been released. Full changelog on the Github release page. The macOS installer will come later.

New to this release is a full installer for Windows on ARM, so any of you with Snapdragon X Elite laptops (or maybe even one of those Ampere workstations) can use a native build instead of running it through the x64 emulation layer.

Thanks to qyot27 for putting together this long-awaited release.

And much appreciated to everyone who shared ideas, requests, and bug reports, you’ve been a huge help!

If you want to talk more about this release, check out the discussion on GitHub:
https://github.com/AviSynth/AviSynth...iscussions/432

Additionally, here are some statistics showcasing our download count.

Avisynth 3.7.4 released 20250324 
(first 10/48 hours)

61/159 AviSynthPlus_3.7.4_20250324-filesonly.7z
243/1075 AviSynthPlus_3.7.4_20250324.exe
14/46 AviSynthPlus_3.7.4_20250324_arm64.exe
58/163 AviSynthPlus_3.7.4_20250324_vcredist.exe
24/54 AviSynthPlus_3.7.4_20250324_xp.exe
21/44 AviSynthPlus_3.7.4_20250324_xp_vcredist.exe

Avisynth 3.7.3 released 2023.07.06 21 months before 3.7.4

10805 AviSynthPlus_3.7.3_20230715-filesonly.7z
56689 AviSynthPlus_3.7.3_20230715.exe
2024 AviSynthPlus_3.7.3_20230715_macOS_10.15+_x64-filesonly.tar.xz
2360 AviSynthPlus_3.7.3_20230715_macOS_10.15+_x64.pkg
1924 AviSynthPlus_3.7.3_20230715_macOS_11.0+_arm64-filesonly.tar.xz
2501 AviSynthPlus_3.7.3_20230715_macOS_11.0+_arm64.pkg
22942 AviSynthPlus_3.7.3_20230715_vcredist.exe
2771 AviSynthPlus_3.7.3_20230715_vcredist_xp.exe
2801 AviSynthPlus_3.7.3_20230715_xp.exe

Avisynth 3.7.2 released 2022.03.18, 16 months before 3.7.3

15910 AviSynthPlus_3.7.2_20220317-filesonly.7z
65920 AviSynthPlus_3.7.2_20220317.exe
7277 AviSynthPlus_3.7.2_20220317_macOS_10.13_._10.14-filesonly.tar.xz
7441 AviSynthPlus_3.7.2_20220317_macOS_10.13_._10.14_x64.pkg
7263 AviSynthPlus_3.7.2_20220317_macOS_10.15+_x64-filesonly.tar.xz
7316 AviSynthPlus_3.7.2_20220317_macOS_10.15+_x64.pkg
7215 AviSynthPlus_3.7.2_20220317_macOS_11.0+_M1-filesonly.tar.xz
7558 AviSynthPlus_3.7.2_20220317_macOS_11.0+_M1.pkg
18785 AviSynthPlus_3.7.2_20220317_vcredist.exe
8332 AviSynthPlus_3.7.2_20220317_vcredist_xp.exe
2994 AviSynthPlus_3.7.2_20220317_xp.exe

[DTL]

Here is script-based example of LetterBox with float placement of the new border (only left for example to make it more short):

Function LetterBoxLeftFloatP(clip c, float left, int flt_rad)
{
  left_int=Int(left)
  pad=1
  l_padded=AddBorders(c,pad, 0,0,0)
  unflt=LetterBox(l_padded, 0, 0, x1=left_int+pad)
  frac=Frac(left)
  flt=GaussResize(unflt, unflt.width, unflt.height, p=8, b=2.71828, s=0, force=1, src_left=(0.0-frac))
  uf_internal=Crop(l_padded, left_int+flt_rad+pad, 0, l_padded.width-(left_int+flt_rad+pad), l_padded.height)
  proc_padded=Overlay(flt, uf_internal, x=left_int+flt_rad+pad, y=0)
  return Crop(proc_padded,pad,0,0,0).SubTitle(Format("left={left}"))
}

BlankClip(10000, 200, 200, color=$7F7F7F, pixel_type="YV24")

Animate(last, 0, 10000, "LetterBoxLeftFloatP",\
-0.5, 3,\
Float(last.width/2), 3)

LanczosResize(width*2, height*2, taps=16)

It even support such strange left coordinate like -0.5 (possibly lowest valid is -0.99) to move the new border completely out of the frame (for given flt_rad and filter kernel setup). But in the range of 0.0 to about 1.2 the balancing part of the transient still cropped out and it still shows some ringing (though still significantly less in comparison with old hard transient LettelBox(x1=1)). It looks with such simple method it is unavoidable (or special case for coordinates size < about 1.2 is required (changing filter kernel and possibly flt_rad to larger blurring).

"here are some statistics showcasing our download count."

15910 AviSynthPlus_3.7.2_20220317-filesonly.7z
65920 AviSynthPlus_3.7.2_20220317.exe

10805 AviSynthPlus_3.7.3_20230715-filesonly.7z
56689 AviSynthPlus_3.7.3_20230715.exe

This also confirm somehow sad idea: To the end of each civilization we have best designed tools with all fixes and requirements implemented (like software too) but no one need it anymore. 1 year (0.01 of a century) step at 202x shows decreasing in download rate at about 10 to 50% at different packages.

[Stereodude]

Are there some sort of language/character set dependencies in AVIsynth+ that are set by the application opening the .avs file?

I had a .avs that VirtualDub 2.2.0.755 could open without any issue. It would display a correct image with the correct number of frames just like any other .avs, but a jpsdr build of x265 (version 4.1.0.054+45+15-b8ba3fe87 [Mod by JPSDR using mod by Patman]) could not open the .avs from a cmd window in Windows 10 22H2. I got this message on the console:

avs+ [INFO]: AviSynth+ 3.7.3 (r4003, 3.7, x86_64)
avs+ [FLAW]: Error loading file: DGSource: Could not open one of the input files.
Check that the input files listed at the top of the DGI file actually exist.
This can happen after making an index and then moving the source file(s).

If you want to have your Avisynth script and your source file(s) in different directories,
then you must enable the Use Full Paths option in the DGIndexNV settings before saving your project.
Alternatively, you can edit the DGI file to add the full paths, in which case re-indexing is not required.

The script had:

DGSource("video.dgi").crop(0,20,-0,-20)

video.dgi file (name obscured for anonymity):

DGAVCIndexFileNV25 DGIndexNV 255.0.0.0 X64
C:\HDTV Tools\DGDecNV\

C:\Temp\BD\____é____...

The file being opened by DGDecNV had an é in the filename. I had to rename the source file changing the é to an e and then change the filename in the .dgi the same way and then x265 could open the .avs file.

I'm totally confused why one program could open the .avs and the other returned an error. This is the first time I've seen this.

[jpsdr]

Hi.
In current AVS+, is faste crop like this crop(1,0,0,0,align=false) still possible, and so creating a non aligned frame after, or is the parameter align just kept for not breaking compatibility but ignored ?
More globaly, is there a minimal alignment value guaranteed whatever you do ? Even using something like env->NewVideoFrame(vi,8) in a plugin code ?

[qyot27]

Originally Posted by Stereodude

Are there some sort of language/character set dependencies in AVIsynth+ that are set by the application opening the .avs file?

I had a .avs that VirtualDub 2.2.0.755 could open without any issue. It would display a correct image with the correct number of frames just like any other .avs, but a jpsdr build of x265 (version 4.1.0.054+45+15-b8ba3fe87 [Mod by JPSDR using mod by Patman]) could not open the .avs from a cmd window in Windows 10 22H2. I got this message on the console:

avs+ [INFO]: AviSynth+ 3.7.3 (r4003, 3.7, x86_64)
avs+ [FLAW]: Error loading file: DGSource: Could not open one of the input files.
Check that the input files listed at the top of the DGI file actually exist.
This can happen after making an index and then moving the source file(s).

If you want to have your Avisynth script and your source file(s) in different directories,
then you must enable the Use Full Paths option in the DGIndexNV settings before saving your project.
Alternatively, you can edit the DGI file to add the full paths, in which case re-indexing is not required.

The script had:

DGSource("video.dgi").crop(0,20,-0,-20)

video.dgi file (name obscured for anonymity):

DGAVCIndexFileNV25 DGIndexNV 255.0.0.0 X64
C:\HDTV Tools\DGDecNV\

C:\Temp\BD\____é____...

The file being opened by DGDecNV had an é in the filename. I had to rename the source file changing the é to an e and then change the filename in the .dgi the same way and then x265 could open the .avs file.

I'm totally confused why one program could open the .avs and the other returned an error. This is the first time I've seen this.

Presence or lack of a manifest that launches the application in UTF-8 mode?

It's far easier in many cases to just turn on UTF-8 system-wide and forget about it, as AviSynth just uses whatever the system locale is (even 2.6 is fine with UTF-8 in this scenario; it's not exclusive to Plus). Notepad has defaulted to saving in UTF-8 without BOM for several years now.