[XviD-devel] multithreading

Lars Täuber lars.taeuber at web.de
Thu Jun 25 15:28:29 CEST 2009


Hi Radek,

Radek Czyz <radoslaw at syskin.cjb.net> schrieb:
>  > - initialize two buffers. one for future I-frames one for future P-frames
> 
> You're assuming the two GOPs are independent and they only are in 
> constant-quantizer mode. In any other ratecontrol, overflow/underflow 
> from one gop has to be incorporated in compression strength of following 
> GOP.

yes, you're right I'm using quantized encondings with different quantizers for each frame type.
I'd like xvid to use more of my cpu cores to encode faster. To me it seems there is much more power unused on my box.
But I realize that can't be done with this windows compatibility in mind.

How much work is a second API for non-VfW systems and an encoding scheme like I suggested for quantized encodings?

I wonder if the application (avidemux) could somehow emulate my suggested behaviour by starting parallel encodings of single GOPs by reading the first pass log file and cut it into pieces of GOPs at occurences of I-frames. In this situation it would be helpful to have a minimalized first and fast run of xvid to only get to know the order of frame types.
But then the first I-frame of the following GOP can't be used for B-frame calculation at the end of the current GOP. That wouldn't be as efficient as the normal run, would it?

Regards
Lars
-- 
Lars Täuber <lars.taeuber at web.de>


More information about the Xvid-devel mailing list