[Bug 706566] New: 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

           Summary: d3dvideosink: bufferpool implementation does not work
                    well with device-lost/resets
    Classification: Platform
           Product: GStreamer
           Version: 1.x
        OS/Version: Windows
            Status: NEW
          Severity: blocker
          Priority: Normal
         Component: gst-plugins-bad
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: slomo at circular-chaos.org
         QAContact: gstreamer-bugs at lists.freedesktop.org
                CC: t.i.m at zen.co.uk, slomo at circular-chaos.org,
                    ylatuya at gmail.com
     GNOME version: ---


+++ This bug was initially created as a clone of Bug #697868 +++

Resizing requires resetting the device and all the resources allocated to this
d3d pool if we use the default pool. I believe that using a managed pool
instead allows resources to persists in a device reset:

http://msdn.microsoft.com/en-us/library/windows/desktop/bb147168(v=vs.85).aspx

"Use the D3DPOOL_MANAGED flag at creation time to specify a managed resource.
Managed resources persist through transitions between the lost and operational
states of the device. These resources exist both in video and system memory. A
managed resource will be copied into video memory when it is needed during
rendering. The device can be restored with a call to IDirect3DDevice9::Reset,
and such resources continue to function normally without being reloaded with
data. However, if the device must be destroyed and re-created, all resources
must be re-created."

We should also be using the managed for devices lost, and not recreate the
device as it's done now but only reset it to reuse the existent resources.





We should probably disable allowing usage of the pool outside d3dvideosink for
1.2, and then find a real solution that allows us to still continue to work
zerocopy.

-- 
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.