AviSynth+ thread Vol.2

[gispos]

When will there be a final build of all the fixes that were included in post_test14?

[gispos]

Seems to be dying out here, unfortunately...

[BilboFett]

Originally Posted by gispos

Seems to be dying out here, unfortunately...

I don't know how much further they can take it. Its a solid program and its successful in achieving what its meant to do; apart from a few random bugs now and then that are discovered.
What else do you hope for it to do? HDR processing or something?

[FranceBB]

Originally Posted by BilboFett

HDR processing or something?

It already can handle pretty much everything in terms of HDR, from custom LUTs to tonemapping in any possible way etc. Heck, with frame properties we can even have dynamically changing metadata (like the brightness in nits) per single frame. I mean, in theory you could literally calculate and have the MaxCLL defined on a frame-by-frame basis and then perform dynamic tonemapping based on that. If anything, Avisynth is probably the best frameserver out there to handle HDR contents and has been on the forefront of innovation for a very long time.

Originally Posted by BilboFett

I don't know how much further they can take it. Its a solid program and its successful in achieving what its meant to do; apart from a few random bugs now and then that are discovered.

Yep, yep, all this is true but this doesn't mean that innovation will stop. I'm sure Ferenc and Stephen will cook out a new release.

Let's take a look at the last few releases from 2019 to today:

AviSynth+ 3.7.3 - Jul 16, 2023
AviSynth+ 3.7.2 - Mar 18, 2022
AviSynth+ 3.7.1 - Jan 1, 2022
AviSynth+ 3.7.0 - Jan 11, 2021
AviSynth+ 3.6.1 - Jun 20, 2020
AviSynth+ 3.6.0 - May 20, 2020
AviSynth+ 3.5.1 - Apr 3, 2020
AviSynth+ 3.5.0 - Mar 3, 2020
AviSynth+ 3.4.0 - Oct 21, 2019

Leaving aside 2020 which was a bit weird being it the pandemic period, between March 18, 2022 and July 16, 2023, 485 days passed, so if we apply the same logic we can expect the future release to be:

AviSynth+ 3.7.4 - Nov 12, 2024

It's a long way 'till November.
Given that we're currently in August and that up until now we've had 70 commits shaping up 3.7.4 I'd say that we're totally on track and we have nothing to worry about.
Mines are just speculations, but remember: in master Ferenc we trust.



EDIT: Uhhh, this is my 3000th post. It had to be special and I'm glad that it was about Avisynth, my favorite frameserver.

[gispos]

Originally Posted by BilboFett

I don't know how much further they can take it. Its a solid program and its successful in achieving what its meant to do; apart from a few random bugs now and then that are discovered.
What else do you hope for it to do?

See, I'm too late... Almost forgot the Avisynth thread.
There are several reasons for my post.

I want to read something here again, this wish has been fulfilled. Thanks FranceBB

The official version contains bugs that can cause AvsPmod to crash when reinitializing a clip.
Many (new) users do not use the latest test version in which this bug has been fixed.

And last but not least, you can never have enough of good things.

I would just like to ask if anyone here knows why there seems to be issues when using Avisynth filters & scripts, that on CPU's over 12 cores, drop encoding speeds with x265 ??

Or is it x265 ??

[LigH]

I don't believe you can generalise that easily. Not without knowing your exact setup in detail.

In general, the speed of a well scalable encoder should increase with the number of cores, but not linearly, it will saturate. The efforts to manage more parallel calculations will increase. More calculations need to wait for intermediate results of others.

Similar for filtering: Parallel processing of video frames may reduce the scope of each thread, depending on the strategy how the material is split among the threads. Each thread needs its own copy of a filter to run, each copy needs RAM. In the special case of QTGMC, it may spawn multiple EDI filter threads per copy of the main routine, so the dependency on the number of cores squares if you don't limit EDIThreads. And when RAM is fully utilized by both Avisynth filters and the encoder (easily possible when encoding UHD video), Windows will start to use the swap file on disk which will delay the processing a lot...

[FranceBB]

