This commit does for AVInputFormat what commit
59c9dc82f4 did for AVOutputFormat:
It adds a new type FFInputFormat, moves all the internals
of AVInputFormat to it and adds a now reduced AVInputFormat
as first member.
This does not affect/improve extensibility of both public
or private fields for demuxers (it is still a mess due to lavd).
This is possible since 50f34172e0
(which removed the last usage of an internal field of AVInputFormat
in fftools).
(Hint: tools/probetest.c accesses the internals of FFInputFormat
as well, but given that it is a testing tool this is not considered
a problem.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Unnecessary since acf63d5350adeae551d412db699f8ca03f7e76b9;
also avoids relocations.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Converting from an integer to HWND (which is a pointer) requires
an explicit cast, otherwise Clang errors out like this:
src/libavdevice/gdigrab.c:280:14: error: incompatible integer to pointer conversion assigning to 'HWND' (aka 'struct HWND__ *') from 'long' [-Wint-conversion]
280 | hwnd = strtol(name, &p, 0);
| ^ ~~~~~~~~~~~~~~~~~~~
(With GCC and MSVC, this was a mere warning, but with recent Clang,
this is an error.)
After adding a cast, all compilers also warn something like this:
src/libavdevice/gdigrab.c:280:16: warning: cast to 'HWND' (aka 'struct HWND__ *') from smaller integer type 'long' [-Wint-to-pointer-cast]
280 | hwnd = (HWND) strtol(name, &p, 0);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~
On Windows, long types are 32 bit, so to get a usable pointer, we
need to use long long. And interpret it as unsigned long long
while at it - i.e. using strtoull.
Finally, right above it, the code triggered the following warning:
src/libavdevice/gdigrab.c:278:15: warning: mixing declarations and code is incompatible with standards before C99 [-Wdeclaration-after-statement]
278 | char *p;
| ^
Signed-off-by: Martin Storsjö <martin@martin.st>
x11grab can capture windows by their ID, but gdigrab can only capture
windows by their names, internally calling FindWindowW to lookup its
handle.
This patch simply allows the user to specify a window handle directly.
Signed-off-by: Lena <lena@nihil.gay>
This is possible now that the next-API is gone.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: James Almer <jamrial@gmail.com>
av_gettime_relative() is using the monotonic clock therefore more suitable for
elapsed time calculations. Packet timestamps are still kept absolute, although
that should be configurable in the future.
Related to ticket #9089.
Signed-off-by: Marton Balint <cus@passwd.hu>
missed the category AV_CLASS_CATEGORY_DEVICE_VIDEO_INPUT lead to
ffmpeg -devices doesn't show gdigrab as a input device
FIx#7848
Found-by: dangibson
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
In Windows if using scaling other than 100% then the grabbed window was not captured fully (cropped)
Signed-off-by: Dilshod Mukhtarov <dilshodm@gmail.com>
Based on original code by Christophe Gisquet in 2010, updated to work
with current ffmpeg APIs.
Supports grabbing a single window or an area of the screen, including
support for multiple monitors (Windows does funky stuff with negative
coordinates here).
I've moved most of the configuration to AVOptions; the input file name
is now only the string "desktop", or "title=<windowname>" to select a
single window. The AVOptions are the same as x11grab where possible.
Code has been added to support a "show_region" mode, like x11grab, which
will draw a rectangle on the screen around the area being captured.
Instead of duplicating code for paletted image handling, I make use of
the GDI API's ability to output DIB (BMP) images, which can be run
through ffmpeg's existing BMP decoder.
Signed-off-by: Calvin Walton <calvin.walton@kepstin.ca>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
