AviSynth+ thread Vol.2

[flossy_cake]

ScriptClip appears to return audio from the clip being iterated on instead of the clip returned by the expression

global withAudio = ColorBars().ConvertToYV12().Text("withAudio")

global withoutAudio = ColorBars().ConvertToYV12().KillAudio().Text("withoutAudio")

ScriptClip(withoutAudio, "return withAudio", after_frame=true, local=false) 

# the returned clip appears to be equivalent to AudioDub(withAudio, withoutAudio)

[Gavino]

Originally Posted by flossy_cake

ScriptClip appears to return audio from the clip being iterated on instead of the clip returned by the expression

That's by design.
ScriptClip doesn't do any audio processing, it only operates on the video track.

[flossy_cake]

If it's by design, then I would say it's not very good design as I noticed just now that it also sets the field parity of the returned clip to that of the one being iterated on.

last = ColorBars().ConvertToYV12().KillAudio()
global tff = last.AssumeTFF().Text("TFF", align=9)
global bff = last.AssumeBFF().Text("BFF", align=9)
ScriptClip(tff, "return bff", after_frame=true, local=false)
info()

This will cause problems for filters downstream from the ScriptClip which need to see its field order, such as if the ScriptClip returns DoubleWeave which has alternating field order. Hopefully this can be worked around by manually setting the parity of each frame back to what it should be via a custom frame property.

[wonkey_monkey]

If it's by design, then I would say it's not very good design

It has to get its output clip properties from somewhere, and while it's easy for a human to look at "return bff" and know that it's just returning all the frames of bff, it would (correct me if I'm wrong, Gavino) be far too complicated for ScriptClip to be able to do this kind of introspection on arbitrary inputs. For a lot of scripts it would just be impossible - for example, if you wrote a ScriptClip that selected a frame from one of three clips depending on the frame number, how would it know which clip's properties (frame rate, field parity, etc) to use?

[flossy_cake]

Originally Posted by wonkey_monkey

for example, if you wrote a ScriptClip that selected a frame from one of three clips depending on the frame number, how would it know which clip's properties (frame rate, field parity, etc) to use?

I believe the fps of the input clip and return clip have to be the same for it to work correctly, otherwise eg. if input clip is 30 and return clip is 60, the output plays back at half speed.

I don't see the need to modify the audio or field order of the output clip.

[flossy_cake]

Also sorry if my comments about ScriptClip sound overly critical - I've been fighting with it the past few weeks and it's causing me a lot of headaches getting it to play nice with multithreading, avoiding memory leaks and my QTGMC output was broken due to this field order issue. Gavino's Grunt thread page 1 has some quotes from other members noting how quirky and strange the runtime environment is, so I know I'm not alone in this frustration.

[flossy_cake]

I'm just playing around with Avisynth's internal TimeStretch audio filter and was wondering about this:

Originally Posted by http://avisynth.nl/index.php/TimeStretch

Since tempo, rate and pitch are floating-point values, but sample rates are integers, rounding effects in calculations are unavoidable; the resulting audio track duration may be off by up to several 10's of milliseconds (less than one video frame) per hour.

Several 10's of milliseconds per hour doesn't seem trivial to me - a 3 hour movie could be off by 100ms then? That seems significant, and longer recordings of several hours, say, live events like sports or whathaveyou could become ruined by it.

I was thinking... is it possible to somehow force a manual audio resync every n minutes, to nudge it back in sync? Could this be done in Aviysynth scripting or only within the TimeStretch plugin itself?

[tebasuna51]

Originally Posted by flossy_cake

...
Several 10's of milliseconds per hour doesn't seem trivial to me - a 3 hour movie could be off by 100ms then? That seems significant, and longer recordings of several hours, say, live events like sports or whathaveyou could become ruined by it.

The time can't be stretched.

The audio don't be never stretched, if it is not in sync with the video is a video fps problem. Play the video at fps it was filmed and the audio is always in sync.

If you film the Usain Bolt 100 m WR (9.58 s) at 24 fps and play it at 25 fps you have a new WR of 9.2 s

BTW if you want modify the real audio duration to fit the wrong video duration you can add some correction at your taste, there are audio editors.

[flossy_cake]

Originally Posted by tebasuna51

If you film the Usain Bolt 100 m WR (9.58 s) at 24 fps and play it at 25 fps you have a new WR of 9.2 s

I think that depends if you used ChangeFPS() or AssumeFPS().

Anyway, I'm not modifying the video fps at all. The TimeStretch function only processes audio, and I'm going to be modifying audio pitch while retaining audio length, and the wiki says audio length will be slightly off due to unavoidable rounding errors, and if the audio length is different then it's not going to be in sync with video.

I tried to reproduce it by taking a 1hr clip and Loop(20).TimeStretch(pitch_n=24000, pitch_d=25025) to simulate pitch down of 4% and skipped to the end and audio was still in sync. But I don't think this simulates the issue - I'll probably have to leave the video running overnight and come back the next day and see if it's still in sync.

If it isn't, then I had an idea: split the clip into say 3 hour chunks with Trim, and do the TimeStretch() on each individual clip before joining them back together with ++. But then maybe there will be a little audio glitch every 3 hours at the splice point. I think the optimal solution would be for TimeStretch to handle it internally and when it detects drift is > some value it should smooth over the resync point using its own timestretching algorithms.

[r0lZ]

It is usually assumed that an A/V difference of 100 ms or even more is not perceptible. So, unless you want absolutely to watch a 24 hours movie, you should not worry too much.

[flossy_cake]

Originally Posted by r0lZ

It is usually assumed that an A/V difference of 100 ms or even more is not perceptible.

In MPC-HC I can adjust audio delay with hotkeys in 10ms increments and at 100ms it's noticeable to me the lip sync is off.

[pinterf]

Originally Posted by DTL

Heh - small fix for UV scale at RGB<->YUV at 'limited/narrow' levels mapping https://forum.doom9.org/showthread.p...18#post1988318 is not included in the 3.7.3 release. Pinterf promised to make a big redesign of all 'convert' core functions with a fix for this issue included (also with better performance) but it looks like it will happen in some 3.7.4testXXX next builds. So currently with 3.7.3 release the same workaround with additional UV scaling is required.

Yeah, promised, it's still here on my desktop, but did not make a final-final test, so the release did not get untested change. Probably I'm going to upload the changes as is to the git repo, because I didn't find issues by myself.

[pinterf]

Originally Posted by real.finder

this make dither tools not working

colorbars(pixel_type="yv12")
Dither_convert_8_to_16()
ditherpost(mode=-1)

edit: anything newer than Avisynth+ 3.7.3 test 7 (20230223) will give same error

Is it still an issue the 3.7.3 release? I'm unable to reproduce it

I've raised an issue here in order to check it later: https://github.com/AviSynth/AviSynthPlus/issues/365 now it's "later", but I'm unable to see the error. I don't understand, becasue my code does contain a check against such plugins built with pre-V5 AVISYNTH_INTERFACE_VERSION.
Maybe an Avisynth 2.5 plugin was accidentally built with AVISYNTH_INTERFACE_VERSION = 5 in its avisynth.h????)

