Sebastian Dröge
d8b1efe13a
d3dvideosink: Don't try to recreate swapchain while the window is minimized
...
It will fail and cause the sink to crash. Instead wait until the window is
visible again before checking if the swapchain really has to be recreated.
https://bugzilla.gnome.org/show_bug.cgi?id=741608
2015-11-30 19:53:28 +02:00
Fabio Cetrini
79f57e62dc
d3dvideosink: Avoid frame rendering while the window is completely hidden
...
https://bugzilla.gnome.org/show_bug.cgi?id=749856
2015-06-10 15:03:31 +02:00
Roman Nowicki
29098129be
d3dvideosink: release existing D3D swap chain on init
...
https://bugzilla.gnome.org/show_bug.cgi?id=745159
2015-02-25 16:19:57 +02:00
Sebastian Dröge
e36c27cd46
d3dvideosink: Don't initialize the render window swap chain while the device is lost and we're waiting for reset
...
https://bugzilla.gnome.org/show_bug.cgi?id=744615
2015-02-24 11:19:48 +02:00
Sebastian Dröge
d1d31dae6d
d3dvideosink: Deactivate the fallback pool and unref the fallback buffer when resetting
...
Otherwise we will still have a reference to the surface left, which would
prevent activating the sink again later. E.g. after we lost the device.
Hopefully fixes https://bugzilla.gnome.org/show_bug.cgi?id=744615
2015-02-18 12:45:22 +02:00
Sebastian Dröge
4ec87d9690
d3dvideosink: Open Direct3D devices in a threadsafe way
...
Otherwise we'll get crashes when using the device from multiple
threads, e.g. when using multiple sinks at once.
https://bugzilla.gnome.org/show_bug.cgi?id=707523
2014-07-15 13:30:16 +02:00
Sebastian Dröge
c134930dbe
d3dvideosink: Always lock the D3D surfaces in write mode
...
Locking them in readonly mode can give different stride to mapping
in write mode, which then causes rendering to be broken.
Happened on all (many?) NVIDIA GPUs.
Thanks to voskater15@gmail.com for hinting at the problem.
https://bugzilla.gnome.org/show_bug.cgi?id=712809
2014-07-03 19:10:26 +02:00
Sebastian Dröge
73c40a3132
d3dhelpers: Swap UV planes properly for YV12 as compared to I420
...
If we only do it in one place colors will look funny.
2014-07-03 19:06:26 +02:00
Sebastian Dröge
25974ac0a9
d3dvideosink: Don't leak all surfaces
...
This was broken when disabling the buffer pool exporting.
Also disable buffer pool a bit more efficient...
2014-07-02 10:33:15 +02:00
Sebastian Dröge
28d250ec3f
d3dvideosink: PostMessage() takes integers as last parameters, not pointers
2014-07-02 10:33:15 +02:00
Sebastian Dröge
677608bfb7
d3dvideosink: Remove unused variable
2014-07-02 10:33:15 +02:00
Eric Trousset
f54efc206f
d3dvideosink: Release D3D surfaces when shutting down the sink
...
https://bugzilla.gnome.org/show_bug.cgi?id=726026
2014-06-23 20:44:23 +02:00
Tim-Philipp Müller
3f1eb8ee71
d3dvideosink: post proper error message when window disappears
2014-04-08 17:52:12 +01:00
Sebastian Dröge
c84278ae04
d3dvideosink: Only pass a dest rectangle if set, otherwise pass NULL
...
Call with an uninitialized rectangle will cause errors.
https://bugzilla.gnome.org/show_bug.cgi?id=714998
2014-04-02 23:10:01 +02:00
Alexey Chernov
d96999328a
d3dvideosink: First destroy the window, then unregister the class
...
It's impossible to create another pipeline with d3dvideosink after disposing
the previous one due to some problem in d3dvideosink. The message is: "Unable
to register Direct3D hidden window class".
I've evaluated the problem and it's that UnregisterClass() in working thread is
called before DestroyWindow() and UnregisterClass() does nothing.
https://bugzilla.gnome.org/show_bug.cgi?id=722622
2014-01-21 09:45:07 +01:00
Andoni Morales Alastruey
ef7a8c2ca8
d3dvideosink: disable buffer pools
...
On a device lost, all the surfaces allocated in the
device need to be released before resetting the device,
which can't be done for the allocated buffers.
https://bugzilla.gnome.org/show_bug.cgi?id=706566
2013-09-02 18:21:11 +02:00
Andoni Morales Alastruey
7f18295321
d3dvideosink: use bilinear filter as much as possible
...
Use the bilinear scalling filter when the magnifier or the minifier
filters are avaible. Some graphics cards do not provide minifier filters
but we want to use it for upscalling if it's available
https://bugzilla.gnome.org/show_bug.cgi?id=697176
2013-04-04 11:39:45 +02:00
Sebastian Dröge
42965f5aa0
d3dvideosink: Make sure that all buffers in our pool contain our own memory
2013-03-27 09:09:59 +01:00
Sebastian Dröge
ff30417bd9
d3dvideosink: Add support for crop meta
2013-03-26 14:27:43 +01:00
Sebastian Dröge
81304a7956
d3dvideosink: Implement a buffer pool that shares D3D surfaces with upstream
2013-03-26 13:39:46 +01:00
Sebastian Dröge
abede65bbc
d3dvideosink: Allocate a new offscreen surface for every buffer
...
This is a preparation for implementing a buffer pool.
2013-03-26 13:39:46 +01:00
Sebastian Dröge
85690b802d
d3dvideosink: Remove scary "while (object.refcount > 0) release (object);" code
...
If there is a memory leak, this isn't the way how it should be fixed.
2012-12-22 18:43:37 +01:00
Sebastian Dröge
0642f3a143
d3dvideosink: Don't use "class" as variable name and don't use C99 comments
2012-12-22 18:13:48 +01:00
Sebastian Dröge
23265c8428
d3dvideosink: Only open system resources in in NULL->READY, not on object instantiation
2012-12-22 18:04:42 +01:00
Sebastian Dröge
827655ffb4
d3dvideosink: Properly copy frames to D3D with the right strides and everything
...
And only support color formats that are actually supported by the driver,
this allows proper zero-copy handling later and simplifies the code a lot.
Also simplify some other places, like the format mapping code.
2012-12-22 17:57:41 +01:00
Sebastian Dröge
de8f436b21
d3dvideosink: Fix some more compiler warnings
2012-12-22 11:58:21 +01:00
Sebastian Dröge
872dc5feb6
d3dvideosink: Rename keep-aspect-ratio to force-aspect-ratio and default to TRUE
...
For consistency with other video sinks.
2012-12-22 11:34:43 +01:00
Sebastian Dröge
5ea516d735
d3dvideosink: Add files that had to be included in the last commit
2012-12-22 11:30:08 +01:00
