This should exercise the corner cases of numerous codecs.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

* commit '570d4b21':
  x86: h264: Don't keep data in the redzone across function calls on 64 bit unix
Merged-by: Michael Niedermayer <michaelni@gmx.at>

* commit '0776e0ef':
  adpcm: Write the proper predictor in trellis mode in IMA QT

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

* cehoyos/master:
  Allow values >31bit for -analyzeduration.
Merged-by: Michael Niedermayer <michaelni@gmx.at>

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

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

We know that the called function (ff_chroma_inter_body_mmxext)
doesn't touch the redzone, and thus will be kept intact - thus,
this doesn't fix any bug per se.

However, valgrind's memcheck tool intentionally assumes that the
redzone is clobbered on every function call and function return
(see a long comment in valgrind/memcheck/mc_main.c). This avoids
false positives in that tool, at the cost of an extra stack pointer
adjustment.

The other alternative would be a valgrind suppression for this issue,
but that's an extra burden for everybody that wants to run libavcodec
within valgrind.
Signed-off-by: Martin Storsjö <martin@martin.st>

The actual predictor value, set by the trellis code, never
was written back into the variable that was written into
the block header. This was accidentally removed in b304244b.

This significantly improves the audio quality of the trellis
case, which was plain broken since b304244b.

Encoding IMA QT with trellis still actually gives a slightly
worse quality than without trellis, since the trellis encoder
doesn't use the exact same way of rounding as in
adpcm_ima_qt_compress_sample and adpcm_ima_qt_expand_nibble.

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

Based-on code by: Carl Eugen Hoyos and Andrey Utkin
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>

The value is used by some bitstream to mark the maximum bit rate.

See thread:
Subject: [FFmpeg-devel] [PATCH] Add rc_max_rate to ffprobe stream output
Date: Sun,  1 Jun 2014 17:36:36 +0100
To: ffmpeg-devel@ffmpeg.org

http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/178461Signed-off-by: Stefano Sabatini <stefasab@gmail.com>

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

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

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

* commit '1619274f':
  av_dict_set: fix potential memory leak with AV_DICT_DONT_OVERWRITE
Merged-by: Michael Niedermayer <michaelni@gmx.at>

* commit '7b06ddb8':
  configure: use .altmacro for gnu as check on arm
Merged-by: Michael Niedermayer <michaelni@gmx.at>

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

This very slightly improves compression
Found-by: Christophe Gisquet <christophe.gisquet@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

The max depth is 3
Found-by: Christophe Gisquet <christophe.gisquet@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

This is probably not the simplest solution but as this is needed for a bugfix,
simplification is left for later.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Fixes a regression since fb3e3808 similar to ticket #2661,
reported by fluffrabbit at aol dot com.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

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

av_dict_set leaks it key/value arguments if AV_DICT_DONT_OVERWRITE is
combined with AV_DICT_DONT_STRDUP_{KEY,VAL} and the key exists.

Clang's integrated assembler (after 3.4) does not yet support the
'.altmacro' directive which is only used in arm asm. Support is planned:
http://llvm.org/bugs/show_bug.cgi?id=18918

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

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

xmm6 was being clobbered in ff_hscale8to{15,19}_8_sse2 on Win64
Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

There's an SSE2 version already, and technically the SSE version
on x86_64 was wrong (using pshufd and pshuflw, SSE2 instructions).
Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

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

It was lost during the port.
Should fix fate on 3dnowext machines.
Signed-off-by: James Almer <jamrial@gmail.com>
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>