[MPlayer-dev-eng] [PATCH] Direct3D VO better handling of uncooperative video adapter

Georgi Petrov gogothebee at gmail.com
Mon Jan 26 23:39:16 CET 2009


It doesn't work with the current code, because it's not right.

With the current code when the adapter is uncooperative, attempts are
being made to execute the actual D3D instructions (like StretchRect,
Begin/End scence) and so on, which leads to a crash (even if those
functions all return errors and then all other frame-copy functions
return error, it's not the right thing to do anyway).

After the patch all those D3D instructions are ignored until the
adapter is cooperative again. Meanwhile the "playback" continues and
MPlayer doesn't know that the adapter is uncooperative. This is the
right behavior.

For example when UAC has popped up waiting for Continue/Cancel, the
video adapter is uncooperative. We don't know when the user is going
to push the button, so we must continue to render (actually not
render, but tell MPlayer we're rendering be returning normal return
values in all functions) and hope that sometimes the adapter will be
reset again.

This is the main difference. If you want me to investigate exactly WHY
MPlayer hangs with the code before the patch, I will. But when I do,
it doesn't mean that the patch is not neede. It doesn't fix a bug, it
changes a behavior and as a side effect the bug is gone.

On Tue, Jan 27, 2009 at 12:28 AM, Reimar Döffinger
<Reimar.Doeffinger at stud.uni-karlsruhe.de> wrote:
> On Mon, Jan 26, 2009 at 11:48:14PM +0200, Georgi Petrov wrote:
>> Oh, I forgot - before this patch a Continue/Cancel dialog of UAC
>> crashes MPlayer as well. The patch solves this problem as well. Now
>> *THIS* is pretty good reason to accept it. Not that the other ones
>> aren't.
>
> Well, all I can see from the discussion so far my impression is that you
> somehow have found a solution, but you have no idea why it does not work
> with the current code nor why exactly this patch fixes it, and I suspect
> it may be due to incorrect error-handling in the code which will still
> not work - which in turn might mean there is a race condition and in
> maybe one in a million cases it will still crash.
> _______________________________________________
> MPlayer-dev-eng mailing list
> MPlayer-dev-eng at mplayerhq.hu
> https://lists.mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
>



More information about the MPlayer-dev-eng mailing list