[MPlayer-dev-eng] [PATCH] af_scaletempo

[Robert Juliano]

On Sun, Oct 07, 2007 at 05:04:43AM +0300, Uoti Urpala wrote:
> On Sat, 2007-10-06 at 20:05 -0400, Robert Juliano wrote:
> > On Sat, Oct 06, 2007 at 10:26:01PM +0300, Uoti Urpala wrote:
> > > I think it's better to fix some of the general filter issues before
> > > adding the filter. It buffers more data internally than than the
> > > existing resample filters.
> > 
> > Yeah, and it uses more memory than format and more CPU than
> > channels?  I don't see the relevance of the comparison.
> 
> 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?

> > > - enable the filter delay logic again and dynamically set the delay
> > > value in af_scaletempo after each call
> > 
> > Unless someone shows me otherwise, delay = 0.  The way the
> > filter works is by consuming input at a scaled rate and output
> > at the nominal rate or it can be viewed as skipping forwards
> > or backwards every few milliseconds.  I'm not sure delay even
> > makes sense in this context.
> 
> 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?

> (that's assuming the average rates are exact; MPlayer could cope with a
> filter with identical nominal input and output rate outputting 999
> samples for each 1000 read, but it'd require a different definition
> here). Most of the time it is not 0: if you feed input one sample at a
> time there will be no output at first (increasing delay) then a bigger
> output block at once (delay drops again).

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?

> 
> >   And if it's disabled, what does
> > it have to do with adding a filter today?
> 
> Ignoring delay doesn't matter that much with existing commonly used
> filters which do not cause much delay. However if I read the code
> correctly scaletempo has typical delay values varying by 60 ms, which is
> quite a lot when video frame timing is based on audio position.

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

robert