[XviD-devel] help me please (about setedges() and others)

[Nicola Bicocchi]

On Thu, 30 Oct 2003 08:08:18 +0100 (CET)
Christoph Lampert <chl at math.uni-bonn.de> wrote:

> On Wed, 29 Oct 2003, Nicola Bicocchi wrote:
> >   i'm playing with xvid in my thesis and i don't understand some things:
> 
> Hi,
> what's the thesis about? 

A research group of my univeristy have written some code which 
recognizes, classifies and tracks moving objects in a scene, and
automatically recognizes background changes whenever an object
becomes static.
The idea is to store (or send) not the whole scene but only
interesting objects.
Since there are no core profile implementations avaiable, I
decided to modify xvid to reach the goal.
I've already written a program, but it doesn't reach
psnr/bitrate rate values that i was attending for.

I've a couple of other questions.
could you breifly explain me what are refH refV refHV,
and whait is acdc_prediction in I-frames??

thank you very much
and excuse me for my bad english
bye



> 
> > 1) in encoder creation: 
> >   pEnc->mbParam.edged_width = 16 * pEnc->mbParam.mb_width + 2 * EDGE_SIZE;
> >   pEnc->mbParam.edged_height = 16 * pEnc->mbParam.mb_height + 2 * EDGE_SIZE;
> > 
> > why edged_width and height are so big ?
> 
> It's not very big, it's just 2*EDGE_SIZE (1 left, 1 right) larger than the
> original frame. mb_width is the width in "number of macroblocks"! Those
> are 16 pixels wide each. 
> 
> > which is the function of the extra memory allocated ?
> > i don't understand the function image_setedges() called in FrameCodeP. what does it do ?
> 
> A general rule in MPEG-4 is the following: If a position (e.g. a
> vector) points to outside the (visible) frame, the pixel value at the edge is 
> used instead of the nonavailable one. 
> Since it would be too slow to always check for outside boundaries and 
> decide to use edges pixel instead, we just add a region of (at
> least) 16 pixels to every edge, which is identically filled with this edge
> pixel value. Then e.g. a macroblock lying half inside and half outside the
> normal frame can be just be treated the same as one completely inside the
> frame, so we get rid of all checks and special cases. 
> 
> 
> > 2) i would like to store videos recorded by a fixed camera.
> > in these videos background stands still and moving objects are quite little.
> > in your opinion are there big problems if i would like to code not the whole frame
> > but just a part of it (a rectangular region) ??
> 
> Yes. The big problem is, that it wouldn't work with XviD, and you would
> have to leave MPEG-4 Advanced Simple Profile. There is support for
> encoding arbitrary objects, but that's only in Main Profile. XviD is far
> from that. You can't just encode a part of the frame, that's not possible
> with the current routines. 
> If you knew in advance, that some parts of the image do not move and will
> never move, then you can crop the input. But with moving objects, the
> changing reagion of course changes over time. 
> 
> But that it not much of a problem: If a part of the frame doesn't change
> at all, it is usually (for P- and B-VOPs) encoded in SKIP mode which
> means, each 16x16 macroblock takes just a single bit in the bitstream. 
> 
> gruel
> 
> 
> _______________________________________________
> XviD-devel mailing list
> XviD-devel at xvid.org
> http://list.xvid.org/mailman/listinfo/xvid-devel