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. |
20th March 2011, 00:35 | #2 | Link |
Registered User
Join Date: Apr 2002
Location: Germany
Posts: 5,389
|
Some might enjoy using the "HighQualitySharpen" plugin as a post-processor for this. HighQualitySharpen has been successfully tested, over more than a decade, by thousands of people on billions of different videos.
Code:
function HighQualitySharpen(clip c) { c.sharpen(0.6).mergechroma(c) } I mean, c'mon! It's not a bad function, but did it really take 3 years and thousands of videos to NOT include "blend=false", to NOT expose useful MAnalyse parameters, to instead hard-code EXHAUSTIVE search even for the fast mode, and to use non-effective search ranges for the MRecalculate stages? It's not bad, but you are ringing a pretty big bell for something that looks like just having left the proof-of-concept stage.
__________________
- We´re at the beginning of the end of mankind´s childhood - My little flickr gallery. (Yes indeed, I do have hobbies other than digital video!) |
20th March 2011, 00:35 | #3 | Link |
Registered User
Join Date: Jan 2006
Posts: 1,867
|
There's a lot of blending on that, and seems to be no scene change detection. If that's your intent, great, but people are usually looking to *fix* blended sources.
I don't see any actual interpolation. Look at the missiles firing, all I get is blends of two of the original frames. Can you explain what it's supposed to do better? See frame 687, horrible artifacts. A lot of the motion switches between interpolated and blended at random. Double legs appear every other frame. Overall very blurry and flickery. I can even see that at full speed. Last edited by jmac698; 20th March 2011 at 00:51. |
20th March 2011, 03:39 | #4 | Link |
Registered User
Join Date: Jun 2010
Posts: 443
|
If you're interested in seeing the discussion we've had up to this point it's at AVS Forum here.
I've added blend=false for the next release since that seems like a good idea. jmac698, please feel free to convert the original video with a different function like blendfps or convertfps to see the difference. Here is a comparison I made comparing BlendFPS with InterFrame: InterFrame - BlendFPS I should also update those sample videos since they are from an earlier version of the script. I will post back when they are updated. Last edited by SubJunk; 22nd March 2011 at 22:07. |
20th March 2011, 07:29 | #5 | Link |
Registered User
Join Date: Apr 2009
Posts: 478
|
I have been looking for a good way to convert my 29.97 fps content to 59.94. Despite the negativity so far in the thread, I will give it a go once my current encoding job is done. Thanks for the hard work
Edit: I think I will wait for the blend=false version first... Last edited by aegisofrime; 20th March 2011 at 07:32. |
20th March 2011, 08:06 | #6 | Link | |
Registered User
Join Date: Jun 2010
Posts: 443
|
Quote:
I have updated to version 1.0.1 now which includes the blend=false change |
|
20th March 2011, 09:09 | #7 | Link |
Registered User
Join Date: Feb 2010
Location: New York
Posts: 116
|
I can't speak to the motion estimation/compensation side of this, but from a scripting point of view you could simplify things a bit (line breaks added to avoid breaking tables):
Code:
function InterFrame(clip Input, string "Preset", int "NewNum", int "NewDen") { # Defaults Preset = default(Preset, "Quality") # Determine new framerate NewNum = default(NewNum, Input.Framerate == 25 ? 50 : Input.Framerate == 30 ? 60 : 60000) NewDen = default(NewDen, Input.Framerate == 25 || Input.FrameRate == 30 ? 1 : 1001) super = MSuper(Input, hpad=16, vpad=16, rfilter=4) dct = Preset == "Quality" ? 5 : 0 chroma = Preset == "Quality" ? true : false # Make interpolation vector clip backward_1 = MAnalyse( super, blksize=16, searchparam=3, search=3, dct=dct, \ chroma=chroma, plevel=0, badrange=(-24), isb=true ) forward_1 = MAnalyse( super, blksize=16, searchparam=3, search=3, dct=dct, \ chroma=chroma, plevel=0, badrange=(-24), isb=false) backward_2 = MRecalculate( super, backward_1, blksize=8, \ searchparam=1, search=3, chroma=chroma) forward_2 = MRecalculate( super, forward_1, blksize=8, \ searchparam=1, search=3, chroma=chroma) backward_3 = MRecalculate( super, backward_2, blksize=4, \ searchparam=0, search=3, chroma=chroma) forward_3 = MRecalculate( super, forward_2, blksize=4, \ searchparam=0, search=3, chroma=chroma) # Put it together Preset == "Quality" ? \ MFlowFps( Input, super, backward_3, forward_3, num=NewNum, den=NewDen, \ ml=10000, thSCD1=300, blend=false) : \ MBlockFps( Input, super, backward_3, forward_3, num=NewNum, den=NewDen, \ mode=0, thSCD1=300, blend=false) } First things first, you can use expressions within the Default() filter call, just like any other. Since the selection of values for NewNum and NewDen don't depend on anything but the input framerate, you can eliminate your original "Determine new framerate" section and do the same work up top. Second, looking up the preset values for 'dct' and 'chroma' in MVTools 2 lets you get rid of the other Eval block. Create a pair of new variables that fall back to the appropriate values, and you can now collapse the two sections of vector clip assignments into one. Two potential drawbacks are that if you ever decide to introduce other differences between the "Quality" and "Speed" presets, you'll need to either add more variables or go back to an Eval() based design, and that if the defaults for 'dct' and 'chroma' change in future releases of MVTools, you'll need to update accordingly. I still think doing it the way I've shown makes the script easier to read and maintain, but you're certainly free to make up your own mind about that. One final note, don't forget the NOP() filter if you ever need to skip processing at some level of a conditional statement. Eval(""" """) works, too, but in this case a simple no-op would have accomplished the same thing. Last edited by Robert Martens; 20th March 2011 at 09:19. |
20th March 2011, 10:34 | #8 | Link |
Registered User
Join Date: Jun 2010
Posts: 443
|
Thanks for the tips, Robert Very much appreciated, and on a personal note thanks to you and aegisofrime for helping to create a more positive feeling here.
The way the thread started was a bit disconcerting for me and I'm really pleased that it seems to be turning around |
20th March 2011, 11:31 | #9 | Link | |
Avisynth language lover
Join Date: Dec 2007
Location: Spain
Posts: 3,431
|
On downloading this, I was disappointed to find it wasn't a plugin at all, but 'just' a script function wrapper for the MVTools functions I already use for this purpose. Nothing wrong with that, but the way it's presented is a bit misleading.
Quote:
Also there is a subtle difference from the original: an explicit value of 0 can no longer be used to indicate 'use input frame rate'. I do agree that the use of Eval for this purpose is ugly (and cannot be easily extended to nested conditionals). GScript provides a more usable block-if construct. When used in a separate file from the main script, you don't even need to put the code inside GScript(""" ... """), as you can just use GImport() instead of Import() to load the file. (Unfortunately, this does not extend to auto-loading a .avsi, as Import is always implicitly used there.) |
|
20th March 2011, 11:54 | #10 | Link |
Registered User
Join Date: Feb 2010
Location: New York
Posts: 116
|
GScript is of course the smart way to do things like this, but if you'll indulge me for a moment:
For the problem of splitting the values from one another, unfolding the OR and using careful spacing should make it a little nicer: Code:
NewNum = default(NewNum, Input.Framerate == 25 ? 50 : Input.Framerate == 30 ? 60 : 60000) NewDen = default(NewDen, Input.Framerate == 25 ? 1 : Input.FrameRate == 30 ? 1 : 1001) Looking at version 1.01: Code:
# Determine new framerate NewNum != 0 ? Eval(""" # Use user values """) : Input.Framerate == 25 ? Eval(""" NewNum = 50 NewDen = 1 """) : Input.Framerate == 30 ? Eval(""" NewNum = 60 NewDen = 1 """) : Eval(""" NewNum = 60000 NewDen = 1001 """) Last edited by Robert Martens; 20th March 2011 at 11:58. |
20th March 2011, 12:16 | #11 | Link |
Avisynth language lover
Join Date: Dec 2007
Location: Spain
Posts: 3,431
|
In the original, a user-supplied 0 will cause the output frame rate to be determined by the input rate. (NewNum being 0 will give false for the first condition, so move on to test the input rate.)
In your version, a user-supplied 0 stays as 0, giving an output rate of 0/0. You could fix this this by rewriting it as: Code:
NewNum = Default(NewNum, 0) NewNum = NewNum != 0 ? NewNum : Input.Framerate == 25 ? 50 : Input.Framerate == 30 ? 60 : 60000 NewDen = NewNum != 0 ? NewDen : Input.Framerate == 25 ? 1 : Input.FrameRate == 30 ? 1 : 1001 Last edited by Gavino; 20th March 2011 at 12:31. Reason: suggest default NewDen = 1 |
20th March 2011, 14:38 | #13 | Link | |
Registered User
Join Date: Apr 2009
Posts: 478
|
Quote:
|
|
20th March 2011, 14:50 | #14 | Link | |
Registered User
Join Date: Apr 2002
Location: Germany
Posts: 5,389
|
Quote:
Frame interpolation has a huge pile of hardcore technical problems. For lots of these problems, MVTools does *not* have *any* solution. You can only toy around with the various parameters. But whatever you do, it'll only be "maybe better here, but worse there". Let "frame interpolation" be a "very big table". Then, MAnalyse+MFlowFPS is a "too small tablecloth". You can shift the tablecloth around until you get blue in the face, but you can never cover the whole table. And worse, there is no possibility to make up a "very very slow script with better solutions", because the problematic issues are not accessable from the script level. MVTools has no idea what "motion" actually is. There is no reference for the interpolated frames to check against. And it doesn't even seem possible to transpose a MMask accordingly (would require usage of inverse vector orientation, which feature is not offered by MVTools.) Dead road, there's hardly anything to do for the script writers. All in all, you can build your sandcastle however you like it. The only thing guaranteed is that it'll be swept away by the next wave floating along.
__________________
- We´re at the beginning of the end of mankind´s childhood - My little flickr gallery. (Yes indeed, I do have hobbies other than digital video!) Last edited by Didée; 20th March 2011 at 15:33. Reason: a typo. |
|
20th March 2011, 18:29 | #15 | Link | |
Registered User
Join Date: Sep 2010
Location: Austin, TX
Posts: 40
|
Didée used this metaphor:
Quote:
|
|
20th March 2011, 20:40 | #16 | Link |
Grand Fruitioner
Join Date: Mar 2004
Location: Chicago, IL
Posts: 115
|
I was under the impression that the "smooth motion" in modern TVs was just them a) preserving all frames from deinterlacing, and b) having Hz be a multiple of the source FPS (so 24fps and 30fps content both display with perfect timing).
I wasn't aware that they actually did any motion interpolation. |
20th March 2011, 22:47 | #17 | Link | |||
Registered User
Join Date: Jun 2010
Posts: 443
|
Quote:
Quote:
I disagree with your general impression of the process, though; it's very limited and like you said it will never be the holy grail, but I have been using it on all my videos for nearly a year - sometimes in realtime with MPC-HC and sometimes encoded - and have been happy with the results. It's far from perfect but I think it's good already, and having tried every other script I've come across I can say that I think this one is the best that exists so far. Sometimes I have found a better one so I just incorporate those changes into this one, so this one stays the best Quote:
Maybe you're right, I can change the title to say "plugin script" if you think that would be better. Last edited by SubJunk; 20th March 2011 at 22:52. |
|||
Tags |
48fps, 60fps, framedoubling, interframe, smooth motion |
Thread Tools | Search this Thread |
Display Modes | |
|
|