[XviD-devel] Two Encoders

[Christoph Lampert]

On Mon, 18 Nov 2002, peter ross wrote:

> >From: Christoph Lampert <chl@math.uni-bonn.de>
> >I had a few bad ideas about SMP. What's your oppinion about this one?
> >
> >Instead of higher speed (which is difficult because of data dependencies),
> >we could go for higher quality:
> 
> this is also achievable with one cpu.

Of course, but it's perfectly possible to do in SMP whereas on single CPU
is will definitely slow things down. Of course, when it's implemented it
should _run_ one single-CPU, too, no question about this. 

> infact, some older ms-mpeg4v3 (divx311) encoders functioned much
> like you described: each frame was encoded twice, using different
> versions of the codec, and the better (psnr,framesize,etc). frame is
> selected.
> 
> if you want to expierement with smp (and i know you do gruel...), why
> not parallelize the bframes encoder? its should be easy.

Because Bframe encoding is not finished (I guess). The structure is
hopefully going to change to something more readable... 
Also, Bframes-SMP is only possible if Bframes are active,
and I don't trust in out Bframe-decision routines, yet, to use them for
"production" material. Quality-targeted SMP is always possible. 

But the main point was, that I am looking for ways to multithread
_without_ having to mess with xvidcore itself ( I don't like the #ifdef
solutions, and huge ifs even less). Simple calling two or more copies of
the encoder could be a wrapper function. Just call encoder_create(),
but with a "XVID_MULTIENCODE" flag. Since a pointer to Encoder-Structure
is passed to the calling routine, internal changes could be done from the
wrapper, too. Neither the core itself, nor the calling application would
have to care about SMP or not. 

gruel