RFE :- FrameRateNumerator() and FrameRateDenominator() functions

[IanB]

Given the FrameRate() function returns quite limited precision, less then 32 bit float, can functions for FrameRateNumerator() and FrameRateDenominator() be include in the scripting interface to provide access to the maximum precision available.

I have logged a RFE on sourceforge:- "[ 980307 ] FrameRate Numerator & Denominator script functions" with attached updated script.cpp and script.h files that implement these 2 extra functions.
See:- http://sourceforge.net/tracker/index.php?func=detail&aid=980307&group_id=57023&atid=482676

In addition in order to maximise the restricted precision the code for FrameRate() has been modified to perform the division of numerator by denominator using double precision which finally in turn is reduced to a float.

Also included is an alternate version of AudioLength(), called AudioLengthF(), which returns a float. Although of limited precicion, it does not become negative when more than 2^31 samples are present and gives the correct order of magnitude. (Devious scripting using both functions and modulo arithmetic can represent the exact audio sample count if required).

IanB

[sh0dan]

Great! I'll add it ASAP!

[esby]

That sounds a good idea,
but I just hope it will not gives more synchronisation issues when using textsub or other timed subtitler...

esby

[IanB]

Esby,

Shouldn't be a problem, these functions just expose the existing variables to the scripting language.

Anybody writing cunning scripts can now achieve the maximum accuracy possible.

IanB

[scharfis_brain]

some time ago, I had to deal with some NTSC clips, that seemed to had the true framerate of 30/1.001 = 29.97002997
creating a blankclip with exactly that framerate wasn't possible....
so, I got an error when trying to merge the original & the blankclip together, cause the created blankclip only was 29.97 fps instead of 29.97002997

(my function unblendpattern() suffers this problem)

[stickboy]

So after IanB added the FrameRateNumerator and FrameRateDenominator functions, I thought: oh good, now I can write user-defined function that overloads AssumeFPS:
function AssumeFPS(clip clipToModify, clip clipToMatch)
{
return clipToModify.AssumeFPS(clipToMatch.FrameRateNumerator(),
\ clipToMatch.FrameRateDenominator())
}Because after all, that's almost always what people really want to do with AssumeFPS, right?

But after some thought, I think that although it can be written as a user-defined function, it probably is better as an internal function. I know Bidoche prefers otherwise (http://forum.doom9.org/showthread.php?s=&threadid=78365#post513573), but my reasoning is that overloading internal functions with user-defined ones can be too confusing to readers.

Anyhow, it's trivial to implement, but I made some diffs (http://www.avisynth.org/stickboy/tmp/fps.diff) anyway if someone feels like merging it in.

[sh0dan]

Originally posted by stickboy
Anyhow, it's trivial to implement, but I made some diffs (http://www.avisynth.org/stickboy/tmp/fps.diff) anyway if someone feels like merging it in.

Nice addition! Merged!

Edit: Have you tested what happends if there is no video in the supplied clip? :D I added a check.