[XviD-devel] How to get informations on a XVid bug ?

[Harghh]

First, thank you for your answers.

I was finally able to reproduce the problem in a debugger as you suggested.
And yes, the problem is related to DirectShow filters.

I tryed to understand the problem, but failed.
So i post my informations here and i hope someone can help me.

I have a small test program which can be used to reproduce the problem. 
Its written in Delphi and use the DSPack DirectShow library.
What this program do is opening an avi file with a File Source DS filter 
and render this file to a video renderer window, its pretty simple.
Just send me a mail and i will send it to you with its source code.

I did all tests with XviD 1.0.1.

I can reproduce the problem on at least 3 computers (running W2K and WXP, 
with DirectX 8.1, 9.0b and 9.0c).

There is some conditions for the bug to appear :

- the video file need to have a size > viewer window size
- you need to completely hide the viewer window while playing (with 
another window for instance), hiding only partially does nothing for me
- it always crash after than a keyframe passed through the 
CxvidDecoder::Transform, non-keyframes don't make it crash
- it seems to be the first keyframe after than the window was hidden who 
make crash

When the bug occurs i get the following call stack (i replaced 
yv12_to_bgra_mmx with yv12_to_bgra_c for the test purpose) :

yv12_to_bgra_c(unsigned char * 0x0667e1bc, int -516, unsigned char * 
0x063daa00, unsigned char * 0x063fdc60, unsigned char * 0x06407e20, int 
448, int 224, int 320, int 240, int -2147483648) line 446 + 362 bytes
safe_packed_conv(unsigned char * 0x06660000, int 516, unsigned char * 
0x063daa00, unsigned char * 0x063fdc60, unsigned char * 0x06407e20, int 
448, int 224, int 320, int 240, int -2147483648, void (unsigned char *, 
int, unsigned char *, unsigned char *, unsigned char *, int, int, int, 
int, int)* 0x01ea11ef _yv12_to_bgra_c, ...) line 528 + 45 bytes
image_output(IMAGE * 0x06350150, unsigned int 320, int 240, unsigned int 
448, unsigned char * * 0x01782a34, unsigned int * 0x01782a44, int 
-2147483584, int 0) line 764 + 120 bytes
decoder_output(DECODER * 0x06350080, IMAGE * 0x06350150, MACROBLOCK * 
0x064d3680, xvid_dec_frame_t * 0x01782a20, xvid_dec_stats_t * 0x022efe84, 
int 0, int 4) line 1379 + 70 bytes
decoder_decode(DECODER * 0x06350080, xvid_dec_frame_t * 0x01782a20, 
xvid_dec_stats_t * 0x022efe84) line 1537 + 44 bytes
xvid_decore(void * 0x06350080, int 2, void * 0x01782a20, void * 
0x022efe84) line 680 + 17 bytes
XVID! 01E920f2()

and it stops on the line :
MAKE_COLORSPACE(yv12_to_bgra_c, 	4,2,2, YV12_TO_RGB,		2,1,0,3)

I found another bug while doing my tests. I deactivated Direct3D 
acceleration using DXDiag and in this case the test program crashed in 
some circumstances when it start playing the first frame.
The problem was the line CloseLib() at the beginning of 
CxvidDecoder::CheckInputType in this block :

	if (*mtIn->Type() != MEDIATYPE_Video)
	{
		DPRINTF("Error: Unknown Type");
		/* The following line was causing an error in my program while Direct3D 
acceleration
		   was disactivated */
		//CloseLib();
		return VFW_E_TYPE_NOT_ACCEPTED;
	}

As the error is handled and an error code is returned, why closing the 
library ?
Doing this will crash if another input type is accepted and the filter is 
then used normally.

I also had 3 minors problems compiling Xvid (in debug mode) on a Windows 
2000 system :

- libxvidcore : in debug mode the .dll is named libxvidcore.dll instead of 
xvidcore.dll and isn't put in the bin directory.
- vfw : after linking there is a copy command which copy xvidcore.dll into 
vfw/bin, i had to replace each / with a \
- dshow: error on linking, i had to replace strmbase.lib with strmbasd.lib 
in Project settings -> Link -> Object/Library modules


Harghh