Hey master Ferenc, I've got a reply from Olli Parviainen, the SoundTouch guy, about bumping the limit from 16ch to 32ch, thus allowing TimeStretch to handle more channels in Avisynth.
His reply is tracked here: Link and he updated his repository after applying the following changes: Link
The latest master of SoundTouch with the relative changes is here: Link
As such, I've updated the issue I opened in July in the Avisynth repository about TimeStretch() failing when the clip had more than 16 audio channels Link
As result, I opened the following pull request to implement the same changes Olli has done (kudos to him) in the local SoundTouch copy we have in Avisynth thus allowing TimeStretch() to process more than 16ch Link
Hopefully, this change will make its way into the next AviSynth+ 3.7.4 release. That would make me extremely happy, but if not, it's not a big deal, we can wait until a new stable version of SoundTouch is released before the changes are implemented.
Either way, it's your call, you're the master (well, you and Stephen obviously :P ).

[FranceBB]

In Avisynth 3.7.3 r4066, when I use FadeIn() I get 2 extra frames, but when I use FadeOut() I only get 1 extra frame.

To reproduce:

ColorBars(848, 480, pixel_type="YV12")

trim(0, 100)

This will give you a 101 frames clip.

ColorBars(848, 480, pixel_type="YV12")

trim(0, 100)

FadeIn(1)

This will give you a 103 frames clip (2 frames are added).

ColorBars(848, 480, pixel_type="YV12")

trim(0, 100)

FadeOut(1)

This will give you a 102 frames clip (1 frame is added).




So the question is: why does FadeIn() add 2 frames, but FadeOut() only adds 1 frame? Shouldn't they both add 1 frame (or both 2 frames)?

[LigH]

Doesn't look like intended. But please compare also against Fade...[0|2].

[qyot27]

As also posted in the frame properties thread:

Originally Posted by Reel.Deel

@qyot27

Would it be possible for AviSynth+ to pass a timecode file (VFR) to FFmpeg?

Nearly three years later...

$ ../ffmpeg_build/bin/ffmpeg -i test.avs -vf vfrdet -f null -
ffmpeg version N-117370-g8f3957c41c Copyright (c) 2000-2024 the FFmpeg developers
  built with gcc 13 (Ubuntu 13.2.0-23ubuntu4)
  libavutil      59. 41.100 / 59. 41.100
  libavcodec     61. 21.100 / 61. 21.100
  libavformat    61.  9.100 / 61.  9.100
  libavdevice    61.  4.100 / 61.  4.100
  libavfilter    10.  6.100 / 10.  6.100
  libswscale      8.  4.100 /  8.  4.100
  libswresample   5.  4.100 /  5.  4.100
  libpostproc    58.  4.100 / 58.  4.100
Input #0, avisynth, from 'test.avs':
  Duration: 00:03:16.95, start: -0.667000, bitrate: 0 kb/s
  Stream #0:0: Video: rawvideo (I420 / 0x30323449), yuv420p(progressive), 512x384, 21.83 fps, 29.97 tbr, 1k tbn
  Stream #0:1: Audio: pcm_f32le, 24000 Hz, stereo, flt, 1536 kb/s
[Parsed_vfrdet_0 @ 0x5a1d9609e7c0] VFR:-nan (0/0)
Stream mapping:
  Stream #0:0 -> #0:0 (rawvideo (native) -> wrapped_avframe (native))
  Stream #0:1 -> #0:1 (pcm_f32le (native) -> pcm_s16le (native))
