MVTools

[SubJunk]

It is actually 23.976fps, regardless of what certain tools report. In that case it looks like the framerate is being truncated to 4 digits (2397) so that is why it displays like that.
Like I have said to you before many times, 23.970 is not a valid framerate for anything, if something is actually at that framerate it is a weird mistake. Plus I have that video you used to test and I know it is 23.976fps.

[Jeremy Duncan]

Hi Subjunk,

I'm not asking if the video is 23.970. We all know that that is not the framerate of the video. I even posted a link to sw that shows the framerate of the video so you or they could use it to double check.

WMP shows the frame rate of red riding hood properly, but not the montage video that I took the screenshot of them dancing from. Either it's wmp that's at fault, or it's ffdshow. But all this is off topic anyway and not really important as I can just type the real framerate in changefps.

[Gavino]

Originally Posted by Jeremy Duncan

I can just type the real framerate in changefps.

By itself, your mvtools code produces exactly two frames for each input frame it gets, adding the extra one by interpolating between each input frame. No matter what rate ffdshow 'thinks' the framerate is, if you use a different rate in changefps, that will add or delete frames in the input stream to mvtools, throwing the motion analysis off and giving a jerkier result.

So it seems to me you actually need the changefps to do nothing (other than buffering the frames), and the only way to ensure that is to use
video = video.changefps(video, linear=true).

[Didée]

BTW, if you're aiming at just *doubling* the framerate, there's no need to juggle with FrameRateNumerator() and FrameRateDenominator().

In MFlowFPS and MBlockFPS, if you set either num=0 or den=0, it will automatically double the input framerate.

[Jeremy Duncan]

Gavino,

I tried with your code and the one I used where I input the actual framerate in changefps and frame stepped and honestly I could not see any jerkiness either way. This was with the dancing video. Tomorrow maybe I'll try the red riding hood video with the bon fine scene.
I know what jerky video looks like too, I saw it before in red riding hood, but I didn't see it in the dancing video.

Didée,

Before when I set num and den like this: num=FramerateNumerator(A)*2, den=FramerateDenominator(A)*1 and set changefps to use the actual frame rate the cpu cores on my Intel E6600 was very unevenly used.

Then I used your advice and setup num and den to be 1 and 0, and deleted the changefps code, but the cores were still slightly enevenly used.

Then I added the changefps code and set the actual frame rate in changefps, and the cores were practically evenly used across both cores.

For some reason using num and den and changefps this way balances the cpu load evenly.

to you both for helping me.

setmtmode(5,0)
SetMemoryMax(512)
video=ffdshow_source().changefps(23.976, linear=true)
A = video.autolevels()
B = video
setmtmode(2)
SetMemoryMax(512)
super_1 = A.MSuper(pel=2, hpad=12, vpad=12, rfilter=2, isse=true)
super_2 = B.MSuper(pel=2, hpad=12, vpad=12, rfilter=1, isse=true)
backward_vec = MAnalyse(super_1, isb=true, blksize=16, levels=2, search=2, searchparam=1,  isse=true, sadx264=7, lambda=200, dct=10)
forward_vec = MAnalyse(super_1, isb=false, blksize=16, levels=2, search=1, searchparam=1,  isse=true, sadx264=7, lambda=200, dct=10)
backward_vec_1 = MRecalculate(super_1, backward_vec, blksize=8, search=2, searchparam=1, dct=10)
forward_vec_1 = MRecalculate(super_1, forward_vec, blksize=8, search=1, searchparam=1, dct=10)
B.MFlowFps(super_2, backward_vec_1, forward_vec_1, num=0, den=1, thscd1=350,  thscd2=100, ml=100)
distributor()

setmtmode(5,0)
SetMemoryMax(512)
video=ffdshow_source().changefps(23.976, linear=true)
A = video.autolevels()
B = video
setmtmode(2)
SetMemoryMax(512)
super_1 = A.MSuper(pel=2, hpad=12, vpad=12, rfilter=2, isse=true)
super_2 = B.MSuper(pel=2, hpad=12, vpad=12, rfilter=1, isse=true)
backward_vec = MAnalyse(super_1, isb=true, blksize=16, levels=2, search=2, searchparam=1,  isse=true, sadx264=7, lambda=200, dct=10)
forward_vec = MAnalyse(super_1, isb=false, blksize=16, levels=2, search=1, searchparam=1,  isse=true, sadx264=7, lambda=200, dct=10)
backward_vec_1 = MRecalculate(super_1, backward_vec, blksize=8, search=2, searchparam=1, dct=10)
forward_vec_1 = MRecalculate(super_1, forward_vec, blksize=8, search=1, searchparam=1, dct=10)
B.MBlockFps(super_2, backward_vec_1, forward_vec_1, num=0, den=1,thscd1=350,  thscd2=100, mode=3, thres=30)
distributor()

