Motion filter : +1st MC FPS-change script for real usage

[scharfis_brain]

maybe a special interlaced mode could be implemented, that takes care for the bobbing?

So it isn't fooled by static areas (which obviously are bobbing) AND creates non bobbing full sized (frame heigth, not field heigth) vector frames.

This would be a GREAT help for mocomped deinterlacing.

[mg262]

scharfis,

I'm being a bit dense atm and I'm not sure how to read and that -- do you mean that you want the filter to take bobbed input but try and be intelligent about using original scanlines rather than interpolated lines? Or do you mean that you want the filter to be/include a bobber?

[scharfis_brain]

sorry, I wrote it a bit mixed up.

I mean this:

source("blah.xxx")
assume?ff()
vectors=separatefields().analyse(interlaced=true)
compensated=somesmartbob().mvcompensate(vectors)

this means: take a fieldseparated video and do the analyse on it.
of course this analyse must take care for static areas and has to ensure that the vector movement is smooth (no bob-jitter!)
also the vector field has to have the size of the full frame (like the smart bobbed one)

[Fizick]

I do not know, what scharfis_brain told about,
but I consider (in some future) fieldbased input, half-pel interpolation,
and one pixel shift field compensation (I have it in DePan).

[scharfis_brain]

but I consider (in some future) fieldbased input, half-pel interpolation,
and one pixel shift field compensation (I have it in DePan).


but this will create wobbly vectors in static areas

[Fizick]

Half-pel assume bilinear interpolation.

Another approach (I see it in some deHaan article?) :
Withot halft-pel, simply to add penalty to SAD cost for candidate vectors with odd vertial shift.
Take full interlaced frames. (It is used for fast realtime).

[mg262]

scharfis,

what you ask is definitely possible. I was in any case thinking of having motion vectors for interlaced clips actually use distances measured in bobbed space;* it removes a lot of headache, and makes the algorithm trivially resistant to jitter. So would just be a matter of moving 8x16 blocks instead of 8x8 blocks, or equivalently duplicating each row of motion information. You can almost do that right now by writing:

Interleave(motioninformation, motioninformation).Weave()

(The only reason that wouldn't work is because motion information is currently padded to make sure it contains an even number of scanlines -- but I was planning to move it from YV12 luma to YUY2 or forthcoming Y8 anyway, which would obviate the need for padding.)

*I hope that comment is clear... poke me if it isn't. I tried to write a bit more about it but it looked like I was just making it more confusing. Key point is that still scenes will have stored motion vectors of (0,0), not (0,±0.5).

Also bear in mind that there are proper motion compensated bobbing algorithms... cf one of the papers Fizick pointed me to: http://www.ics.ele.tue.nl/~dehaan/pdf/111_IVCP_ZHAO

Edit: I have yet to find any explicit discussion of interlaced->interlaced FPS conversion. AFAICS most papers implicitly expect you to use a MC bob + a progressive MC frame rate change (both discussed extensively in the literature), then discard unneeded fields. Quite apart from the usage of interpolated values for further interpolation, I think that this misses the point completely -- if you are applying half pixel compensation, direct interlaced->interlaced FPS conversion is almost the same problem as progressive->progressive conversion, and the methods extend directly. I will expand on that later.

[That's not to imply that bob + frame rate change + discard is a bad idea in scripts, given the currently available tools.]

[scharfis_brain]

IMO one cannot go another way than

mvbobbing -> mvfpsconversion -> resize -> reinterlace

working directly with the fields won't work. You need to make it progressive.

[mg262]

To keep the argument as simple as possible, let me first ask you this: if resizing were not an issue, would you consider a one step process to be feasible?

[castellandw]

Oh yeah, the Doctor Who restoration team video engineers said the motion compensation with phase correlation was done on a full frame meaning all the 50-60 fps full progressive frames were deinterlaced from the 25-30 fps interlaced frames. So you have to make the frames progressive for motion compensation. In terms of frame rate conversion, there should be a motion compensated fps function (like MVFps in MVTools) required for anything involving motion compensation because the frame rate change occurs during the motion compensation process. To do motion compensation first with something like MVTools and then use ConvertFPS or ChangeFPS won't work properly. On the subject of bobbing,

@scharfis, on the subject of bobbing for interlaced frames involving motion compensation, you could look at section 2.2-2.3 of Snell's Guide To Motion Compensation on Pre-Processing and Motion Estimation:
http://www.snellwilcox.com/knowledgecenter/books/books/emotion.pdf
Although I'm not sure how helpful, but you should try out that Block Overlap plugin by Fizick in your mvbob function, and let's hope someone can achieve coding phase correlation.

[Joel Cairo]

castellandw:

With regard to the Doctor Who restorations, there should be no need to for the Restoration Team to recover frames from interlaced content... the episodes that they treat with motion conversion are derived from 25 fps film telerecordings, so it's my understanding that they just have special video transfers made, clean up the image, and work directly from those.

-Kevin

[castellandw]

Kevin, what are you talking about? I'm talking about regular broadcast standards conversion process (aka PAL-to-NTSC or NTSC-to-PAL) in general with the Snell Converter that the Restoration Team uses. This is nothing to do with recovering the original interlaced frames from film telerecordings like the actual VIDFIRE process.

[Joel Cairo]

Ahh-- my mistake... I lost track of the conversation.

Sorry for the confusion! :)

-Kevin

[mg262]

Oh yeah, the Doctor Who restoration team video engineers said the motion compensation with phase correlation was done on a full frame meaning all the 50-60 fps full progressive frames were deinterlaced from the 25-30 fps interlaced frames. Thank you, that is worth knowing...
So you have to make the frames progressive for motion compensation.... but that doesn't follow from it. It just means that they/the equipment they had did it that way.

[castellandw]

Well, I hope I'm explaining this right. They did mention interpolating to full frame if I remember correctly (God, I wish they didn't delete their old message threads.), but you can ask them too.

