TFM() and DGSource() for VapourSynth?

[CarlEdman]

After having used AviSynth for a decade for my video edits, I just discovered VapourSynth and it looks fantastic. Much more modern and compatible and without all the pain and suffering that the various MT/64-bit AviSynth versions involved. Kudos to everybody involved!

However, while a ton of my filters appear to have been converted, there seem to be two filters I really need that don't exist for VapourSynth yet.

(1) For teleciding I use tfm.tdecimate(hybrid=1). Back when I tested all the various teleciders for AviSynth it seemed to be the best and has performed well for all these years. It does the right thing even if the cadence is off and a creditable approximation when there are--as occasionally happens--some genuine interlaced sequences intermixed with the telecined ones.

Is VIVTC an adequate replacement?

(2) My source filter is always DGSource(). I saw that there was a d2vsource() filter which is great, but for modern codecs like h264, you need DGIndexNV/DGSource().

Any work on this or alternatives? FFMS2 could work, I guess, but I do not trust its accuracy as I do DGSource().

[mawen1250]

VFM works much the same as TFM. But compared to TDecimate, VDecimate lacks some important functions (such as vfr mode).

As for source filter:
1. For ts/m2ts input, lsmas.LWLibavSource is a good choice, it's safer than ffms2 when non-linear access occurs.
2. For mp4 input, lsmas.LibavSMASHSource definitely is the best choice.
3. For mkv input, both lsmas and ffms2 are OK.

