Re: multithreading

Hi,

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

There is a better way, "just" do what x264 does. It scales very well and 
allows for some really interesting stuff (like trellis-based frame 
decisions).

If someone would follow x264's overall design closely then he can 
achieve that reliably. The biggest issue today is not VfW compatibility 
really, but simply the fact there is nobody interested in doing that - 
it's a hard work and xvid is not "fun". It's old, relatively mature, its 
user base are not enthusiasts and there is minimal "community" today - 
don't forget it was strictly community that drove the most exciting 
stage of xvid's development.

Radek


Lars Täuber wrote:
> Hi Radek,
> 
> Radek Czyz <[email protected]> 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

_______________________________________________
Xvid-devel mailing list
[email protected]
http://list.xvid.org/mailman/listinfo/xvid-devel