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. |
|
|
Thread Tools | Search this Thread | Display Modes |
27th December 2005, 11:50 | #1 | Link |
Registered User
Join Date: Nov 2001
Posts: 9,770
|
avs devs: plz integrate nicefps() into changefps()/assumefps()
changefps/assumefps() allow to input float fps and people make extensively use of this
now the problem is that it doesnt seem to output for eg 23.976 the standard 24000/1001 numerator,denominator but some other high values this now leads to that for example the x264 encoder is forced to use 64bit precision times, which again causes players like mplayer or quicktime not handling these 64bit, but expecting 32bit, to bork now we had lots of people reporting problems in the mpeg-4 avc forum reporting these problems and they could be tracked down to the useage of change/assumefps() with float fps input or with input .avi files that have been created from such scripts now there are three solutions for fixing this: 1) make the whole world use change/assumefps(24000/1001) instead of changefps(23.976) or similar for other framerates 2) make the whole world use the nicefps() filter, as discussed here, which scales the framerate in a "nice" way 3) change the behaviour of change/assumefps() to not output these big values anymore by maybe integrating the nicefps()'s function into change/assumefps() or making change/assumefps process the string itself instead of using float math now i would be really happy if 3) could be done (as 1) and 2) is surely impossible), cause it would remove like "50%" of the x264 error reports
__________________
Between the weak and the strong one it is the freedom which oppresses and the law that liberates (Jean Jacques Rousseau) I know, that I know nothing (Socrates) MPEG-4 ASP FAQ | AVC/H.264 FAQ | AAC FAQ | MP4 FAQ | MP4Menu stores DVD Menus in MP4 (guide) Ogg Theora | Ogg Vorbis use WM9 today and get Micro$oft controlling the A/V market tomorrow for free |
27th December 2005, 12:50 | #2 | Link |
AviSynth Enthusiast
Join Date: Jul 2002
Location: California, U.S.
Posts: 1,267
|
If only AviSynth used doubles instead of floats, then it more easily could rationalize 23.976 to 2997/125.
Overloading AssumeFPS to take a string might be okay (please, don't add any more *FPS functions), but then you still have the problem of educating people to use it. |
27th December 2005, 13:49 | #3 | Link | ||
Avisynth 3.0 Developer
Join Date: Jan 2002
Location: France
Posts: 639
|
Quote:
Users generally mean 24000/1001 when they put 23.976 and not 2997/125. Besides FPS is rational, not float or even double, every api with some sense use it like that. VFW certainly does, avs should do the same (3.0 does) Quote:
|
||
27th December 2005, 15:43 | #4 | Link | |
Registered User
Join Date: Dec 2003
Location: MO, US
Posts: 999
|
Quote:
Code:
double n = args[1].AsFloat(); int d = 1; while (n < 16777216 && d < 16777216) { n*=2; d*=2; } return new AssumeFPS(args[0].AsClip(), int(n+0.5), d, args[2].AsBool(false), env); Code:
double n = args[1].AsFloat(); int d = 1; while (n < 1000000.0 && d < 1000000) { n*=10.0; d*=10; } int x = int(n+0.5), y = d, t; while (y) { t = x%y; x = y; y = t; } return new AssumeFPS(args[0].AsClip(), int(n+0.5)/x, d/x, args[2].AsBool(false), env); Last edited by tritical; 27th December 2005 at 16:08. |
|
27th December 2005, 20:08 | #6 | Link | ||
AviSynth Enthusiast
Join Date: Jul 2002
Location: California, U.S.
Posts: 1,267
|
Quote:
And rationalizing to 2997/125 is still an improvement over 12570329/524288 that AviSynth currently generates, yes? Would 2997/125 not address bond's "high-values lead to unnecessary 64-bit computation" issue? Quote:
Last edited by stickboy; 27th December 2005 at 20:12. |
||
28th December 2005, 02:54 | #9 | Link |
interlace this!
Join Date: Jun 2003
Location: i'm in ur transfers, addin noise
Posts: 4,555
|
another possibility is to simply pick the /1001 framerate that fits the input the best.
AFAIK the only rational framerates are those of (colour) NTSC. when someone types 29.97 it is plainly obvious that they mean 30000/1001, so really this number can be assumed without any drawbacks (as stickboy says, who's going to notice 1/100th of a second after 3 hours? considering that 1-frame desync is quite common on DVDs anyway, particularly if they've been standards converted, and nobody seems to notice that). presets would be interesting too - something like "assumefps("film")" to give 24000/1001, or "assumefps("NTSC") gives 30000/1001, etc. this would certainly be easier to type (and understand...) than 30000/1001 etc.
__________________
sucking the life out of your videos since 2004 |
28th December 2005, 09:44 | #10 | Link | |||
Avisynth 3.0 Developer
Join Date: Jan 2002
Location: France
Posts: 639
|
Quote:
That method certainly works Quote:
|
|||
28th December 2005, 17:15 | #11 | Link |
Mushroomeur
Join Date: Jun 2003
Location: Mushrooms of Paris Town
Posts: 267
|
afaik, 24000/1001 is not the fps of the "films". it's the fps used to get the NTSC framerate from a "photographic material produced for the cinema". the framerate of the films is 24 fps (http://www.doom9.org/ivtc-tut.htm). Maybe the word "film" is not correct.
|
28th December 2005, 17:38 | #12 | Link | ||
Registered User
Join Date: Dec 2003
Location: MO, US
Posts: 999
|
Quote:
Quote:
|
||
31st December 2005, 12:28 | #13 | Link |
Registered User
Join Date: Nov 2001
Posts: 9,770
|
so will my proposal be followed?
__________________
Between the weak and the strong one it is the freedom which oppresses and the law that liberates (Jean Jacques Rousseau) I know, that I know nothing (Socrates) MPEG-4 ASP FAQ | AVC/H.264 FAQ | AAC FAQ | MP4 FAQ | MP4Menu stores DVD Menus in MP4 (guide) Ogg Theora | Ogg Vorbis use WM9 today and get Micro$oft controlling the A/V market tomorrow for free |
31st December 2005, 20:51 | #14 | Link |
Registered User
Join Date: Dec 2003
Location: MO, US
Posts: 999
|
If anyone is interested in testing, I have merged the code I posted before and Mug Funky's preset idea (though I used the names "ntsc_film", "ntsc_video", "ntsc_double" for 24000/1001, 30000/1001, 60000/1001 respectively) into the changefps/convertfps/assumefps filters in the custom version of avisynth I keep on my website.
|
2nd January 2006, 14:34 | #15 | Link |
Avisynth Developer
Join Date: Jan 2003
Location: Melbourne, Australia
Posts: 3,167
|
Avery's latest blog, Wikipedia and AVI fractions refers to this article on continued fractions. This might give the narrow minded something to broaden their horizons.
As for guessing what the true FPS the user really intended from a single precision float approximations of FPS, I think I would have to class that with vodoo and other paranomal superstition. Doing so is very fraught. The current code is able to exactly return to the same single precision floating point value originally set, none of the above suggested code mods provide this. If we change the definition of 29.97 and 23.976 FPS then there will be some lazy users who may be transiently happy but in the long run smart alec hacks, like the proposed, always return to bite you big time. And what do we do with the well intensioned 29.97002997 or 23.976023976 values (which don't fit is a float anyway). For a case in point consider :- A current user builds a script and set the fps to 23.976 (not 24000/1001), they add an audio track edited in an external editor that has explicit knowledge of single precision 23.976 fps framerate. It works as expected. 9 months later we have a new AVS version, with hacked code, the user is not happy his previous working script inexplicably is now getting audio desync.... The idea for easy to spec string equivalences has merit. Of course it can be implemented immediatly as a simple .avsi script, no need to polute the core. Bottom line is if you want 30000/1001 fps or 24000/1001 fps then that is what you should spec. So maybe we need to provide text presets to make this easy to understand for the innumerate masses. P.S. For the uninformed this code Code:
while (n < 16777216 && d < 16777216) { n*=2; d*=2; } |
3rd January 2006, 00:42 | #18 | Link | |
Moderator
Join Date: Nov 2001
Location: Netherlands
Posts: 6,364
|
Some discussion on #x264 with respect to this problem
Quote:
|
|
3rd January 2006, 05:09 | #19 | Link | |
Registered User
Join Date: Dec 2003
Location: MO, US
Posts: 999
|
Quote:
1.) d is limited to < 2^24, which means various values in the range 0 < x < 0.5 (granted it's not a common fps value) will not be translated into a num/den combo that when converted back to float will equal the original. Also, in the current code n only needs to be limited to < 2^23 for the loop condition since single precision floating point only has 23 bits for the mantissa. 2.) It will not work for other various values (119.88 is one example), due to how avisynth's script parser converts to float. Take a look at the floating point part of the Tokenizer::GetNumber() routine, it should be doing all the intermediate stuff in double (otherwise too much error accumulates), but it currently does it in float. For example, if you do assumefps(119.88) avisynth spits out 982057/8192 for a num/den. The 982057/8192 comes from assumefps() calling vi.setfps(num,den) which finds the gcd and and divides it out, in this case it is 32. That means original numbers that get passed are 31425824/262144 while the actual binary fp representation of 119.88 is equal to 31425822/262144. The error comes from the script parser conversion, which, as written, doesn't convert 119.88 to 0x42efc28f (hex value of the 4 bytes at the float memory location), but 0x42efc290. If that routine is changed to use doubles for intermediate steps then the correct value (0x42efc28f) is produced. Anyways, whether or not the code is changed doesn't really matter to me (that's why I keep a custom version ). |
|
6th January 2006, 15:22 | #20 | Link |
Registered User
Join Date: Nov 2001
Posts: 9,770
|
another problem with parsers on such 64bit requiring framerates:
http://forum.doom9.org/showthread.php?t=105154 edit: is the behaviour the same than with assume/changefps when setting the fps via directshowsource? can we plz change the handling of 29.97, 23.976 aso in avisynth :>
__________________
Between the weak and the strong one it is the freedom which oppresses and the law that liberates (Jean Jacques Rousseau) I know, that I know nothing (Socrates) MPEG-4 ASP FAQ | AVC/H.264 FAQ | AAC FAQ | MP4 FAQ | MP4Menu stores DVD Menus in MP4 (guide) Ogg Theora | Ogg Vorbis use WM9 today and get Micro$oft controlling the A/V market tomorrow for free Last edited by bond; 6th January 2006 at 16:32. |
|
|