If you really want to use those AviSynth plugins, it's possible to load them with 32bit VS.
Alternatively, you can try using them in an AviSynth script and loading it with vsavsreader (http://forum.doom9.org/showthread.php?t=165957).

[videoh]

If someone can point me to a guide or documentation for porting filters to VapourSynth, I would consider porting DGDecNV/IM.

[jackoneill]

If someone can point me to a guide or documentation for porting filters to VapourSynth, I would consider porting DGDecNV/IM.

The API documentation (http://www.vapoursynth.com/doc/api/vapoursynth.h.html#writing-plugins) contains some words about writing plugins.

There are lots of filters you can look at for inspiration:
https://github.com/vapoursynth/vapoursynth/tree/master/src/filters
https://github.com/vapoursynth/vapoursynth/tree/master/src/core
In particular, BlankClip (https://github.com/vapoursynth/vapoursynth/blob/master/src/core/simplefilters.c#L1030), because it's a simple source filter.

If you have any questions, feel free to ask.

[Myrsloik]

Don't forget the invert example (https://github.com/vapoursynth/vapoursynth/blob/master/sdk/invert_example.c) which has comments explaining many things.

Otherwise I think blankclip is the best place to start looking since it's a source filter.

[videoh]

Thanks, gents, I'll get cracking on it.

[sl1pkn07]

please. make a miltiplatform plugin. if not, we gain nothing

[CarlEdman]

Thanks, that would be great, videoh!

[videoh]

please. make a miltiplatform plugin. if not, we gain nothing What do you mean by multiplatform?

[sl1pkn07]

can build on linux/macos. no only windows-centric

[Myrsloik]

...
(1) For teleciding I use tfm.tdecimate(hybrid=1). Back when I tested all the various teleciders for AviSynth it seemed to be the best and has performed well for all these years. It does the right thing even if the cadence is off and a creditable approximation when there are--as occasionally happens--some genuine interlaced sequences intermixed with the telecined ones.

Is VIVTC an adequate replacement?


There's a simple reason it doesn't do hybrid things the way you want. It's OBSOLETE. For the past 10+ years (http://forum.doom9.org/showthread.php?t=64440) I've tried to get everyone to embrace VFR. It's really the right thing to do even if it requires a little bit of extra work.

But since you pointed it out I'll make vdecimate export more information so you could create something similar with a script, if that's what you want.

[CarlEdman]

@Myrsloik You are right in principle--VFR really is the way to go with material that genuinely is a mixture between interlaced and telecined material.

Fortunately, these days almost all the material I work on is already either constant 24 frames-per-second progressive or 60 fields-per-second interlaced. Almost all than remains is almost purely 24 frames-per-second telecined to 60 fields-per-second, with no or almost no interlaced material. All of those convert well to constant 24 or 30 progressive frames-per-second. The tiny fraction (about 0% for me in recent years) that does not fit into these categories might convert better to VFR, but then I'd start to worry about compatibility with all my devices and players.

[videoh]

can build on linux/macos. no only windows-centric Ouch, CUVID is Windows only AFAIK. So I would have to re-engineer for VDPAU. And who knows about Mac?

So is there any interest in a Windows-only port?

[sl1pkn07]

In my knowledge, CUVID It exists for linux


/usr/lib/libnvcuvid.so
/usr/lib/libnvcuvid.so.1
/usr/lib/libnvcuvid.so.352.09

/opt/cuda/include/cuviddec.h
/opt/cuda/include/nvcuvid.h
/opt/cuda/samples/3_Imaging/cudaDecodeGL/doc/nvcuvid.pdf


if build '3_Imaging/cudaDecodeGL' sample in CUDA SDK 7.0.28


└───╼ sudo GLPATH=/usr/lib make
[sudo] password for sl1pkn07:
"/opt/cuda"/bin/nvcc -ccbin g++ -I../../common/inc -m64 -gencode arch=compute_20,code=compute_20 -o FrameQueue.o -c FrameQueue.cpp
"/opt/cuda"/bin/nvcc -ccbin g++ -I../../common/inc -m64 -gencode arch=compute_20,code=compute_20 -o ImageGL.o -c ImageGL.cpp
"/opt/cuda"/bin/nvcc -ccbin g++ -I../../common/inc -m64 -gencode arch=compute_20,code=compute_20 -o VideoDecoder.o -c VideoDecoder.cpp
"/opt/cuda"/bin/nvcc -ccbin g++ -I../../common/inc -m64 -gencode arch=compute_20,code=compute_20 -o VideoParser.o -c VideoParser.cpp
"/opt/cuda"/bin/nvcc -ccbin g++ -I../../common/inc -m64 -gencode arch=compute_20,code=compute_20 -o VideoSource.o -c VideoSource.cpp
"/opt/cuda"/bin/nvcc -ccbin g++ -I../../common/inc -m64 -gencode arch=compute_20,code=compute_20 -o cudaModuleMgr.o -c cudaModuleMgr.cpp
"/opt/cuda"/bin/nvcc -ccbin g++ -I../../common/inc -m64 -gencode arch=compute_20,code=compute_20 -o cudaProcessFrame.o -c cudaProcessFrame.cpp
"/opt/cuda"/bin/nvcc -ccbin g++ -I../../common/inc -m64 -gencode arch=compute_20,code=compute_20 -o videoDecodeGL.o -c videoDecodeGL.cpp
"/opt/cuda"/bin/nvcc -ccbin g++ -m64 -gencode arch=compute_20,code=compute_20 -o cudaDecodeGL FrameQueue.o ImageGL.o VideoDecoder.o VideoParser.o VideoSource.o cudaModuleMgr.o cudaProcessFrame.o videoDecodeGL.o -L../../common/lib/linux/x86_64 -lGL -lGLU -lX11 -lXi -lXmu -lglut -lGLEW -lcuda -lcudart -lnvcuvid
mkdir -p ../../bin/x86_64/linux/release
cp cudaDecodeGL ../../bin/x86_64/linux/release
"/opt/cuda"/bin/nvcc -ccbin g++ -I../../common/inc -m64 -gencode arch=compute_20,code=compute_20 -o NV12ToARGB_drvapi64.ptx -ptx NV12ToARGB_drvapi.cu
mkdir -p data
cp -f NV12ToARGB_drvapi64.ptx ./data
mkdir -p ../../bin/x86_64/linux/release
cp -f NV12ToARGB_drvapi64.ptx ../../bin/x86_64/linux/release

see the -lnvcuvid

if run the sample:

└───╼ ./cudaDecodeGL
[CUDA/OpenGL Video Decode]
Command Line Arguments:
argv[0] = ./cudaDecodeGL
[cudaDecodeGL]: input file: <./data/plush1_720p_10s.m2v>
VideoCodec : MPEG-2
Frame rate : 30000/1001fps ~ 29.97fps
Sequence format : Progressive
Coded frame size: [1280, 720]
Display area : [0, 0, 1280, 720]
Chroma format : 4:2:0
Bitrate : 14116kBit/s
Aspect ratio : 16:9


argv[0] = ./cudaDecodeGL

> Device 0: < GeForce GTX 770 >, Compute SM 3.0 detected
>> initGL() creating window [1280 x 720]
> Using CUDA/GL Device [0]: GeForce GTX 770
> Using GPU Device: GeForce GTX 770 has SM 3.0 compute capability
Total amount of global memory: 2039.7773 MB
>> modInitCTX<NV12ToARGB_drvapi64.ptx > initialized OK
>> modGetCudaFunction< CUDA file: NV12ToARGB_drvapi64.ptx >
CUDA Kernel Function (0x01fca330) = < NV12ToARGB_drvapi >
>> modGetCudaFunction< CUDA file: NV12ToARGB_drvapi64.ptx >
CUDA Kernel Function (0x01fd11c0) = < Passthru_drvapi >
Free memory: 1469.9062 MB
> VideoDecoder::cudaVideoCreateFlags = <1>Use CUDA decoder

setTextureFilterMode(GL_NEAREST,GL_NEAREST)
ImageGL::CUcontext = 01d5b7c0
ImageGL::CUdevice = 00000000
reshape() glViewport(0, 0, 1280, 720)
[cudaDecodeGL] - [Frame: 0016, 00.0 fps, frame time: 89543860224.00 (ms) ]
[cudaDecodeGL] - [Frame: 0032, 804.6 fps, frame time: 1.24 (ms) ]
[cudaDecodeGL] - [Frame: 0048, 654.3 fps, frame time: 1.53 (ms) ]
[cudaDecodeGL] - [Frame: 0064, 683.3 fps, frame time: 1.46 (ms) ]
[cudaDecodeGL] - [Frame: 0080, 657.7 fps, frame time: 1.52 (ms) ]
[cudaDecodeGL] - [Frame: 0096, 637.4 fps, frame time: 1.57 (ms) ]
[cudaDecodeGL] - [Frame: 0112, 637.5 fps, frame time: 1.57 (ms) ]
[cudaDecodeGL] - [Frame: 0128, 599.1 fps, frame time: 1.67 (ms) ]
[cudaDecodeGL] - [Frame: 0144, 627.6 fps, frame time: 1.59 (ms) ]
[cudaDecodeGL] - [Frame: 0160, 686.3 fps, frame time: 1.46 (ms) ]
[cudaDecodeGL] - [Frame: 0176, 598.0 fps, frame time: 1.67 (ms) ]
[cudaDecodeGL] - [Frame: 0192, 548.1 fps, frame time: 1.82 (ms) ]
[cudaDecodeGL] - [Frame: 0208, 516.1 fps, frame time: 1.94 (ms) ]
[cudaDecodeGL] - [Frame: 0224, 603.4 fps, frame time: 1.66 (ms) ]
[cudaDecodeGL] - [Frame: 0240, 725.9 fps, frame time: 1.38 (ms) ]
[cudaDecodeGL] - [Frame: 0256, 747.2 fps, frame time: 1.34 (ms) ]
[cudaDecodeGL] - [Frame: 0272, 753.0 fps, frame time: 1.33 (ms) ]
[cudaDecodeGL] - [Frame: 0288, 733.6 fps, frame time: 1.36 (ms) ]
[cudaDecodeGL] - [Frame: 0304, 715.5 fps, frame time: 1.40 (ms) ]
[cudaDecodeGL] - [Frame: 0320, 656.2 fps, frame time: 1.52 (ms) ]

[cudaDecodeGL] statistics
Video Length (hh:mm:ss.msec) = 00:00:00.502
Frames Presented (inc repeats) = 329
Average Present Rate (fps) = 654.13
Frames Decoded (hardware) = 329
Average Rate of Decoding (fps) = 654.13


then i supposed is possible can use CUVID in linux

http://docs.nvidia.com/cuda/samples/3_Imaging/cudaDecodeGL/doc/nvcuvid.pdf

for mac users, i'm not completely sure if cuvid works

greeetings

[captainadamo]

For OS X you'd probably want to use Video Toolbox. Its benefit is also not being tied to any specific hardware vendor. But obviously that makes videoh's porting effort much more difficult.

I've been planning to create such a plugin using it already, but I've just not had the time.

[Asmodian]

Ouch, CUVID is Windows only AFAIK. So I would have to re-engineer for VDPAU. And who knows about Mac?

So is there any interest in a Windows-only port?

I would be quite interested in a Windows-only port, if it was compatible with 64-bit VapourSynth. :)

[stax76]

Is there any HW decoder for VapourSynth x64 on Win10? I'm sure many users are interested especially when there are more 4K sources in the future.

[CarlEdman]

So is there any interest in a Windows-only port?
Any progress on the "promised" DgSource filter for VapourSynth, even if it is Windows-only? As its lack is my only obstacle to switching to VapourSynth from avisynth, I am eagerly anticipating it!

[videoh]

Is there any kind of wrapper in Vaporsynth to use existing Avisynth source filters?

[sneaker_ger]

Write an AviSynth script and use VapourSynth's native AviSource or vsavsreader (http://forum.doom9.org/showthread.php?t=165957).

Or do you mean a wrapper to create a VapourSynth compatible plugin?

[jackoneill]

32 bit VapourSynth for Windows can load many 32 bit Avisynth 2.5 plugins. http://www.vapoursynth.com/doc/functions/loadpluginavs.html

[Reel.Deel]

Since DGSource cannot be loaded in 64-bit VapourSynth I use AVFS (http://www.turtlewar.org/avfs/) to create a fake avi and then load it with AviSource in VapourSynth. Is not as nice as having DGSource natively but this works rather well.

[videoh]

First mistake: I installed Python 3.5 and Vapoursynth barfed on it. Why is Vapoursynth so picky about it?

[Myrsloik]

First mistake: I installed Python 3.5 and Vapoursynth barfed on it. Why is Vapoursynth so picky about it?

Because python is horrible and has no binary compatibility between different versions for modules on windows. That's why. R27 only comes with 3.4 support and it'll take a few more days before my 3.5 support is completely ready.

[videoh]

Making progress (I think). I can type these lines in the interpreter and they all succeed.

core = vs.get_core()
core.std.LoadPlugin('.../ffms2.dll')
ret = core.ffms2.Source(source='file.avi')
ret.set_output()

If I put them into a .py file then how do I open the script in Vdub 64?

Sorry for my ignorance but if y'all can help me y'all will get DGDecNV for Vapoursynth much faster. Thank you.

[Myrsloik]

Making progress (I think). I can type these lines in the interpreter and they all succeed.

core = vs.get_core()
core.std.LoadPlugin('.../ffms2.dll')
ret = core.ffms2.Source(source='file.avi')
ret.set_output()

If I put them into a .py file then how do I open the script in Vdub 64?

Sorry for my ignorance but if y'all can help me you will get DGDecNV for Vapoursynth much faster. Thank you.

You use .vpy as the extension and it'll work in vdub.

[videoh]

Sweet, it works. :)

Off to look at BlankClip and how source filters work...

[videoh]

So, is that ffms2.dll that I got from Git as linked at the Vapoursynth page special for Vapoursynth or is it a standard Avisynth one? The GitHub doesn't look dedicated to Vapousynth and in fact says Avisynth! I am so confused. :confused:

[Myrsloik]

So, is that ffms2.dll that I got from Git as linked at the Vapoursynth page special for Vapoursynth or is it a standard Avisynth one? The GitHub doesn't look dedicated to Vapousynth and in fact says Avisynth! I am so confused. :confused:

It's a combined plugin so it works in both.

[videoh]

That's awesome sauce. I'll make mine that way too. :D

[Boulder]

Sorry for my ignorance but if y'all can help me y'all will get DGDecNV for Vapoursynth much faster. Thank you.You probably don't need to worry about that, I asked DG on his forum and he said that he's going to do it. I expect it to occur rather sooner than later if I read correctly between the lines. Of course, there might be unexpected obstacles but anyway.. :)

[videoh]

Pretty much common knowledge now:

videoh = DG

If that were not the case how could videoh have the source code for DGDecNV? ;)

