The 3GPP spec uses the following calculation for high spreading:
thr'_spr = max(thr_scaled, s_h(n) * thr_scaled(n-1))
where, n is defined as the current band, and s_h() is defined as "[...] the
distance of adjacent bands in Bark and a constant slope that is 15 dB/Bark
[...]". This is a little ambiguous as you would assume you want the Bark
width of the previous band for this calculation. However, this assumption
appears to be incorrect, and you really want the Bark width of the current
band. Coincidentally this is exactly what the spec calls for! =P
This noticeably improves Tom's Diner at low bitrates (I tested at 64kbps,
with mid/side disabled).
Patch by: Nathan Caldwell <saintdev@gmail.com>
Originally committed as revision 25622 to svn://svn.ffmpeg.org/ffmpeg/trunk
These blocks depended on the compiler keeping xmm registers untouched between
them.
Originally committed as revision 25619 to svn://svn.ffmpeg.org/ffmpeg/trunk
suncc does not like the leading commas inside the macro, but it has no problem
with trailing commas.
Originally committed as revision 25615 to svn://svn.ffmpeg.org/ffmpeg/trunk
This greatly improves bitrate handling. You will now get within a few
kbps of your requested bitrate instead of 20-40kbps higher.
There is absolutely no analog to this line in the 3GPP spec, that I
can find.
patch by Nathan Caldwell saintdev (at) gmail
Originally committed as revision 25589 to svn://svn.ffmpeg.org/ffmpeg/trunk
Removing the modification vastly improves quality (at a slight bitrate
cost) for some samples. castanets.wav is a good example. The closest
equivalent I see to the modification in the 3GPP spec is a similar
modification (over a specific frequency range) when TNS is used.
This also changes the threshold-in-quiet calculation to match the
3GPP spec.
patch by Nathan Caldwell saintdev (at) gmail
Originally committed as revision 25588 to svn://svn.ffmpeg.org/ffmpeg/trunk
According to the 3GPP spec:
"Thus the pre-echo control is inactive for the first short window (but
not all short windows in a short frame) after a start block and for
all frames with a stop window sequence."
Currently, pre-echo control is only run when the current frame is not
a short frame, and the previous frame is not a short frame.
patch by Nathan Caldwell saintdev (at) gmail
Originally committed as revision 25587 to svn://svn.ffmpeg.org/ffmpeg/trunk
Reading 7 bits as an unsigned int can't result in a value exceeding 127.
Accordingly, remove error message (as it'll never be reached).
Originally committed as revision 25575 to svn://svn.ffmpeg.org/ffmpeg/trunk
Bug caused by the fact that get_bits(gb, 0) is undefined.
Doesn't affect any streams generated by the official Theora encoder, but such
streams are nevertheless valid.
Fixes decoding of CELT-933dd833-nmr-bandt.ogv.
Originally committed as revision 25573 to svn://svn.ffmpeg.org/ffmpeg/trunk
Do decode init in the init function instead of at the first frame.
Fix some possible crash cases.
Originally committed as revision 25572 to svn://svn.ffmpeg.org/ffmpeg/trunk
Some code was initializing some xmm registers in one asm block and using them
in the following block, assuming they wouldn't be changed in between blocks.
Originally committed as revision 25568 to svn://svn.ffmpeg.org/ffmpeg/trunk
thus making forced key frames work.
Patch by Nicolas George, nicolas d george a normalesup d org
Originally committed as revision 25567 to svn://svn.ffmpeg.org/ffmpeg/trunk
I used the same loop counter for the inner and outer initalization loops.
This caused initalization to only run for the first channel. This in turn lead
to any channel other than the first using only short blocks.
Patch by Nathan Caldwell, saintdev at gmail
Originally committed as revision 25566 to svn://svn.ffmpeg.org/ffmpeg/trunk
Nathan Caldwell
Ramiro Polla
Michael Niedermayer
Jason Garrett-Glaser
Nicolas George
James Zern