Re: Advanced Motion Compensation for sub 500kbit DVD Video

--- Lourens Veen <[email protected]> wrote:
...[our triangle-based codec]
> > had a very wierd 'warbly' look to it, as if you
> were
> > looking at the image through an old piece of glass
> > with irregular thickness, or a funhouse mirror.
> 
> Hmm, interesting. What did the motionfields look
> like, were they 
> correct in the sense that the pixels in one frame
> moved the way 
> they did in the movie? I can see this going wrong if
> the wrong 
> pixels are matched, but not if the matching is
> correct.

The problem was subtle, and to be fair we gave up on
it before truly completing the research.  It seems to
me that our problems started once we tried to compute
the new image off of the previously reconstructed
image, as opposed to just morphing a single image over
several frames.  The slightest error in the motion
vectors would multiply, creating a 'jiggling' effect. 
It didn't seem likely that residual coding was going
to be very beneficial with this sort of instability. 
Then again, we barely scratched the surface of what
you could try.
> 
> Wait a second, I can see it going wrong. If the
> surface the triangle 
> is mapped to isn't really flat, the linear
> interpolation across the 
> traingle is going to be incorrect. You'd have to
> have some sort of 
> displacement mapping for the texture instead of only
> the motion 
> information from the traingles vertices. I think
> :-). Comments?

It depends on how coarse or fine your triangulation
is.  I think for most motion sequences, you could
ignore this problem safely.  3D engines typically do
not do this correction (at least they didn't 5 years
ago), and you don't tend to notice it unless the
perspective is extreme (like a wide-angle lens on a
roadway for instance).  However, of course your
residual error will be off a bit, and have to spend
more bits correcting.  But this is how all compression
works today, so you shouldn't be in too bad a
position.

> ...[in traditional algorithms,]
 Errors do not propagate; and the
> > problem is conveniently broken down into modular,
> > disconnected pieces.
> 
> I see. But it's rather hard to extrapolate motion
> vectors if they're 
> jumping all over the place because there happened to
> be a better 
> match somewhere else. Which potentially costs bits.

Ahh, you hit the nail on the head.  Typical motion
vector algorithms don't necessarily do 'motion' that
truly corresponds to the motion of the objects in a
scene.  Take a hazy sky, for instance; much of it
looks the same, so you could use a block from anywhere
and have a pretty good match.  But try extrapolating
that to the rest of a motion field, and you are in
trouble!  Now you get the global, recursive problem;
which set of motion vectos works best GLOBALLY, when
they're all part of a motion field?

...
> Vibrant? That may be a bit too optimistic :-). The
> way I see it is 
> that with VP3 soon available, there's not really a
> 'market' for 
> Tarkin unless it's substantially better than VP3,
> and other current 
> codecs (someone once quipped "a movie on a zip-disk"
> and that's 
> what I think Tarkin should aim for). I'm not quite
> sure where VP3 
> stands performance-wise, and from what I gather from
> the web it's 
> not quite up to par with DivX, but it's a lot
> cheaper for sure, and 
> with disk space in abundance the size difference
> only really 
> matters in online distribution. 

With a few tweaks, I think it can definitely beat or
at least equal MPEG-4/Divx.  Some would say it does so
already; it's a pretty close match.

>There is OpenDivX,
> but that's not 
> Free Software and also has patent issues, being an
> MPEG-4 encoder. 
> So that's where something slightly better than VP3
> would come in 
> handy, but otherwise I don't think it would be that
> useful.

Tarkin should definitely be shooting for a substantial
gain.  You really need to look at state-of-the-art
codecs such as On2's VP5 or H.26L; to be taken
seriously, a codec based on totally new technology
will need to have a 20-30% bitrate advantage at
similar quality levels.
> 
> Tarkin at the moment has been described by Monty as
> a research 
> project, and that's what it is. I feel the goal
> should be to create 
> a codec that is substantially better than anything
> currently 
> available, which means we'll have to try new things
> (which we have 
> to anyway to avoid patent problems). If something
> doesn't work, we 
> simply have to try something else. Any help with
> figuring out what 
> does and what doesn't work is very much appreciated,
> so keep 'em 
> coming :-).
> 
> Lourens
> - -- 
> GPG public key:
> http://home.student.utwente.nl/l.e.veen/lourens.key
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.6 (GNU/Linux)
> Comment: For info see http://www.gnupg.org
> 
>
iD8DBQE9ODUPvmNyqZHWDvURAgwxAJ9gn6zQ1ndNHP1+dbGUCfBZihNvkQCeNdeP
> ehLEsO9lYyc1ucbWd+qanyU=
> =6IPP
> -----END PGP SIGNATURE-----
> 
> 
> --- >8 ----
> List archives:  http://www.xiph.org/archives/
> Ogg project homepage: http://www.xiph.org/ogg/
> To unsubscribe from this list, send a message to
> '[email protected]'
> containing only the word 'unsubscribe' in the body. 
> No subject is needed.
> Unsubscribe messages sent to the list will be ignored/filtered.

__________________________________________________
Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes
http://autos.yahoo.com

--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to '[email protected]'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.