[Didée]

In the past, I've experienced issues very similar to the ones you have mentioned. However, for the most part, your solutions do not work for me.

first off: my ffdshow-Avisynth-scripts happen to start with
SetMemoryMax(600)
ffdshow_source()
changefps(last,last,true)
which in essence is the same as your recommendation.

- when I put "Distributor()" as the last line in ffdshow/Avisynth, then my player will crash immediately when loading a video. Always, without exception. For me, MT works only without Distributor().

- I found that in ffdshow/Avisynth, SetMTmode() often does not work well for me. On a few videos it works good, but on the majority of videos it works bad (i.e.: unusable) for me. For ffdshow, I had to switch to MT().

- multithreading works only efficiently if the source is decoded directly by ffdshow. When decoding is done e.g. by an MS decoder and ffdshow is in the chain only as a post-processor, multithreading becomes problematic.

- for some reason, it seems that multithreading in ffdshow never uses more than 4 threads for me. When I set threads = 6 or 8, the CPU graph shows only 4 cores get loaded.


Can't tell if such behaviour is "typical" or rather "unique". Just wanted to point out the possibility that your elaborate postings about how to do this-or-that in ffdshow might cause problems for many users. Small differences in a system's multimedia setup can cause substantial differences in the behaviour! - And consequently, what works for you, might not work at all for other users.

In any case, I'd say that "multithreading in ffdshow->Avisynth" is an odd thing.

[Gavino]

Originally Posted by Jeremy Duncan

I tried with your code and the one I used where I input the actual framerate in changefps and frame stepped and honestly I could not see any jerkiness either way.

In the examples you've given, the difference in framerates was small, so relatively few frames would be affected (eg 1 in 4000 in one of the cases). So you won't always notice a difference using 'your' code, but where there is any visible difference, I would expect my code to be the one with better results, and it also has the advantage you don't have to change it for each new source.

For some reason using num and den and changefps this way balances the cpu load evenly.

The two ways of using num and den are completely equivalent, so don't affect anything but readability and ease of writing. Using changefps with linear=true is what balances the cpu load, but this has nothing to do with changing the rate from what ffdshow reports. I think that's the point that is confusing you - you don't want to really change the fps at that point, it's just a trick to use the buffering feature of the changefps filter.

[Jeremy Duncan]

Gavino,

This is the code now:

setmtmode(5,0)
SetMemoryMax(512)
video=ffdshow_source().changefps(ffdshow_source(), linear=true)
A = video.autolevels()
B = video
setmtmode(2)
SetMemoryMax(512)
super_1 = A.MSuper(pel=2, hpad=12, vpad=12, rfilter=2, isse=true)
super_2 = B.MSuper(pel=2, hpad=12, vpad=12, rfilter=1, isse=true)
backward_vec = MAnalyse(super_1, isb=true, blksize=16, levels=2, search=2, searchparam=1,  isse=true, sadx264=7, lambda=200, dct=10)
forward_vec = MAnalyse(super_1, isb=false, blksize=16, levels=2, search=1, searchparam=1,  isse=true, sadx264=7, lambda=200, dct=10)
backward_vec_1 = MRecalculate(super_1, backward_vec, blksize=8, search=2, searchparam=1, dct=10)
forward_vec_1 = MRecalculate(super_1, forward_vec, blksize=8, search=1, searchparam=1, dct=10)
B.MBlockFps(super_2, backward_vec_1, forward_vec_1, num=0, den=1,thscd1=350,  thscd2=100, mode=3, thres=30)
distributor()

Didée,

If your having problems then a problem solving step would be elimination process. Try my method and see if it fixes those problems you mentioned.

[Didée]

Originally Posted by Jeremy Duncan

If your having problems then a problem solving step would be elimination process. Try my method and see if it fixes those problems you mentioned.

I've tried a plentitude of different setups. More exactly, I've tried all setups that I can only think of.

The conclusion is what I've written in my previous post. Perhaps you need to read it more closely.

In case it was too much text -- the ultimative points are in the first sentence and in the penultimate sentence. I repeat:

Originally Posted by Didée

your solutions do not work for me.

and

Originally Posted by Didée

what works for you, might not work at all for other users.

[travolter]

@jeremy

About these new scripts, ones working OK in some computers and not in others.. I start to think that all is related about how different CPUs do the processing and expecially the MT thing.

I have here a Q9550 and usually I have to modify settings in your scripts because my cpu seems "bottlenecked" while cpu monitor is not showing 100% usage (?)

What cpu are u using?

[Jeremy Duncan]

I don't know the right cpu for this. I have a Intel E6600 and it seems to run fine when I play standard definition dvd's. On some scenes it stutters and slows down to a crawl though, so I don't really know the cpu to use.

