Vapoursynth

[lansing]

I'm trying to create a blankclip with compatbgr32, but blankclip doesn't support the format.

[Myrsloik]

Originally Posted by lansing

I'm trying to create a blankclip with compatbgr32, but blankclip doesn't support the format.

Create a rgb24 blankclip and then convert it if you really need it

[lansing]

Originally Posted by Myrsloik

Create a rgb24 blankclip and then cpnvert ot of you really need ot

When I declared a copy clip and format in blankclip, the declared format doesn't overwrite the format of the copy clip like other arguments. It still gave me the error "compat formats not supported".

core.std.BlankClip(compat_clip,length=padding, format=vs.RGB24)

[Myrsloik]

Originally Posted by lansing

When I declared a copy clip and format in blankclip, the declared format doesn't overwrite the format of the copy clip like other arguments. It still gave me the error "compat formats not supported".

core.std.BlankClip(compat_clip,length=padding, format=vs.RGB24)

Will fix

[Boulder]

How to properly do a thing like Greyscale() in Vapoursynth? I've got a movie which is supposedly black and white, but according to the x265 logs, there is data in the chroma channels.

core.std.ShufflePlanes(clips=inclip, planes=0, colorfamily=vs.GRAY) does create a greyscale clip but in Gray8 format. If I use core.resize.Bicubic(clp, format=vs.YUV420P16) after it to make the video something to feed to x265, the chroma channels have garbage (green) in them.

[mandarinka]

Usually the "black and white" is a transfer from film or photo material. It is not going to be greyscale in the computer (or YUV) sense of the word.

If you strip the chroma, you will loose that "color" tone of the source, and it is likely not-so-insignificant alteration. So I would not do this, unless you are dealing with actual digital cap of a greyscale computer image and you know that for sure.

Basically, think of "sepia" photos. You also ruin those by insisting on saving them in "BW/greyscale" format.

[Myrsloik]

Originally Posted by Boulder

How to properly do a thing like Greyscale() in Vapoursynth? I've got a movie which is supposedly black and white, but according to the x265 logs, there is data in the chroma channels.

core.std.ShufflePlanes(clips=inclip, planes=0, colorfamily=vs.GRAY) does create a greyscale clip but in Gray8 format. If I use core.resize.Bicubic(clp, format=vs.YUV420P16) after it to make the video something to feed to x265, the chroma channels have garbage (green) in them.

Try R40-RC2

It also fixes the blankclip bug reported by lansing

[Boulder]

Originally Posted by mandarinka

Usually the "black and white" is a transfer from film or photo material. It is not going to be greyscale in the computer (or YUV) sense of the word.

If you strip the chroma, you will loose that "color" tone of the source, and it is likely not-so-insignificant alteration. So I would not do this, unless you are dealing with actual digital cap of a greyscale computer image and you know that for sure.

Basically, think of "sepia" photos. You also ruin those by insisting on saving them in "BW/greyscale" format.

Hmm..that's an interesting point of view. I was asking this because it is the first time for BW movies that I see anything chroma-related in the P/B frame weighting according to x264/x265 logs. Of course, I'll compare the two outputs if I can see any difference.

Myrsloik: thanks, will test it!

[Boulder]

Originally Posted by Myrsloik

Try R40-RC2

It also fixes the blankclip bug reported by lansing

And it works, no more garbage there.

[mandarinka]

It can also contain rainbows and such garbage added in transfer/processing too, in such case, I would try to use derainbowers on it, maybe even strong ones (but not ones that wash out colors in large areas, to be safe).

[Boulder]

Originally Posted by mandarinka

It can also contain rainbows and such garbage added in transfer/processing too, in such case, I would try to use derainbowers on it, maybe even strong ones (but not ones that wash out colors in large areas, to be safe).

I checked many places by comparing the greyscaled and original output and couldn't see any visual differences. Maybe there's just some bluish hue or something like that which is basically impossible to notice even with a frame by frame comparison. Funny thing is that the greyscale version required a slightly more bitrate when I did a short test encode. The UV channels clearly affected the frame type decision.

[Myrsloik]

