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