AviSynth+ thread Vol.2

[kedautinh12]

AviSynthPlus r3973
https://gitlab.com/uvz/AviSynthPlus-Builds

[real.finder]

with yv411 source using LWLibavVideoSource or ffms2 both give _ChromaLocation = 2 and make avspmod, ConvertToRGB or ConvertToYV16 give error

[pinterf]

Originally Posted by real.finder

with yv411 source using LWLibavVideoSource of ffms2 both give _ChromaLocation = 2 and make avspmod, ConvertToRGB or ConvertToYV16 give error

Probably 0-"left" and 2-"topleft" (they are the same in other-than-4:2:0 formats) could be enabled? I think, this is how it is handled, but since there is no valid choice at 411, using any _Chromalocation hint was disabled until now.

[real.finder]

Originally Posted by pinterf

Probably 0-"left" and 2-"topleft" (they are the same in other-than-4:2:0 formats) could be enabled? I think, this is how it is handled, but since there is no valid choice at 411, using any _Chromalocation hint was disabled until now.

I think maybe it safe to make it if 411 then _Chromalocation could has 0-"left" or 2-"topleft"

[FranceBB]

Avisynth 3.7.3 Beta 9, using the following script:

BlankClip(length=0)

makes ffmpeg go crazy as I described here: https://forum.doom9.org/showthread.php?t=184819

Even AVSPmod mod really doesn't like length=0 in BlankClip():



Given that using BlankClip(length=1) produces 1 frame of black, namely frame 0:



what is BlankClip(length=0) supposed to output? And why is it making FFMpeg go on forever and AVSPmod mod fail?
I even tried with VirtualDub, it doesn't fail, and although the preview is bogus like this:



it does produce a file which is 1 frame long (frame 0) of pure black when I play it back with MPC-HC:



I reported the issue to the ffmpeg community, but the more I test the more I think that we (the Avisynth community) might be the one at fault here.
I'm not sure. What do you think, guys?

[poisondeathray]

BlankClip(length=0) makes no sense, but there should be an appropriate error message such as "Not a clip"

[qyot27]

Originally Posted by poisondeathray

BlankClip(length=0) makes no sense, but there should be an appropriate error message such as "Not a clip"

This. FFmpeg reads video and audio packets separately, and if either reaches EOF, it attempts to read the other one before exiting, because it is easily possible - and not a bug - that either video or audio might be longer than the other, and it shouldn't be truncated.

The error is that length=0 is treated by BlankClip as somehow valid when it isn't, and ends up creating an audio stream of infinite length, which FFmpeg then attempts to read/output. Forcing an output length via the -t parameter would probably demonstrate that it is indeed attempting to write an ever-increasing number of audio samples, until the process is killed.

[FranceBB]

Gotcha.
So... what next? I think we should be throwing an error and display it correctly as an error if length=0 is passed to BlankClip() instead of failing silently.

The good thing is that a new version of Avisynth is being worked on, so perhaps we can include this in 3.7.3 Beta 10 (or one of the next betas before the stable release)?

Anyway, it's just a proposition as I've addressed it in the code at work last Sunday (yes, I rushed to work on Sunday when I saw the server crash eheheheheh). Anyway, as far as my use case is concerned, now if there's a clip of 0 frame, length is forced to 1 as one workaround in the AVS Script that my supply chain generates automatically (and I'll make sure to include the fix in the next public release of FFAStrans, if Steinar approves my pull request).

I'll let the ffmpeg guy know as well and close the ticket there anyway, since this is not a bug on their end.

[gispos]

Originally Posted by FranceBB

Avisynth 3.7.3 Beta 9, using the following script:



makes ffmpeg go crazy as I described here: https://forum.doom9.org/showthread.php?t=184819

Even AVSPmod mod really doesn't like length=0 in BlankClip():

At first I was also surprised that no error 'Not a clip' is output, had to look 2 - 3 times to find the error. Fixed.

Edit:
Avisynth should have returned an error here, but probably does not.

self.src_frame = self.clip.get_frame(frame)
if self.clip.get_error():
    Error()
    return False

[qyot27]

