Link on Motion Compensation

[mg262]

I found this very readable and interesting. It deliberately does not assume knowledge of the Fourier Transform or any mathematical background.

(Mug Funky, you've probably seen this already, but if not I think you will particularly like it -- it seems to relate to the high end converters you've mentioned before on Doom9.)

Original
www.snellwilcox.com/knowledgecenter/books/books/emotion.pdf

Cached
http://www.google.com/url?sa=t&ct=res&cd=1&url=http%3A//www.snellwilcox.com/knowledgecenter/books/books/emotion.pdf&ei=34Y_Q7OuJK2SiAL23rT3CA&sig2=cJNHFSpg4IGI3kV9JoJHoQ

[MfA]

Kinda sad that this is from 1994, and stuff like blending is still being used ...

I think Gerard de Haan's True motion estimation using feature correspondences (http://www.ics.ele.tue.nl/~dehaan/pdf/97_VCIP04Braspenning.pdf) would be more robust and easier to implement than FFT based methods though.

[mg262]

Ah -- brilliant. I have looked before for a link on true-motion, but searching for those words brings up too many irrelevant results. So, thank you very much!

[Fizick]

See papers by de Haan

http://www.ics.ele.tue.nl/~dehaan/

[mg262]

Wow, that's a lot of papers! Thank you very much.

Edit: Please excuse this link for convenience -- I'm a little too lazy to keep using search everytime I want this... MVTools thread (http://forum.doom9.org/showthread.php?t=84770...)

[Fizick]

A LOW COMPLEXITY MOTION COMPENSATED FRAME INTERPOLATION METHOD

http://research.microsoft.com/asia/dload_files/group/mcom/2005/LowComplexityMC.pdf

[mg262]

Looks interesting... but if I have read it correctly it requires you to have access to the MPEG motion vectors, so it's not so straightforward to implement in AVISynth?

[Fizick]

1. We can try use Mpeg2decode
2. We can use vectors from MVtools or Motion as initial set.

[scharfis_brain]

yeah, grabbing motion vectors from mpeg stream themselves would be a cool idea for fast MoComp-Stuff :)

[Manao]

Or not : before doing the MVTools, that is what I planned to do. But vectors used to encode are not necessarily the vectors we would want for MC & co. Using it as a set of predictors, however, might be interesting.

But you'll need yet another way to attach mv to frames in order to give them to the downstream filter that'll effectively do the analysis.

mg262, Fizick, any idea on the format you'd want the data to be ? And on how to attach it properly ?

[mg262]

@Manao,
any idea on the format you'd want the data to be ? And on how to attach it properly?
I don't think I'm going to implement this one, but reading this did make me think of something: it is perfectly possible for a filter to return more than one clip; simply return an AVSValue which is an array of AVSValues, each of which is a clip. So one could modify a source function to return both the video stream and motion vectors in an existing format. (Implementing this is fiddly, but I think it is possible.)

[Fizick]

Manao,
I post this link here simply to do not forget about it. :)
Analysis can be done incide (improved) MVtools.

But it may be discussed later. Probably some unification (Motion and MVtools) will be useful. Or may be not ;)