[mg262]

castellandw,

Don't worry, that's clear enough. As I said, I had the impression that that was the standard method. I just want to suggest a different way of doing it...

[castellandw]

scharfis_brain mentioned about bobbing before motion compensation took place, and it got me wondering, shouldn't we use better bobbers than just smart bob such as leakkernelbob?

[Mug Funky]

it's a chicken and egg thing.

to do a motion-compensated deinterlace (good bob) we need to start with a good bob.

[scharfis_brain]

That's why I cannot wait tritical releasing his new Tdeint2!

[mg262]

Mug Funky, scharfis,

:confused: Why do you need to start with a normal bob?

The only thing that comes to my mind is the case where you have vertical motion of 1 (or 3 or 5, etc) original scan lines per field, i.e. the case where field 0 and field 1 match pixel for pixel. In this case, you either have to look further afield temporally (which may not help and increases the risk from incorrect motion prediction), or (safer) use pure spatial upconversion.

Cf again the paper Fizick pointed us to:
http://www.ics.ele.tue.nl/~dehaan/pdf/111_IVCP_ZHAO

There is a motion-compensated deinterlace which starts ab initio.

[castellandw]

@msg262, has anyone actually implemented the GST algorithm as a plugin for AVIsynth or at least tested out the GST algorithm to see if it actually has good results? Also, do you think I should go to the Doctor Who restoration team to see if they know what kind of deinterlace technique is used before motion compensation starts in the Snell converters they use?

[MfA]

if you are applying half pixel compensation, direct interlaced->interlaced FPS conversion is almost the same problem as progressive->progressive conversion, and the methods extend directly.Performing interpolation for inherently aliased fields works even worse than for progressive frames though.

[mg262]

do you think I should go to the Doctor Who restoration team to see if they know what kind of deinterlace technique is used before motion compensation starts in the Snell converters they use?If you are curious about it, go ahead... but it's not necessary for this thread. The strength of AVISynth is that tools can be mixed and matched -- you are free to try any deinterlacer with this or any any motion compensation. If you find convincing evidence that a particular deinterlacer is very effective (for a particular task), you can present it clearly in a new thread and hope someone is interested enough to build one.