Now it does:
https://github.com/AviSynth/AviSynth...eee829223d1d54

[qyot27]

To explain a bit further, I'm now not really sure if it was generating valid audio either, because if I tried to do

ffmpeg -i test.avs -vn -acodec copy output.wav

the output length reported before it errored out was something like -577100 hours. Which would indicate a problem with the integer used to represent the length of the stream. And the AviSynth docs have the following rather useful tidbit when describing audio samples properties:

Returns the number of samples of the audio of the clip (type: int). Be aware of possible overflow on very long clips (2^31 samples limit).

Which made me think there might be an overflow happening for the length of the clip, since 2^31 = 2,147,483,648 seconds / 60 = 35,791,394.133 minutes / 60 = 596,523.235 hours. Like I said, it's not exact (~577100 vs. 596523) but with other kinds of overhead, it's close enough. That may be a completely wrong assumption about what the issue actually was, but it doesn't really matter, since it will error out now if BlankClip is set to less than 1 frame long.

[FranceBB]

Thanks for the fix and the explanation, Stephen!
(also thanks to Gispos for addressing it in AVSPmod mod; I didn't report it in the AVSPmod mod thread only 'cause I thought it should really be Avisynth throwing a proper error anyway, but thanks for addressing it for older version of AVS too in AVSPmod mod )

[gispos]

Originally Posted by FranceBB

...
(also thanks to Gispos for addressing it in AVSPmod mod; I didn't report it in the AVSPmod mod thread only 'cause I thought it should really be Avisynth throwing a proper error anyway, but thanks for addressing it for older version of AVS too in AVSPmod mod )

You can also test it right now
https://drive.google.com/drive/folde...usp=share_link

[FranceBB]

Originally Posted by gispos

You can also test it right now
https://drive.google.com/drive/folde...usp=share_link

It works and it correctly returns an error message.



While this outputted an image without asking any questions about the audio, just like before:

[gispos]

Originally Posted by FranceBB

It works and it correctly returns an error message.

While this outputted an image without asking any questions about the audio, just like before:

If I understand correctly, that's so good ?
But it will probably change when avisynth gives an error on BlankClip(0). Then there is nothing I can do about it.

[FranceBB]

Originally Posted by gispos

If I understand correctly, that's so good ?

It's fine, it's fine, thanks

Originally Posted by gispos

But it will probably change when avisynth gives an error on BlankClip(0).

Yeah and rightly so. I would rather get a proper error than a memory leak in FFMpeg that takes my whole farm of several servers down and makes me rush back to the office after getting an incident on Spark and a phone call on a Sunday! XD

[gispos]

Originally Posted by FranceBB

Yeah and rightly so. I would rather get a proper error than a memory leak in FFMpeg...

My mistake, I thought you use BlankClip(0) in the script for something.
At the second look I recognized it now... The script was only meant as an example... Sometimes it takes longer...

[DTL]

Some syntax request for some resizers:

Currently AVS resampling engine also used as convolution filter with resizer's kernel for non-resizing processing. So it required not very nice hacky way of forcing processing using non-zero src_left and/or src_top small float value. Also non-zero non-required shift may more degrade output.

So 2 ideas:
1. Add more param to resizers like force_processing (fp) = 0 (default - no), 1,2,3 (H, V, H+V), or horfp=false/true and verfp=false/true.

2. Add naming aliases with H(V) ending - like standard GaussResize and GaussResizeH/GaussResizeV/GaussResizeHV (conditionless forced H, V or HV processing). It looks like shortest way of script typing.

Mostly needed for resizers with user-adjustable kernel (taps or p or b,c params).

May be other ideas exist how to force resizer processing if width and height not changed ?

[pinterf]

Originally Posted by real.finder

I think maybe it safe to make it if 411 then _Chromalocation could has 0-"left" or 2-"topleft"

Opened an issue at github, just for the reference. I had (and maybe will continue to have) busy working weeks, you'll notice a minor slowdown for some days.
Then I can finally have a look at DTL's (old and new) resizer related things.

[kedautinh12]

AviSynthPlus r3982
https://gitlab.com/uvz/AviSynthPlus-Builds