TFM() and DGSource() for VapourSynth?

[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?