It is certainly worthwhile to know what methods are used in hardware -- if the explanation is sufficiently detailed to be replicable. But I think you should not assume that the methods used in hardware, even high-end hardware, are the "best" methods around. (The same caveat should be placed on academic material.) In the end, to choose an approach for a given task, you need to immerse yourself in the material until you understand the strengths and weaknesses of each method well enough to pick -- or construct -- the appropriate one for the task.

@msg262, has anyone actually implemented the GST algorithm as a plugin for AVIsynth or at least tested out the GST algorithm to see if it actually has good results?I don't think so, but I couldn't tell you for sure... you could :search:

On this, on phase correlation, things are only implemented when someone has an interest in implementing them -- which typically means an interest in the specific tasks for which they are useful. I'm going to steal some well chosen words:6. Some time ago i also waited when somebody will wrote filter with advanced algo.
... take C compiler, and become the talented progammer !

[mg262]

MfA, inherently aliased fields: do you mean aliased in the sense that they are aliases of each other or aliased in the sense of anti-aliasing? (I think you mean the former, but if it's the latter I'll have to think some more...)

Update on progress: I put in the half-pixel assembly, and then spent a fair while profiling, optimising, trying a lot of different things to squeeze out more speed. I will probably release a new version after putting in FindReverseMotion and ReverseCompensate functions. After that, real life will soak up most of my time, but I'm thinking of implementing one of these two (in C to start with):
-- simple (bilinear) mesh warping
-- simple (no clever occlusion handling) FPS conversion.

Simple because I like to have a baseline to test more advanced features against. Preferences?

[MfA]

The frequency of the underlying signal is unchanged compared to progressive, but the vertical sampling frequency is halfed ... so more aliasing.

[castellandw]

On this, on phase correlation, things are only implemented when someone has an interest in implementing them -- which typically means an interest in the specific tasks for which they are useful.

@msg262, so does this mean phase correlation really isn't important toward making a better motion compensation engine for right now? I'm not trying to go away from the fact that I don't want to code a plugin that does phase correlation because I'm a lesser-experienced programmer, but for now, you guys pretty much seem to have more experience in this and are much more advanced programmers in this than me. Of course, the reason I wanted to ask about what deinterlacer that the Snell converter uses for motion compensation was because I thought which deinterlacer to use did matter when motion compensation is applied to the frame.

[mg262]

Got it. I would certainly agree that

50p --MC-FPS-> 60p --discard fields-> 30i

Beats

50p --discard fields-> 25i --MC-FPS-> 30i

But our case is slightly different. Our underlying material is 25i , and the only way we can get 50p back out of it is by bobbing, i.e. by interpolating values. Now IMO the MC-FPS unit is just as capable of interpolating values as a bobber. In fact, I would argue that it is better placed because:

a) Suppose we are interpolating midway between fields B and C in this configuration:
A B C D
Now a bobber will use parts of C to fill in bits of B, and then the FPS unit will use those filled in bits to create the intermediate frame -- but really this is giving us no more information than it already gets from considering C directly.

b) The bobber will also use A to fill in B -- but the FPS unit can do this if it chooses to, simply by expanding the temporal radius. You could argue that this introduces extra inaccuracy (pulling information across 1.5 fields distance rather than 1 field distance), but
i) the information is being pulled across 1.5 fields anyway; it's just happening in two hops
ii) the bobber itself is always pulling information across 1 field's distance, whereas the MC-FPS unit can get away with looking across 0.5 fields distance.

