Hi there, i am working on a graphics driver. A customer of ours has an issue
with one particular type of stream when played with WinCE 5.0 or 6.0
ceplayer, the output comes out corrupted... its an MPEG1 stream which
eventually uses overlay with a yuyu2 format. As far as i have debugged so
far, our driver seems to be doing everything fine (ddraw init, caps
reporting, surface creation, lock/unlock... etc). Using other dd ovl apps and
even some streams, we can get yuy2 output to appear fine.
After turning on additional debug messages in quartz.dll, we know that the
filter graph dump == video renderer <- mpeg video codec <- mpeg-1 stream
spitter.... and we also believe that the MPEG video codec initially tries to
negotiate a Y41P format which the video renderer fails and proposes YUY2.
(our driver isnt aware of this event because we report dd caps as only
supporting 422 packed and 420 planar formats).
However when the player starts outputting the data (via successful locks and
flips), its visually corrupted... but the corruption has a very clear pattern
to it. Inspecting it closely, it looks like the video renderer (or the codec)
is not moving to the next line properly - it looks like after copying an
entire width of pixels, it doesnt increment the dest ptr by the balance of
pitch in bytes, it simply continues with the next line of pixels on this same
scanline (since our overlay surface pitch is bigger than the width) ... i can
confirm this by hacking my driver to ensure the width and pitch is the same -
which the hardware wont like depending on the dimensions - we usually let the
driver dictate the pitch. when i do this, then the output looks good.
Note that other streams when forced to run in yuy2 (by removing the yuv
planar caps in my dd driver), work fine. I think this is unique to the
possibility of a Y41P to Yuy2 conversion happenning in the mpeg1 codec.
Could someone help reply to me on whether my hunch about wether this mpeg1
codec bug is valid?