If you still get the error, please upload me somewhere the exact plugin binary you are using, thanks.

[FranceBB]

Originally Posted by pinterf

Is it still an issue the 3.7.3 release?

No, looks like it was broken in some of the 3.7.3 test but eventually got fixed in the stable build:




Sorry for not closing this https://github.com/AviSynth/AviSynthPlus/issues/365 I should have checked too, but I very rarely have time to do anything nowadays...

I'm gonna comment it there too, thank you as always, Ferenc, the conditional to check the version of the plugins and apply the workaround is indeed working as expected

Originally Posted by pinterf

Yeah, promised, it's still here on my desktop, but did not make a final-final test, so the release did not get untested change.

Don't worry, I think plenty of people here are gonna be more than happy to test it on the field as soon as the first 3.7.4 test1 release is gonna be available (me included). Testing is literally the least we could do

[StvG]

Originally Posted by pinterf

Is it still an issue the 3.7.3 release? I'm unable to reproduce it

I've raised an issue here in order to check it later: https://github.com/AviSynth/AviSynthPlus/issues/365 now it's "later", but I'm unable to see the error. I don't understand, becasue my code does contain a check against such plugins built with pre-V5 AVISYNTH_INTERFACE_VERSION.
Maybe an Avisynth 2.5 plugin was accidentally built with AVISYNTH_INTERFACE_VERSION = 5 in its avisynth.h????)

If you still get the error, please upload me somewhere the exact plugin binary you are using, thanks.

It's still an issue with 3.7.3 release. I reproduced it with this version (the version from here).
What version did you use?

[FranceBB]

Originally Posted by StvG

It's still an issue with 3.7.3 release. I reproduced it with this version (the version from here).
What version did you use?

Just to keep everyone aligned, the conversation is continuing here: https://github.com/AviSynth/AviSynthPlus/issues/365

I used v1.28.0 built on Wednesday 07 October 2020, 16.27.15 however even if I swap dither.dll 1.28.0 from October 2020 with the one you provided (which is the same as the one provided by Real Finder) that was built on Monday 17 July 2023, 08.33.18, I get the same result:

