Commit graph

3 commits

Author SHA1 Message Date
Seungha Yang
f058eda798 win32ipc: Fix pipe handle leak
Named pipe handle must be closed if it's no longer needed

Fixes: https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2923
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5228>
2023-08-23 18:33:04 +09:00
Seungha Yang
c6a6c56cdf win32ipc: Add support for zero-copy rendering
* Extend protocol so that client can notify of releasing shared memory
* Server will hold shared memory object until it's released by client
* Add allocator/buffer pool to reuse shared memory objects and buffers

Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3765>
2023-01-27 18:55:13 +00:00
Seungha Yang
4f846540cb win32ipc: Add WIN32 shared memory videosrc/sink elements
Windows supports various IPC methods but that's completely
different form that of *nix from implementation point of view.
So, instead of adding shared memory functionality to existing
shm plugin, new WIN32 shared memory source/sink elements
are implemented in this commit.

Each videosink (server) and videosrc (client) pair will communicate
using WIN32 named pipe and thus user should configure unique/proper
pipe name to them (e.g., \\.\pipe\MyPipeName).
Once connection is established, videosink will create named shared memory
object per frame and client will be able to consume the object
(i.e., memory mapped file handle) without additional copy operation.

Note that implementations under "protocol" directory are almost
pure C/C++ with WIN32 APIs except for a few defines and debug functions.
So, applications can take only the protocol part so that the application
can send/receive shared-memory object from/to the other end
even if it's not an actual GStreamer element.

Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3441>
2022-11-24 12:41:18 +00:00