[FFmpeg-soc] [soc]: r1335 - dirac/libavcodec/dirac.c

[Michael Niedermayer]

Hi

On Mon, Sep 10, 2007 at 08:14:19PM +0200, Marco Gerards wrote:
> marco <subversion at mplayerhq.hu> writes:
> 
> > Author: marco
> > Date: Mon Sep 10 18:14:17 2007
> > New Revision: 1335
> >
> > Log:
> > fix the code to check for a zero codeblock
> >
> > Modified:
> >    dirac/libavcodec/dirac.c
> 
> With this commit packing of the motion vectors work.  For now I just
> use semi-random motion vectors and calculate a residue based on that.
> Of course this is not useful for other reasons than testing if motion
> vector packing works and it does.  Now the encoder does support
> writing the bitstream for intra and inter frames.
> 
> So the next logical step is searching for optimal/good motion vectors.
> As you know, I have no prior experience in multimedia and FFmpeg.  So
> my questions can be quite silly or trivial.
> 
> First of all, am I right that the goal of a good ME is decreasing the
> information in the residue?  In that case the residue gets smaller
> when compressed.  So a better match results in a smaller residue thus
> better compression.

well, the theoretic goal is to produce a bitstream which when decoded
looks as similar as possible relative to the original video to a human
for a given bitrate ...

now we dont have 2^(size in bits of the final video) humans and decoders
currently to solve this directly :)

because of the minor problem mentioned above yes, reducing the residue
and the number of bits needed to store the motion vector is a common
goal of ME

for estimating the bits of the motion vector something like
log2(ABS(coded mv.x)) + log2(ABS(coded mv.y)) might do if the exact value is
hard to find due to adaptive arithmetic coding and such

to meassure the amount of reside left libavcodec has many comparission 
functions
see DSPContext, me_cmp_func, AVCodecContext.me_cmp and all the stuff
surrounding it

the resulting distortion value and number of bits can be combined by:

distortion + lambda*bits where lambda is a constant, and lambda is generally
set proportional to the quatization factor or quantization factor squared
depending on the used distortion meassure
the best motion vector can then be searched by trying to minimize that ...

this happens to be optimal in the sense that the global minimum of that
equation will correspond to the minimum distortion at a specific number of
bits

also maybe you want to look at the paper below, though theres nothing
wavelet or OBMC related in it IIRC so iam not sure how usefull it is,

http://citeseer.ist.psu.edu/504646.html

maybe someone else, loren? has a link to a more recent and good 
motion estimation paper?


> 
> Next, I wonder how to proceed.  Can I use a ME algorithm from FFmpeg?

can, yes its surely possible ...


> Michael mentioned iterative_me, from Snow.  I assume this is the only
> OBMC ME algorithm in FFmpeg?  

yes, though, simply using a non-OBMC algorithm (that is pretend during ME
that there where just squares and no overlap) will also work, it would be
somewhat lower quality though ...


> It's quite hard for me to understand
> this code and to understand if it is possible to use this at all.

well, i dont think the snow code can be used as is, it surely would need
some changes, the other non OBMC ME code in libavcodec can be used as is
but it requires you to build a "fake" MpegEncContext, not beautifull i know
if you want to try, then look at the snow or svq1 svn log at the point where
ME support was added to them ...
also no ME code in libavcodec currently supports blocks smaller than 8x8

also if you like to try, a new clean, flexible fast and generic ME code
would be welcome
(or cleaning up the existing code to make it independant of MpegEncContext)


[...]

> Dirac supports pixel, halfpel, qpel and eighthpel motion compensation.

the old standard way to handle that is to do full pel search then try the
8 sorrounding halfpel points around the best fullpel point, then the
8 surrounding qpel points around the best halfpel point and so on
(this is of course slow, there are faster methods like doing some zonal
search begining at the best fullpel point or analysing and interpolating
the error surface from the available fullpel points and then just trying
points which have a low expected error/distortion...)

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Concerning the gods, I have no means of knowing whether they exist or not
or of what sort they may be, because of the obscurity of the subject, and
the brevity of human life -- Protagoras
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-soc/attachments/20070911/8229f7b3/attachment.pgp>