VersionString: AviSynth+ 3.7.3 (r4003, 3.7, x86_64)
VersionNumber: 2.60
File / Product version: 3.7.3.0 / 3.7.3.0
Interface Version: 10
Multi-threading support: Yes
Avisynth.dll location: C:\WINDOWS\SYSTEM32\avisynth.dll
Avisynth.dll time stamp: 2023-07-15, 21:48:08 (UTC)
PluginDir2_5 (HKLM, x64): C:\Program Files (x86)\AviSynth+\plugins64
PluginDir+ (HKLM, x64): C:\Program Files (x86)\AviSynth+\plugins64+

[C 2.5 Plugins (64 Bit)] [Version, Time stamp]
C:\Program Files (x86)\AviSynth+\plugins64+\assrender.dll [0.35.0.0, 2021-03-04]
C:\Program Files (x86)\AviSynth+\plugins64+\mlrt_ncnn.dll [1.0.1.0, 2023-03-20]
C:\Program Files (x86)\AviSynth+\plugins64+\mlrt_ov.dll [1.0.0.0, 2023-03-20]

[C++ 2.5 Plugins (64 Bit)] [Version, Time stamp]
C:\Program Files (x86)\AviSynth+\plugins64+\dither.dll [n/a, 2023-07-17]
C:\Program Files (x86)\AviSynth+\plugins64+\HDRMatrix-x64.dll [n/a, 2018-01-09]
C:\Program Files (x86)\AviSynth+\plugins64+\HDRNoise-x64.dll [n/a, 2018-01-09]
C:\Program Files (x86)\AviSynth+\plugins64+\HDRSharp-x64.dll [n/a, 2018-01-09]
C:\Program Files (x86)\AviSynth+\plugins64+\LeakKernelDeint.dll [1.5.4.0, 2010-03-14]
C:\Program Files (x86)\AviSynth+\plugins64+\VSFilter.dll [3.0.0.306, 2014-12-07]
C:\Program Files (x86)\AviSynth+\plugins64+\warpsharp.dll [n/a, 2011-06-14]

Play audio is of course enabled in AVSPmod mod.

Ferenc also tried to reproduce it, but to no avail...
The fact that you can also reproduce this, StvG, and not just real.finder, means that there's something really there.
In the meantime, despite not being able to reproduce the issue (just like I can't reproduce it on my pc ), Ferenc made some changes and provided a test build https://drive.google.com/uc?export=d...Ve2L6rw2qEohs4
Testing on my computer would be pointless 'cause I can't reproduce the error anyway, so can you guys who can actually reproduce the error, test the new build and see if it solves it?

[StvG]

@FranceBB, thanks for the info.

From that github thread, it seems they found the culprit.

[FranceBB]

Originally Posted by StvG

From that github thread, it seems they found the culprit.

Yes, Ferenc made a new build that solves the issue.
In case anyone needs it, you can find the latest Ferenc build here: Link

[pinterf]

Originally Posted by FranceBB

Yes, Ferenc made a new build that solves the issue.
In case anyone needs it, you can find the latest Ferenc build here: Link

yes, but do not use it yet for production please, contains some unfinished code parts on other areas. Wait a little bit for the official git commits.

[pinterf]

Try this one. Much safer, git commits are still not uploaded, I'd wait a bit.
Avisynth 3.7.3+ tests
Avisynth+ 3.7.3post test 4 (20231019 - r4013)

20231019 3.7.3 post 4
---------------------
- Fix #365 (https://github.com/AviSynth/AviSynthPlus/issues/365)
  Avisynth 2.5 plugins when NICE_FILTER would crash with "invalid response to CACHE_GETCHILD_AUDIO_MODE".
  Bug appeared since reintroducing audio cache in 3.7.3.
- Fix #370: array size assert error in ConvertToYUY2 when internally ConvertTo422 is called.
  Reason: ConvertToYUV422 has one more parameter (ChromaOutPlacement) than ConvertToYUY2 has
- Issues mentioned in #354 https://github.com/AviSynth/AviSynthPlus/issues/354 
  - Leave _ColorRange frame property as-is, when using matrix names "PC.709" or "PC.601", 
    for example in ConvertToRGB32.
    Formerly _ColorRange property would always set to 0 (full range), even if a limited range 
    clip (e.g. ColorBarsHD) was inputted. Now we act as the specification 
    ( http://avisynth.nl/index.php/Convert ) says: 
    "PC.601 and PC.709 keep the range unchanged, instead of converting between 0-255 RGB 
    and 16-235 YUV, as is the normal practice."
    Now ColorBarsHD().ConvertToRGB32(matrix="PC.601").propShow()
    would display "_ColorRange=1 (limited)", since ColorbarsHD's output is limited as well.
  - Studio RGB (limited) range will now be recognized (through _ColorRange=1) and utilized in 
    conversions from RGB, such as in GreyScale, ConvertToY, ConvertToYUVxxx.
    When input or output would require it, rgb offset of 16 (or scaled equivalents) is used 
    for supporting limited range rgb (similar to Y offset=16 used at limited range YUV conversions)