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

[Georgi Petrov]

> There is no code making any such decision. What kind of circumstances
> does this occur in? How long are the delays you're talking about?

Yes, I don't know exactly what's happening, but this was my
observation. If I put "empty" code in flip_page(), MPlayer doesn't
stop on suspend/resume/hibernate/3D Screen saver. If I leave the D3D
reset inside it, it takes some time, fiip_page() returns with some
delay and the playback stops. flip_page() doesn't have return type, so
it shouldn't care what's happening inside. I understand your though
about the audio driver and this might be the case, but the patch is
simple enough and IMHO is doing the right thing - moving D3D reset out
of flip_page() and ensuring smooth reset path.

> One possible cause for playback permanently breaking after a delay could
> be a bug in your _audio_ driver which makes it break if a buffer
> underrun occurs during the delay. You can test that by comparing the
> behavior with -nosound.

I'm sorry.
-nosound doesn't make a difference. MPlayer still stops. The simplest
way to test it (at least under Vista, I'm not sure for XP) is to lock
the workstation. During a lock, the screen does black for a second,
during which I suppose the D3D rendering context is destroyed and the
adapter becomes uncooperative. The old code causes the playback to
stop, after the simple patch it's ok. -nosound doesn't make a
difference.