[XviD-devel] question about gmc

[Christoph Lampert]

Hi,

On Fri, 7 Mar 2003, Radek Czyz wrote:
> > Also, we don't use the result of GME as predictor, if the
> > result is translational-only (GMC is switched off, then) and that we
> > really should.
> 
> ...and that puts me back to not-understanding part of the universe..
> We can't use the result of GME as predictor because we do GME later.

Again, I meant of previous frame. 

> I'll go to sleep now. The best thing to do ;))))

> Ah, just a simple suggestion/question. In B-frames, we do ME first
> and coding later (just like in pframes). Is there something which
> would stop us from doing it one by one? (ME->MC->coding; repeat)?
> 
> It could be a bit faster - MC data still in cache after ME.

There are two approached in a clash:

a) Do everything macroblock based, 
   ME for a (macro)block, MC for the block, DCT for the block, 
   bitstream encoding etc. for the block, then start with next block

b) Do everything framebased, 
   ME for all blocks, MC for all blocks, DCT for all blocks etc. 

The advantage of a) is speed. Everything is as localized as possible, 
so you can reuse cached data. 

The advantage of b) is "more information". You can reuse data from the
previous step for the next. This is useful for everything "adaptive",
e.g. adative quantization might want to use ME information of _all_
blocks before decising on a quantizer for _any_ block. 

XVID uses a mixture at the moment: Something is framebased (ME), something
macroblock based (MC->Coding). We even switched from one to the other and
back at one time. 
I think the speed penalty for b) is easier to avoid (by prefetch) than the
missing information problem of a), so if we think of more 
"intelligent" routine for the future, b) or the XVID mixture would be
easier to extend. 
We can of course also stick to a), _until_ somebody comes up with a
routine that needs the information. Image preprocessing/filtering or
segmentation would be candidates that needs as much information as
possible.

gruel