* commit 'e4dc1000':
  yuv4mpeg: split the demuxer and muxer into separate files

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

* commit '3ef6c526':
  a64: check that extradata exists before reading from it
Merged-by: Michael Niedermayer <michaelni@gmx.at>

* commit 'b1365649':
  a64: remove unneeded struct qualifier
Merged-by: Michael Niedermayer <michaelni@gmx.at>

* commit 'd256ed78':
  4xm: allocate extradata properly.
Merged-by: Michael Niedermayer <michaelni@gmx.at>

* commit 'fd056029':
  lavc: add avcodec_free_context().

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

* commit 'e1b66778':
  lavc: remove the locking code in avcodec_close()

Conflicts:
	libavcodec/utils.c

Note, if someone knows of a external codec lib/API, hwaccel or other that requires
locking on its close/free side, please contact ffmpeg-devel.
Merged-by: Michael Niedermayer <michaelni@gmx.at>

Pad it with the required amount of zeros, check for malloc failure.

Right now, the caller has to manually manage some allocated
AVCodecContext fields, like extradata or subtitle_header. This is
fragile and prone to leaks, especially if we want to add more such
fields in the future.

The only reason for this behaviour is so that the AVStream codec context
can be reused for decoding. Such reuse is discouraged anyway, so this
commit is the first step to deprecating it.

This function should not modify any global state, so there should be no
reason for any locking.

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

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

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

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

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

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

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

Whenever av_gettime() is used to measure relative period of time,
av_gettime_relative() is prefered as it guarantee monotonic time
on supported platforms.
Signed-off-by: Olivier Langlois <olivier@trillion01.com>
Reviewed-by: Marton Balint <cus@passwd.hu>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

* commit '584f8840':
  riff: Pass block_align to estimate frame duration
Merged-by: Michael Niedermayer <michaelni@gmx.at>

Whenever av_gettime() is used to measure relative period of time,
av_gettime_relative() is prefered as it guarantee monotonic time
on supported platforms.
Signed-off-by: Olivier Langlois <olivier@trillion01.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

The parser is needed. FATE breaks if not present.

Whenever av_gettime() is used to measure relative period of time,
av_gettime_relative() is prefered as it guarantee monotonic time
on supported platforms.
Signed-off-by: Olivier Langlois <olivier@trillion01.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Whenever av_gettime() is used to measure relative period of time,
av_gettime_relative() is prefered as it guarantee monotonic time
on supported platforms.
Signed-off-by: Olivier Langlois <olivier@trillion01.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

These functions are using the POSIX clock_gettime() function with the
CLOCK_MONOTONIC clock id. If these are not present on the targeted
platform, the new functions will fallback on using the original realtime functions
av_gettime() and av_usleep().

Monotonic support can be added on other platforms with their
equivalent native system API eventually if possible.

Whenever time is requested to measure relative time, the monotonic clock,
when available, is superior to the system realtime clock because it is
not affected by discontinuous jumps in the system time

In a future step, offering the flexibility to let the user choose between
rt and monotonic clock for avdevices packets will be investigated.

It is very easy to experience the issues that this patch attempt to address
by rewinding back in the past the system time while ffmpeg is running.

this is breaking the ffmpeg report printing (ffmepg.c:print_report()) and
the the rate emulator functionality (-re) without the patch.
Signed-off-by: Olivier Langlois <olivier@trillion01.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Fix incorrect wSamplesPerBlock(=0) written for ADPCM_IMA_WAV
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

* cehoyos/master:
  Fix compilation of libavcodec/x86/hevc_deblock.asm with nasm.
Merged-by: Michael Niedermayer <michaelni@gmx.at>

* cus/stable:
  ffplay: add support for toggling between multiple video filters with the w key
  ffplay: fix typo in docs
  ffplay: try multiple sample rates if audio open fails
  cmdutils: replace usages of "#ifdef __MINGW32__" with "#ifdef _WIN32" because MSVC only defines _WIN32
  ffplay: fix compilation with Visual Studio
  ffplay: increase AV_SYNC_THRESHOLD_MIN to 0.04
Merged-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Marton Balint <cus@passwd.hu>

Signed-off-by: Marton Balint <cus@passwd.hu>

Should fix ticket #3509.
Signed-off-by: Marton Balint <cus@passwd.hu>

cmdutils: replace usages of "#ifdef __MINGW32__" with "#ifdef _WIN32" because MSVC only defines _WIN32

With the previous patch, this should fix ticket #3580 as well.
Signed-off-by: John Peebles <johnpeeb@gmail.com>

Based on a patch by achristensen from trac.ffmpeg.org.

Partially fixes ticket #3580.
Signed-off-by: Marton Balint <cus@passwd.hu>

Less than 0.04 sec delays should not be noticable, and it helps us with 50fps
content where some timing errors can cause a frame dup where it is not really
necessary.
Signed-off-by: Marton Balint <cus@passwd.hu>

Suggested-by: Reimar

Fixes ticket #3644.

Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>