[XviD-devel] Status of GMC

Christoph Lampert xvid-devel@xvid.org
Sat, 2 Nov 2002 18:00:31 +0100 (CET)


On Sat, 2 Nov 2002, Marco Al wrote:

> Christoph Lampert wrote:
> 
> > gruel
> >
> > P.S. What's smaller? A coded INTER-block without DCT and with vectors
> > (0,0), or a completely black INTRA-block?
> 
> No idea, but a related question ... has anyone tried if using skip (instead of
> (0,0) without coefficients) even has any benefit at all on a global scale if
> b-frames are used? I could see them being counterproductive, you would think the
> skip threshold would have to be higher for a start. 

Why should they not have positive effect? A block which is SKIP in a P-VOP
and the intermediate B-VOPs (which is the common case) is encoded at 1 bit
in total. Without Skip it's at least 10 bits or so per block per frame. 
At low bitrates and in static scenes (when SKIP is frequent) this
should really make a difference. And it speeds things up in decoding...
 
> BTW you sure a specific optimization for borders (which might not even be really
> black a lot of the time, given the constrained luma range of tv signals) is
> really usefull? It is always better to crop after all.

Yes, for encoding efficience of course it's better to crop. But there are
situations where crop isn't possible for some reasons, e.g. hardware
devices which need fixed aspect ratio or always scale to fullscreen. 
Or the black bars are intentional, e.g. mplayer only displays
ASCII subtitles within the video frame. If there are black bars in the
bottom, the subtitles do not cover the picture. 
At the moment, black bars slow down encoding, but need hardly any space. 
If done correctly it's only slighly more than 1 bit per 16x16 block, so
less than +1 kbit/s even in full letterboxed PAL 

Anyway, the problem is simply how to keep GMC efficient (once it is at
all), if parts of the picture are static (e.g. pure black) and one
previously knows about this. 

gruel