Also note that at least some motion compensated deinterlacing methods, like the GST, can be directly applied to FPS change -- we obtain motion compensated samples from previous and next fields, apply the generalised sampling theorem to reconstruct a curve, and read the values we want off the curve. (I think there are better methods available, which allow things like e.g. lower weighting of information pulled across a larger temporal distance... but that's another matter.)

[mg262]

castellandw,
does this mean phase correlation really isn't important toward making a better motion compensation engineI honestly don't know. I'm not confident enough to call this one. If you want my gut feeling... I have a tendency to distrust maths-based methods unless I can see (theoretically or empirically) that they model the problem domain well. (IMO, there is a visible tendency for academics who are not mathematicians per se to be impressed by maths just because it looks hard.) A priori, you can also see that phase correlation will tend to mess up on small objects.

The only way to really to which method is best is to implement both methods and refine them with all the tweaks everyone has thought of and then compare them on real applications like FPS conversion. So, having implemented one method, we need to refine it and include applications before any comparison is even possible.

[scharfis_brain]

60p --MC-FPS-> 60p --discard fields-> 30i

is it meant this way or is it just a typo?

Did you mean:
50p --MC-FPS-> 60p --discard fields-> 30i

or

60p --MC-FPS-> 50p --discard fields-> 50i

[mg262]

Oops... completely right, scharfis. :o I fixed it. Thank you.

[scharfis_brain]

btw.: for standards conversion of interlaced SDTV (50i and 60i) there needs to be a deinterlacer applied.

mainly for those reasons:
1) scaling the fields between 480 and 576 lines while preserving static areas
2) doing a good motion vector search
3) getting material to replace MoComp mismatches
4) make your live easier ;)

[castellandw]

castellandw,
I honestly don't know. I'm not confident enough to call this one. If you want my gut feeling... I have a tendency to distrust maths-based methods unless I can see (theoretically or empirically) that they model the problem domain well. (IMO, there is a visible tendency for academics who are not mathematicians per se to be impressed by maths just because it looks hard.) A priori, you can also see that phase correlation will tend to mess up on small objects.

Well, it seems clear that it'll mess up on small objects, which as I understand is why phase correlation is only limited to large object movements on regular standards converters. You know, I like to give Fizick's MVFlow function a try since it works on pixels of a frame instead of blocks of a frame, but Fizick says that doing motion compensation by pixels can create very strange deformed pictures, so for now, I'll stick to anything involving blocks of frames instead of pixels.

[Mug Funky]

hmm. motion-compensating a new field for deinterlacing doesn't _necessarily_ need a bob to start with - whatever is performing the motion compensation simply needs to be aware of the half-pixel shift between fields and take that into account. MVtools doesn't do this (why should it... it's not a deinterlacer after all), so we have to feed it with a smart bobbed clip where the half-pixel shifts are minimised as much as possible. and as scharfi says, it makes things easier because you can just re-use the smartbobbed clip to fill areas where motion compensation has produced artefacts.

[edit]

@ castellandw:

mvflow still works with blocks, but it moves each pixel when compensating. it just interpolates the vector field made from the block-matching process. this can really help with angular motion and even rotation though, so it's still got an edge over moving full blocks. though for interpolation, i think forward+backward with OBMC and a blocksize of 4 would be nearly perfect as well.

[scharfis_brain]

when compensating fields directly one doesn't achieve a goodsuppirxel accuracy.

When I use an ELA based smart bob instead, I have much better subpixel precision due to the ELA interpolation. (lesser jaggieness)

[mg262]

1) scaling the fields between 480 and 576 lines while preserving static areas
2) doing a good motion vector search
3) getting material to replace MoComp mismatches
4) make your live easier2. and 3. I can certainly accept. I don't understand the "vectors=separatefields().analyse(interlaced=true)/compensated=somesmartbob().mvcompensate(vectors)" request in the context of 2, though... I would have thought you would want to do it the other way round, i.e. find the motion vectors on the bobbed clip but compensate the un-bobbed clip.

As for 1.: Once the motion compensation is in play, you simply have a vertical slice with (approx) known values at irregular intervals, and you want the values at particular points... AFAICS, the number and spacing of those points doesn't matter... so I think you can do the resampling at the same time as interpolation. (And use your favourite resampling method for the interpolation.)

4. Yours or mine :p?

Edit: I don't know how much you will be able to rely on the subpixel accuracy of the true motion algorithm, even on progressive content, anyway... if it looks like being a problem, do tell me because there are quality/speed trade-offs that can be made.

[mg262]

