Incidentally `-y` also collides with avconv global options.
Update x11grab to match and document the option.
CC: libav-stable@libav.org
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
The paint_mouse_pointer() code uses XFixes to retrieve the cursor
coordinates, but XFixes gives no information about which screen the
pointer is on; this results in always drawing the cursor on the
captured screen even if the mouse pointer was on another screen.
For example, when capturing from screen 1 (i.e. -f x11grab -i ":0.1")
the cursor was being drawn in the captured image even when the mouse
pointer was actually on screen 0, which is wrong and visually confusing.
CC: libav-stable@libav.org
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
The code uses XFixes to retrieve the cursor coordinates, but XFixes
gives no information of what screen the pointer is on; this results in
always drawing the cursor on the captured screen even if the mouse
pointer was on another screen.
For example, when capturing from screen 1 (i.e. -f x11grab -i ":0.1")
the cursor was being drawn in the captured image even when the mouse
pointer was actually on screen 0, which is wrong and visually confusing.
Use XQueryPointer to check that the pointer is actually on the screen
which is being captured.
Signed-off-by: Antonio Ospite <ao2@ao2.it>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This specifies better the meaning of the variable, and is also in
preparation of a subsequent change which will introduce a temporary
Window variable for which "w" is an good name.
Signed-off-by: Antonio Ospite <ao2@ao2.it>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The X11 servers by VNC, at 32-bits depths, has the following masks:
R:0x000007ff G:0x003ff800 B:0xffc00000
This is not compatible with AV_PIX_FMT_0RGB32, and the result
is success with completely wrong colors.
In particular, do not upcase first word, do not use final dot, use a verb
to specify what the option does, sort entries by name, apply random
vertical align.
When using "-f x11grab -i :0.0" valgrind reports a definitely lost
memory block with this message:
==31544== 5 bytes in 1 blocks are definitely lost in loss record 1 of 2
==31544== at 0x4026E68: memalign (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==31544== by 0x4026F17: posix_memalign (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==31544== by 0x60D399A: av_malloc (in /usr/lib/x86_64-linux-gnu/libavutil.so.51.22.1)
==31544== by 0x60D3A70: av_strdup (in /usr/lib/x86_64-linux-gnu/libavutil.so.51.22.1)
==31544== by 0x4A2BE58: ??? (in /usr/lib/x86_64-linux-gnu/libavdevice.so.53.2.0)
==31544== by 0x506D29E: avformat_open_input (in /usr/lib/x86_64-linux-gnu/libavformat.so.53.21.0)
==31544== by 0x400A80: main (in /home/ao2/WIP/am7xxx-play/tests/a.out)
The 5 bytes lost are the ones from param = av_strdup(":0.0"), so let's
free param in the exit path.
Also check the av_strdup() return value.
Note: calling av_free(param) even when av_strdup() fails and param is
NULL is OK and keeps the code simpler without adding another label to
skip av_free().
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
AVFormatParameters are converted into corresponding private options in
av_open_input_file/stream() compat wrappers, so accessing them from
demuxers is redundant.
Clément Bœsch
Diego Biurrun
Christian Hujer
Luca Barbato
Antonio Ospite
Michael Niedermayer
Nicolas George
Lukasz Marek
Carl Eugen Hoyos
Paul B Mahol
Isaac Dooley
Anton Khirnov
Martin Storsjö
Stefano Sabatini
Clément Bœsch
Nicolas George
Antonio Ospite
Yu-Jie Lin