AviSynth+ thread Vol.2

[real.finder]

Originally Posted by pinterf

It is not 100%, just a trivial case was fixed. So the likelyhood you are seeing this error was decreased. There still can be circumstances in the frame request pattern when you get this error.

and now it fully fixed! thank you so much pinterf!

I think all avs/avs+ mt and non-mt problems is fixed, we can encode faster and without deadlock or crashes or glitches thanks to you and Asd-g (and others that fixes and improved avs+ like nekopanda and avs+ father ultim)

[FranceBB]

Originally Posted by real.finder

and now it fully fixed! thank you so much pinterf!

Absolutely amazing news for this and for giving some love to SSE4.1, there may not be many users but they will definitely appreciate it.

Thank you, Master Ferenc!

[pinterf]

Originally Posted by FranceBB

I'm so happy right now. This is a very unexpected present, so thank you!
About the colorbars, we've got ColorBars() for BT.601, ColorBarsHD() for BT.709, are we gonna get ColorBarsUHD() for BT.2020?

Something appears to be off in Histogram, though, as this:

produces identical results despite one combination having

Check with targets=true, this is a master switch for the axes, as a result of my wrong decision, just tell me (honestly, since you went into the rabbit hole, it seem illogical so must be changed).
EDIT: haha, not a wrong decision, just a mis-placed ending curly-bracket, one block outer than it was necessary

[pinterf]

New build: Avisynth r4549
https://github.com/pinterf/AviSynthP...3.7.6pre-r4549

The biggest focus lately has been cleaning up the xxToYUV functions to bring their parameters and optimization in line with ConvertToPlanarRGB. This process triggered an endless series of new issues, forcing me to dig deep into historical code to understand why things were built the way they were.

Also, I updated our online documentation according these changes and findings.

I’ve also fixed the Histogram parameters related to the new features introduced in recent builds, which were discussed in the posts above.

For online documentation check https://avisynthplus.readthedocs.io/en/latest/

Actual change log:
https://avisynthplus.readthedocs.io/...gelist376.html

20260305 3.7.5.r4549 (pre 3.7.6)
--------------------------------
- Fix: memory leak in Subframe/MakePropertyWritable after static-frame sources (ColorBars, BlankClip)
- any->YUV conversions (See https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/corefilters/convert.html ).
  - accept bits ans quality parameters, similar to ConvertToPlanarRGB
  - the legacy 8-bit-named functions (``ConvertToYV12``, ``ConvertToYV16``, 
    ``ConvertToYV24``) allowing high-depth sources.
  - "ConvertToYUY2": rewritten to route all conversions through YV16.
  - "ConvertToYUY2": ``ChromaOutPlacement`` parameter added (was missing, present in ConvertToYV16).
  - "ConvertBackToYUY2": kept for backward compatibility; now forwards to ``ConvertToYUY2``. The pre-2.5 left-pixel-only chroma hack is no longer
    needed or applied; the YV16 lossless repack path avoids chroma resampling loss entirely for roundtrip workflows.
  - 8 bit packed RGB formats are converted to planar RGB before 444 conversion.
    Utiliting the optimized and maintained planar RGB infrastructure
  - Fix: "ConvertToYUY2" / "ConvertToYV12": progressive YV12<->YUY2 conversion (use generic YV16/YV12 path)
  - Fix: "ConvertToYUY2": ``_ChromaLocation``, ``_Matrix`` and ``_ColorRange``
    frame properties were not read from YV12 source frames and not written to YUY2 output frames 
    in the old legacy direct conversion path.
  - Fix: "ConvertToYUY2": SSE2 interlaced upsampling used wrong weighting direction, differing from the C reference implementation.
