[XviD-devel] Two Encoders

[Christoph Lampert]

Hi,

On Mon, 18 Nov 2002, peter ross wrote:
> hi,
> 
> >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.
> 
> the FRAMEINFO structure is fairly rock-solid, and i've no intentions
> of changing it. 

Sorry, I didn't mean data structures, I meant "logical structure" of the
routines (I still think encoder.c is somehow a mess).

> fair enough. #ifdefs are bad software engineering,
> and there's still some of 'em in xvidcore dev-api-3.
> in addition to my next commit, i'd like to remove the BFRAMES #defs,
> since xvidcore nolonger compiles without BFRAMES.

I already did that in many files, but not in all...

> >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.
> 
> right. here's my suggestion for simple quality-based-smp:
> 
> 1. modify xvid_encraw (or whatever) such that each thread maintains
>    one instance of the encoder.
> 
> 2. the main/control thread, will instruct each worker thread to encode
>    the current frame. obviously, each thread will use different
>    encoding settings.
> 
> 3. the main/control will wait for all the worker threads to finished.
>    it will then determine the optimal encoding, ie. which thread
>    produced the shortest frame length.
> 
> 4. copy the internal encoder state of the optimal thread, to all the
>    other worker threads (ie. the reference image, and mvs).
>    this is the messiest part: i suggest #includ'ing encoder.h into
>    xvid_rawenc.c, and perform an image_copy on he reference image.
> 
> 5. write bitstream frame to disk, read next input frame from source,
>    and goto 1.

Exactly my idea (for testing). For a final version ("final"? what does
that word mean???) it could be a part of encoder_create() or
encoder_encode(), but not in near future... 

gruel