* commit '69a68593ce5684409c3c4dd9a901bfd8b16925b1':
Remove stray line breaks from avpriv_{report_missing_feature|request_samples}
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '2008f76054906e9ff6bf744800af0e5a5bfe61be':
dca: remove unused decode_hf function and quant_d tables
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit 'aebf07075f4244caf591a3af71e5872fe314e87b':
dca: change the core to work with integer coefficients.
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit 'de9e199a039473ebe4b1b87382e3064d0ea2cf02':
lavc: make avpriv_mpa_decode_header private on next bump
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '955aec3c7c7be39b659197e1ec379a09f2b7c41c':
mpegaudiodecheader: check the header in avpriv_mpegaudio_decode_header
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit 'cea1eef25c3310a68dd327eb74aae14ad3c2ddef':
lavc: get the profile name through the codec descriptor in avcodec_string()
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
Before 741b494fa8, when the reference list
modification description was invalid, the code would substitute the
corresponding reference from the initial ("default") reference list.
After that commit, it will just return an error.
Since there are apparently invalid samples in the wild that used to play
fine with the old code, it is a good idea to re-add some sort of error
resilience here. So, when the reference list modification results in a
missing frame, substitute a previous reference frame for it. The
relevant sample again decodes fine with the same output as previously.
This can happen if s->ls changes from 0 to 1, but picture allocation is
skipped due to s->interlaced.
In that case ff_jpegls_decode_picture could be called even though the
s->picture_ptr frame has the wrong pixel format and thus a wrong
linesize, which results in a too small zero buffer being allocated.
This fixes an out-of-bounds read in ls_decode_line.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Commit b272c3a5aa has sped up dsd_tablegen, and now table generation takes
~ 40k cycles. Thus, these tables can always be generated at runtime.
Tested with/without --enable-hardcoded-tables.
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
Tables are bit identical.
Sample benchmark (Haswell, GNU/Linux+gcc):
old:
814485 decicycles in dsd_ctables_tableinit, 512 runs, 0 skips
new:
356808 decicycles in dsd_ctable_tableinit, 512 runs, 0 skips
Binary size should essentially be identical, and is in fact identical on
the configuration I tested on.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
Intel's Instruction Set Reference (as of September 2015) clearly states
that cvtpi2ps switches to MMX state. Actual CPUs do not switch if the
source is a memory location. The Instruction Set Reference from 1999
(Order Number 243191) describes this behaviour but all later versions
I've seen have make no distinction whether MMX registers or memory is
used as source.
The documentation for the matching SSE2 instruction to convert to double
(cvtpi2pd) was fixed (see the valgrind bug
https://bugs.kde.org/show_bug.cgi?id=210264).
It will take time to get a clarification and fixes in place. In the
meantime it makes sense to change ff_int32_to_float_fmul_scalar_sse to
be correct according to the documentation. The vast majority of users
will have SSE2 so a change to the SSE version has little effect.
Fixes fate-checkasm on x86 valgrind targets.
Valgrind 'bug' reported as https://bugs.kde.org/show_bug.cgi?id=357059
get_ue_golomb() cannot decode values larger than 8190 (the maximum
value that can be golomb encoded in 25 bits) and produces the error
"Invalid UE golomb code" if a larger value is encountered. Use
get_ue_golomb_long() instead (which supports 63 bits, up to 4294967294)
when valid h264/hevc values can exceed 8190.
This updates decoding of the following values: (maximum)
first_mb_in_slice 36863* for level 5.2
abs_diff_pic_num_minus1 131071
difference_of_pic_nums_minus1 131071
idr_pic_id 65535
recovery_frame_cnt 65535
frame_packing_arrangement_id 4294967294
frame_packing_arrangement_repetition_period 16384
display_orientation_repetition_period 16384
An alternative would be to modify get_ue_golomb() to handle encoded
values of up to 49 bits as was done for get_se_golomb() in a92816c.
In that case get_ue_golomb() could continue to be used for all of
these except frame_packing_arrangement_id.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Should fix the regression, and also speeds up table generation.
Tables tested on GNU/Linux+clang: they are identical to the ones prior
to 5495c7f. ff_exp10 caused one slight change in one entry, 50000 became
50001 due to somewhat incorrect rounding.
Untested on ICC; passes FATE on GNU/Linux+gcc.
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
The DCA core decoder converts integer coefficients read from the
bitstream to floats just after reading them (along with dequantization).
All the other steps of the audio reconstruction are done with floats
which makes the output for the DTS lossless extension (XLL)
actually lossy.
This patch changes the DCA core to work with integer coefficients
until QMF. At this point the integer coefficients are converted to floats.
The coefficients for the LFE channel (lfe_data) are not touched.
This is the first step for the really lossless XLL decoding.
This fixes an out-of-bounds read introduced in commit 0379603.
Reviewed-by: Kieran Kunhya <kierank@obe.tv>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Fix possible SF delta violation that would cause an
eventual assertion failure in some corner cases (esp
on very low bitrates) when marking bands for PNS due
to misuse of the sf_delta utilities
'erf' is far from the best name for a variable and is not very
descriptive since the actual variable points to the comparitively best
IS phase. Therefore rename it to 'best'.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
Otherwise the too small buffer is directly used in the frame, causing
segmentation faults, when trying to use the frame.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
This is used to check if the input buffer is large enough, so if this
overflows it can cause a false negative leading to a segmentation fault
in bytestream2_get_bufferu.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Fix related register order issue in ff_h264_idct_add_neon.
Found-by: zjh8890 <243186085@qq.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This macro unconditionally used out[-1], which causes an out of bounds
read, if out is the very beginning of the buffer.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
More don't fit into the integer output.
Also use get_bits_long, since get_bits only supports reading up to 25
bits, while get_bits_long supports the full integer range.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
The type of last_frame_pb_count was chosen to be an int since overflow
is impossible (the spec says the maximum bits per frame is 6144 per
channel and the encoder checks for that).
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
Reviewed-by: Paul B Mahol <onemda@gmail.com>
* commit '458e53f51fc75d08df884f8e9eb3d7ded23e97b3':
mpegvideo_enc: actually add the side data with vbv_delay to the packet
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '81c95eb8eee856d98d4ac37367dbc761f2faf875':
openh264: Directly include the deprecation guards header
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit 'c34df422628e6b7b657faee241fe7bb2629e0f57':
sgienc: Make sure to initialize skipped header portions
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
exp2 is faster.
It may be possible to optimize further; e.g the exponents seem to be
multiples of 0.25. This requires study though.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
If that is the case, the loop setting predictor_state in
sonic_decode_frame causes out of bounds reads of int_samples, which has
only frame_size number of elements.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
exp2 suffices here. Some trivial speedup is done in addition here by
reusing results.
This retains accuracy, and in particular results in identical values
with GNU libm + gcc/clang.
sample benchmark (Haswell, GNU/Linux):
proposed : 424160 decicycles in pow_table, 512 runs, 0 skips
exp2 only: 1262093 decicycles in pow_table, 512 runs, 0 skips
old : 2849085 decicycles in pow_table, 512 runs, 0 skips
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
* commit 'e02de9df4b218bd6e1e927b67fd4075741545688':
lavc: export Dirac parsing API used by the ogg demuxer as public
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit 'f0b769c16daafa64720dcba7fa81a9f5255e1d29':
lavc: add a packet side data type for VBV-like parameters
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '31c51f7441de07b88cfea2550245bf1f5140cb8f':
avpacket: add a function for wrapping existing data as side data
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit 'b09ad37c83841c399abb7f2503a2ab214d0c2d48':
h264: derive the delay from the level when it's not present
Merged without changing the strict_std_compliance check, as it breaks FATE
and changes decoding behavior.
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '792b9c9dfcf44b657d7854368d975b5ca3bc22ca':
h264: set frame_num in start_frame(), not decode_slice_header()
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
This macro unconditionally used out[-1], which causes an out of bounds
read, if out is the very beginning of the buffer.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Due to this typo max_center can be too large, causing nlsf to be set to
too large values, which in turn can cause nlsf[i - 1] + min_delta[i] to
overflow to a negative value, which is not allowed for nlsf and can
cause an out of bounds read in silk_lsf2lpc.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Due to this typo max_center can be too large, causing nlsf to be set to
too large values, which in turn can cause nlsf[i - 1] + min_delta[i] to
overflow to a negative value, which is not allowed for nlsf and can
cause an out of bounds read in silk_lsf2lpc.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Also correct the check to reject log < 7, because UPDATE_CACHE only
guarantees 25 meaningful bits.
This fixes undefined behavior:
runtime error: shift exponent is negative
Testing with START/STOP timers in get_ue_golomb, one for the first
branch (A) and one for the second (B), shows that there is practically no
slowdown, e.g. for the cavs decoder:
With the check in the B branch:
629 decicycles in get_ue_golomb B, 4194260 runs, 44 skips
433 decicycles in get_ue_golomb A,268434102 runs, 1354 skips
Without the check:
624 decicycles in get_ue_golomb B, 4194273 runs, 31 skips
433 decicycles in get_ue_golomb A,268434203 runs, 1253 skips
Since the B branch is executed far less often than the A branch, this
change is negligible, even more so for the h264 decoder, where the ratio
B/A is a lot smaller.
Fixes: mozilla bug 1230239
Fixes: fbeb8b2c7c996e9b91c6b1af319d7ebc/asan_heap-oob_195450f_2743_e8856ece4579ea486670be2b236099a0.bit
Found-by: Tyson Smith
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
PSNR doesn't change as expected. The AAC spec doesn't really say
anything about how exactly to generate noise.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
Quite a bit faster than int32_to_float_fmul_array8_c calling
ff_int32_to_float_fmul_scalar_neon through FmtConvertContext.
Number of cycles per int32_to_float_fmul_array8 call while decoding
padded.dts on exynos5422:
before after change
cortex-a7: 1270 951 -25%
cortex-a15: 434 285 -34%
checkasm --bench cycle counts: cortex-a15 cortex-a7
int32_to_float_fmul_array8_c: 1730.4 4384.5
int32_to_float_fmul_array8_neon_c: 571.5 1694.3
int32_to_float_fmul_array8_neon: 374.0 1448.8
Interesting are the differences between
int32_to_float_fmul_array8_neon_c and int32_to_float_fmul_array8_neon.
The former is current behaviour of calling
ff_int32_to_float_fmul_scalar_neon repeatedly from the c function,
The raw numbers differ since checkasm uses different lengths than the
dca decoder.
~25% faster dts decoding overall. The checkasm CPU cycles numbers are
not that useful since synth_filter_float() calls FFTContext.imdct_half().
cortex-a57 cortex-a53
synth_filter_float_c: 1866.2 3490.9
synth_filter_float_neon: 915.0 1531.5
With fftc.imdct_half forced to imdct_half_neon:
cortex-a57 cortex-a53
synth_filter_float_c: 1718.4 3025.3
synth_filter_float_neon: 926.2 1530.1
The vector mode was deprecated in ARMv7-A/VFPv3 and various cpu
implementations do not support it in hardware. Vector mode code will
depending the OS either be emulated in software or result in an illegal
instruction on cpus which does not support it. This was not really
problem in practice since NEON implementations of the same functions are
preferred. It will however become a problem for checkasm which tests
every cpu flag separately.
Since this is a cpu feature newer cpu do not support anymore the
behaviour of this flag differs from the other flags. It can be only
activated by runtime cpu feature selection.
Almost all the places from which this function is called already check
the header manually and in the two that don't (the mp3 muxer) the check
should not cause any problems.
The limit is a conservative guess, the spec does not seem to specify a limit
Reviewed-by: Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The transpose_4x4H is wrong which cost me much time to find this bug. The orders of r2 and r3 are wrong,
this bug waste me much time while I make aarch64 arm instruction which used the function.
This also removes a #ifdef and special case for the fixed point case
Reviewed-by: Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
If the input contains too many too large values, the imdct can overflow.
Even if it didn't, the output would be larger than the valid range of 29
bits.
Note that this is a very delicate limit: Allowing values up to 1<<25
does not prevent input larger than 1<<29 from arriving at
sbr_sum_square, while limiting values to 1<<23 breaks the
fate-aac-fixed-al_sbr_hq_cm_48_5.1 test.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Fix OOB access in search_for_pns which was using
w2 outside the window group loop, and fix a typo
in which it was checking sf_idx instead of band_type
Reviewed-by: Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
This gets rid of virtually useless hardcoded tables hackery. The reason
it is useless is that a 320 element lut is anyway placed regardless of
--enable-hardcoded-tables, from which all necessary tables are trivially
derived at runtime at very low cost:
sample benchmark (x86-64, Haswell, GNU/Linux, single run is really
what is relevant here since looping drastically changes the bench). Fluctuations
are on the order of 10% for the single run test:
39400 decicycles in aacsbr_tableinit, 1 runs, 0 skips
25325 decicycles in aacsbr_tableinit, 2 runs, 0 skips
18475 decicycles in aacsbr_tableinit, 4 runs, 0 skips
15008 decicycles in aacsbr_tableinit, 8 runs, 0 skips
13016 decicycles in aacsbr_tableinit, 16 runs, 0 skips
12005 decicycles in aacsbr_tableinit, 32 runs, 0 skips
11546 decicycles in aacsbr_tableinit, 64 runs, 0 skips
11506 decicycles in aacsbr_tableinit, 128 runs, 0 skips
11500 decicycles in aacsbr_tableinit, 256 runs, 0 skips
11183 decicycles in aacsbr_tableinit, 509 runs, 3 skips
Tested with FATE with/without --enable-hardcoded-tables.
Reviewed-by: Rostislav Pehlivanov <atomnuker@gmail.com>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
pow is a very wasteful function for this purpose. A low hanging fruit
would be simply to replace with exp2f, and that does yield some speedup.
However, there are 2 drawbacks of this:
1. It does not exploit the integer nature of the argument.
2. (minor) Some platforms lack a proper exp2f routine, making benefits available
only to non broken libm.
3. exp2f does not solve the same issue that plagues pow, namely terrible
worst case performance. This is a fundamental issue known as the
"table-maker's dilemma" recognized by Prof. Kahan himself and
subsequently elaborated and researched by many others. All this is clear from benchmarks below.
This exploits the IEEE-754 format to get very good performance even in
the worst case for integer powers of 2. This solves all the issues noted
above. Function tested with clang usan over [-1000, 1000] (beyond range of
relevance for this, which is [-255, 255]), patch itself with FATE.
Benchmarks obtained on x86-64, Haswell, GNU-Linux via 10^5 iterations of
the pow call, START/STOP, and command ffplay ~/samples/jpeg2000/chiens_dcinema2K.mxf.
Low number of runs also given to prove the point about worst case:
pow:
216270 decicycles in pow, 1 runs, 0 skips
110175 decicycles in pow, 2 runs, 0 skips
56085 decicycles in pow, 4 runs, 0 skips
29013 decicycles in pow, 8 runs, 0 skips
15472 decicycles in pow, 16 runs, 0 skips
8689 decicycles in pow, 32 runs, 0 skips
5295 decicycles in pow, 64 runs, 0 skips
3599 decicycles in pow, 128 runs, 0 skips
2748 decicycles in pow, 256 runs, 0 skips
2304 decicycles in pow, 511 runs, 1 skips
2072 decicycles in pow, 1022 runs, 2 skips
1963 decicycles in pow, 2044 runs, 4 skips
1894 decicycles in pow, 4091 runs, 5 skips
1860 decicycles in pow, 8184 runs, 8 skips
exp2f:
134140 decicycles in pow, 1 runs, 0 skips
68110 decicycles in pow, 2 runs, 0 skips
34530 decicycles in pow, 4 runs, 0 skips
17677 decicycles in pow, 8 runs, 0 skips
9175 decicycles in pow, 16 runs, 0 skips
4931 decicycles in pow, 32 runs, 0 skips
2808 decicycles in pow, 64 runs, 0 skips
1747 decicycles in pow, 128 runs, 0 skips
1208 decicycles in pow, 256 runs, 0 skips
952 decicycles in pow, 512 runs, 0 skips
822 decicycles in pow, 1024 runs, 0 skips
765 decicycles in pow, 2047 runs, 1 skips
722 decicycles in pow, 4094 runs, 2 skips
693 decicycles in pow, 8190 runs, 2 skips
exp2fi:
2740 decicycles in pow, 1 runs, 0 skips
1530 decicycles in pow, 2 runs, 0 skips
955 decicycles in pow, 4 runs, 0 skips
622 decicycles in pow, 8 runs, 0 skips
477 decicycles in pow, 16 runs, 0 skips
368 decicycles in pow, 32 runs, 0 skips
317 decicycles in pow, 64 runs, 0 skips
291 decicycles in pow, 128 runs, 0 skips
277 decicycles in pow, 256 runs, 0 skips
268 decicycles in pow, 512 runs, 0 skips
265 decicycles in pow, 1024 runs, 0 skips
263 decicycles in pow, 2048 runs, 0 skips
263 decicycles in pow, 4095 runs, 1 skips
260 decicycles in pow, 8191 runs, 1 skips
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
This fixes out-of-bounds reads in avoid_clipping.
Reviewed-by: Rostislav Pehlivanov <atomnuker@gmail.com>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
In the merge commit 78265fcfee this behaviour
was broken and the CORRUPT flag would never ever be set on a frame. However
the flag on the AVCodecContext was taken into account properly, including
AV_CODEC_FLAG2_SHOW_ALL.
The reason for this was that the recovered field of the next output picture
was always set to TRUE whenever one of the two AVCodecContext flags was set,
which made it impossible to detect later, before outputting, if the frame was
really recovered or not. Now don't set it to TRUE unless the frame is really
recovered and check the AVCodecContext flags right before outputting.
Signed-off-by: Sebastian Dröge <sebastian@centricular.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
With only 7 coefficients per short window at most the extra precision
makes a difference and seems to reduce crackling and stddev even
further.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
* commit 'b805482b1fba1d82fbe47023a24c9261f18979b6':
aac: Provide more information on the failure message
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
Don't print a warning when dcadec_context_filter() returns positive
warning code. Most relevant warnings are now output through the callback
function.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Take request_channel_layout as a hint and don't force 2.0 downmix by
using both the 2CH and 6CH flags together.
Remove warnings about missing coefficients because they are no longer
relevant.
Honor AV_CH_LAYOUT_NATIVE and make it possible for native DTS channel
layout to be output.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
These variables are coming from mpegvideoenc where are supposedly used
as bit counters on various frame properties. However their use is
unclear as they lack documentation, are available only from a very small
subset of encoders, and they are hardly used in the wild. Also frame_bits
in aacenc is employed in a similar way.
Remove this functionality from AVCodecContex, these variable are mostly
frame properties, and too few encoders support setting them with anything
useful.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Most option values are simply unused or ignored and in practice the
majory of codecs only need to check whether to enable rle or not.
Add appropriate codec private options which better expose the allowed
features.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
* commit 'f023d57d355ff3b917f1aad9b03db5c293ec4244':
lavc: G.723.1 encoder
Split existing FFmpeg G.723.1 encoder into a new file.
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '165cc6fb9defcd79fd71c08167f3e8df26b058ff':
g723_1: Move sharable functions to a separate file
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit 'aac996cc01042194bf621d845bbe684549b5882e':
g723_1: Rename files to better reflect their purpose
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit 'b74b88f30da2389f333a31815d8326d5576d3331':
g723_1: Handle values at the ends of the table in lsp2lpc()
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
If the chroma components are subsampled, smaller buffers are allocated
for them. In that case the maximal block_offset for the chroma
components is not as large as for the luma component.
This fixes out of bounds writes causing segmentation faults or memory
corruption.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
There are a couple of major changes here:
1. Start using TNS coefficient compression.
2. Start using 3 bits per coefficient maximum for short windows.
The bits we save from these 2 changes seem to make a nice impact on the
rest of the file/windows.
3. Remove special case gain checking for short windows.
4. Modify the coefficient loop to support up to 3 windows.
The additional restrictions on TNS were something that was no in the
specifications and furthermore restricting TNS to only low energy short
windows was done to compensate for bugs elsewhere in the code.
Overall, the improvements here reduce crackling artifacts heard in very
noisy tracks.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
The original plan was to have TNS use data from the PNS search to better
tune itself to noise but this was never used nor necessary. This should
slightly boost the PNS accuracy if TNS was used.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
