grayscale is coded as 4 pixels at a time, the encoder lacks support
for the case where width%4 != 0, and will simply encode less data
leaving random data after decoding at the right side
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit '27860819d508068f056cf48473af04868791ad77':
ppc: Consistently use convenience macro for runtime CPU detection
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'f121dbd9f76031d7f6d56261be2f14937a19d2dd':
mpegts: Provide an option to override the pcr period
Conflicts:
doc/muxers.texi
libavformat/mpegtsenc.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '3f7e94eccd1c0d64679f2c4eda8bb942a158dfac':
mpegts: Move the option section to the bottom
Conflicts:
libavformat/mpegtsenc.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '570d4b21863b6254d6bbca9c528bede471bb4478':
x86: h264: Don't keep data in the redzone across function calls on 64 bit unix
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '0776e0ef6ba4160281ef3fabea43e670f3792b4a':
adpcm: Write the proper predictor in trellis mode in IMA QT
See: fa8f060b75
Merged-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>
* commit '7b06ddb8352fe7f434414d7911ced94956bb25b2':
configure: use .altmacro for gnu as check on arm
Merged-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>
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 fb3e380 similar to ticket #2661,
reported by fluffrabbit at aol dot com.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
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
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>
Michael Niedermayer
Vittorio Giovara
Diego Biurrun
Carl Eugen Hoyos
Luca Barbato
Christophe Gisquet
Martin Storsjö
Billy Shambrook
Ronald S. Bultje
Paul B Mahol
Janne Grunau
James Almer