[FFmpeg-devel] [Patch][GSoC] Motion Estimation filter

Michael Niedermayer michael at niedermayer.cc
Wed Apr 13 22:01:35 CEST 2016

On Wed, Apr 13, 2016 at 07:24:42PM +0000, Davinder Singh wrote:
> good vectors? how can i improve them? since it search for every possible
> place, it should give best match. can you give more details, why
> surrounding vectors need to be considered?

the goal is to find the true motion that is how the physical object
moves, the best match pixel by pixel may not represent the true motion
at all
for example a block that contains a finely detailed high contrast
object and that matches with a low difference to only one spot in the
new image would likely represent a good/true motion vector
a block that contains a sharp straight line and that matches well
would likely be accurate in the direction normal to the line but may
be somewhat inaccurate in the direction along the line
a block containing nearly flat constant color will quite possibly
match somewhere best that is very far from the true motion
and blocks that on another frame move off screen or behind other objects
will also match best somewhere pixel by pixel but wherever they will
match it will not be the true motions direction

whats needed is to have the "strong/good" matching vectors pull any
surrounding weak ones towards themselfs in some form.

Researching algorithms/papers that attempt to find true motion well and
robustly, may be needed. Its liklely theres some existing research and
experiments in that area. Of course we will have to experiment too
but there should be some existing stuff

Its important to note though that this problem differs from motion
estimation used in video encoding.
But the methods used in video encoding still should perform much better
than "flat" independant exhaustive search (they are also MUCH faster)
For encoder targeted ME there is UMH and the older EPZS
i dont know what algorithm is good for finding true motion
but the encoder targeted ones at least have a term that minimizes
vector differnces (as there is cost in a encoder to store the
difference from the predicted)

> also i tried to compare it with export_mvs, they seems quite similar.
> the export_mvs ones, sometimes use multiple vectors at for certain blocks.
> DSM_
> On Tue, Apr 12, 2016 at 5:44 AM Michael Niedermayer <michael at niedermayer.cc>
> wrote:
> > On Sat, Apr 09, 2016 at 11:50:07PM +0000, Davinder Singh wrote:
> > > ok, applied the changes. with new closest vector condition. will add
> > > threshold now.
> >
> > it may be beyond the scope of this qualification task but to get
> > good quality vectors the surrounding vectors will have to be
> > considered in choosing each vector
> >
> > [...]
> >
> > --
> > Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> >
> > The bravest are surely those who have the clearest vision
> > of what is before them, glory and danger alike, and yet
> > notwithstanding go out to meet it. -- Thucydides
> > _______________________________________________
> > ffmpeg-devel mailing list
> > ffmpeg-devel at ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is wrong.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20160413/7f0f3a03/attachment.sig>

More information about the ffmpeg-devel mailing list