Janne Grunau [Mon, 19 Dec 2011 17:11:44 +0000 (18:11 +0100)]
h264: clear trailing bits in partially parsed NAL units
Trailing bits are likely to be non-zero if the NAL unit is truncated.
Clearing the bits make overreads of the bitstream less likely in this
case. Fixes playback of
http://streams.videolan.org/streams/mp4/Mr_MrsSmith-h264_aac.mp4 which
has a forbidden byte sequence of 0x00 0x00 0x00 in it SPS.
Janne Grunau [Sun, 18 Dec 2011 21:42:36 +0000 (22:42 +0100)]
h264: skip start code search if the size of the nal unit is known
Start code emulation prevention is only required in Annex B bytestream
packed NAL units. For other coding formats the size is already known.
Looking for a start code prefix can result in false positives like in
http://streams.videolan.org/streams/mp4/Mr_MrsSmith-h264_aac.mp4
which has a false positive in the SPS.
Mans Rullgard [Sun, 18 Dec 2011 20:41:42 +0000 (20:41 +0000)]
avcodec: deprecate AVFrame.age
This was intended as an optimisation for skipped blocks in MPEG2
P-frames and never used elsewhere. Removing this "optimisation"
speeds up MPEG2 decoding by 1-2% (ARM Cortex-A9).
Ronald S. Bultje [Sun, 18 Dec 2011 16:27:43 +0000 (08:27 -0800)]
swscale: fix overflows in vertical scaling at top/bottom edges.
This fixes integer multiplication overflows in RGB48 output
(vertical) scaling as detected by IOC. What happens is that for
certain types of filters (lanczos, spline, bicubic), the
intermediate sum of coefficients in the middle of a filter can
be larger than the fixed-point equivalent of 1.0, even if the
final sum is 1.0. This is fine and we support that.
However, at frame edges, initFilter() will merge the coefficients
for the off-screen pixels into the top or bottom pixel, such as
to emulate edge extension. This means that suddenly, a single
coefficient can be larger than the fixed-point equivalent of
1.0, which the vertical scaling routines do not support.
Therefore, remove the merging of coefficients for edges for
the vertical scaling filter, and instead add edge detection
to the scaler itself so that it copies the pointers (not data)
for the edges (i.e. it uses line[0] for line[-1] as well), so
that a single coefficient is never larger than the fixed-point
equivalent of 1.0.
Uoti Urpala [Sun, 18 Dec 2011 14:17:07 +0000 (16:17 +0200)]
tmv decoder: set correct pix_fmt
Previously the decoder only worked if the user had set avctx->pix_fmt
manually. For some reason the libavformat tmv demuxer sets this, so
the problem was not visible in avplay etc.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
Mans Rullgard [Sat, 17 Dec 2011 15:05:24 +0000 (15:05 +0000)]
build: link test programs with static libraries
Many of the test programs directly access internal symbols not
exported from the shared libraries. This allows tests to run
when configured with shared libraries.
Ronald S. Bultje [Sat, 17 Dec 2011 19:56:40 +0000 (19:56 +0000)]
swscale: fix overflow in gray16 vertical scaling.
This fixes the same overflow as in the RGB48/16-bit YUV scaling;
some filters can overflow both negatively and positively (e.g.
spline/lanczos), so we bias a signed integer so it's "half signed"
and "half unsigned", and can cover overflows in both directions
while maintaining full 31-bit depth.
Ronald S. Bultje [Fri, 16 Dec 2011 00:03:54 +0000 (00:03 +0000)]
swscale: fix overflows in output of RGB48 pixels.
For certain types of filters where the intermediate sum of coefficients
can go above the fixed-point equivalent of 1.0 in the middle of a filter,
the sum of a 31-bit calculation can overflow in both directions and can
thus not be represented in a 32-bit signed or unsigned integer. To work
around this, we subtract 0x40000000 from a signed integer base, so that
we're halfway signed/unsigned, which makes it fit even if it overflows.
After the filter finishes, we add the scaled bias back after a shift.
We use the same trick for 16-bit bpc YUV output routines.
Mans Rullgard [Sat, 17 Dec 2011 16:19:24 +0000 (16:19 +0000)]
mp3dec: hack: fix decoding with safe bitstream reader
The buffer splicing relies on the bitstream reader over-reading
the end of the buffer as declared in init_get_bits(), although
more data is actually present. Manually moving the bitstream
boundary after init_get_bits() allows this to work as expected.
Mans Rullgard [Sat, 17 Dec 2011 15:48:19 +0000 (15:48 +0000)]
fate: fix eatqi test
The sample has an incomplete last frame. Decoding it is pointless.
The garbage produced was changed by the bitstream reader now
protecting against over-reads.
Ronald S. Bultje [Fri, 16 Dec 2011 21:42:04 +0000 (21:42 +0000)]
get_bits: introduce safe bitreading to prevent overreads.
When turned on, H264/CAVLC gets ~15% (CVPCMNL1_SVA_C.264) slower for
ultra-high-bitrate files, or ~2.5% (CVFI1_SVA_C.264) for lower-bitrate
files. Other codecs are affected to a lesser extent because they are
less optimized; e.g., VC-1 slows down by less than 1% (all on x86).
The patch generated 3 extra instructions (cmp, cmovae and mov) per
call to get_bits().
The performance penalty on ARM is within the error margin for most
files, up to 4% in extreme cases such as CVPCMNL1_SVA_C.264.
Based on work (for GCI) by Aneesh Dogra <lionaneesh@gmail.com>, and
inspired by patch in Chromium by Chris Evans <cevans@chromium.org>.
Mans Rullgard [Fri, 16 Dec 2011 21:19:50 +0000 (21:19 +0000)]
get_bits: remove A32 variant
The A32 bitstream reader variant is only used on ARMv5 and for
Prores due to the larger bit cache this decoder requires.
In benchmarks on ARMv5 (Marvell Sheeva) with gcc 4.6, the only
statistically significant difference between ALT and A32 is
a 4% advantage for ALT in FLAC decoding. There is thus no (longer)
any reason to keep the A32 reader from this point of view.
This patch adds an option to the ALT reader increasing the bit
cache to 32 bits as required by the Prores decoder. Benchmarking
shows no significant change in speed on Intel i7. Again, the
A32 reader fails to justify its existence.
Ronald S. Bultje [Mon, 12 Dec 2011 20:02:58 +0000 (12:02 -0800)]
h264: don't drop B-frames after next keyframe on POC reset.
The keyframe after a POC reset may not be the first to be returned to
the user. Therefore, don't reset the expected next POC once we return
a keyframe to the user, but once we know that the next frame in the
return-queue is a keyframe.
Shitiz Garg [Thu, 15 Dec 2011 09:02:59 +0000 (14:32 +0530)]
westwood: Make sure audio header info is present when parsing audio packets
Audio header information might get scrambled and would not parse,
yet wsqva_read_packet would try to parse audio packets causing
segfaults such as floating point exception.
Martin Storsjö [Wed, 14 Dec 2011 20:32:29 +0000 (22:32 +0200)]
libgsm: Reset the MS mode of GSM in the flush function
The mode is set in libgsm_decode_init, but the decoder
object is simply destroyed and recreated in the flush
function - therefore the mode has to be set again.
This fixes playback using the libgsm_ms decoder in avplay.