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

The file contains the code for the audio buffersink as well.

* qatar/master:
  qdm2: remove broken and disabled dump_context() debug function
  x86: h264_intrapred: use newly introduced SPLAT* and PSHUFLW macros
  x86inc: add SPLATB_LOAD, SPLATB_REG, PSHUFLW macros
  x86inc: modify ALIGN to not generate long nops on i586
  x86: h264_intrapred: port to cpuflag macros
  avplay: update input filter pointer when the filtergraph is reset.
  avconv: fix parsing of -force_key_frames option.
  h264: use templates to avoid excessive inlining
  xtea: Make the count parameter match the documentation
  blowfish: Make the count parameter match the documentation
  mpegvideo: Don't use ff_mspel_motion() for vc1
  xtea: invert branch and loop precedence
  blowfish: invert branch and loop precedence
  flvdec: optionally trust the metadata
  avconv: Set audio filter time base to the sample rate
  vp8: Add ifdef guards around the sse2 loopfilter in the sse2slow branch too

Conflicts:
	ffmpeg.c
	ffplay.c
	libavcodec/h264.c
	libavcodec/mpegvideo_common.h
Merged-by: Michael Niedermayer <michaelni@gmx.at>

* 'mxfenc_improvements' of https://github.com/mbouron/FFmpeg:
  mxfenc: support dnxhd codec
  mxfenc: support smpte dv codec
Merged-by: Michael Niedermayer <michaelni@gmx.at>

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

Signed-off-by: Diego Biurrun <diego@biurrun.de>

Signed-off-by: Diego Biurrun <diego@biurrun.de>

Allow to show different supported multi-threading methods for an
encoder/decoder pair.

Fixes ticket #1512

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

This should fix a configure failure
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

After some internal talks it seems the code is similar to what is in FFmbc
by Baptiste Coudurier; Baptiste accepted to relicense the similiar chunks
from GPL to LGPL.

Fixes an invalid read on size change.

Currently it always exits with an error when more than
one position is specified.

CC: libav-stable@libav.org

Signed-off-by: Stefano Sabatini <stefasab@gmail.com>

Instead of inlining everything into ff_h264_hl_decode_mb(), use
explicit templating to create versions of the called functions
with constant parameters filled in.  This greatly speeds up
compilation of h264.c and reduces the code size without any
measurable impact on performance.

Compilation time for h264.c on an i7 goes from 30s to 5.5s.
Code size is reduced by 430kB.
Signed-off-by: Mans Rullgard <mans@mansr.com>

MP3 fixed and floating point decoders are optimized
 for MIPS architecture.
Signed-off-by: Nedeljko Babic <nbabic@mips.com>
Reviewed-by: Vitor Sessak <vitor1001@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

* git://github.com/mjbshaw/FFmpeg-OpenJPEG-J2K-Encoder:
  libopenjpegdec: add support for decoding YUV420/422/444P12/14
  libopenjpegenc: cosmetics: reorder pix_fmts
  libopenjpegenc: add support for YUV420/422/444P12/14
Merged-by: Michael Niedermayer <michaelni@gmx.at>

Previously it was interpreted as number of bytes, while the
documentation stated that it was the number of 8 byte blocks.
This makes it behave similarly to the existing AES code.
Signed-off-by: Martin Storsjö <martin@martin.st>

Previously it was interpreted as number of bytes, while the
documentation stated that it was the number of 8 byte blocks.
This makes it behave similarly to the existing AES code.
Signed-off-by: Martin Storsjö <martin@martin.st>

Using ff_mspel_motion assumes that s (a MpegEncContext
poiinter) really is a Wmv2Context.

This fixes crashes in error resilience on vc1/wmv3 videos.

CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>

  This is more similar to the "overall" FFmpeg coding style.

  Make it easier to spot the example. This way it can already be
discovered by scanning the table of contents.

  Make the document more consistent.

  It might be easier to understand for some people and is a bit more
in line with e.g. OpenSSH documentation. The meaning of the text stays
exactly the same.

Should slightly improve performance depending on the compiler used.

Should slightly improve performance depending on the compiler used.

In certain conditions video or audio frames might appear way later in the
stream.

If the output frame size is smaller than the input sample rate,
and the input stream time base corresponds exactly to the input
frame size (getting input packet timestamps like 0, 1, 2, 3, 4 etc),
the output timestamps from the filter will be like
0, 1, 2, 3, 4, 4, 5 ..., leadning to non-monotone timestamps later.

A concrete example is input mp3 data having frame sizes of 1152
samples, transcoded to aac with 1024 sample frames.

By setting the audio filter time base to the sample rate, we will
get sensible timestamps for all output packets, regardless of
the ratio between the input and output frame sizes.
Signed-off-by: Martin Storsjö <martin@martin.st>

This was missed in the the previous commit in 70a1c800.
Signed-off-by: Martin Storsjö <martin@martin.st>

Fixes ticket #1513

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

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

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