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>
Deprecated in 40cf1bbacc.
(The currently disabled filter vf_mcdeint and vf_uspp were users of
this field; they have not been changed, so that whoever wants to fix
them can see the state of these filters when they were disabled.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: James Almer <jamrial@gmail.com>
These are auxiliary side-data functions, so they should have been
switched to size_t in d79e0fe65c,
but this has been forgotten.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The next pointer is kept at the end for backwards compatability until the
major bump, when it should ideally be moved at the front.
Signed-off-by: James Almer <jamrial@gmail.com>
The option allows to select a specific window instead of the whole
screen.
Reviewed-by: Andriy Gelman <andriy.gelman@gmail.com>
Signed-off-by: Andriy Gelman <andriy.gelman@gmail.com>
Keep on reading fragments until we got fragment_size amount of data, otherwise
we might get frames with 1-2 samples only if pa_stream_peek is called slightly
less frequently than sample rate.
Note that fragments might contain a lot less data than fragment_size, so
reading multiple fragments to get fragment_size amount of data is intentional.
Signed-off-by: Marton Balint <cus@passwd.hu>
Otherwise we might return 1-2 samples per packet if av_read_frame() call rate is
only sligthly less than the stream sample rate.
Signed-off-by: Marton Balint <cus@passwd.hu>
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>
It has been added in 6db42a2b6b,
yet since then none of the necessary create/free_device_capabilities
functions has been implemented, making this API completely useless.
Because of this one can already simplify
avdevice_capabilities_free/create and can already remove the function
pointers at the next major bump; given that the documentation explicitly
states that av_device_capabilities is not to be used by a user, it's
options can already be removed (save for the sentinel).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
xserver defines the endianness of the grabbed images. Use this information
to set the correct pixel format.
This also fixes format selection in configuration depth=32/bpp=32 with
xserver on a little endian machine. Before the patch, the big endian
layout 0RGB was always selected which is incorrect because BGR0 should
be used. RGB24 was also incorrectly assumed (but this format was removed
in xserver 1.20).
The big-endian settings can be tested using docker+qemu from a little-endian
machine:
$ docker run --rm --privileged multiarch/qemu-user-static --reset -p yes
$ docker run --rm -it -v /tmp:/tmp powerpc64/debian /bin/bash
In docker container
$ apt-get update
$ apt-get install xvfb
$ apt-get install x11-apps
To test AV_PIX_FMT_0RGB32
$ Xvfb :2 -screen 0 720x480x24 &
$ export DISPLAY=:2
$ xclock -geometry 720x480 -bg green #test different colors
On your host machine grab the frames using the following
command. View output to check that colors are rendered correctly
$ ./ffmpeg -y -f x11grab -i :2.0 -codec:v mpeg2video out.mp4
Other pixel formats can be tested by modifying how Xvfb is started in the docker
container:
AV_PIX_FMT_RGB565
$ Xvfb :2 -screen 0 720x480x16
AV_PIX_FMT_RGB555
$ Xvfb :2 -screen 0 720x480x15
AV_PIX_FMT_BGR24 / AV_PIX_FMT_RGB24
This is difficult to test because bpp=24 support was removed in xserver 1.20
https://lists.x.org/archives/xorg-devel/2018-February/056175.html?hmsr=joyk.com&utm_source=joyk.com&utm_medium=referral
However, I was able to run previous version of Xvfb (with some
modifications to force 24bpp) to check that images are rendered correctly.
Reviewed-by: Carl Eugen Hoyos <ceffmpeg@gmail.com>
Signed-off-by: Andriy Gelman <andriy.gelman@gmail.com>
As we get a new set of objects each frame anyway, we
do not gain anything by keeping the modifier constant.
This helps with capturing when switching your setup a
bit, e.g. from ingame to desktop or from X11 to wayland.
Signed-off-by: Mark Thompson <sw@jkqxz.net>
The kernel defaults to initializing the field to 0 when modifiers
are not used and this happens to be linear. If we end up actually
passing the modifier to a driver, tiling issues happen.
So if the kernel doesn't return a modifier set it explicitly to
INVALID. That way later processing knows there is no explicit
modifier.
Signed-off-by: Mark Thompson <sw@jkqxz.net>
The function is not used anywhere else and is causing mingw-w64 clang
builds to fail with
ffmpeg-git/libavdevice/decklink_dec.cpp:792:5: error: no previous prototype for function 'get_bmd_timecode' [-Werror,-Wmissing-prototypes]
int get_bmd_timecode(AVFormatContext *avctx, AVTimecode *tc, AVRational frame_rate, BMDTimecodeFormat tc_format, IDeckLinkVideoInputFrame *videoFrame)
Signed-off-by: Christopher Degawa <ccom@randomderp.com>
Signed-off-by: Marton Balint <cus@passwd.hu>
./ffmpeg -list_devices true -f decklink -i dummy
[Blackmagic DeckLink indev @ 0x2f96d00] The "list_devices" option is deprecated: list available devices
[decklink @ 0x2f96400] The -list_devices option is deprecated and will be removed. Please use ffmpeg -sources decklink instead.
->
[Blackmagic DeckLink indev @ 0x306ed00] The "list_devices" option is deprecated: use ffmpeg -sources decklink instead
Reviewed-by: Marton Balint <cus@passwd.hu>
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
For the document(indevs.texi and outdevs.texi) used it as boolean.
Reviewed-by: Marton Balint <cus@passwd.hu>
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
The patch will change the numerical values for the string constants so bump
micro version.
Reviewed-by: Marton Balint <cus@passwd.hu>
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
This patch adds a select_region option to the xcbgrab input device.
If set to 1, the user will be prompted to select the grabbing area
graphically by clicking and dragging. A rectangle will be drawn to
mark the grabbing area. A single click with no dragging will select
the whole screen. The option overwrites the video_size, grab_x, and
grab_y options if set by the user.
For testing, just set the select_region option as follows:
ffmpeg -f x11grab -select_region 1 -i :0.0 output.mp4
The drawing happens directly on the root window using standard rubber
banding techniques, so it is very efficient and doesn't depend on any
X extensions or compositors.
Reviewed-by: Andriy Gelman <andriy.gelman@gmail.com>
Signed-off-by: Omar Emara <mail@OmarEmara.dev>
