[MPlayer-users] <vo_direct3d>Allocating offscreen surface failed

David Bolen db3l.net at gmail.com
Mon Mar 23 21:31:15 CET 2009


Greg Bryant <bryantgtx at gmail.com> writes:

> Thanks David.  IT seems to be just that machine.  I copied to a different
> system, and it worked.  from msdn, there's only one error code,
> D3DERR_INVALIDCALL, and fortunately (or not), that's what's coming back.

Yeah, sorry - should have noticed that - not so helpful.

> The screen is 1280x720 via DVI.  I loaded up dxdiag, and ran the tests, and
> they ran fine.  The d3d9.dll version is 5.03.2600.5512, the same as on the
> other two systems.  The size being passed to CreateOffscreenPlainSurface is
> 720x400 (the size of the video), so it shouldn't be an overall window size.

I believe current SVN versions should create the initial off screen
surface at display size not video size (as of 1/27, r28379), so
depending on how much earlier your current code base is, you might
give a shot at a more recent version just for the heck of it.  Though
I suspect there aren't material differences regarding the basic
surface creation.

Can you see any other differences in the CreateOffscreenPlainSurface
parameters between the two systems?

> I see two main differences.  One is that it's DVI rather than standard VGA.
> The other is that it's a VIA chipset rather than a straight Intel. Not sure
> why either of those would make a difference, since the regular D3D tests
> passed.

I have trouble seeing it being a DVI/VGA difference.  Much more likely
is that it's something to do with the D3D support related to the the
VIA chipset driver compared to the driver for your other system(s)
video chipsets.

Have you tried running mplayer with verbose logging (-v) to gather a
few more of the internal vo_direct3d messages?  Maybe it has something
to do with the format mapping that goes on between media format and
display format - e.g., maybe the VIA chipset D3D driver doesn't
support the same formats, which prevents prev->movie_src_fmt from
being established properly, which then becomes an invalid parameter to
the offscreen surface creation call.

Otherwise, not sure what else to suspect.  Perhaps you'll be better
off with directx and/or gl on that system?

-- David








More information about the MPlayer-users mailing list