Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
3rd October 2015, 14:29 | #61 | Link |
Pig on the wing
Join Date: Mar 2002
Location: Finland
Posts: 5,730
|
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: Code:
now normalizes the framerate returned from avisynth filters
__________________
And if the band you're in starts playing different tunes I'll see you on the dark side of the Moon... |
3rd October 2015, 14:40 | #62 | Link | |
Professional Code Monkey
Join Date: Jun 2003
Location: Kinnarps Chair
Posts: 2,555
|
Quote:
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.
__________________
VapourSynth - proving that scripting languages and video processing isn't dead yet Last edited by Myrsloik; 3rd October 2015 at 14:54. |
|
3rd October 2015, 18:16 | #63 | Link |
Useful n00b
Join Date: Jul 2014
Posts: 1,667
|
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.
Last edited by videoh; 3rd October 2015 at 23:40. |
4th October 2015, 12:55 | #64 | Link |
Professional Code Monkey
Join Date: Jun 2003
Location: Kinnarps Chair
Posts: 2,555
|
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.
__________________
VapourSynth - proving that scripting languages and video processing isn't dead yet |
4th October 2015, 13:09 | #65 | Link |
Useful n00b
Join Date: Jul 2014
Posts: 1,667
|
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? Last edited by videoh; 4th October 2015 at 13:36. |
4th October 2015, 13:34 | #66 | Link | |||
Registered User
Join Date: Mar 2014
Posts: 308
|
Doom9 is busy being a goldmine of irony these days.
Quote:
Quote:
Quote:
__________________
Say no to AviSynth 2.5.8 and DirectShowSource! |
|||
4th October 2015, 13:45 | #67 | Link |
Useful n00b
Join Date: Jul 2014
Posts: 1,667
|
@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. Last edited by videoh; 4th October 2015 at 14:19. |
4th October 2015, 14:18 | #68 | Link |
unsigned int
Join Date: Oct 2012
Location: 🇪🇺
Posts: 760
|
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.
__________________
Buy me a "coffee" and/or hire me to write code! |
4th October 2015, 14:31 | #70 | Link | |
Useful n00b
Join Date: Jul 2014
Posts: 1,667
|
Quote:
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. Last edited by videoh; 4th October 2015 at 14:53. |
|
4th October 2015, 20:07 | #71 | Link |
Excessively jovial fellow
Join Date: Jun 2004
Location: rude
Posts: 1,100
|
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. |
4th October 2015, 20:35 | #72 | Link |
Professional Code Monkey
Join Date: Jun 2003
Location: Kinnarps Chair
Posts: 2,555
|
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.
__________________
VapourSynth - proving that scripting languages and video processing isn't dead yet |
4th October 2015, 22:45 | #74 | Link |
Registered User
Join Date: Jun 2002
Location: On thin ice
Posts: 6,837
|
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.
__________________
https://github.com/stax76/software-list https://www.youtube.com/@stax76/playlists Last edited by stax76; 4th October 2015 at 22:50. |
5th October 2015, 02:58 | #76 | Link |
Angel of Night
Join Date: Nov 2004
Location: Tangled in the silks
Posts: 9,559
|
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. |
5th October 2015, 11:28 | #77 | Link | |
Registered User
Join Date: Nov 2014
Posts: 440
|
Quote:
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.
__________________
github.com |
|
5th October 2015, 11:58 | #78 | Link | |
Excessively jovial fellow
Join Date: Jun 2004
Location: rude
Posts: 1,100
|
Quote:
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) Last edited by TheFluff; 5th October 2015 at 12:04. |
|
5th October 2015, 22:51 | #80 | Link | |
Registered User
Join Date: Oct 2011
Posts: 204
|
Quote:
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... |
|
Thread Tools | Search this Thread |
Display Modes | |
|
|