With remote displays supporting the MIT-SHM extension,
the extension is detected and used, but attaching fails
asynchronously.

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.

Fix a segfault if the XFixes extension is not available on
the X11 server.
Can be reproduced using the VNC server.

Signed-off-by: NLukasz Marek <lukasz.m.luki@gmail.com>

Fixes ticket #3068.

Signed-off-by: NPaul B Mahol <onemda@gmail.com>

Fixes resource leak and Ticket2450
Reviewed-by: NCarl Eugen Hoyos <cehoyos@ag.or.at>
Signed-off-by: NMichael Niedermayer <michaelni@gmx.at>

Signed-off-by: NMichael Niedermayer <michaelni@gmx.at>

Fixes Ticket1738

Based-on: A fix found in a perl module (http://ffmpeg.org/pipermail/ffmpeg-user/2012-August/008804.html)
Reviewed-by: NClemens Fruhwirth <clemens@endorphin.org>
Signed-off-by: NMichael Niedermayer <michaelni@gmx.at>

Signed-off-by: NMartin Storsjö <martin@martin.st>

Signed-off-by: NMartin Storsjö <martin@martin.st>

Favor draw_mouse option. Should simplify parsing, and make it more
robust.

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.

Found-by: ubitux
Signed-off-by: NMichael Niedermayer <michaelni@gmx.at>

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: NRonald S. Bultje <rsbultje@gmail.com>

Remove adding a constant value to each pixel to make it opaque.

It's supposed to be called only from (de)muxers.

Fixes ticket #163.
Approved-by: Clemens Fruhwirth
Approved-by: Edouard Gomez

Trivial replacements with sed are done in this commit:
sed 's/av_new_stream(\([^)]*\), 0)/avformat_new_stream(\1, NULL)/'

AVFormatParameters are converted into corresponding private options in
av_open_input_file/stream() compat wrappers, so accessing them from
demuxers is redundant.

Draw the current grabbing region for indication.
Signed-off-by: NYu-Jie Lin <livibetter@gmail.com>
Signed-off-by: NAnton Khirnov <anton@khirnov.net>

-follow_mouse centered|PIXELS
  move grabbing region to where mouse pointer at the center; or
  only move when pointer reaches within PIXELS to the edge.
Signed-off-by: NYu-Jie Lin <livibetter@gmail.com>
Signed-off-by: NAnton Khirnov <anton@khirnov.net>

Signed-off-by: NAnton Khirnov <anton@khirnov.net>

It's simpler and less error-prone.

Fixes some memleaks along the way.