[XviD-devel] Improving encoding speed with additional information

Christoph Lampert chl at math.uni-bonn.de
Sun Feb 6 11:47:33 CET 2005


Hello Peter, 

On Sun, 6 Feb 2005, Peter Bergmann wrote:
> Was this question too complicated or is there a better place to
> ask for this information  ? hrmpff.

I don't like being hrmpff'ed at, but here is your answer. It guess, 
nobody has answered so far, because there _isn't_ a good answer, and 
also similar questions were (more or less) answered before: 
 
> > 1)
> > Compared to video data I have very small changes from frame to frame
> > because most parts of the screen do not change at all. What are the 
> > best (speed/quality) xvid encoding parameters for such
> > "video data" ?

It sounds to me, that your changes are not what we would consider "small" 
changes (i.e. the difference pic between two frames has only small 
values), but rather "localized" chances, i.e. most stays the same, some 
parts change very much. 

You can try the "cartoon" setting, which is kind of a hack to support
material like this, but apart from that, XviD is optmized for "natural 
video", which is the main target of MPEG-4. For animation, especially like 
geometrical object, other codecs might be vastly more effective (but 
please don't ask me which...). If it's just geometrical object, try 
something vector based. 
If you really want to use XviD, you can also try using a large number of 
B-frames, because those are very efficient if blocks don't change at all. 

> > 2)
> > I have a big advantage: I do know exactly which parts (rectangle area) 
> > of the new frame has changed compared to the previous one. So there 
> > should be no need for xvid to analyse the complete frame!
> > Is there a way to "help" the encoder using this information?
> > How can I tell xvid which areas did not or did change ?

On the API level, you can't. We tried a while ago to support this, for 
speeding up the encoding of black letterbox bars, and to support some kind 
of parallel encoding, but it was dropped very soon because it creates a 
lot of work on the implementation side and there was no obvious gain. 

But feel free to add such a feature yourself: You might want to try 
passing a boolean data structure to the encoder, where each 16x16 block 
has a flag if it changed or not. Then, the encoding routine should mark 
each "unchanged" block as SKIP in or before ME. This should cause all 
further processing (Motion Compensation, (i)DCT, residue encoding) for 
this block to be skipped.

Alternatively, you can use adaptive quantization, to give a very high 
quantizer to the unchanged areas and a low one to the changed. This should 
prevent the common problem that blocks are not skipped, because their 
reconstructed image information isn't close enough to the original (which 
is frequent if the image has sharp edges). 

> > How much cpu could be save?

You can't tell in advance. Definitely not linearly in the area. XviD 
already has a fast "SKIP" detection, so no Motion Estimation is performed 
if the image didn't change at all, and writing these block to the 
bitstream is very fast as well (there's only 1 bit per block). 
What you would gain is much less memory access, but one can only speculate 
about speedup. A rough impression could come from testing like this: 
Create the same animation twice, once encode it in a small window of an 
otherwise static frame, and once encode only the window. Then, compare 
speed and size. 

gruel



More information about the XviD-devel mailing list