Seems to be the only solution so far.
People over @ doom9 forum reported same error with same solution a month ago.
Question is -and has been over there, too- if your graphic card reports to support YV12 overlay but
fails to do so.
It's irritating to me, why YUY2 overlay should outperform(=no display bugs) YV12 because the latter is much faster. It uses 12bit per pixel instead of 16bit used by YUY2, though at a lower bandwidth.
Actually, if a graphic card manages YUY2 overlay so why the heck it doesn't do YV12?
Also most DVD/MPEG2 data is stored in YUY2 mode defaulting in YUY2 overlay display -who wonders why- no color space convertion needed.
If you have an MPEG4 stream such as XVid or DivX, it will be decoded in YV12 (YUV 4: 2: 0) internally, because it's restricted in MPEG4 specs, and then converted to YUY2 if requested as output. Working in this sequence why does that error described above not occur in YUY2 also, for it's the 2nd step in the row???
Look here:
http://forum.doom9.org/showthread.ph...DivX+YUY2+YV12
and here:
http://forum.doom9.org/showthread.ph...er+output+yuy2.
I'm not 100% sure about current default Xvid decoder output,
BST.
I think it still defaults to YV12 in the first line. Frankly, I was unable to collect further information about current build. :roll:
As an alternative you may use DivXg400 filter to force YUY2!
Lately, as until now BST did not reveal the nature of overlay 1 and 2, I assumed that mode 1 was YV12 and mode 2 YUY2...