[Bug 706566] d3dvideosink: bufferpool implementation does not work well with device-lost/resets

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=706566
  GStreamer | gst-plugins-bad | 1.x

--- Comment #4 from Andoni Morales <ylatuya at gmail.com> 2013-09-02 10:12:38 UTC ---
Created an attachment (id=253819)
 View: https://bugzilla.gnome.org/attachment.cgi?id=253819
 Review: https://bugzilla.gnome.org/review?bug=706566&attachment=253819

0001-d3dvideosink-disable-buffer-pools.patch

This patch disables the buffers pool for now.

I have been trying to use textures instead of surfaces, but it seems like
textures created in the MANAGED pool can't be locked, so it's a dead end too.

There is still one last thing to test, which is using the IDirect3DDevice9Ex
(with the "Ex" suffix), which does not require recreating textures after
resetting the device:

http://msdn.microsoft.com/en-us/library/windows/desktop/bb219800%28v=vs.85%29.aspx
"In previous versions of DirectX, when an application experienced a mode
change, the only way to recover was to reset the device and re-create all video
memory resources and swap chains. Now with DirectX for Windows Vista, calling
Reset after a mode change does not cause texture memory surfaces, textures and
state information to be lost and these resources do not need to be recreated."

This API is not available in windows XP so we should use a wrapper for the 2
interfaces and fallback properly in XP disabling the buffer pool.


The

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.