af_scaletempo kept outdated values in the af->delay field after
reconfiguration until some audio was fed through the filter. This
could affect audio sync code after a playback speed change.
Additionally, in the special case speed=1 the code did not set the
af->mul field at all. Initialize both fields after reconfiguration.
This crash happened when audio channels were reconfigured from 6
channels to 2, and playback speed was set to 2.
The crash is caused by passing a negative size to memcpy. It appears
reinitialization doesn't clear the buffer. As the result, the buffer
can be larger as the maximum buffer size, i.e. the invariant
bytes_queued <= bytes_queue is violated.
Fix this by resetting the buffer length on reconfiguring (set the
bytes_queued vairable to 0). Also reset some other state for clarity
and robustness, although these changes aren't strictly needed for
avoiding the actual crash.
This may also get rid of some noise played right after reinitialization,
as the re-used buffer was in the wrong audio format.
Tweak some code parts that used to rely on string literals from
translation macros being concatenated with other adjacent string
literals. Break up the resulting string into independently translated
parts, so that the existing translations for those parts can still be
used.
The scaletempo filter has a special-case check to return the samples
unchanged if the current scaling factor is 1. In this case code
setting af->delay wasn't run. If the scale had had a different value
and then been changed to 1 as a result of a playback speed change then
the delay field could have a nonzero value left, resulting in A/V sync
errors. Fix by setting the delay field to 0 in the scale == 1 special
case code.
Changing the way the loop is done is necessary to reduce register pressure.
About 20% speedup even on 32 bit x86.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@25103 b3059339-0415-0410-9bf9-f77b7e298cf2
Just removing the += s->samples_overlap - s->num_channels; still provides a
ca. 20% speedup on x86 (AThlon X2 64) with gcc 3.4 (compiler stupidity?)
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@25102 b3059339-0415-0410-9bf9-f77b7e298cf2
Substract the delay caused by filter buffering when calculating
currently playing audio position. This matters for af_scaletempo which
buffers significant and varying amounts of data. For other current
filters the effect is normally insignificant.
Instead of the old time-based filter delay field (which was ignored)
this version stores the per-filter delay in units of bytes input read
without corresponding output. This allows the current scaletempo
behavior where other filters before and after it can see the same
nominal samplerate even though the real duration of the data varies;
in this case the other filters can not know the delay they're causing
in terms of real time.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@24928 b3059339-0415-0410-9bf9-f77b7e298cf2
Make internal functions static and remove leading '_' from some
function names. Cast pointers to compatible 8-bit pointer types
instead of ints when calculating their difference.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@24927 b3059339-0415-0410-9bf9-f77b7e298cf2
The value of the "speed" suboption was not initialized before calling
subopt_parse(). If the command line had suboptions but "speed" was not
one of them then the code accessed an uninitialized pointer and
possibly crashed. Fixed by initializing the option value.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@24926 b3059339-0415-0410-9bf9-f77b7e298cf2
Because of a missing *num_channels factor the filter copied audio from
an incorrect position. This mixed up the channel order and hurt audio
quality even if the channels had identical content.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@24925 b3059339-0415-0410-9bf9-f77b7e298cf2
Stefano Pigozzi
Uoti Urpala
wm4
Uoti Urpala
Amar Takhar
bircoph
diego
reimar
uau