* commit 'bef067f88c74190cdf7e76d12f02e12e069974aa':
vdpau: check video surface and decoder capabilities
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'ce083282f0a8b7d63c4047c30b7bac498f9806dd':
vdpau: common support for managing the VdpDecoder in avcodec
Conflicts:
libavcodec/vdpau.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
This function provides an explicit VDPAU device and VDPAU driver to
libavcodec, so that the application is relieved from codec specifics
and VdpDevice life cycle management.
A stub flags parameter is added for future extension. For instance, it
could be used to ignore codec level capabilities (if someone feels
dangerous).
Signed-off-by: Anton Khirnov <anton@khirnov.net>
This is necessary to recreate the decoder with the correct parameters,
as not all codecs invoke get_format() in this case.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Fixes regression from Ticket3962
This basically favors the first global header while since 34751f8313
it was the last. If this heuristic turns out worse, do not hesitate to revert this and
reopen 3962 as a feature request for multiple STSD
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
it should not be possible to be larger as its stored as 8bit value
but we would be overwriting a stack buffer if it is ...
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Using the not so new init and uninit callbacks, avcodec can now take
care of creating and destroying the VDPAU decoder instance.
The application is still responsible for creating the VDPAU device
and allocating video surfaces - this is necessary to keep video
surfaces on the GPU all the way to the output. But the application
will no longer needs to care about any codec-specific aspects.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Fixes ticket #3948
Based-on-patch-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Alexander Strasser <eclipse7@gmx.net>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit '5b9c817dc7577b6d44acc94d73b9c77c52cda489':
x11grab: Check XFixesGetCursorImage return value
Conflicts:
libavdevice/x11grab.c
See: a65c0a3fe8
The warning with adjusted text is kept from a65c0a3fe8
but drawing the cursor is not disabled in case XFixesGetCursorImage() fails
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '68211c70afcfd4d675029cc85fba7dee8de53bdf':
vc1: Do not assume seek happens after decoding
See: 6801eb0a09
Merged-by: Michael Niedermayer <michaelni@gmx.at>
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>
Fixes out of array access
Fixes: asan_heap-oob_4da4f3_7_asan_heap-oob_4da4f3_173_Xmen_avc_500.vp6
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
