Fixes: Ticket4878
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit c980c5e54dfe83ce8b631845ce750c38cec56873)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The variable is not a constant and can lead to race conditions
Fixes: repro.webm (not reproducable with FFmpeg alone)
Found-by: Dale Curtis <dalecurtis@google.com>
Tested-by: Dale Curtis <dalecurtis@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit dabea74d0e82ea80cd344f630497cafcb3ef872c)
the pps offset is used to locate pps in the spspps_buf; however, the
current calc method is wrong because it is the offset of the original
avctx->extradata;
when there is only one sps in the avcc; the value is correct by
coincidence, however, it will
fail in avcc with multi sps
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 6b32d0d86b6bec2b5cb565d6ab4556f8cd66214a)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 3d126ef188639e0b55bdbbb755eafced66f23352)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Commits 43bc5cf9 and c5371f77 add code for skipping initial zeros in mp3
packets. This code forgot to report to the user that data was skipped at
all.
Since audio codecs allow partial packet decoding, the user application
has to rely on the return value. It will remove the data reported as
consumed by the decoder, and feed it to the decoder again. This resulted
in the mp3 frame after the zero region to be decoded over and over
again, until the zero region was finally skipped by the application.
Fix this by including the amount of skipped bytes to the number of
consumed bytes returned by the decode call.
Fixes trac ticket #4890.
(cherry picked from commit cb1da9fb8d71bb611a7b0028914c97afc3f5711d)
Modified datatype of function argument (pitch from int32_t to ptrdiff_t).
Signed-off-by: Shivraj Patil <shivraj.patil@imgtec.com>
Commit in master: 322e960dbf32b846b26f95afa6c0e652bc04e90d
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Modified sps and pps access from old HEVCContext(s) structure to newly introduced HEVCParamSets(ps).
Signed-off-by: Shivraj Patil <shivraj.patil@imgtec.com>
Commit in master: b0732b0214a40cdbcaf49d72cc6f25a7e9e5f115
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: invalid_read.nut
Found-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 2d221d9e069e6269cb41f3678f2734800171d87b)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
CID 1260 (as evidenced by incorrect decoding of a sample from ticket
4876) seems to use incorrect weight tables. It appears those tables
were not zigzag-scanned.
Apply zigzag on weight tables for new CIDs 1258, 1259, and 1260, and
fix an incorrect chroma table for CID 1256.
Fixes last issue from ticket #4876.
Found-by: Christophe Gisquet <christophe.gisquet@gmail.com>
Signed-off-by: Christophe Gisquet <christophe.gisquet@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 428424fe75206753ab2039e624031c9643623ea0)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This bit is 1 in some samples, and seems to coincide with interlaced
mbs and CID1260. 2008 specs do not know about it, and maintain qscale
is 11 bits. This looks oversized, but may help larger bitdepths.
Currently, it leads to an obviously incorrect qscale value, meaning
its syntax is shifted by 1. However, reading 11 bits also leads to
obviously incorrect decoding: qscale seems to be 10 bits.
However, as most profiles still have 11bits qscale, the feature is
restricted to the CID1260 profile.
The encoder writes 12 bits of syntax, last and first bits always 0,
which is now somewhat inconsistent with the decoder, but ends up with
the same effect (progressive + reserved bit).
Partially fixes ticket #4876.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 2801a1352dc8682b028e53880f9847fcb2116947)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes hang.nut
Found-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit b2955b6c5aed11026ec5c7164462899a10cdb937)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fix segfault with too large slice_count
Fixes Ticket4879
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit aa6c43f3fdec8a7518534b9dab20c9eb4be11568)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 055e56e9f76da3298f1b59bf5ea46f570e844600)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This commit improves the TNS implementation to the point where it's
actually usable and very rarely results in nastyness (in all bitrates
except extremely low bitrates it's increasing the quality and prevents
some distortions from the coder being audiable).
Also adds a double filter support which is only used if the energy
difference between the top and bottom of the SFBs is above the
thresholds defined in the header file. Looking at the bitstream
that fdk_aac generates it sometimes used a double filter despite
the specs stating that a single filter should be enough for almost
all cases and purposes.
Unlike FAAC or fdk_aac we sometimes use a reverse filter in case
the energy difference isn't enought to use a double filter. This
actually works better.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
This commit adds a flag to use the pure coefficients instead
of the processed ones (sce->coeffs). This is needed because
IS will apply the changes to the coefficients immediately
before the adjust_common_prediction function and it doesn't
make sense to measure stereo channel coefficient difference
when one of the channels coefficients are all zero.
Therefore add a flag to use pure coefficients in that case.
TNS is the only thing touching the coefficients before IS
so common window prediction will not take that into account
but the effect of the TNS filter per coefficient can be small
(a few percent) so to some approximation it's fine to just
ignore that.
Also fixed a small error which doesn't alter the results
that much. pow(sqrt(number), 3.0/4.0) == pow(number, 3.0/8.0) !=
pow(number, 3.0/4.0).
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
