Thread: Avisynth+
View Single Post
Old 3rd June 2018, 11:23   #4083  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 2,314
New test build
Avisynth+ r2696
https://drive.google.com/open?id=1yU...bDpSdEbR6yugUm

Compared to last test build (r2693):
- ConvertBits from/to 32 bits assume full source/destination range only for RGB. Additional fix was in limited range conversion when source is 32 bits
- Avisource: Greyscale 10, 12, 14, 16 bits for Y1[0][10] .. Y1[0][16] (not tested)

Full list since last official release (r2664)
Code:
- AviSource to support more formats with 10+ bit depth.
  http://avisynth.nl/index.php/AviSource

  When pixel_type is not specified or set to "FULL", AviSource will try to request the formats one-by-one in the order shown in the table below.

  When a classic 'pixel_type' shares more internal formats (such as YUV422P10 first tries to request the v210 then P210 format)
  you can specify one of the specific format directly. Note that high bit-depth RGBP is prioritized against packed RGB48/64.

  The 'FourCCs for ICDecompressQuery' column means that when a codec supports the format, it will serve the frame in that one, Avisource then will convert it to the proper colorspace.

  Full support list (* = already supported): 
  'pixel_type' Avs+ Format   FourCC(s) for ICDecompressQuery
  YV24         YV24          *YV24
  YV16         YV16          *YV16 
  YV12         YV12          *YV12
  YV411        YV411         *Y41B
  YUY2         YUY2          *YUY2
  RGBP10       RGBP10        G3[0][10]  r210  R10k
  r210         RGBP10        r210
  R10k         RGBP10        R10k             
  RGBP         RGBP10        G3[0][10]  r210  R10k
               RGBP12        G3[0][12]
               RGBP14        G3[0][14]
               RGBP16        G3[0][16]
               RGBAP10       G4[0][10]
               RGBAP12       G4[0][12]
               RGBAP14       G4[0][14]
               RGBAP16       G4[0][16]
  RGB32        RGB32         *BI_RGB internal constant (0) with bitcount=32
  RGB24        RGB24         *BI_RGB internal constant (0) with bitcount=24
  RGB48        RGB48         BGR[48]    b48r 
  RGB64        RGB64         *BRA[64]   b64a
  Y8           Y8            Y800       Y8[32][32]   GREY
  Y            Y8            Y800       Y8[32][32]   GREY
               Y10           Y1[0][10]
               Y12           Y1[0][12]
               Y14           Y1[0][14]
               Y16           Y1[0][16]
  YUV422P10    YUV422P10     v210       P210
  v210         YUV422P10     v210
  P210         YUV422P10     P210
  YUV422P16    YUV422P16     P216
  P216         YUV422P16     P216
  YUV420P10    YUV420P10     P010
  P010         YUV422P10     P010
  YUV420P16    YUV420P16     P016
  P016         YUV422P16     P016
  YUV444P10    YUV444P10     v410
  v410         YUV444P10     v410
- Changed (finally): 32bit float YUV colorspaces: zero centered chroma channels. 
  U and V channels are now -0.5..+0.5 (if converted to full scale before) instead of 0..1
  Note: filters that relied on having the U and V channel center as 0.5 will fail.
  Why: the old UV 0..1 range was a very-very early decision in the high-bitdepth transition project. Also it is now
  compatible with z_XXXXX resizers (zimg image library, external plugin at the moment).
- New function: bool IsFloatUvZeroBased()
  For plugin or script writers who want to be compatible with pre r2672 Avisynth+ float YUV format:
    Check function availablity with FunctionExists("IsFloatUvZeroBased").
    When the function does not exists, the center value of 32 bit float U and V channel is 0.5
    When IsFloatUvZeroBased function exists, it will return true (always for official releases) if U and V is 0 based (+/-0.5)
- Fix: RGB64 Turnleft/Turnright (which are also used in RGB64 Resizers)
- Fix: Rare crash in FrameRegistry
- Enhanced: Allow ConvertToRGB24-32-48-64 functions for any source bit depths
- Enhanced: ConvertBits: allow fulls-fulld combinations when either clip is 32bits
  E.g. after a 8->32 bit fulls=false fulld=true: 
  Y: 16..235 -> 0..1 
  U/V: 16..240 -> -0.5..+0.5
  Note: now ConvertBits does not assume full range for YUV 32 bit float. 
  Default values of fulls and fulld are now true only for RGB colorspaces.