I have ddr2 as well, if I had ddr3 ram it would be better. And if my videocard which is a ATI 4670 had ddr5 ram it would be better, right now it has ddr2 I think.
In other words the ram speed plays a part in the performance of the pc ability. Other things like that.

Didée,

I wonder if you got the realtime ffdshow with avisynth going or not? Did you manage to get it going?

[Didée]

Sure, I use framerate doubling quite frequently. Just that I need to use MT() for that, because SetMTmode doesn't play nice for me in ffdshow.

My script basically looks like this: (some #'ed processing lines removed)

SetMemoryMax(600)
ffdshow_source()
changefps(last,last,true)

MUL = 0 # 1 # 
BLK = (width<1000) ? 16 : 32 
ME1 = (width<1300) ?  5 :  4 
ME2 = (width<1300) ?  4 :  2 
DCT = (width<1300) ?  5 :  0
LEV = (width<1300) ?  3 :  2

MT("""
sup = MSuper(hpad=16, vpad=16, pel=1, levels=LEV, rfilter=3, isse=true)
bv = MAnalyse(sup,blksize=BLK, levels=LEV, search=ME1, searchparam=ME2, isb=true, plevel=0, dct=DCT)
fv = MAnalyse(sup,blksize=BLK, levels=LEV, search=ME1, searchparam=ME2, isb=false, plevel=0, dct=DCT)
MBlockFps(sup, bv, fv, num=60*MUL, den=1, mode=1)
""",4,32)

You see, quite primitive settings. But it does the job good enough, and it never hits THE WALL.

[SubJunk]

That reminds me Didee, I have reverted the blend=false change you suggested in InterFrame because of the scene change detection problems. I found that with blend=false a lot of action scenes weren't interpolating, and of course weakening the values just means that the blend=false hardly ever gets used anyway.

Check out this sample video made with the new InterFrame (which is mostly a MVTools2 script, so this is relevant to the topic), I think it is pretty cool The new version adds GPU-acceleration as well as increased quality.
Original - InterFrame (default settings)

[PelPix]

Hey guys. I've been using MVtools for a while now to interpolate frames for motion blur in game videos. My current script is simply

super = MSuper()
backward_vec = MAnalyse(super, overlap=4,isb = true, search=3)
forward_vec = MAnalyse(super, overlap=4, isb = false, search=3)
MFlowFps(super, backward_vec, forward_vec, num=768, den=1)
TemporalSoften(6,255,255,0,2).selectevery(32,1)

I'm interpolating 768 frames out of 144. At that incredible level, I know I will never be able to remove the blocky artifacts from the output altogether, but do you have any tips on lessening them that I might not have already found out?

Keep in mind that my source footage is raw captures from the output of a game engine. There is no compression or distortion of any kind, so nothing needs to be included to counteract that.

[SubJunk]

You can use a higher value for ml in MFlowFps to reduce the artifacts, which weakens the mask but with other values it won't matter much. Try using ml=10000 which basically disables it, then if you need a stronger mask try lowering the value until you're happy.
Another thing is to grab the custom build of MVTools from the SVP, or you can get it from the guide in my signature. It lets you use ml=0 (whereas it is locked to greater than 0 in the official version).
Also in the custom build there is a better mask called sadml which is a good replacement for ml. It offers similar advantages with less artifacts. Have a look at InterFrame to get an idea of how to use the custom build, or just ask questions here and I'm happy to help

[PelPix]

Alright. I actually tried InterFrame directly, but found that it actually put more weight on the original frames than the interpolated ones when using it for motion blur, which obviously isn't correct.
I just disabled the mask. It looks wonderful. I guess motion blur is too low-frequency to need a mask at all, huh? It's blurring some one-pixel lines that can't be blurred though, so I'll continue tweaking it.

[PelPix]

Double posted

[SubJunk]

Yeah it's not made with motion blur in mind, but hopefully there are some tips in there that translate to your script

[SubJunk]

Hopefully someone can help me with this question

Is there a way to make MVTools2 get vectors from a smaller source and apply them to a bigger source?
For example, if I have a 1920x1080 video, and I want MVTools2 to do all its work on a downsized version of it (say 1280x720), and then at the final step (MFlowFPS) scale it to the 1920x1080 size again?

In other words, the main source wouldn't be resized at any stage, only the motion information.

When I try the obvious thing of just creating the super clip from a resized source while keeping the input the same resolution, I get the error "inconsistent source and vector frame size", but I'm not a pro at AviSynth scripting so I wonder if anyone has a way to do it?

[Didée]

There once was the "MVIncrease" filter for this purpose, but IIRC it's not supported anymore. It did only a strictly 2x increase anyway.

What about (blocksize=32, overlap=0, pel=1) -- not fast enough?