On 09.07.2022 07:01, Gyan Doshi wrote:
On 2022-07-09 04:24 am, Timo Rothenpieler wrote:
---
Changelog | 1 +
configure | 7 +
doc/filters.texi | 68 ++
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/version.h | 2 +-
libavfilter/vsrc_ddagrab.c | 980 +++++++++++++++++++++++++++++
libavfilter/vsrc_ddagrab_shaders.h | 120 ++++
8 files changed, 1179 insertions(+), 1 deletion(-)
create mode 100644 libavfilter/vsrc_ddagrab.c
create mode 100644 libavfilter/vsrc_ddagrab_shaders.h
diff --git a/Changelog b/Changelog
index 1a7c84b7f8..9467e92dd1 100644
--- a/Changelog
+++ b/Changelog
@@ -24,6 +24,7 @@ version 5.1:
- VDPAU AV1 hwaccel
- PHM image format support
- remap_opencl filter
+- ddagrab (Desktop Duplication) video source filter
The source filters are all generative filters. This should be called a
capture filter.
Why is it a filter instead of in lavd?
lavd has no infrastructure for hardware acceleration whatsoever, and
returns packets, not frames.
There'd be no way to access the likes of -init_hw_device from lavd.
And it also seems pointless an extra indirection to put something that
produces frames into lavd.
With the included patch for lavfi.c you can use it via lavd if you
really want to.
Though you give up any control over the created hwdevice context.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
