[PATCH] MPEG doxy comments (was Re: [Ffmpeg-devel] Motion Estimation in snow.c for Waevelet encoded frames (DWT))

[Michael Niedermayer]

Hi

On Sat, Mar 31, 2007 at 11:06:45PM +0200, Guillaume POIRIER wrote:
> Hi,
> 
> On 3/30/07, Loren Merritt <lorenm at u.washington.edu> wrote:
> >On Fri, 30 Mar 2007, Aniket Joshi wrote:
> >
> >> I am trying to implement a new motion estimation algorithm for wavelet
> >> encoded frames (DWT). The command I use for encoding the raw file is:
> >> ffmpeg -t 60 -s 176x144 -i formulaone_64kbps_5fps.yuv -f rawvideo 
> >-pix_fmt
> >> yuv420p -strict -2 -vcodec snow -b 600 -an -f mp4 play.mp4.
> >>
> >> I have some queries about the motion search part:
> >>
> >>
> >> - Could you please tell me what exactly the cmp function defined at
> >> line 106 of motion_est.c does? Does it compare two macroblocks?
> >
> >It compares two blocks, which may be full macroblocks or may be partitions
> >thereof. Though snow doesn't have macroblocks in the same sense as
> >mpeg-like codecs, so you can consider all blocks to be partitions of
> >various sizes.
> 
> [..]
> 
> I've put your explanations as Doxy comments.
> 
> Is it worth making it to svn?

definitly, see my comments below though
[...]
>      int pre_penalty_factor;
> -    int penalty_factor;
> +    int penalty_factor;                /*!< an estimate of the bits required to
> +                                        code a given mv value, e.g. (1,0) takes
> +                                        more bits than (0,0). We have to
> +                                        estimate whether any reduction in
> +                                        residual is worth the extra bits. */

maybe clarify mv value vs. difference to predited mv ...


[...]
> Index: libavcodec/motion_est_template.c
> ===================================================================
> --- libavcodec/motion_est_template.c	(revision 8578)
> +++ libavcodec/motion_est_template.c	(working copy)
> @@ -991,13 +991,24 @@
>          return   var_diamond_search(s, best, dmin, src_index, ref_index, penalty_factor, size, h, flags);
>  }
>  
> +/**
> +   \param P[10][2] a list of candidate mvs to check before starting the
> +   iterative search. If one of the candidates is close to the optimal mv, then
> +   it takes fewer iterations. And it increases the chance that we find the
> +   optimal mv.
> + */
>  static av_always_inline int epzs_motion_search_internal(MpegEncContext * s, int *mx_ptr, int *my_ptr,
>                               int P[10][2], int src_index, int ref_index, int16_t (*last_mv)[2],
>                               int ref_mv_scale, int flags, int size, int h)
>  {
>      MotionEstContext * const c= &s->me;
> -    int best[2]={0, 0};
> -    int d, dmin;
> +    int best[2]={0, 0};      /*!< x and y coordinates of the motion vector.

of the best motion vector IIRC


> +                               i.e. the difference between the position of the
> +                               block current being encoded and the position of
> +                	       the block chosen to predict it from. */
> +    int d;                   ///< the score (cmp + penalty) of any given mv
> +    int dmin;                /*!< the best value of d, i.e. the score
> +                               corresponding to the mv stored in best[]. */


can local variables be doxygenized?

also please use consistent doxygen tags (/*! vs. /**)


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

I know you won't believe me, but the highest form of Human Excellence is
to question oneself and others. -- Socrates
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070331/abbafdc4/attachment.pgp>