[XviD-devel] what's wrong again ;)

Christoph Lampert xvid-devel@xvid.org
Mon, 30 Sep 2002 16:15:26 +0200 (CEST)


On Mon, 30 Sep 2002, Radoslaw 'sysKin' Czyz wrote:

> Hi
> 
> I found another problem with new timecodes ;) They are so simple, yet
> so tricky.
> This time, it's with max_bframes = -1. 

Does encoder_encode without bframe init fbase correctly? 

> Encoding crashes after exactly
> one second, at WriteVopHeader() again.
> Those are time values, dumped at every WriteVopHeader():
> 
> seconds = 0 ;fbase = 65535 ;ticks = 0

Frame #0, ticks=0,   but what strange fbase is that??? 
Is Windows giving us wrong values again? 

> seconds = 0 ;fbase = 65535 ;ticks = 0
> seconds = 0 ;fbase = 65535 ;ticks = 0

If max_bframes=-1 there should be no dummy frames, so this is 
wrong! 

> seconds = 0 ;fbase = 65535 ;ticks = 2730

So fincr = 2730  which gives us  24.0054 fps 
(=fbase/fincr). I don't have to understand this value, do I?

> seconds = 0 ;fbase = 65535 ;ticks = 5460
> seconds = 0 ;fbase = 65535 ;ticks = 8190
> seconds = 0 ;fbase = 65535 ;ticks = 10920
> seconds = 0 ;fbase = 65535 ;ticks = 13650
> seconds = 0 ;fbase = 65535 ;ticks = 16380
> seconds = 0 ;fbase = 65535 ;ticks = 19110
> seconds = 0 ;fbase = 65535 ;ticks = 21840
> seconds = 0 ;fbase = 65535 ;ticks = 24570
> seconds = 0 ;fbase = 65535 ;ticks = 27300
> seconds = 0 ;fbase = 65535 ;ticks = 30030
> seconds = 0 ;fbase = 65535 ;ticks = 32760
> seconds = 0 ;fbase = 65535 ;ticks = 35490
> seconds = 0 ;fbase = 65535 ;ticks = 38220
> seconds = 0 ;fbase = 65535 ;ticks = 40950
> seconds = 0 ;fbase = 65535 ;ticks = 43680
> seconds = 0 ;fbase = 65535 ;ticks = 46410
> seconds = 0 ;fbase = 65535 ;ticks = 49140
> seconds = 0 ;fbase = 65535 ;ticks = 51870
> seconds = 0 ;fbase = 65535 ;ticks = 54600
> seconds = 0 ;fbase = 65535 ;ticks = 57330
> seconds = 0 ;fbase = 65535 ;ticks = 60060
> seconds = 0 ;fbase = 65535 ;ticks = 62790
> seconds = -1 ;fbase = 65535 ;ticks = 65520

There does _this_ -1  come from? It means that the reference 
FRAME has a "lower" timecode than the current. 

> I think I should finally learn how the timestamps work, myself ;)

And I should learn how encoder_encode() works in contrast to
encoder_encode_bframes(), which of course I don't understand either, 
but nevertheless I was able to fix it. 

Aha, encoder_encode calls inc_frame_num() after encoding... Why is that? 
That's a little late for correct timecodes. 

I moved the inc_frame_num() from the very end of encoder_encode() to the
beginning here: 

-----------------------------------SNIP----------------
	start_global_timer();

	ENC_CHECK(pEnc);
	ENC_CHECK(pFrame);
	ENC_CHECK(pFrame->bitstream);
	ENC_CHECK(pFrame->image);

	SWAP(pEnc->current, pEnc->reference);

	pEnc->current->global_flags = pFrame->general;
	pEnc->current->motion_flags = pFrame->motion;
	pEnc->mbParam.hint = &pFrame->hint;

	inc_frame_num(pEnc);

--------------SNAP-------------------


The crash is gone then, because now the frame get's correct time code
before encoding (and WriteVopHeader) is done, not afterwards.

gruel