[XviD-devel] ref bitstreams

[skal]

	Pete,

On Mon, 2002-11-04 at 13:45, peter ross wrote:
> >From: skal <skal@planet-d.net>
> >	Hi,
> >
> >	I'm trying to decode some reference bitstream with 'xvid_decraw'
> >	but failing (amongst others) with this one:
> >
> >ftp://ftp.tnt.uni-hannover.de/pub/MPEG/video/conformance/version_2/
> >vcon-ge11-ACEL1.bits
> >
> >	Did someone already try decoding the reference bitstreams too,
> >	and could have a hint about what's going on before I dive into
> >	the code?
> >
> >	later,
> >		Skal
> >
> 
> hi,
> 
> its an ACE (advanced coding efficiency) bitstream, the
> "video_object_type_indication" header field is set to 12.
> xvid currently halts if the object type isnt core,simple, or main.
> 
> to enable it, edit src/bitstream/bitstream.c ...
> 
> 	if (BitstreamShowBits(bs, 8) != VIDOBJLAY_TYPE_SIMPLE &&
> 		BitstreamShowBits(bs, 8) != VIDOBJLAY_TYPE_CORE &&
> 		BitstreamShowBits(bs, 8) != VIDOBJLAY_TYPE_MAIN &&
> 		BitstreamShowBits(bs, 8) != 0)	// BUGGY DIVX
> 
> ... and add "BitstreamShowBits(bs, 8) != 12", or just remove the
> if() statement completetly.

	thanks, it passes though, now...
> 
> the video decodes correctly xvid; although it is a rather blocky
> encoding.

	That's the problem :) I don't know what it should look
	like in the end... Anyway, I've dug a little in the 
	norm/code and found something that isn't clear: 
	section 7.6.9.6 states that a skipped mb in the future 
	should trigger a decoding of b-vop macroblock "treated 
	as the fwd mode with motion vector". 
	Very well, now section 7.6.8 says that the predictor
	should then be updated afterward. So, I've added a 
 
 dec->p_fmv = zeromv;  

	at line 1236 of decoder.c (just after decoder_bf_mbinter(...)).
	It seems to reduce the blockyness, but I couldn't say,
	lacking a reference output to aim at...

	So, is this correction correct?

	(BTW: sooner or later, calls to decoder_bf_mbinter() or
	decoder_bf_interpolate_mbinter() according to the exact
	mb->mb_type (or variant thereof) will have to sorted for
	qpel interpolation, because there's a difference between
	16x16 prediction and 4*(8x8) ones...   </BTW>)

	(<BTW2> Section 7.6.9.6 also talks about skipped MB in
	DIRECT mode if modb1 is '1' blah blah... which appears
	to me completely out of the point...Is it?)


	I've also tried the other reference bitstream 
	'vcon-a1os8.bits' (the dreaded Stefan sequence) and it
	seems, too, decoding gets wacky around frame #19, with 
	or without the 'p_fmv' modification...

> 
> also, the decoder has debug output which ive found to be most
> useful when decoding proprietary encoded (or test) streams.
> debug output is enabled by editing src/portab.h, and setting
> DPRINTF_LEVEL macro to 0xf.

	thanks, this is most useful...

	bye,

			Skal