TFM() and DGSource() for VapourSynth?

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

Originally Posted by 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

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 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.

Originally Posted by 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.

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

Originally Posted by videoh

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 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]

Originally Posted by videoh

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]

Originally Posted by 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.

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

Originally Posted by 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.

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]

Originally Posted by videoh

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]

Originally Posted by 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.

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]

Originally Posted by feisty2

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...