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>
Additionally, make sure a buffer gets enqueued again (even in error paths) after
it has been succesfully dequeued.
Tested-by: Dmitry Volyntsev <xeioexception@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'bb3ead7e54fec205c595cfb8b1d8900d50d3d1cc':
x11grab: Fallback to normal XImage if SHM is not supported
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '58396e806c65fe0eb00e6ccf1980f810cdceed05':
x11grab: Use a typedef for the context, as most other code does
Conflicts:
libavdevice/x11grab.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '7bb505a33ca131906b2ceb2f298e104c862740ea':
x11grab: Drop a spurious space in the extension reporting message
Conflicts:
libavdevice/x11grab.c
See: 9af2097120
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Timothy Gu <timothygu99@gmail.com>
This file with the incorrect name was added after the name was fixed in all other files.
This is thus fixing a mistake
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'ab56fabe6294524e99815451ad01e4ff50c6d734':
vfwcap: Add fallback define for HWND_MESSAGE
The merged commit reverts the HWND_MESSAGE removial, and adds a #ifndef around
commit 8bc52dbd9d
vfwcap: Drop fallback VfW defines
The defines were added long ago when MinGW still lacked them.
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '424b929b5cb9ca4094099f25179829260d4b0fa3':
pulse: Add a wallclock option to be compatible with other other captures
Conflicts:
libavdevice/pulse_audio_dec.c
wallclock mode was supported and default in FFmpeg already before this commit.
its thus left the default
Merged-by: Michael Niedermayer <michaelni@gmx.at>
PulseAudio expilitly requires name of the source.
This patch makes it use default source when not provided.
It simplifies programistic use.
Signed-off-by: Lukasz Marek <lukasz.m.luki2@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
As of September 14 2012, v4l_enumstd() will return ENODATA
when a device's std field is set to 0. That is, the device
does not have a standard format. In order to properly
handle this case, v4l2_set_parameters should catch the
ENODATA code and break instead of failing.
Below is the v4l2-core commit describing this change.
>>commit a5338190efc7cfa8c99a6856342a77d21c9a05cf
>>Author: Hans Verkuil <hans.verkuil@cisco.com>
>>Date: Fri Sep 14 06:45:43 2012 -0300
>>
>> [media] v4l2-core: tvnorms may be 0 for a given input, handle that case
>>
>> Currently the core code looks at tvnorms to see whether ENUMSTD
>> or G_PARM should be enabled. This is not a good check for drivers
>> that support the STD API on one input and the DV Timings API on another.
>> In that case tvnorms may be 0.
>> Instead check whether s_std is present (for ENUMSTD) or whether g_std or
>> current_norm is present for g_parm.
>> Also, in the enumstd core function return ENODATA if tvnorms is 0,
>> because in that case the current input does not support the STD API
>> and ENUMSTD should return ENODATA for that.
>>
>> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
>> Reviewed-by: Sakari Ailus <sakari.ailus@iki.fi>
>> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
