allowing access to the size but not the extradata itself is not useful
and could lead to potential problems if writing happens through this field
Reviewed-by: Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>
Reviewed-by: Lukasz Marek <lukasz.m.luki2@gmail.com>
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This buffer is resized when vpx_codec_get_cx_data() returns a
VPX_CODEC_STATS_PKT packet.
CC: libav-stable@libav.org
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
* commit 'ae5e1f3d663a8c9a532d89e588cbc61f171c9186':
tiff: Check that there is no aliasing in pixel format selection
See: e1c0cfaa41
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '0025f7408a0fab2cab4a950064e4784a67463994':
vorbis: Check the vlc value in setup_classifs
Conflicts:
libavcodec/vorbisdec.c
See: ae038c0914
See: 709cae2bcb
Merged-by: Michael Niedermayer <michaelni@gmx.at>
The valid returned values are always at most 11bit.
Remove the previous check that assumed larger values plausible and
use a signed integer to check get_vlc2 return values.
CC: libav-stable@libav.org
Fixes out of array access
Fixes: ffmpeg_opus_crash1.ogg
This solution is likely not optimal in terms of error concealment but
its simple and fixes the out of array access.
Found-by: Thomas Lindroth <thomas.lindroth@gmail.com>
Tested-by: Thomas Lindroth <thomas.lindroth@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This is safer than to assume that all error pathes cleared them and
nothing will use uncleared pointers.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Fixes out of array accesses
Fixes: ffmpeg_mjpeg_crash2.avi
Found-by: Thomas Lindroth <thomas.lindroth@gmail.com>
Tested-by: Thomas Lindroth <thomas.lindroth@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This mainly consists of replacing all the pointer arithmatic 'addiu'
instructions with PTR_ADDIU which will handle the differences in pointer
sizes when compiled on 64 bit mips systems.
The header asmdefs.h contains the PTR_ macros which expend to the correct mips
instructions to manipulate registers containing pointers.
Signed-off-by: James Cowgill <james410@cowgill.org.uk>
Reviewed-by: Nedeljko Babic <Nedeljko.Babic@imgtec.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
There are no independant uses of mips32r2 instructions except for the
FPU parts. Due to the heavy use of mips32r2 specifc fpu extensions, I
am guessing the original author intended MIPSFPU to imply MIPS32R2 anyway.
Since these fpu instructions are available on mips64 (non-r2), enable them
there as well.
Also remove the last occurence of HAVE_MIPS32R2 (which is coupled to
HAVE_MIPSFPU anyway).
mips32r2 is left in the list of options form compatability so that using
--disable-mips32r2 doesn't break anything.
Signed-off-by: James Cowgill <james410@cowgill.org.uk>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Removing these removes the dependency of this code on mips32r2 which would
allow it to be used on processors which have FPU instructions, but not r2
instructions (like the mips64el debian port for instance).
Signed-off-by: James Cowgill <james410@cowgill.org.uk>
Reviewed-by: Nedeljko Babic <Nedeljko.Babic@imgtec.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Instead, warn that bitrate will be clamped down to the maximum allowed.
Patch is mostly work of Kamendo2 in issue #2686, quite tested within that issue.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit '25c29d32835f38cdc5f0c84fa27dfc489a228770':
libopenh264enc: Add support for building with OpenH264 1.4
Merged-by: Michael Niedermayer <michaelni@gmx.at>
According to the WebP Lossless Bitstream Specification
"each transform is allowed to be used only once".
If a transform is more than once this can lead to memory
corruption.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
If it doesn't fit into 12 bits it triggers an assertion.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
According to the WebP Lossless Bitstream Specification the highest
allowed value for a prefix code is 39.
If prefix_code is too large, the calculated extra_bits has an invalid
value and triggers an assertion in get_bits.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Regular autovariance is no longer "experimental", and a version of it with
bias towards dark scenes is now in mainline x264.
Signed-off-by: Peter Cordes <peter@cordes.ca>
* commit '25f613f8be3b51e4396b93cda131e4631ba54302':
dca: Move syncword definitions to a separate header
Conflicts:
libavcodec/dca_parser.c
libavformat/dtsdec.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Although the specification mandates this bit to zero, it may happen
that software tools incorrectly flip it to one, invalidating a possibly
valid stream.
Relax this restriction, by failing only when AV_EF_BITSTREAM is set.
This behaviour is similar to aac decoders in Firefox and Quicktime.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
The macro is implemented as a do{}while()
enclosing this is () appears to be a GNU extension (6.1 Statements and Declarations in Expressions)
the () is also unneeded and wrong as the macro returns no
value
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This fixes pixel values not being properly shifted in
libopenjpeg_copyto16 and libopenjpeg_copy_to_packed16 methods.
Pixel formats like xyz12le need to be shifted by AVComponentDescriptor::shift
to get the correct values.
Reviewed-by: Michael Bradshaw <mjbshaw@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
On mips64, the registers t[4-7] do not exist. Instead of using a lot of #ifdef
or defines to handle differing register names, use variables and let GCC
allocate the registers automatically (like in the other mips assembly files).
In get_band_cost_ESC_mips, t4 and t5 were renamed to t6 and t7 to avoid a
variable name conflict.
Signed-off-by: James Cowgill <james410@cowgill.org.uk>
Reviewed-by: Nedeljko Babic <Nedeljko.Babic@imgtec.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This is obviously needed for 64-bit support.
Signed-off-by: James Cowgill <james410@cowgill.org.uk>
Reviewed-by: Nedeljko Babic <Nedeljko.Babic@imgtec.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Normally the aic decoder finds the proper slice combination (multiple of
some number less than 32) but in case of odd width, it resorts to the
default values, which were actually swapped.
The number of slices is modified to account for such odd width cases.
CC: libav-stable@libav.org
This patch fixes a pointer arithmetic bug in adjust_frame_information that resulted in heavily corrupted audio when using M/S encoding. Also, a backup copy of untransformed coefficients has to be kept around or attempts at re-processing the frame (which happens when hevavily overspending bits during transients) will result in re-encoding of the coefficients and subsequent corruption of the resulting stream.
A/B testing shows the bug as corrected, but still cannot prove that M/S coding is a win at least in numbers. Limited listening tests do show improvement on M/S encoded samples in lower bitrates, but they're hidden among the other artifacts that remain to be corrected in the encoder.
Some of the regressions flagged in the report do show poor stereo image (but not buggy), so M/S encoding is clearly not good enough yet to be defaulted to auto.
In numbers, Patched against Unpatched, stereo_mode auto:
Files: 114
Bitrates: 6
Tests: 683
Serious Regressions: 0 (0%)
Regressions: 0 (0%)
Improvements: 227 (33%)
Big improvements: 92 (13%)
Worst regression - mybloodrusts.wv - 256k
- StdDev: 28.61 pSNR: -0.43 maxdiff: 1372.00
Best improvement - 60.wv - 384k
- StdDev: -369.57 pSNR: 45.02 maxdiff: -13322.00
Average - StdDev: -80.56 pSNR: 2.49 maxdiff: -8858.00
Patched against Unpatched stereo_mode ms_off shows no difference.
Patched stereo_mode auto vs Unpatched stereo_mode ms_off shows a small average improvement, just not too significant:
Serious Regressions: 0 (0%)
Regressions: 10 (1%)
Improvements: 45 (6%)
Big improvements: 2 (0%)
Worst regression - Illinois.wv - 256k
- StdDev: 33.20 pSNR: -2.03 maxdiff: 477.00
Best improvement - song_of_circomstances.flac - 384k
- StdDev: -3.97 pSNR: 7.61 maxdiff: -826.00
Average - StdDev: -10.25 pSNR: 0.20 maxdiff: -281.00
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
If it doesn't fit into 12 bits it triggers an assertion.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
According to the WebP Lossless Bitstream Specification the highest
allowed value for a prefix code is 39.
If prefix_code is too large, the calculated extra_bits has an invalid
value and triggers an assertion in get_bits.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This is a small change, but it does have a big impact on bit allocation.
all the regressions marked in the report have no audible
difference (I didn't check them all though), but the improvements can
be heard.
This affects mostly high bit rates. It's related to issue #2686.
In the report, A is the patched version, B is unpatched, all
comparisons show deltas in the form (A-B), so a positive pSNR delta
means a better quality in the patched version, and negative a
regression. Regressions are only considered for pSNR deltas below
-1db, they're considered serious below -6db.
All measurements were done with tiny_psnr.
The summary of the report inline for quick reading:
Files: 58
Bitrates: 6
Tests: 347
Serious Regressions: 0 (0%)
Regressions: 10 (2%)
Improvements: 54 (15%)
Big improvements: 26 (7%)
Worst regression - sine_tester.flac - 384k
- StdDev: 1.68 pSNR: -3.05 maxdiff: -178.00
Best improvement - 07 - Bound.flac - 384k
- StdDev: -1700.05 pSNR: 20.64 maxdiff: -29595.00
Average - StdDev: -55.67 pSNR: 1.20 maxdiff: -1593.00
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Some files produced by the official encoder have up to 16bit of
padding instead of the expected padding to the byte.
Use a self-explanatory macro instead of a simple number.
CC: libav-stable@libav.org
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
9127 -> 8936 decicycles (fate-suite/vc1/SA10143.vc1)
13855 -> 10976 decicycles (fate-suite/vc1/SA20021.vc1)
tests done by the author over this function but with the whole
patchset applied not just this commit
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Several encoders were multiplying the buffer size by 8, in order to get
a bit size. However, the buffer_size argument is for the byte size of
the buffer. We had experienced crashes encoding prores (Anatoliy) at
size 4096x4096.
Change register constraint on the v variable from = to +. This was causing GCC
to think that the v variable was never read and therefore not initialize it.
This fixes about 20 fate failures on mips64el.
Signed-off-by: James Cowgill <james410@cowgill.org.uk>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The float_copy and fmul_and_reverse functions are refactored out from the
multiple copies in this file.
Signed-off-by: James Cowgill <james410@cowgill.org.uk>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The optimized C version of this code actually runs faster than this
version, so remove it.
Signed-off-by: James Cowgill <james410@cowgill.org.uk>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Remove some assembly that the compiler can easily handle optimally on its own.
GCC produces almost identical assembly.
Signed-off-by: James Cowgill <james410@cowgill.org.uk>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Q_fract should have be declared as 'const float*'.
Also fix the constness of some local variables affected by this.
Signed-off-by: James Cowgill <james410@cowgill.org.uk>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
GCC is perfectly happy generating optimized multiplication code on its own for
64-bit arches. GCC refuses to optimize the loongson code when in 32-bit mode,
so I've left that.
Signed-off-by: James Cowgill <james410@cowgill.org.uk>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Fixes out of array read
Fixes: asan_heap-oob_4d4eb0_3994_cov_3169972261_zmbv_15bit.avi
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Fixes out of array read
Fixes: asan_heap-oob_2ff30d2_3479_cov_3803648058_src13_hrc7_525_420_2.264
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
When calling ff_alloc_entries, a number of entries are created.
They are never freed, as running fate with slice threading and
several frames on e.g. fate-hevc-conformance-ENTP_A_Qualcomm_1
would show.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Fixes the following link error:
nutdec.c:(.text+0x2d47): undefined reference to `ff_codec_movvideo_tags'
isom.c:(.text+0x332): undefined reference to `avpriv_mpeg4audio_get_config'
isom.c:(.text+0x39e): undefined reference to `avpriv_mpa_freq_tab'
Fixes integer overflow and out of array read.
Fixes: signal_sigsegv_24169e6_3445_cov_3778346427_snow_chroma_bug.avi
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'cb4cb7b0ea12b791dde587b1acd504dbb4ec8f41':
qsv: Skip qsv.h compilation if qsv is not enabled
Conflicts:
libavcodec/Makefile
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '061c489895d29049a88dc6118e4b639a273b31d6':
eamad: check for out of bounds read
Conflicts:
libavcodec/eamad.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Averaging over 2 pixels doesn't work correctly for the last pixel, because the
rest of the buffer is not initialized.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This fixes invalid reads of the packet buffer in av_dup_packet
Based on patch by Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Currently, a part of the loop has to be handled in plain C, because of DSP
function requirements of having batches of 16 elements to process.
Instead, pad the buffer with 0 where the DSP functions are overreading.
Signed-off-by: James Almer <jamrial@gmail.com>