R40 released. Blog post as usual. Everyone should upgrade since it's a maintenance release.

[hydra3333]

Thank you. In regard to building vapoursynth :-

I think I had been using an incorrect github link for avisynth+

Can you please confirm whether this is the right link ? It seems to have been updated more recently.
https://github.com/pinterf/AviSynthPlus/tree/MT

And this is the right link for zimg I guess.
https://github.com/sekrit-twc/zimg/releases

[Myrsloik]

Originally Posted by hydra3333

Thank you. In regard to building vapoursynth :-

I think I had been using an incorrect github link for avisynth+

Can you please confirm whether this is the right link ? It seems to have been updated more recently.
https://github.com/pinterf/AviSynthPlus/tree/MT

And this is the right link for zimg I guess.
https://github.com/sekrit-twc/zimg/releases

Both are right

[DJATOM]

Myrsloik
I tried to find out why TCPServer fails: https://github.com/DJATOM/TCPDeliver...erver.cpp#L478. I don't know why it crashing on GetFrame call, that code works well on Avisynth.

[pinterf]

Possibly a rare use case in Expr: you cannot use 8-16 bit clips with 32 bit float clips in one expression (working register ordering is the opposite)

[kgrabs]

^ speaking of std.Expr, outputting float from int clips, or vice versa causes some crazy things to happen: http://screenshotcomparison.com/comparison/123935

[Myrsloik]

Originally Posted by kgrabs

^ speaking of std.Expr, outputting float from int clips, or vice versa causes some crazy things to happen: http://screenshotcomparison.com/comparison/123935

Already fixed in git. Same issue as pinterf found.

[Myrsloik]

Originally Posted by DJATOM

Myrsloik
I tried to find out why TCPServer fails: https://github.com/DJATOM/TCPDeliver...erver.cpp#L478. I don't know why it crashing on GetFrame call, that code works well on Avisynth.

Nope, can't figure out exactly why. Couldn't even get it to connect and trigger the error oddly enough. Not going to spend more time on this since it's a great perversion even of the avisynth api...

[lansing]

I have a problem applying multiple instances of the virtualdub filter neatvideo in vapoursynth, it was able to load preview but crash on preview close.

core.avs.LoadPlugin(r"C:\Program Files (x86)\AviSynth+\plugins64+\VDubFilter.dll")
core.avs.LoadVirtualdubPlugin(r'neatvideo.vdf', 'nv', 1)

clipa = core.avs.nv_2(clip, setting_a)
clipb = core.avs.nv_2(clip, setting_b)

clip = clipa + clipb
clip.set_output()

However, saving the filter under a different function name will work:

core.avs.LoadPlugin(r"C:\Program Files (x86)\AviSynth+\plugins64+\VDubFilter.dll")
core.avs.LoadVirtualdubPlugin(r'neatvideo.vdf', 'nv', 1)
core.avs.LoadVirtualdubPlugin(r'neatvideo.vdf', 'nv2', 1)

clipa = core.avs.nv_2(clip, setting_a)
clipb = core.avs.nv2_2(clip, setting_b)

clip = clipa + clipb
clip.set_output()

I first thought that it was a problem with neatvideo and avisynth because it was mentioned on the user manual. But after asking in the neatvideo forum and testing it out in avs+, it actually works without any problem. So I think the problem is from vapoursynth.

Here's the crash log from vs editor

Problem signature:
  Problem Event Name:	BEX64
  Application Name:	vsedit.exe
  Application Version:	18.0.0.0
  Application Timestamp:	59f4da49
  Fault Module Name:	NeatVideo.vdf_unloaded
  Fault Module Version:	0.0.0.0
  Fault Module Timestamp:	540f49bd
  Exception Offset:	000007fed7512d60
  Exception Code:	c0000005
  Exception Data:	0000000000000008
  OS Version:	6.1.7601.2.1.0.256.1
  Locale ID:	1033
  Additional Information 1:	0052
  Additional Information 2:	0052a83208d9c99bc2a54c9c0c8ea3e8
  Additional Information 3:	ce3c
  Additional Information 4:	ce3cde77cba7f1c58c793ecf99d5100f