[XviD-devel] Improving encoding speed with additional information

[Peter Bergmann]

Thank's a lot christoph and sorry for hrmpffing :)
I'll try all of your hints and post the results to this list ...


Christoph Lampert wrote:

>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
>