Press [q] to stop, [?] for help
[out_#0:1 @ 0x79f294003140] The "all_channel_counts" option is deprecated: accept all channel counts
Output #0, null, to 'pipe:':
  Metadata:
    encoder         : Lavf61.9.100
  Stream #0:0: Video: wrapped_avframe, yuv420p(progressive), 512x384, q=2-31, 200 kb/s, 29.97 fps, 29.97 tbn
    Metadata:
      encoder         : Lavc61.21.100 wrapped_avframe
  Stream #0:1: Audio: pcm_s16le, 24000 Hz, stereo, s16, 768 kb/s
    Metadata:
      encoder         : Lavc61.21.100 pcm_s16le
[Parsed_vfrdet_0 @ 0x79f29c002600] VFR:0.782667 (2348/652) min: 33 max: 668 avg: 47
[out#0/null @ 0x5a1d96b50f40] video:1289KiB audio:18402KiB subtitle:0KiB other streams:0KiB global headers:0KiB muxing overhead: unknown
frame= 3001 fps=0.0 q=-0.0 Lsize=N/A time=00:02:20.37 bitrate=N/A speed= 141x

To zero in on the important bits there:

Stream #0:0: Video: rawvideo (I420 / 0x30323449), yuv420p(progressive), 512x384, 21.83 fps, 29.97 tbr, 1k tbn
...
[Parsed_vfrdet_0 @ 0x79f29c002600] VFR:0.782667 (2348/652) min: 33 max: 668 avg: 47

The very experimental FFmpeg test build:
ffmpeg_N-117370-g8f3957c41c.7z
Because the test build is intended to test the feature, vfr mode is enabled by default, but can be turned off by -avisynth_flags -vfr.

By 'very experimental' I mean that it comes with some very obvious issues that will need addressing. These are documented in the patch's commit message.

[Jamaika]

Originally Posted by qyot27

By 'very experimental' I mean that it comes with some very obvious issues that will need addressing. These are documented in the patch's commit message.

I don't like the structure of the avisynth .dll in static ffmpeg. So Windows says don't add viruses.
I removed shared .dll avisynthm but that doesn't apply to added plugins.
Since I removed the .dll avisynth, I had to adapt the plugins to C++11 or rather C++23 ffmpeg.

avisynth_c.cpp:2142:57: warning: narrowing conversion of '(unsigned int)avs->AviSynthContext::vi->AVS_VideoInfo::fps_numerator' from 'unsigned int' to 'int' [-Wnarrowing]
 2142 |         st->avg_frame_rate    = (AVRational) { avs->vi->fps_numerator,
      |                                                ~~~~~~~~~^~~~~~~~~~~~~
avisynth_c.cpp:2143:57: warning: narrowing conversion of '(unsigned int)avs->AviSynthContext::vi->AVS_VideoInfo::fps_denominator' from 'unsigned int' to 'int' [-Wnarrowing]
 2143 |                                                avs->vi->fps_denominator };
      |                                                ~~~~~~~~~^~~~~~~~~~~~~~~

FFmpeg has a larger video decoder database than 5 years ago
No support for decoding AVI files in avisynth by ffmpeg

    switch(pbiSrc->biCompression) {
    case MAKEFOURCC('M','P','4','3'):    // Microsoft MPEG-4 V3 '34PM'
    case MAKEFOURCC('D','I','V','3'):    // "DivX Low-Motion" (4.10.0.3917) '3VID'
    case MAKEFOURCC('D','I','V','4'):    // "DivX Fast-Motion" (4.10.0.3920) 4VID'
    case MAKEFOURCC('A','P','4','1'):    // "AngelPotion Definitive" (4.0.00.3688) '14PA'
      if (AttemptCodecNegotiation(asi.fccHandler, pbiSrc)) return;
      pbiSrc->biCompression = MAKEFOURCC('M', 'P', '4', '3');
      if (AttemptCodecNegotiation(asi.fccHandler, pbiSrc)) return;
      pbiSrc->biCompression = MAKEFOURCC('D', 'I', 'V', '3');
      if (AttemptCodecNegotiation(asi.fccHandler, pbiSrc)) return;
      pbiSrc->biCompression = MAKEFOURCC('D', 'I', 'V', '4');
      if (AttemptCodecNegotiation(asi.fccHandler, pbiSrc)) return;
      pbiSrc->biCompression = MAKEFOURCC('A', 'P', '4', '1');
    default:
...
    env->ThrowError("AVISource: couldn't locate a decompressor for fourcc %s", s);

Directshow is thrown into the trash. It is only under MSVC.