[XviD-devel] Two Encoders

[peter ross]

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

have a look at the "bframe flush code" located at the begining of
encoder_encode_bframes(). when pEnc->flush_bframes is set,
the encoder encodes all the frames in the pEnc->bframes array.
it does this incrementally over several calls to encoder_encode_bframes,
until pEnc->bframenum_head == pEnc->bframenum_tail.

---
if ((pFrame->image == NULL || pEnc->flush_bframes)
	&& (pEnc->bframenum_head < pEnc->bframenum_tail)) {

        /* ... ignore the final frame fixup ... */

	FrameCodeB(pEnc, pEnc->bframes[pEnc->bframenum_head], &bs);

	pFrame->length = BitstreamLength(&bs);
	pFrame->intra = 2;

	if (input_valid)
		queue_image(pEnc, pFrame);

	emms();

	RateControlUpdate(&pEnc->rate_control, 
pEnc->bframes[pEnc->bframenum_head]);
	pEnc->bframenum_head++;

	return XVID_ERR_OK;
}
---

a basic 2-threa smp version would call FrameCodeB twice.
the pthreads control code is probably the most difficult part!

-- pete

_________________________________________________________________
Tired of spam? Get advanced junk mail protection with MSN 8. 
http://join.msn.com/?page=features/junkmail