It's your request over at my forum that got me moving on this here.

[Boulder]

Hehe, I kinda wondered why DGDecNV had suddenly become open source :)

Time for a new nick, perhaps? :D

[videoh]

Time for a new nick, perhaps? :D Yeah, I was thinking of something like 'neuron2'. :p

[Boulder]

I thought you always wanted to go forward, not backward.. :P

[videoh]

neuron3 ? :scared:

OK, let's stay on topic now.

[videoh]

Wow, Vapoursynth is highly cool and not at all hard to code for as I imagined it might be. I've already got the Vapoursynth interface in place and can open a .vpy script with DGDecodeNV.dll and DGSource() and play it in VirtualDub. It plays green frames, though, because I haven't hooked up getFrame to my decoder yet, but that should take only a day or two. Famous last words, I know, but things are progressing nicely. The only challenging thing is to avoid unnecessary code duplication for the Avisynth and Vapoursynth functionalities.

Congratulations to Myrsloik for this excellent frame server project and thanks to him also for his valuable support.

[videoh]

@Myrsloik: Can the per-frame properties be enhanced to contain arbitrary name-value pairs that an app could define? It seems to me that hard-coding the properties precludes future use cases that you may not have anticipated.

[Myrsloik]

Question for Myrsloik:

Is there some reason that the per-frame properties cannot contain arbitrary name-value pairs that an app could define?

You can set any name value pairs you want. The ones listed are only because I want to have them well defined and those names start with _. Anything goes really.

[videoh]

Got it. Thank you.

[Boulder]

While you're designing the native VS build, I have a question regarding Vapoursynth's multithreading and DGSource. Is it generally safe to allow multithreading for DGSource or is it better to use core = vs.get_core(threads=1) before it and core = vs.get_core(threads=-1) afterwards? I assume it's mostly up to the GPU driver but there's no general opinion on this matter.

[Myrsloik]

While you're designing the native VS build, I have a question regarding Vapoursynth's multithreading and DGSource. Is it generally safe to allow multithreading for DGSource or is it better to use core = vs.get_core(threads=1) before it and core = vs.get_core(threads=-1) afterwards? I assume it's mostly up to the GPU driver but there's no general opinion on this matter.

This isn't avisynth. All filters have to specify how they want to be threaded. Only the first get_core() call matters, all arguments are ignored for later calls (you should never need to use any of the arguments apart from when debugging or developing).

[Boulder]

This isn't avisynth. All filters have to specify how they want to be threaded. Only the first get_core() call matters, all arguments are ignored for later calls (you should never need to use any of the arguments apart from when debugging or developing).What about in the case of an Avisynth plugin loaded in Vapoursynth?

[Myrsloik]

What about in the case of an Avisynth plugin loaded in Vapoursynth?

It's still not avisynth.

[videoh]

I don't know enough about Vapoursynth yet to comment with respect to DGSource(). I'll let you know what I discover about it. ;)

[videoh]

Things are looking real good, guys and gals. I am playing video with random access from a .vpy script with 64-bit DGDecodeNV.dll.

The only stuff left is to change the bitblt's for pulldown to Vapoursynth ones (AVSenv->BitBlt is obviously not available) and to implement the debug overlay. Then it's done! :eek:

[Reel.Deel]

Awesome! :thanks:

[MeteorRain]

OMG that's so awesome!

[videoh]

Here is some tasty DGDecodeNV cooked Vapoursynth-style. Your test results will be appreciated. The standard DGIndexNV should be used for indexing. Note that hinting is gone for Vapoursynth as it will be converted to use Vapoursynth per-frame properties.

http://rationalqm.us/misc/DGDecodeNV_Vapoursynth.zip

This is a dual-function DLL for both Avisynth and Vapoursynth. Sample script:

import vapoursynth as vs
core = vs.get_core()
core.std.LoadPlugin('dgdecodenv_vs64.dll')
ret = core.dgdecodenv.DGSource('alba.dgi',debug=1)
ret.set_output()

[MeteorRain]

Here is some tasty DGDecodeNV cooked Vapoursynth-style.

Did a quick test to load a random ts file and a bluray file and it works like a charm. MPEG2 and H.264 source.

[videoh]

Sweet. Thank you for the testing.

[sl1pkn07]

any plans to get plugin for non-windows systems?

[videoh]

Currently, no, but it's not ruled out in the future.

[Boulder]

Thanks for the test build :) Unfortunately it might take me a while to get to test it so you'll probably end up releasing a final build before that.. Nevertheless, great job once again!

[videoh]

I did in fact release it as DGDecNV 2050.

[Boulder]

I didn't want to open a new thread so I'm posting this here since it seems to concern DGSource.