Motion, 3 November 2005 (http://people.pwf.cam.ac.uk/mg262/posts/Motion_03Nov05.dll)

Most of the changes are under the hood to speed things up. Half-pixel accuracy is now in assembly, and works about as fast as the integer version did before (~ 200 FPS). Half-pixel and assembly are now used by default. Bidirectional estimation/compensation is available like this:

FindMotion(from = previous) or FindMotion(from = next)
Compensate(source = previous) or Compensate(source = next)

Both default to previous. So standard compensation (moving parts of frame n-1 to replicate frame n) is still done like this:#AVISource...
Compensate(FindMotion())And reverse compensation (moving parts of frame n+1 to replicate frame n) is done like this:#AVISource...
Compensate(FindMotion(from = next), source = next)(If the argument names are confusing, suggestions for better alternatives would be welcome.)

Here is an example interleave script for motion compensated denoising:#AVISource...
Interleave(\
Compensate(FindMotion(from = previous,initialise = 4), source = previous),\
last,\
Compensate(FindMotion(from = next,initialise = 4), source = next))
#temporal smoother, radius 1
SelectEvery(3, 1)Remember to set the reset parameter in both FindMotion calls if you want to be able to seek; I typically use reset = 50, but lower values will give you faster seeking.

[castellandw]

mg262, it would be nice if you packaged a help file next time around along with the dll for all the functions in your DLL because it's gonna start to get messy to look through this long bunch of posts in this message thread.

[Mug Funky]

yeeee! will try it immediately!

[edit]

backward prediction seems to be compensating the wrong frame? try:

back=compensate(last.deleteframe(0).findmotion(reset=100,from=next))

subtract(back,last)

[mg262]

@castellandw,

I thought about recappping all the function arguments, but realised there weren't any important arguments that weren't mentioned in the above post. So:

FindMotion(clip, ...)
from = previous/next
int reset (default 0)
int initialise (default 1)*

Motion estimation usually relies on estimated motion vectors for the previous frame, but if e.g. reset = 50 then motion vectors are calculated from scratch every 50 frames. Increasing initialise increases the accuracy of vectors calculated from scratch.

*There are more arguments, but they are IMO no longer useful except possibly for debugging... just there to avoid breaking scripts for the moment.

Compensate(clip, clip motion, [source = previous/next])

DrawMotion(clip, clip motion)

Example scripts for the first two are above; view motion like this:

#source
DrawMotion(FindMotion())

#source
DrawMotion(FindMotion(from = next))

Edit: I have put together a filter recap, below, and I will update and relink with each substantial change. But I don't want to suggest that reading this is enough to jump into the discussion... the whole point of starting this thread was to obtain feedback to direct the development (and I have been given plenty of expert feedback -- thanks, guys!)

[Didée]

Regarding artefacts in compensated frames:

>> Repair( compensated, reference, 4 )

is not the solution. But it's part of it. :)

[mg262]

@Mug Funky,

I'm a bit confused... your script produces something that shows a a big difference between the two clips, but on the other hand I can't tell what it is meant to do. You can't AFAIK use backwards-estimated information for forward compensation, for the following reason: there may be blocks in frame n+1 that don't map to any block in frame n, so it's not clear what you should put in for those blocks. To make that more precise:

findmotion(reset=100,from=next)

will find, for each block in frame 30, the block in frame 31 which is most similar to it (give or take mumbling about true motion).Now

compensate(findmotion(reset=100,from=next), source = next)

will replace each block in frame 30 with the block from frame 31 which is most similar to it.

But, given the information from findmotion(reset=100,from=next), there is no way to replace blocks in frame 31 using blocks from frame 30... because we just don't have the right information. Given a block in the frame 31, we have no easy way to calculate which block from frame 30 to use.

Does that answer your question? Or have I got the wrong end of the stick completely?

Edit: there was a silly bug in the initialisation code... you won't see any difference in the results, but please grab this again anyway:
Motion, 3 November 2005 (http://people.pwf.cam.ac.uk/mg262/posts/Motion_03Nov05.dll) (upload at 14:06)

[Mug Funky]

aaah, i missed the "source=next" thing. sorry. works a treat now :)

thanks for your work. this is looking great.

[edit]

btw, how do i shot hpel? i can't seem to see it in the options posted here (am i blind?)

[mg262]

It's on by default. You can use FindMotion(subpixel = false) to turn it off... but it's fast enough that I can't think of much reason to turn it off? (Similarly, if for some reason you want to switch off the assembly you can use useassembly = false.)

Edit: This is not documentation, in the sense that reading it isn't a proper substitute for the discussion in this thread, but it is a recap of all the filter options to save you having to look back:

Basic Usage and Filter Options
http://people.pwf.cam.ac.uk/mg262/posts/motion%20recap.txt

I agree this thread has become too long to digest... + looking back, large parts no longer apply, e.g. thoughts on implementing backwards compensation. So if no one has any objections, I may start a new thread at some point when there is a new version, and repeat the main requests, etc?

Incidentally, to let you write standards conversion scripts (your way), what do I need to implement? Just a progressive ConvertFPS function?

[castellandw]

Incidentally, to let you write standards conversion scripts (your way), what do I need to implement? Just a progressive ConvertFPS function?

Were you talking to me, mg262? If you were talking to me, a motion compensated convertfps using your motion compensation engine in your dll would be nice for a start because I probably think it's not such a good idea to do motion compensation and then frame rate conversion separately. Do you think motion compensation and convert frame rate separately might cause jerky motion? By the way, mg262, have you tried Fizick's Block Overlap plugin yet?

[scharfis_brain]

@mg262: Hmm. I seem to have contradiced myself. (I only had a few minutes before I had to leave for school)

I have the following in mind, because it 'might' be more reliable to find motion vectors:
search the motion on the separated fields, but create (stable for static areas) a vector stream, that can be applied to the smart-bobbed clip.
But only implement it, if it gives benefits over the current approach (smart-bobbing and then searching for motion)

fpsconversion itself only needs to be progressive. reinterlacing can be done easily afterwards.

[castellandw]

I have the following in mind, because it 'might' be more reliable to find motion vectors:
search the motion on the separated fields, but create (stable for static areas) a vector stream, that can be applied to the smart-bobbed clip.
But only implement it, if it gives benefits over the current approach (smart-bobbing and then searching for motion)

@scharfi, wasn't this already discussed when you mentioned this or is it something else different:

source("blah.xxx")
assume?ff()
vectors=separatefields().analyse(interlaced=true)
compensated=somesmartbob().mvcompensate(vectors)

[scharfis_brain]

yeah it was, but mg262 said he didn't understand it ?!?

[mg262]

castellandw,
have you tried Fizick's Block Overlap plugin yet
That is the third time you have said that in the last four days. I sent you an thorough reply when you first PMed me, and it hasn't changed:
Thank you for reminding me about that... it had slipped my mind. At the moment, it looks like one of the niches Motion will fill is fast motion compensation, which means that the factor of two slowdown from BlockOverlap is quite serious. Other thing is, something like this is mainly for users to try rather than developers -- the ability to mix-and-match plug-ins without having to know anything about the code is one of the great strengths of AVISynth! Of course, that doesn't preclude me from trying it and recommending it... but for the moment my main focus is on prevention rather than cure, i.e. trying to alter my plug-in so it doesn't produce as many blocks (because that's something users can't do).

I probably think it's not such a good idea to do motion compensation and then frame rate conversion separately. Do you think motion compensation and convert frame rate separately might cause jerky motion?This makes no sense. The notion of "motion compensation and then frame rate conversion separately" is meaningless.

I don't mean to be rude... but I think you need to go and absorb a lot more about a) the nature and strengths of AVISynth and b) the uses of motion compensation (which is not an end in itself, but a means to other, specific, ends). I'm not saying this based on a single comment, but rather on the general nature of your posts; there is an implied context behind messages in this thread which you are often missing. Also, second-hand comments (aka argument from authority) are not terribly useful, not because they are right/wrong, but because we need the reasoning, intuition and often technical details that underlie them. Please don't take this the wrong way... I don't mean to have a go at you. But I do think you need to learn to walk before you can run.

scharfis_brain,
Your script was very clear and I understood it; rather, I should have said that I didn't understand point 2. (higher-quality analysis possible after bobbing) coming after the first request (analyse and then bob). The situation is now clear. I think that, as you imply, we will have to implement both and see which is better.

Incidentally, it seems perfectly legal to upsample any clip (interlaced or progressive) to improve the quality of the motion vectors found. (This is just Mug Funky's supersampling again.)

[castellandw]

castellandw,

That is the third time you have said that in the last four days. I sent you an thorough reply when you first PMed me, and it hasn't changed:


Sorry, I thought when you said it didn't preclude you from trying it that you meant you might try it since the Block Overlap plugin produces fewer blocks with motion compensation. Anyway, as I mentioned, I tried out the Block Overlap plugin and seen better results with it on motion compensation, and I was just wondering if anyone tried it out to see if they got better results as well. OK, if it's more of something for users to try out still, then no problem.


This makes no sense. The notion of "motion compensation and then frame rate conversion separately" is meaningless.

I think I should try to rephrase it. What I meant here is on applying motion compensation on the video(whether it's applying MVTools or the Motion DLL) and then using a frame rate conversion function (ConvertFPS and ChangeFPS) for standards conversion. I understand that smart bob deinterlacers are used best before ChangeFPS(which drops and inserts frames) or ConvertFPS(which by default blends frames which causes some motion blur) generally on Avisynth in terms of standards conversion. However, if motion compensation is applied, then would dropping or inserting frames or motion blurring by the likes of ConvertFPS() or ChangeFPS() have any worse effect on the motion compensated video because if not, then I'd be happy to just use ConvertFPS() or ChangeFPS()? So basically, I'm just wondering if both ConvertFPS() or ChangeFPS(), without recognizing the case of motion compensated video will worsen the motion information on a motion compensated video?


I don't mean to be rude... but I think you need to go and absorb a lot more about a) the nature and strengths of AVISynth and b) the uses of motion compensation (which is not an end in itself, but a means to other, specific, ends). I'm not saying this based on a single comment, but rather on the general nature of your posts; there is an implied context behind messages in this thread which you are often missing. Also, second-hand comments (aka argument from authority) are not terribly useful, not because they are right/wrong, but because we need the reasoning, intuition and often technical details that underlie them. Please don't take this the wrong way... I don't mean to have a go at you. But I do think you need to learn to walk before you can run.

Keep in mind that I mentioned before that you guys have much more experience in this than me, and so I'm trying to learn from you guys as best as I can as well. I'm not trying to hinder the discussion in this thread, especially by attempting to be an authority on various things. I can read up and absorb on a lot of things, but it's also good to ask people to get their understanding as well. In the case of standards conversion especially by the Doctor Who restoration team who mention to me as far as I remember that frame rate is converted while the motion compensation is taking place in high-end standards converters, that's why I mention that using MVTools or the Motion DLL and then use ConvertFPS() and ChangeFPS() is probably not a good idea, but I wanted to ask for sure if the motion blurring on ConvertFPS() or the inserting and dropping of frames on ChangeFPS() won't matter? However, since it seems that I won't really get the implied context, to relieve the only need for anyone to respond which involves the point of possible argument, I'll actually just end it before beginning it as best as I can without being insulting by saying that not responding to my question is perfectly fine to be your guys' call. Without being condescending, if I get no response, which usually is very likely for me, then I'm happy to stick to asking in the Avisynth usage forum or just keep silent while looking and trying out stuff here, which I'm very used to doing within my life because I don't want to get in the way interfering and hindering other people's discussions here.

[Mug Funky]

motion estimation and interpolation is meant as a replacement for convertfps. running convertfps after compensation (compensating what?) would be counter-productive. much better to create new frames using motion interpolation than the blending in convertfps (which for lack of a better word could be called temporal interpolation, but that's an ambiguous term).

i'm totally looking forward to fast motion-compensated standards conversion in avisynth - right now i'm doing a straight smart-bob > blend > resize > re-interlace. this is good as most regular standards converters and i'm happy with it, but if there's a way to improve something i'm always up for it.