weird VDub crashes

[R3g]

Having been away for one month, I upgraded XviD and started a new encoding session to see the improvments. The problem is that VDub crashes all the time. The weird thing is that it happens never at the same time. It can crash after 20 minutes of encoding, but yesterday it ran without problem during 6 hours before crashing (1000 frames from the end )
When it crashes, VDub send me it's own error popup. When I hit ok, windows sends me an application error messagebox saying : "The instruction at xxxxxxxx uses the address yyyyyyyy . The memory cannot be 'read'". xxxxxxxx and yyyyyyy are never the same. Don't know if it is useful, but I join to this message the crash report generated by VDub. The program disassembly it shows is alwys the same, and the error always at the same place. All thi assembly doesn't mean anything to me, so if someone could explain what it says...

Finally, my config : I use a Dvd2Avi 1.86 project frameserved to VDub through Avisynth. I've had the error with VDub 1.4.9 and 1.4.10, and with XviD binaries dated 5, 6, and 14 of April, from Nic or Koepi.

Please help me 'cause I can't wait for too long before trying the new codec!!!

[-h]

Hrm that assembly code isn't from XviD. It's colorspace conversion code from the looks of it, so I'd say the culprit is DVD2AVI (or specifically, MPEG2DEC.DLL).

Not sure what you can do about that, apart from trying a different MPEG-2 decoder.

-h

[R3g]

Thanks. Never had problem with mpeg2dec, I use it for long time. Do you think it can come from Dvd2Avi ? It's the only soft I changed in the decoding side.

Sorry for involving XviD into that, but I saw xvid!encore on top of the error window.

Thanks

[R3g]

Well, back to Dvd2Avi 1.76, and it still crashes.

-h> I wanted to ask for a precision : you say theassembly hown is related to color space conversion. But as I process the whole chain in YUV, I assumed no such conversion had to be done. So what ?

And, one more thing : could anyone confirm that the involved assembly is mmx related ? If it is, could the mmx optimization of VDub, or my CPU (which is a Celeron 800) be involved ?

Thanks for helping me.

[-h]

-h> I wanted to ask for a precision : you say theassembly hown is related to color space conversion. But as I process the whole chain in YUV, I assumed no such conversion had to be done. So what ?

It's "very similar" to XviD's colorspace assembly code, but definitely not the same. I just can't think of any other code that'd look like that, thus I assumed it was colorspace stuff.

There are still going to be colorspace conversions in the filter chain - when decoding MPEG-2, the picture is converted from YV12 planar to YUYV (4:2:0) interleaved, then AVISynth probably converts it to 4:2:2 interleaved, then XviD finally converts it back to YV12 planar. It would be a fair bit faster to leave it in YV12 planar the whole time, I think trbarry was having a tinker with this.

And, one more thing : could anyone confirm that the involved assembly is mmx related ? If it is, could the mmx optimization of VDub, or my CPU (which is a Celeron 800) be involved ?

It is indeed hand-written mmx code. Your celeron should be able to handle it fine, I'm not sure what exactly could be triggering this issue.

I would try replacing avisynth.dll, mpeg2dec.dll and even xvid.dll for the heck of it.

-h

[R3g]

Alright, many thanks. already replaced xvid.dll thre times, so it is definitely innocent. I'm currently doing a test after replacing mpeg2dec.dll, so just wait & see.

For the mmx stuff, I was just thinking of my Celeron trying to tell me it is going to die soon....

[R3g]

The investigation goes on : if I disable the CPU optimizations in VDub and XviD, tha crash still happens, but the disassembly in the error messagebox is not the same. As I changed nothing in the decoding side, I doubt that Avisynth is involved in that. I join here the crash report without optimizations, if -h or someone else still have some energy for me.

[R3g]

Ooops, forgot to attach !

[-h]

Well I doubt that stuff is hand-written assembly - it's a bit too ugly. Definitely not from XviD, I've never seen it before.

It still seems to be decoding-related though, it's a block memory copy from the looks of it.

Not sure what else I can tell you

-h

[Koepi]

I'd use dvd2avi 1.74 + dividee's mpeg2dec.dll. those don't make problems.
I'll close this topic now as it isn't XviD related. Sorry -h for not intervening earlier and saving your precious time.

R3g, strike 1 (-> forum rules violation).