With a simple script,

import vapoursynth as vs
core = vs.get_core()
clp = core.dgdecodenv.DGSource('L:\ALL_ABOUT_EVE\eve.dgi')
clp.set_output()

vspipe throws an error "Specified filter framerate must be normalized" and gives the Windows crash report window. It points to ucrtbase.DLL.

I checked on a different source I happened to have on my computer, and it doesn't have any problems.

I'm using Vapoursynth R28RC1 with Python 3.5 and the latest slipstream of DGDecNV. Can you verify if this is more likely related to VS itself or DGDecNV?

[Myrsloik]

I added an extra check in r28 to make sure a certain framerate only has one representation. It makes checking for the same framerate much easier. Use vs_normalizeRational on the framerate field and it will work.

This change was made to fix things like 60000/2002 not being considered equal to 30000/1001.

[foxyshadis]

So we need to include VSHelper.h and call vs_normalizeRational() anytime the framerate is set? Seems odd to error out and core dump on that, when setVideoInfo calls it anyway.

[videoh]

It's more than odd. Vapoursynth now breaks working filters "to make things easier". It's a terrible precedent that evolution of Vapoursynth can break filters.

If Vapoursynth detects a "non-normalized framerate" (whatever that may be, I have seen no formal explanation) then why can't Vapoursynth normalize it internally if it needs to do so? Instead of having the code once, you require every source filter writer to do it? And for me it's not just the source filter; the indexer component will need to be changed as well (I'm not going to report one frame rate through the GUI and index file and then give a different one to Vapoursynth). Vapoursynth has code to detect a non-normalized rate and throw an error, but not to normalize it? Vapoursynth can't call vs_normalizeRational() itself on the incoming frame rate? That is bizarre.

And what if a stream actually carries a non-normalized framerate? The source filter has to lie about it? I'm not just talking about multiples but also small deviations from exact rates.

Speaking for myself, I have no intention of modifying DGDecNV this way, so if things stand then DGDecNV will be unusable in Vapoursynth (and I'll have a bad taste in my mouth about spending my time supporting Vapousynth). At least I'll save some time by not having to do it again for DGDecIM.

[jackoneill]

It's more than odd. Vapoursynth now breaks working filters "to make things easier". It's a terrible precedent that evolution of Vapoursynth can break filters.

If Vapoursynth detects a "non-normalized framerate" (whatever that may be, I have seen no formal explanation) then why can't Vapoursynth normalize it internally if it needs to do so? Instead of having the code once, you require every source filter writer to do it? And for me it's not just the source filter; the indexer component will need to be changed as well (I'm not going to report one frame rate through the GUI and index file and then give a different one to Vapoursynth). Vapoursynth has code to detect a non-normalized rate and throw an error, but not to normalize it? Vapoursynth can't call vs_normalizeRational() itself on the incoming frame rate? That is bizarre.

And what if a stream actually carries a non-normalized framerate? The source filter has to lie about it? I'm not just talking about multiples but also small deviations from exact rates.

Speaking for myself, I have no intention of modifying DGDecNV this way, so if things stand then DGDecNV will be unusable in Vapoursynth (and I'll have a bad taste in my mouth about spending my time supporting Vapousynth). At least I'll save some time by not having to do it again for DGDecIM.

Oh, come on. It's not the end of the world.

This isn't about small deviations from "exact" rates. You simply need to pick the smallest pair of numbers that represent your frame rate, e.g. 24000/1001 rather than 120000/5005. That's all there is to it.

It's one additional line in the VapourSynth filter, and maybe 10 in the indexer, if you copy vs_normalizeRational..

[Boulder]

Anyway, think about plugins that may not have a maintainer. Or that someone needs to do extra stuff anyway for things to work :)

This part from the R28 release notes doesn't actually say that the plugins need to be corrected:
now normalizes the framerate returned from avisynth filters

[Myrsloik]

Anyway, think about plugins that may not have a maintainer. Or that someone needs to do extra stuff anyway for things to work :)

This part from the R28 release notes doesn't actually say that the plugins need to be corrected:
now normalizes the framerate returned from avisynth filters

I did think about those plugins. I checked the source code of all plugins (where available) and they do it correctly. AFTER that I added the check. To a test version. To see if I forgot anything.

The changelog doesn't have to say anything about it because this requirement is in the api documentation (http://www.vapoursynth.com/doc/api/vapoursynth.h.html#vsvideoinfo) and has been there for a while now. It's simply not proper api usage.

The change is easily motivated by having only a single representation for every framerate. It makes checking if two clips have the same framerate trivial (the most common thing to do with it).

The avisynth wrapper change is obviously needed since I can't change/control avisynth's rules.

[videoh]

Can you please explain why can't you normalize it yourself in Vapoursynth? You do it for Avisynth plugins so it would be reasonable and sensible to do it for Vapoursynth plugins also. Thank you.

[Myrsloik]

I already explained it. It is the API as defined and documented. I simply forgot to explicitly check it it everywhere until recently. I'm actually quite pleased with both the API and jackoneill's good documentation.

[videoh]

You did *not* explain why you can't do it in the core. Seriously, any developer with half a brain can see that enforcing it in the core is the right thing to do.

And you are wrong about what the API specifies. In specifications, "should" specifies only a preference, while a requirement is denoted by "shall". This is basic stuff, codified in national standards.

If you double down on stupid, I'll drop Vapoursynth support, because it will be apparent that Vapoursynth is a hostile environment. I know you're thinking "no big loss" but your users will beg to differ. Is this silliness really explained by the fact that you don't want people to know how bad ffms2 really is compared to DGDec? Or do you still harbor a grudge from the libav takeover/Doom10 days?

[colours]

Doom9 is busy being a goldmine of irony these days.

You did *not* explain why you can't do it in the core. Seriously, any developer with half a brain can see that enforcing it in the core is the right thing to do.

Isn't the whole reason you're bringing this up that the normalisation is being enforced in the core?

In specifications, "should" specifies only a preference, while a requirement is denoted by "shall". This is basic stuff, codified in national standards.

And who's the one doubling down on the stupid here? Let's see what RFC2119 (https://www.ietf.org/rfc/rfc2119.txt) says about "should":

3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

This is clearly not a thing you're following!

[videoh]

@colours

It's obvious that I mean that the normalization should be performed in the core. Myrsloik and everybody else understands that, why don't you?

The use of should versus shall: E.g., MIL-STD-961E and ANSI/IEEE 830-1984. And your reference even confirms my understanding, i.e., "should" does not mean mandatory! It's a sideline point anyway compared to the technical one, but I raised it because Myrsloik brags about his API.

I'm looking for Myrsloik to explain technically why it is better to put this burden on the plugins. He has not answered that and evades doing so. For that reason, I raise doubts about his motives. Review the thread. I have been gracious to Mysrsloik and he responds by killing my plugin. And have you read the guy's blog? He disses respected developers like tritical [author of TFM(), subject of this thread] that have given so much to our community.

[jackoneill]

Maybe it's not nice for VapourSynth to change the numbers set by the plugin writer. Maybe it is nice that VapourSynth tells the plugin writer when the plugin is generating a weird frame rate.

[feisty2]

I'm looking for Myrsloik to explain technically why it is better to put this burden on the plugins.

because people tend to be lazy
vaporsynth is free and open source, Myrsloik can't get no money out of it. He's doing it like a hobby.
and hobbies don't last
:)

[videoh]

Maybe it's not nice for VapourSynth to change the numbers set by the plugin writer. Maybe it is nice that VapourSynth tells the plugin writer when the plugin is generating a weird frame rate. Are you kidding? The plugin is not generating a weird frame rate. It simply passes the frame rate from the stream, and it is not "weird" in any way.

The only reason the frame rate needs to be changed is that the code *inside Vapoursynth* that compares frame rates is so difficult for Myrsloik to implement that he forces this abortion on us. Here I will help him. Inside the core, change:

existing code to compare frame rates

to

muldivRational(&VI[0].fpsDen, &VI[0].fpsNum, 1, 1);
existing code to compare frame rates

He won't do it because he is stubborn and can't admit when he is wrong. And to defend the nonsense he is willing to break existing plugins, a terrible precedent for Vapoursynth that has a chilling effect on plugin writers. I suggest that you have a private chat with him and try to bring him to his senses.

[TheFluff]

Of all the hills you could have chosen to die on, videoh, was it really the one about refusing to implement a one-line fix to normalize a rational number that was the most important one to you? I get it that you can't turn around on this one now because you've already thrown all your prestige at it, but it's a really, really silly issue to hurf a durf about and you're acting like a gigantic baby.

I'm not sure if you're being deliberately obtuse or if you actually can't see why letting plugins set a non-normalized framerate in the videoinfo struct is a bad idea, so I'll just point out that VapourSynth itself is not the only thing that might want to use the framerate field. The API enforcing that plugins set sane and valid values in the videoinfo is a much better policy than everyone having to do their own sanity checking. In Avisynth a lot of things are never checked for sanity and that's why you get hacks like that silly flipvertical plugin that sets negative pitch by abusing subframeplanar(), leading to a very ambigous and weird situation where data created by one plugin might break others down the line because the API is a lawless Wild West. Needless to say, this is not Avisynth, and we do things differently here.

[Myrsloik]

This is too much for simple guinea pig herder such as myself. Of all the things listed I'm only responsible for one little muldivrational ruining your day. The rest must be the universe hating you.

But now to deal with some of your claims that are HI-LOL-LARIUS.

"Is this silliness really explained by the fact that you don't want people to know how bad ffms2 really is compared to DGDec?"
Check the FFMS2 manual (https://github.com/FFMS/ffms2/blob/master/doc/ffms2-avisynth.md) which in no uncertain terms state how unreliable it is for some formats. Check the revision history too and I'd hardly call that a well kept secret.

"Or do you still harbor a grudge from the libav takeover/Doom10 days?"
I have never been directly involved in ffmpeg, libav or any other fork you can stick that name on. Not really indirectly either. I did hope the libav fork would procure a bit of sanity but that obviously didn't happen.

And since when is starting an alternative website a takeover? Oh, and I didn't start it or do much to keep it running or anything else for that matter. I did a few posts but that place died quickly. I guess people missed all the rule 6 violations on d9 and got bored.

What else did you claim? Something about pouring hate on Tritical (http://www.vapoursynth.com/2012/10/open-binary-introducing-a-practical-alternative-to-open-source/)? He's actually a pretty cool guy with some nice ideas. He even let me relicense the core of TIVTC for use in VIVTC. Unfortunately he didn't (no idea about his recent work) write easily readable and maintainable code. Objective fact. Grab any sane book about programming and you won't find those patterns in there. But here comes the PLOT TWIST!

...actually the plot twist was a lie. Just read it again and you'll see it's only a commentary against the unfortunate state of most open source software that can't be reused in meaningful ways. TIVTC just happened to be the code I was looking at that week. Feel free to do a similar one with my old code. That old YATTA code isn't going to have snarky comments inserted all over its horrible state stored in GUI controls without your help!

For someone who likes to argue what words mean you sure have no clue about how "donation" is usually used either. Fortunately my own projects don't run on "donations" but instead run on DESPAIR AND HATE ON INTERWEB FORUMS. Occasionally supplemented by a small donation though.

[videoh]

It's OK, I can live without Vapoursynth. Forgive me for trying to help make it better. I won't make that mistake again.

[stax76]

I'm not a plugin programmer but I would probably prefer implicit normalization, it looks simpler for plugin authors and doesn't break existing plugins.

[TheFluff]

It's OK, I can live without Vapoursynth. Forgive me for trying to help make it better. I won't make that mistake again.

don't let the door hit you on your butt on your way out

[foxyshadis]

I'm not going to climb up on a cross over the issue, but I still think that it's not a reasonable requirement when VapourSynth itself calls the framerate reduction function vs_normalizeRational() itself, in order to test whether the plugin author did. Making it a fall-over-and-crash error via vsFatal? That's kind of insane. vsFatal is used a little too often in the codebase as it is, I think; abort() is overkill, since that will terminate any host, including an editor that could otherwise show a much more sensible error, or take another action, especially since it already follows assert(false) for debugging. I would reserve vsFatal specifically for detection of memory corruption, MMX state corruption, and other unrecoverable errors. I don't see why an unnormalized frame rate can't be vsWarning().

Since VS is doing it anyway, why not just use that result? Instead of making plugin authors either reimplement it or incorporate extra non-default headers? I mean, the fact that you're already normalizing the value yourself means that there's no longer a possibility of having to compare the wrong way anymore.

[Khanattila]

Are you kidding? The plugin is not generating a weird frame rate. It simply passes the frame rate from the stream, and it is not "weird" in any way.

The only reason the frame rate needs to be changed is that the code *inside Vapoursynth* that compares frame rates is so difficult for Myrsloik to implement that he forces this abortion on us. Here I will help him. Inside the core, change:

existing code to compare frame rates

to

muldivRational(&VI[0].fpsDen, &VI[0].fpsNum, 1, 1);
existing code to compare frame rates

He won't do it because he is stubborn and can't admit when he is wrong. And to defend the nonsense he is willing to break existing plugins, a terrible precedent for Vapoursynth that has a chilling effect on plugin writers. I suggest that you have a private chat with him and try to bring him to his senses.

For me, implicit conversions, implicit casting, implicit saturation, implicit clamping are the worst part of this world.

I can not waste a day to understand what is not working in my program because somewhere there's a fucking operation that sends everything to hell.

On this basis Myrsloik builds VapourSynth. All my support.

[TheFluff]

I'm not going to climb up on a cross over the issue, but I still think that it's not a reasonable requirement when VapourSynth itself calls the framerate reduction function vs_normalizeRational() itself, in order to test whether the plugin author did. Making it a fall-over-and-crash error via vsFatal? That's kind of insane. vsFatal is used a little too often in the codebase as it is, I think; abort() is overkill, since that will terminate any host, including an editor that could otherwise show a much more sensible error, or take another action, especially since it already follows assert(false) for debugging. I would reserve vsFatal specifically for detection of memory corruption, MMX state corruption, and other unrecoverable errors. I don't see why an unnormalized frame rate can't be vsWarning().

Since VS is doing it anyway, why not just use that result? Instead of making plugin authors either reimplement it or incorporate extra non-default headers? I mean, the fact that you're already normalizing the value yourself means that there's no longer a possibility of having to compare the wrong way anymore.

Nobody cares about warnings, though. As proven by Avisynth, if you allow people to do retarded things with the API (warning or no warning), they will happily do so and accuse you of being a fascist if you complain about it. Crashing and burning is the only way to force people to do the right thing.

Vapoursynth is much like Soviet Russia: the state (API) knows what is best for you and will send you to Gulag if you flirt with capitalism (dumb things).

(among javascript hipsters this is sometimes referred to as an "opinionated api" but if you use that term you're probably a douchebag)

[feisty2]

Crashing and burning is the only way to force people to do the right thing.
no offense but, that sounds like, real nazism

[DarkSpace]

Crashing and burning is the only way to force people to do the right thing.
no offense but, that sounds like, real nazism

And the Soviet Russia part sounds perfectly normal to you, does it?

You have to see this extract in context to understand it, so I'll explain that context to you:
The entire post aims to explain why it is a good thing to impose certain restrictions in the API. The point is that when undesired behaviour is detected, the API should complain. Loudly. This is the part where things "crash and burn" because someone exhibited undesired behaviour.
And the part about forcing people to do the right thing is easily explained by examining the consequences of "crashing and burning" the moment such wrong behaviour is detected: In order to produce a product that doesn't "crash and burn", only right behaviour must be used.

As a side note, I certainly am no Nazi, but I, too, have the completely rational desire to burn certain things or people from time to time. Usually, those things or people exhibit extremely dumb behaviour, in a way that directly affects me (or the sorry remnants of my sanity). There's nothing inherently wrong with that, you just need to convert those impulses into something useful. Such as a temple where such people can burn without annoying the neighbours with their death cries...:devil:

[TurboPascal7]

I don't think anybody is disagreeing that API should detect certain errors and complain about them loudly. That's perfectly reasonable unless you want to end up with something like PHP.

What everybody is pissed about is two things. First, the particular restriction seems a bit silly. The end result is that the core will always only work with (and provide to others) normalized framerates, so whether the plugin itself or the core does it is irrelevant, except the core could do it once and every plugin ever would get this functionality for free, while now the plugins have to implement the check independently in every single codebase. You might argue that this is perfectly in line with the "do the adjustment yourself (http://www.vapoursynth.com/doc/avisynthcomp.html)" philosophy of vapoursynth and you would be absolutely right, which doesn't mean everybody should be happy about this.

And more importantly, the API compatibility is broken again. The project is four years old and still hasn't had a single stable version. Everybody laughed at avisynth 2.6 being in alpha for god knows how many years but suddenly it's fine for vapoursynth. Not to mention that there's no vsynth 2.5.8, so if anybody wants a stable API that won't silently break in three months his only choice is to abandon the ship.

But again, this is perfectly consistent with what vsynth has been doing so far and in fact nobody promised a stable API for plugin developers. So in some sense, n2 is at fault here and he got what was coming to him. Whether you actually want to blame n2 or see a larger problem here is an exercise for the reader.

[Myrsloik]

This is different. I went through and started cleaning up the frame time and framerate mess almost half a year ago. All relevant (because no we're only talking about source and framerate modifying filters) plugin authors spotted it and updated their plugins without me having to say anything. That was maybe 4 months ago all that got done I think. The API documentation was updated 5 months ago.

Then fast forward to about right now. Someone shows up and writes a single new plugin that doesn't follow it. And demands that I add a workaround nothing else needs for something that is documented. What is my motivation?

How long has the latest AVS+ build been broken now? You can complain all you want about my project since I don't live for e-praise. But remember this. Your AVS+ co-creation is now doomed to be yet another open binary (http://www.vapoursynth.com/2012/10/open-binary-introducing-a-practical-alternative-to-open-source/) mildly incompatible (http://forum.doom9.org/showthread.php?p=1741742#post1741742) avisynth version the masses here will still somehow try to make work. In the most arcane ways possible. Probably by passing stuff between different avisynth installs or something. You read the future here first. (unless it's already happened, in that case I apologize for claiming to see the future when I clearly didn't)

[hydra3333]

... but I would probably prefer implicit normalization, it looks simpler for plugin authors and doesn't break existing plugins.

+1

and now I will REALLY miss the ever so useful dgindexNV stuff ... can't you PLEASE have a little bit of flexibility and understanding of people and forgiveness ?

... I was in IT project mgt in the 90's and FMD did I have a real and present dislike of ideological positions getting in the way of great outcomes. It feels like one of those things just happened here :( Foot, firearm, aim, bang.

[Boulder]

Yes, there's no real alternative for DGDecNV I'm afraid.

To be honest, I don't understand the "This is not Avisynth so.. / Avisynth scripts are ugly and from the yucky '90s so.. " argument that certain people like to throw around here. What I feel now is that many users will not make the switch from Avisynth to Vapoursynth any time soon :(

[Mad_Hatter]

+1

and now I will REALLY miss the ever so useful dgindexNV stuff ... can't you PLEASE have a little bit of flexibility and understanding of people and forgiveness ?

... I was in IT project mgt in the 90's and FMD did I have a real and present dislike of ideological positions getting in the way of great outcomes. It feels like one of those things just happened here :( Foot, firearm, aim, bang.

There was no real change in the API of Vapoursynth, the only thing that actually got changed is that now the same API rules about framerate are properly checked in order for filter/program writers to pass a normalized framerate(30000/1001 instead of 60000/2002 for example). Now a plugin writers come, ignores the API docs where it is clearly stated that clips should have a normalized framerate(again, this was *already* in the API, it just wasn't *enforced*), and demands an implicit workaround that works *only* for his plugin(because everything else works) because he doesn't want to copypaste a single line of code in his source filter, and maybe some more(still copypaste) in his program. Now *that* would set a precedent which isn't good imho, just because someone has made useful plugins/programs doesn't mean you can break documented API because his/her programs/filters are good. Also, Vapoursynth is not some kind of enterprise program which must mantain legacy compatibility for millennia just for the sake of it, or we will have another avisynth in a pythonic fashion, which defeats the point of an alternative. Again that's my view on the matter.

[feisty2]

@Boulder and hydra3333
there's the avsreader plugin (works at both x86 and x64) allows you to connect to dg stuff via avisynth, if you really need that

[TheFluff]

Yes, there's no real alternative for DGDecNV I'm afraid.

To be honest, I don't understand the "This is not Avisynth so.. / Avisynth scripts are ugly and from the yucky '90s so.. " argument that certain people like to throw around here. What I feel now is that many users will not make the switch from Avisynth to Vapoursynth any time soon :(

To be brutally honest the biggest problem with Avisynth is the users. They know just enough to be dangerous and have seemingly infinite time to spend on insanities. By making Vapoursynth hard to use if you don't actually understand what you're doing we can kinda avoid that problem.

e:
You might argue that this is perfectly in line with the "do the adjustment yourself (http://www.vapoursynth.com/doc/avisynthcomp.html)" philosophy of vapoursynth and you would be absolutely right, which doesn't mean everybody should be happy about this.
My first programming language was Perl, back in the early 00's. In one of my early scripts I wanted to use the trigonometric tangent function for some reason (I was in high school at the time so it probably had something to do with something we did in math class). I was surprised to find that Perl didn't (and still does not) have a builtin tan() function. It only has sin, cos and atan2. Back then I thought that was kinda dumb, but now I'm inclined to think that Larry Wall was right all along. Using only those three and sqrt(), you can (as the Perl manual points out) use a few "familiar relations" to compute the other three (tan/asin/acos). Back then those relations weren't that familiar to me, but I got the point - it was something I should have known. If you want to program, you need to understand what you're doing, and removing the training wheels helps with that.

[Boulder]

To be brutally honest the biggest problem with Avisynth is the users. They know just enough to be dangerous and have seemingly infinite time to spend on insanities. By making Vapoursynth hard to use if you don't actually understand what you're doing we can kinda avoid that problem.And there lies Vapoursynth's problem: does it want to be a one-for-all solution or the Linux of video processing (talking about Linux before the fancy GUIs)?

Heck, I've had problems with grasping the VS basics and I've been programming small things on and off since the 90s :o I must admit that I wouldn't have switched unless I had had to do some Python scripting at work quite recently.

Gotta check avsreader, fortunately DGSource is not the unstable thing in Avisynth.

[feisty2]

Heck, I've had problems with grasping the VS basics and I've been programming small things on and off since the 90s :o
And I was born in the late 90s, I couldn't even talk the time that you had mastered some programming skills
And now I have written some wicked complex vaporsynth scripts and modified some "terrifying" vaporsynth plugins, and I don't feel hard to do any of these
It's just a matter of, willing to learn or not

[Boulder]

It's just a matter of, willing to learn or notAs you get older, you probably find out that the time you can spend on such things might get a substantial cut :D

I do like programming and trying to understand stuff, but I'm afraid Joe Average is usually just trying to get by. Of course, someone might come with a GUI-type solution to overcome the issue.

What I'm worried about is that a good basis is created in vain if the userbase doesn't grow enough. If Myrsloik is the only developer, there's always the risk..

[feisty2]

Actually there's something far worse than the whole avisynth situation
It's the JPEG image
jpg is old and obsolete and it sucks, there're like a million other codecs that are way better than jpg
And jpg is still the most popular image codec

[MeteorRain]

It's completely normal for a video clip to have a fps like 120000/5005. Couldn't see the point to enforce filters to normalize it.

I can live with R27 for the next few months but I can't bear to not have a source filter to decode my files for a few months.

Besides, if the restriction in API has been a while, then that's exactly the proof of a changing API specification. And now, a changing API implementation of that specification.

[Khanattila]

There was no real change in the API of Vapoursynth, the only thing that actually got changed is that now the same API rules about framerate are properly checked in order for filter/program writers to pass a normalized framerate(30000/1001 instead of 60000/2002 for example). Now a plugin writers come, ignores the API docs where it is clearly stated that clips should have a normalized framerate(again, this was *already* in the API, it just wasn't *enforced*), and demands an implicit workaround that works *only* for his plugin(because everything else works) because he doesn't want to copypaste a single line of code in his source filter, and maybe some more(still copypaste) in his program. Now *that* would set a precedent which isn't good imho, just because someone has made useful plugins/programs doesn't mean you can break documented API because his/her programs/filters are good. Also, Vapoursynth is not some kind of enterprise program which must mantain legacy compatibility for millennia just for the sake of it, or we will have another avisynth in a pythonic fashion, which defeats the point of an alternative. Again that's my view on the matter.
Summary of the thread.

[Mad_Hatter]

It's completely normal for a video clip to have a fps like 120000/5005. Couldn't see the point to enforce filters to normalize it.

I can live with R27 for the next few months but I can't bear to not have a source filter to decode my files for a few months.

Besides, if the restriction in API has been a while, then that's exactly the proof of a changing API specification. And now, a changing API implementation of that specification.

I' curious now, in which occasion should a filter pass a non-normalized framerate and why would you want to keep it non-normalized resorting to an implicit conversion in the core?

[foxyshadis]

This is different. I went through and started cleaning up the frame time and framerate mess almost half a year ago. All relevant (because no we're only talking about source and framerate modifying filters) plugin authors spotted it and updated their plugins without me having to say anything. That was maybe 4 months ago all that got done I think. The API documentation was updated 5 months ago.

Then fast forward to about right now. Someone shows up and writes a single new plugin that doesn't follow it. And demands that I add a workaround nothing else needs for something that is documented. What is my motivation?

How long has the latest AVS+ build been broken now? You can complain all you want about my project since I don't live for e-praise. But remember this. Your AVS+ co-creation is now doomed to be yet another open binary (http://www.vapoursynth.com/2012/10/open-binary-introducing-a-practical-alternative-to-open-source/) mildly incompatible (http://forum.doom9.org/showthread.php?p=1741742#post1741742) avisynth version the masses here will still somehow try to make work. In the most arcane ways possible. Probably by passing stuff between different avisynth installs or something. You read the future here first. (unless it's already happened, in that case I apologize for claiming to see the future when I clearly didn't)

Still doesn't explain the use of vsFatal to crash any host when importing a function that works fine in R27, instead of showing an error and allowing the user to correct it. Also doesn't address the fact that VS already internally normalizes framerates, only to use it as a cudgel to check whether every other plugin did their own attempt at the same, instead of just saving the effort all around and making its own implementation standard and automatic.

I can't help but feel like this is a middle finger to users and plugin writers, given that you already do the math internally.

because he doesn't want to copypaste a single line of code in his source filter, and maybe some more(still copypaste) in his program.

It's 25 lines in VapourSynth's implementation, and copy-paste of any multi-line function is anathema to good practice. Even if you go outside the standard header to merely include VS's implementation, it's still three lines. The rest of your rant is basically a defense of intentionally screwing with users every release, just because you can, rather than accidentally doing so or doing it because it's the only way.

[nu774]

Well actually, L-SMASH works had at least one path that didn't normalize fps, so it DID break things.
It's already fixed in this commit, but it's only 12 days old and you need rather recent build to avoid issues.
https://github.com/VFR-maniac/L-SMASH-Works/commit/10bab279192acb181db2995f3903c20fb9643dc3

[hydra3333]

@Boulder and hydra3333
there's the avsreader plugin (works at both x86 and x64) allows you to connect to dg stuff via avisynth, if you really need that
Thanks.

[MeteorRain]

I' curious now, in which occasion should a filter pass a non-normalized framerate and why would you want to keep it non-normalized resorting to an implicit conversion in the core?

I'm not saying that I want it. I'm saying that I don't see the point to enforce normalized framerate (and if you don't comply to the law, screw you up, BOOM).

EDIT:

And if you really want to know the consequence, then a non-normalized framerate can affect timebase of the encoder.
It's hard to tell what's the consequence of a different timebase generated, but that still make differences in the output file.
In short, it creates side effects.

[AzraelNewtype]

I'm not saying that I want it. I'm saying that I don't see the point to enforce normalized framerate (and if you don't comply to the law, screw you up, BOOM).

EDIT:

And if you really want to know the consequence, then a non-normalized framerate can affect timebase of the encoder.
It's hard to tell what's the consequence of a different timebase generated, but that still make differences in the output file.
In short, it creates side effects.

Your edit seems to be a pretty good case for enforcing it, right under a post saying you don't see the point in enforcing it.

[MeteorRain]

Your edit seems to be a pretty good case for enforcing it, right under a post saying you don't see the point in enforcing it.

I can't understand where the conclusion came from. I'm saying that if I want to keep 120000/5005 frame rate and get it passed to the encoder to generate a video with 5005/120000 timebase instead of 1001/24000, why do you think this is a good case to normalize the it?

[mastrboy]

I really don't care who's in the right here, but in the end those who suffer from this little argument/stubbornness is unfortunately the users :(

[Boulder]

I added an extra check in r28 to make sure a certain framerate only has one representation. It makes checking for the same framerate much easier. Use vs_normalizeRational on the framerate field and it will work.

This change was made to fix things like 60000/2002 not being considered equal to 30000/1001.How to use that function to correct these issues? Or is it even possible without a new DGDecNV build?

[hydra3333]

Hello, seeking clarification ... where am I mis-understanding ?

This http://rationalqm.us/board/viewtopic.php?f=8&t=441 and this thread here http://forum.doom9.org/showthread.php?p=1741851#post1741851 both indicate DGdecNV will not be supported in VapourSynth.

This http://forum.doom9.org/showthread.php?p=1741853#post1741853 says use avsreader as a workaround (thanks).

This http://www.animemusicvideos.org/forum/viewtopic.php?f=118&t=125039#p1546405 indicates non-NV DGMPGDec can be used OK in VapourSynth, eg MPEG2Source("c:\path\file.d2v",info=0,ipp=true,cpu=0)

This (4 Mar 2016) http://forum.doom9.org/showthread.php?p=1759402#post1759402 seems to indicate that DGdecNV is supported in VapourSynth because it shows how to use it (code below) and says "DGSource works fine btw".
import vapoursynth as vs
core = vs.get_core()
core.std.LoadPlugin(r'D:\Software\Medien\DGDecNV\DGDecodeNV.dll')
clip = core.dgdecodenv.DGSource(r'D:\Temp\Video\00009 temp files\00009.dgi')
clip = core.vivtc.VFM(clip, 1)
clip = core.vivtc.VDecimate(clip)
clip.set_output()

Reminder for future self:
DGIndex.exe produces .d2v files and is paired with MPEG2Source like
MPEG2Source("%pard2v%",info=0,ipp=true,cpu=6) # DEBLOCK and DERING

DGIndexNV.exe produces .dgi files and is paired with DGsource like
DGSource("%pardgi%",deinterlace=2,resize_w=%Width%,resize_h=%Height%) #deinterlace=2 means double rate deinterlacing

So, can someone please confirm which DG things will and will not work in VapourSynth ?

Thanks to you.

[Myrsloik]

Plain dgdecode works. I tested it myself long ago. The nv version I've never tried since I don't have a suitable graphics card but I think som people have had success with it.

Either way, if they're broken you'll most likely get an instant crash which is hard to miss. Plain dgmpgdec does have a quirk that it doesn't apply user/file specific cropping so you have to do that yourself.

Or just use d2vdecode.

[hydra3333]

Plain dgdecode works.
Or just use d2vdecode.
Thank you.

[Elegant]

@hydra3333 DGDecodeNV works fine IF you are using the release of VapourSynth and version of DGDecodeNV that supports it (R26 and rev 2051 I think; whatever stuff is in that version of StaxRip). I'm still amazed this feud is going on for this plugin. I don't see how having multiple releases of a project is bad (was easy to maintain for the ones I updated) nor do I see how performing your own frame rate normalization to be a "hack", I consider it a standard.

The most amazing part to me is that you have this plugin that requires a license but you'd rather screw yourself out of that income... Worthwhile plugin, just don't grasp the argument for a standalone/no "hack" version.

[hydra3333]

I see there's a new version of DGDecodeNV and a suggestion to try it out.

[Elegant]

I see there's a new version of DGDecodeNV and a suggestion to try it out.

Just tried this out; no dice. Not sure what's causing this but this is the error:

Failed to evaluate the script:
Python exception: No entry point found in C:\Program Files (x86)\VapourSynth\plugins64\DGDecodeNV.dll
Traceback (most recent call last):
File "src\cython\vapoursynth.pyx", line 1491, in vapoursynth.vpy_evaluateScript (src\cython\vapoursynth.c:26905)
File "\\FreeNAS\Users$\Shane\Desktop\Fate-Stay Night.vpy", line 9, in <module>
core.std.LoadPlugin(r'C:\Program Files (x86)\VapourSynth\plugins64\DGDecodeNV.dll')
File "src\cython\vapoursynth.pyx", line 1383, in vapoursynth.Function.__call__ (src\cython\vapoursynth.c:25212)
vapoursynth.Error: No entry point found in C:\Program Files (x86)\VapourSynth\plugins64\DGDecodeNV.dll

EDIT: Found the solution over here (http://forum.doom9.org/showthread.php?p=1781505#post1781505).

[hydra3333]

You mentioned re 64-bit DGDecodeNV :-
..., I am able to load avsplugin, I just replaced "core.dgdecodenv.DGSource" with "core.avs.DGSource"

core.avs.LoadPlugin(path=r'D:\DGDecodeNV.dll')
vid = core.avs.DGSource(dgi=r'D:\0_eng2.dgi')

Great !
Does the latest 64bit DGDecodeNV.dll plugin work OK with the latest vapoursynth ?

I'm re-looking at using it now for GPU enabled decoding/deinterlacing/resizing.
eg in a windows .bat file
#video = core.avs.DGSource(r'%pardgi%',deinterlace=1) # deinterlace=1 means single rate deinterlacing
#video = core.avs.DGSource(r'%pardgi%',deinterlace=2) # deinterlace=2 means double rate deinterlacing, beware extra frame at 0
#video = core.avs.DGSource(r'%pardgi%',deinterlace=2,resize_w=720,resize_h=576) # deinterlace=2 means double rate deinterlacing, beware extra frame at 0
#If using double-framerate NV, fix the double-framerate bug in NV per http://forum.doom9.org/showthread.php?p=1391556#post1391556 like this
#video = core.std.Trim(video,first=1)

As far as I know my sources are all vanilla 25fps interlaced, so hopefully I can ignore the framerate normalization issue stuff per http://forum.doom9.org/showthread.php?p=1741368#post1741368 ?