[MPlayer-dev-eng] [PATCH] af_scaletempo

Uoti Urpala uoti.urpala at pp1.inet.fi
Sun Oct 7 21:11:29 CEST 2007


On Sun, 2007-10-07 at 12:53 -0400, Robert Juliano wrote:
> On Sun, Oct 07, 2007 at 05:04:43AM +0300, Uoti Urpala wrote:
> > That behavior triggers problems elsewhere in MPlayer's filter system.
> > The existing filters are not as badly affected.
> 
> What do I need to do to make these problems visible?

6-channel playback should trigger the buffer problems in most cases.
Exact situation depends on audio bitrate, audio decoder behavior, audio
output buffering and video FPS. You'll see lots of messages like
"4356 bytes of audio data lost due to buffer overflow", with choppy
audio and possibly lost sync.

> > In this context delay can be defined as
> > total_bytes_input/input_bitrate-total_bytes_output/output_bitrate
> 
> For reference, what's the definition normally?

Basically it's supposed to measure how much audio is buffered inside the
filter, or the difference between the timestamp at the end of input and
the timestamp at the end of output. For resample filters and scaletempo
input has to be scaled to match the conversion rate.

> What effect on delay would samples that get skipped or repeated?
> It may buffer 60 ms, but then play each sample 3 times (1/3x), or
> it may play them once and skip 120 ms (3x).
> 
> And what effect, if any, does best_offset have?

The biggest problem is not exactly how parts of output correspond to
parts of input, but the inconsistency of the timestamps when the delay
in the filter is ignored. The relevant part of MPlayer's audio position
calculation is
playing_timestamp = timestamp_at_end_of_decoded_data - unplayed_amount.
When unplayed_amount ignores the data buffered in the filter a decoding
call can make the calculated "currently playing position" jump around as
the hidden delay changes. For example if you feed the filter a little
data but it empties the buffer and outputs a lot more then the audio
position goes backwards: timestamp_at_end_of_decoded_data didn't change
much but unplayed_amount (in buffers taken into account) increased a
lot.

> Again, what do I need to do make this problem visible/audible?

The effects on video depend on sync settings. To see when the problems
occur it's enough to look at the A-V value on the status line. It'll
jump around when scaletempo is active.




More information about the MPlayer-dev-eng mailing list