[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