- 19 Dec, 2011 3 commits
-
-
Diego Biurrun authored
-
Diego Biurrun authored
-
Janne Grunau authored
This reverts commit 87eebb34.
-
- 18 Dec, 2011 13 commits
-
-
Nathan Adil Maxson authored
Signed-off-by:
Ronald S. Bultje <rsbultje@gmail.com>
-
Janne Grunau authored
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.
-
Paul B. Mahol authored
Signed-off-by:
Janne Grunau <janne-libav@jannau.net>
-
Shitiz Garg authored
Width and height might get passed as 0 and would cause floating point exceptions in decode_frame. Fixes bugzilla #149 Signed-off-by:
Janne Grunau <janne-libav@jannau.net>
-
Mans Rullgard authored
Signed-off-by:
Mans Rullgard <mans@mansr.com>
-
Mans Rullgard authored
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). Signed-off-by:
Mans Rullgard <mans@mansr.com>
-
Justin Ruggles authored
This is unnecessary complication that only prints a message and does not affect decoding.
-
Anton Khirnov authored
Fixes avformat_find_stream_info() on streams with number of frames < thread count.
-
Ronald S. Bultje authored
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.
-
Michael Karcher authored
Signed-off-by:
Anton Khirnov <anton@khirnov.net>
-
Anton Khirnov authored
-
Anton Khirnov authored
-
Uoti Urpala authored
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>
-
- 17 Dec, 2011 16 commits
-
-
Mans Rullgard authored
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. Signed-off-by:
Mans Rullgard <mans@mansr.com>
-
Mans Rullgard authored
Signed-off-by:
Mans Rullgard <mans@mansr.com>
-
Ronald S. Bultje authored
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. Signed-off-by:
Mans Rullgard <mans@mansr.com>
-
Mans Rullgard authored
This macro is empty since the removal of the A32 bitstream reader. Signed-off-by:
Mans Rullgard <mans@mansr.com>
-
Mans Rullgard authored
We're shifting individual components (8-bit, unsigned) left by 24, so making them unsigned should give the same results without the overflow. Signed-off-by:
Ronald S. Bultje <rsbultje@gmail.com>
-
Janne Grunau authored
Add a macro to shorten the if condition.
-
Ronald S. Bultje authored
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. Signed-off-by:
Mans Rullgard <mans@mansr.com>
-
Mans Rullgard authored
Signed-off-by:
Mans Rullgard <mans@mansr.com>
-
Mans Rullgard authored
Signed-off-by:
Mans Rullgard <mans@mansr.com>
-
Janne Grunau authored
-
Mans Rullgard authored
Signed-off-by:
Mans Rullgard <mans@mansr.com>
-
Mans Rullgard authored
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. Signed-off-by:
Mans Rullgard <mans@mansr.com>
-
Mans Rullgard authored
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. Signed-off-by:
Mans Rullgard <mans@mansr.com>
-
Shitiz Garg authored
channels would be 0 sometimes and would cause floating point exception Fixes bugzilla #124 Signed-off-by:
Justin Ruggles <justin.ruggles@gmail.com>
-
Ronald S. Bultje authored
Signed-off-by:
Mans Rullgard <mans@mansr.com>
-
Ronald S. Bultje authored
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>.
-
- 16 Dec, 2011 8 commits
-
-
Mans Rullgard authored
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. Signed-off-by:
Mans Rullgard <mans@mansr.com>
-
Alexandra Khirnova authored
Signed-off-by:
Anton Khirnov <anton@khirnov.net>
-
Derek Buitenhuis authored
In the case that (frame_flags & 0x03) == 3, hybrid_maxclip may have had a signed integer overflow. Signed-off-by:
Derek Buitenhuis <derek.buitenhuis@gmail.com> Signed-off-by:
Anton Khirnov <anton@khirnov.net>
-
Derek Buitenhuis authored
It doesn't make much sense to clip pre-shift, nor is it correct for proper decoding. Signed-off-by:
Derek Buitenhuis <derek.buitenhuis@gmail.com> Signed-off-by:
Anton Khirnov <anton@khirnov.net>
-
Ronald S. Bultje authored
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.
-
Mans Rullgard authored
These pointers are already of the correct type. Signed-off-by:
Mans Rullgard <mans@mansr.com>
-
Diego Biurrun authored
-
Mans Rullgard authored
Signed-off-by:
Mans Rullgard <mans@mansr.com>
-