* commit '577899a6':
  lavc: specify the behavior of av_lockmgr_register on failure.

Conflicts:
	libavcodec/avcodec.h
	libavcodec/utils.c
	libavcodec/version.h

See: a950edb4Merged-by: Michael Niedermayer <michaelni@gmx.at>

The register function now specifies that the user callback should
leave things in the same state that it found them on failure but
that failure to destroy is ignored by the library.  The register
function is now explicit about its behavior on failure
(it unregisters the previous callback and destroys all mutex).
Signed-off-by: Manfred Georg <mgeorg@google.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>

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

* commit '8de1d679':
  avconv_vdpau: update to new VDPAU interface
Merged-by: Michael Niedermayer <michaelni@gmx.at>

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

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

* commit 'bef067f8':
  vdpau: check video surface and decoder capabilities
Merged-by: Michael Niedermayer <michaelni@gmx.at>

* commit 'e3e158e8':
  vdpau: add av_vdpau_bind_context()

Conflicts:
	doc/APIchanges
	libavcodec/vdpau.h
	libavcodec/version.h
Merged-by: Michael Niedermayer <michaelni@gmx.at>

* commit '502cde40':
  vdpau: force reinitialization when output resolution changes

Conflicts:
	libavcodec/vdpau.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>

avcodec/vdpau: warn if the user application has not setup avctx->hwaccel_context instead of potentially crashing
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

* commit '89ac99ba':
  vdpau: pass codec-specific parameters from hwaccel

Conflicts:
	libavcodec/vdpau.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>

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

* commit 'ce083282':
  vdpau: common support for managing the VdpDecoder in avcodec

Conflicts:
	libavcodec/vdpau.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>

* commit 'fcc10226':
  vdpau: factor out common end-of-frame handling

Conflicts:
	libavcodec/vdpau.c
	libavcodec/vdpau_h264.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>

* commit '319424d2':
  vdpau: add helper for VDPAU to libav error codes conversion

Conflicts:
	libavcodec/vdpau.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>

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

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

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>

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

Fixes Ticket3985
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Fixes regression from Ticket3962

This basically favors the first global header while since 34751f83
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>

Signed-off-by: James Almer <jamrial@gmail.com>

Signed-off-by: James Almer <jamrial@gmail.com>

Signed-off-by: James Almer <jamrial@gmail.com>

Signed-off-by: James Almer <jamrial@gmail.com>

Signed-off-by: James Almer <jamrial@gmail.com>

Signed-off-by: James Almer <jamrial@gmail.com>

Signed-off-by: James Almer <jamrial@gmail.com>

Signed-off-by: James Almer <jamrial@gmail.com>

Signed-off-by: James Almer <jamrial@gmail.com>

Signed-off-by: James Almer <jamrial@gmail.com>

Signed-off-by: James Almer <jamrial@gmail.com>

Signed-off-by: James Almer <jamrial@gmail.com>

Fixes ticket 3959
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

This is similar to 7d97511eSigned-off-by: Michael Niedermayer <michaelni@gmx.at>

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>

for big enough pictures.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

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