- Update https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/corefilters/convert.html`
  - matrix syntax
  - ConvertToYUY2
  - ``bits`` and ``quality`` parameters
- Update Sampling https://avisynthplus.readthedocs.io/.../sampling.html with historical content notes 
  on legacy ``YUY2`` handling.

[jpsdr]

Thanks for all your work pinterf.
And it's again work for FranceBB who have to make all of his tests...

[TR-9970X]

Originally Posted by pinterf

New build: Avisynth r4549
https://github.com/pinterf/AviSynthP...3.7.6pre-r4549

Surely r3.7.6 will be next

[Nomolu]

Release 3.7.5 r4549 has introduced a bug when using the Overlay function on YUY2 video. I can reproduce it using this simple script:

Version()
ConvertToYUY2()
Overlay(last)

It causes this error:

Avisynth open failure:
ConvertToYUV422: Can only convert from Planar YUV.
E:\z_InProgress_E\Version - Overlay.avs, line 3

And, like I mentioned in post #3619, how about no longer putting 64 bit plugins in the 32-bit plugin directory of the builds?

Anyhow, thank you for all of the hard work, pinterf!

[pinterf]

Originally Posted by Nomolu

Release 3.7.5 r4549 has introduced a bug when using the Overlay function on YUY2 video. I can reproduce it using this simple script:

Version()
ConvertToYUY2()
Overlay(last)

It causes this error:

Avisynth open failure:
ConvertToYUV422: Can only convert from Planar YUV.
E:\z_InProgress_E\Version - Overlay.avs, line 3

And, like I mentioned in post #3619, how about no longer putting 64 bit plugins in the 32-bit plugin directory of the builds?

Anyhow, thank you for all of the hard work, pinterf!

Please check the next day version, thanks, YUY2 conversions were temporarily were disabled in the final build, accidentally, I fixed since then.

[Nomolu]

Yup, 3.7.5.r4551 fixes the problem with Overlay and YUY2 video.

[pinterf]

And thanks for spotting the 64-bit dlls put into the 32-bit plugins folder as well. These were intended to be a copy from the latest official 3.7.5 'filesonly' release, unfortunately, a copy-paste error on my end led to the mismatch.

[pinterf]

Latest test build
Avisynth+ v3.7.6pre-r4554 test build (20260307)

20260307 3.7.5.r4554 (pre 3.7.6)
--------------------------------
- Fix: Working 'quality' parameter for 10-14 bits sources in YUV<->RGB conversions (was: blackness)

20260306 3.7.5.r4551 (pre 3.7.6)
--------------------------------
- Reenable YUY2 in planar target conversions as source (disabled in r4549)
- ConvertToY also gets bits and quality parameters, latter is used when source is RGB.

20260305 3.7.5.r4549 (pre 3.7.6)
--------------------------------
- Fix: memory leak in Subframe/MakePropertyWritable after static-frame sources (ColorBars, BlankClip)
- any->YUV conversions (See https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/corefilters/convert.html`.
  - accept bits and quality parameters, similar to ConvertToPlanarRGB
  - the legacy 8-bit-named functions (``ConvertToYV12``, ``ConvertToYV16``, 
    ``ConvertToYV24``) allowing high-depth sources.
  - "ConvertToYUY2": rewritten to route all conversions through YV16.
  - "ConvertToYUY2": ``ChromaOutPlacement`` parameter added (was missing, present in ConvertToYV16).
  - "ConvertBackToYUY2": kept for backward compatibility; now forwards to ``ConvertToYUY2``. The pre-2.5 left-pixel-only chroma hack is no longer
    needed or applied; the YV16 lossless repack path avoids chroma resampling loss entirely for roundtrip workflows.
  - 8 bit packed RGB formats are converted to planar RGB before 444 conversion.
    Utilizing the optimized planar RGB infrastructure.
  - Fix: "ConvertToYUY2" / "ConvertToYV12": progressive YV12<->YUY2 conversion (use generic YV16/YV12 path)
  - Fix: "ConvertToYUY2": ``_ChromaLocation``, ``_Matrix`` and ``_ColorRange``
    frame properties were not read from YV12 source frames and not written to YUY2 output frames 
    in the old legacy direct conversion path.
  - Fix: "ConvertToYUY2": SSE2 interlaced upsampling used wrong weighting direction, differing from the C reference implementation.
- Update https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/corefilters/convert.html`
  - matrix syntax
  - ConvertToYUY2
  - ``bits`` and ``quality`` parameters
- Update Sampling https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/advancedtopics/sampling.html with historical content notes 
  on legacy ``YUY2`` handling.

20260220 3.7.5.r4529 (pre 3.7.6)
--------------------------------
- Fix Colorbars inaccurate 10+ bit, by using ground truth linear RGB, similarly to ColorBarsHD.
  - Full refactoring.
  - update doc: https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/corefilters/colorbars.html
- Histogram "color" and "color2" (Vectorscope modes) 
  - full refactoring.
  - Drawing is now matrix and color range aware. target positions (75%) +-I and +Q.
  - add individual overlay options:
    added ``matrix``, ``graticule``, ``targets``, ``axes``, ``iq``, ``iq_lines``, ``circle``
    parameters
  - Fix: copy alpha from clip, initialize alpha to zero in the histogram area. 
  - Accurate pixel positioning and scaling to the active histogram area, 
    limited/full range aware.
  - update doc: https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/corefilters/histogram.html

[tormento]

Originally Posted by pinterf

- Fix: Working 'quality' parameter for 10-14 bits sources in YUV<->RGB conversions (was: blackness)

Would you please explain this more in detail?

I can find no reference about that feature/parameter.

I've found fmtconv to be the most precise among the conversion plugins. If AVS+ internals could become so precise and even fast, they would be welcomed ones.

[jpsdr]

@pinterf
Hi.
What is the resamplers status ?
Are the new functions (AVX2 & AVX512) Ok, and can i begin to try to implement them in my ResamplerMT, or are they still in testing mode ?
Just to try to avoid to spend hours for nothing if i have to redo everything later. By later i mean shortly, not if something in a few months append and a fix/change is needed.

[DTL]

Most important update on resamplers for permutex-based functions still not ported to AVS+ is yet another pre-processing of the coeffs in the resampling program. It looks universal for all H to V permute-based transposition functions. See this commit https://github.com/DTL2020/AviSynthP...901c03dc9c9f7e

Also some simple data locality optimization at the 2d resizing of multi-planes (typical colour) formats - process each plane in 2 resizers in a sequence instead of processing all planes in first dimension at first and all planes in second dimension at next stage https://github.com/DTL2020/AviSynthP...ee3c9821eb9bfd . This allows output of the first resize to be hot in cache if possible to be read by second stage.