[PATCH] libavfilter: add atempo filter (revised patch v5)

headers Nicolas George | 13 Jun 2012 19:46

Le sextidi 26 prairial, an CCXX, Pavel Koshevoy a écrit :
> Why is it redundant?  I need to know the sample format in order to
> operate on samples of various types (unsigned char, short int, int,
> float, double).

You have the format in ctx->inputs[0]->format (and idem with outputs).

> You've stated that the PTS has to be consistent with playback
> duration, which in my understanding is a sum of samples output so
> far.  I admit the above calculation assumes 0 PTS as input stream
> origin.  I'll see what I can do to accommodate streams that start
> from non-0 PTS.

I'll alter slightly my statement: the output timestamps must be consistent
with playback duration if the input timestamps are.

The catch is when samples are recorded from a device, for example: we have
timestamps that are based on the real time, and can differ from the
timestamps derived from the sample rate first by some amount of noise (but
if we can eliminate it, so much the better), and second and more important
by an hopefully constant ratio: the clock of a sound card can be slightly
fast or slow (my ICH10 outputs 47998 samples per second when 48000 are
requested, for example, and my old sound card 48003).

> The difficulty is that this filter is meant to be used interactively
> -- user may seek (this affects input stream PTS origin) or change
> tempo at any time.  Suggestions for handling these scenarios
> gracefully are welcome.

That requires, indeed, some planning.

IMHO, in the simple case where the tempo is unchanged, we should simply have
out->pts = in->pts / tempo (expressed as floats, of course it requires
adjustment for integers and time_base); that way, a simple setpts filter can
du the same adjustment on the video stream and keep sync.

In the more complex cases, when the tempo changes, the correct way is
probably to do something that is continuous and piecewise affine. In other
words, out->pts = in->pts + delta, where delta starts at 0 and is recomputed
when the tempo changes to ensure continuity.

But do not consider this a blocker: the filter is already useful by itself
like that, if someone needs timestamps for something, they can write the
patch.

Regards,

--

-- 
  Nicolas George

Re: [PATCH] libavfilter: add atempo filter (revised patch v5)