- Fix: couldn't see variables in avsi before plugin autoloads (colors_rgb.avsi issue)
- Fix: LoadVirtualdubPlugin: Fix crash on exit when more than one instances of a filter was used in a script
- New: LoadVirtualdubPlugin update:
  - Update from interface V6 to V20, and Filtermod version 6 (partial)
  - VirtualDub2 support with extended colorspaces
    Allow RGB24, RGB48, RGB64 besides RGB32
    AutoConvert 8 bit Planar RGB to/from RGB24, RGBPA to/from RGB32 (lossless)
    AutoConvert RGB48 and 16 bit Planar RGB(A) to/from RGB64 (lossless)
    Support YUV(A) 8 bits: YV12, YV16, YV24, YV411, YUVA420P8, YUVA422P8, YUVA444P8
    Support YUV(A) 10-16 bits (properly set "ref_x" maximum levels, no autoconvert)
  - Supports prefetchProc2 callback (API >= V14 and prefetchProc2 is defined) for multiple input frames from one input clip
    PrefetchFrameDirect and PrefetchFrame are supported. PrefetchFrameSymbolic not supported
  - Supports prefetchProc callback (API >= V12 and prefetchProc is defined)
  - Supports when filter changes frame count of the output clip
  - Extra filter parameter added at the end of filter's (unnamed) parameter list
    Imported Virtualdub filters are getting and extra named parameter to the end:
      String [rangehint]
    This parameter can tell the filter about a YUV-type clip colorspace info
    Allowed values:
      "rec601": limited range + 601
      "rec709": limited range + 709
      "PC.601": full range + 601
      "PC.709": full range + 709
      ""      : not defined (same as not given)
    Parameter will be ignored when clip is non-YUV
    How it works: the hint will _not_ change the internal VirtualDub colorspace
    constant (e.g. kPixFormat_YUV420_Planar -> kPixFormat_YUV420_Planar_709 will not happen).
    Instead the base color space is kept and colorSpaceMode and colorRangeMode will set in PixmapLayout.formatEx.
    Filter can either use this information or not, depending on supported API version and its implementation. 
    E.g. Crossfade(20,30) -> Crossfade(20,30,"rec601") though this specific filter won't use it.
- New function: BuildPixelType

  Creates a video format (pixel_type) string by giving a colorspace family, bit depth, optional chroma subsampling and/or a 
  template clip, from which the undefined format elements are inherited.
  "[family]s[bits]i[chroma]i[compat]b[oldnames]b[sample_clip]c"

  string family: YUV, YUVA, RGB, RGBA, Y
  int bits: 8, 10, 12, 14, 16, 32
  string chroma: for YUV(A) 420,422,444,411. Ignored for RGB(A) and Y
  bool compat (default false): returns packed rgb formats for 8/16 bits (RGB default: planar RGB)
  bool oldnames (default false): returns YV12/YV16/YV24 instead of YUV420P8/YUV422P8/YUV444P8
  clip sample_clip: when supported, its format is overridden by specified parameters (e.g. only change bits=10)

  Example#1: define YUV 444 P 10
   
    family = "YUV"
    bits = 10
    chroma = 444
    compat = false
    oldformat = false
    s = BuildPixelType(family, bits, chroma, compat, oldformat)
    BlankClip(width=320,height=200,length=len,pixel_type=s,color=$008080).Info()

  Example#2: Change only the bit depth of the format to 16
   
    newbits = 16
    c = last
    s = BuildPixelType(bits=newbits, sample_clip=c)
    BlankClip(width=320,height=200,length=len,pixel_type=s,color=$008080).Info()

- Source: move to c++17, 'if constexpr' requires. Use Visual Studio 2017 (or GCC 7?). CMakeLists.txt changed.
- Source: C api: AVSC_EXPORT to dllexport in capi.h for avisynth_c_plugin_init
- Source: C api: avs_is_same_colorspace VideoInfo parameters to const
- Project struct: changelog to git.
- Planned: include current header files and def/exp file in installer
pinterf is offline