[M4IF Technotes] Motion estimation + SAD

[the_ether]

Okay, I think I'm sorted now, but is the prediction error the absolute of
the difference between current and previous frames?
If we only have 8 bits / pixel I was wondering what happens about the sign
and whether the DCT only worked with positive values.
I'm assuming that the prediction error can be -ve otherwise the decoder
won't know how to reconstruct the block., but I'm not sure how to handle
the -ve sign.
----- Original Message -----
From: "Peter Haighton" <Peter.Haighton   m4if.org>
To: "the_ether" <the_ether   btinternet.com>
Sent: 29 November 2023 15:56
Subject: RE: [M4IF Technotes] Motion estimation + SAD
> No, the SAD is not the prediction error. The prediction error is
> current-predictor.
>
> Peter
>
>
> -----Original Message-----
> From: the_ether [mailto:the_ether   btinternet.com]
> Sent: Thursday, November 29, 2023 10:37 AM
> To: Peter Haighton
> Subject: Re: [M4IF Technotes] Motion estimation + SAD
>
>
> Thanks for the reply.
>
> I thought that the SAD was also used as the 'prediction error' for
> P-blocks
> which is then passed to a DCT routine for compression. This is what the
> formulas I've seen refer to I believe. In whcih case, my original
> questions
> stand. Why subtract the number of pixels in the block (or is it
> macroblock)?
>
> g.
>
> ----- Original Message -----
> From: "Peter Haighton" <Peter.Haighton   m4if.org>
> To: "the_ether" <the_ether   btinternet.com>; <Technotes   lists.m4if.org>
> Sent: 29 November 2023 14:04
> Subject: RE: [M4IF Technotes] Motion estimation + SAD
>
>
> > Graham,
> >
> > I am not sure exactly what you mean below. SAD is used as to to help
> find
> > the best matching block that minimizes the difference between the
> current
> > and the predictor frame. There are other methods besides SAD. If you
> have
> > already determined that the motion vector is at (0,0) then there is
> little
> > reason to do a SAD.
> >
> > MPEG-4 does support higher bits/pixel in the N-bit profile, but the rest
> > of the video profiles only support 8bits/pixel/component.
> >
> > Peter
> > --
> > Peter Haighton
> > VideoSpheres Inc.
> > 84 Hines Road
> > Kanata, Ontario
> > Canada, K2K 3G3
> > Tel: (613) 270-9646 x3022
> > Fax: (613) 271-9442
> > email: peterh   VideoSpheres.com
> >
> > See http://www.m4if.org for the latest on MPEG-4
> >
> > -----Original Message-----
> > From: technotes-admin   lists.m4if.org
> > [mailto:technotes-admin   lists.m4if.org]On Behalf Of the_ether
> > Sent: Wednesday, November 28, 2023 10:54 PM
> > To: Technotes   lists.m4if.org
> > Subject: [M4IF Technotes] Motion estimation + SAD
> >
> >
> > I have some basic questions:
> >
> > 1- What is the formula for calculating the sum of absolute differences
> > (SAD)
> > for a block, for which the motion vector (MV) has been determined to be
> > (0,0)?
> >
> > I have seen:
> >     SAD = SAD(0,0) - (Nb / 2 + 1)
> >
> > but with two interpretations of Nb:
> > a) Nb = the number of pixels inside the VOP
> > b) same as (a) but multiplied by 2^(bits per pixel - 8) and number of
> > pixels
> > inside the macroblock instead of VOP
> >
> > I have a feeling that MPEG-4 only supports 8 bits per pixel, or at least
> > only 8 bits each pixel in each of the Y, Cb and Cr components. In which
> > case
> > 2^0 = 1 so (a) = (b). (Except for no. of pixels  inside VOP vs MB which
> I
> > think is a typo)
> >
> > 2- Shouldn't Nb be the number of pixels in a *block* (ie Nb = 64)
> instead
> > of
> > a macroblock since DCT is calculated on each of the 6 blocks within a
> > macroblock?
> >
> > 3- Why have this special case for MV(0,0) anyway? What if we have no
> > movement between two frames (ie SAD(0,0) = 0), why subtract (Nb / 2 + 1)
> > prior to performing DCT on that block ?
> >
> > Regards
> >
> > graham
> >
> >
> > _______________________________________________
> > Technotes mailing list
> > Technotes   lists.m4if.org
> > http://lists.m4if.org/mailman/listinfo/technotes
> >
>
>
>
>