[FFmpeg-devel] [PATCH] Add a time_base field to AVFilterPad.

Stefano Sabatini stefano.sabatini-lala
Tue Sep 28 02:34:05 CEST 2010


On date Monday 2010-09-27 23:28:47 +0200, Stefano Sabatini encoded:
> On date Thursday 2010-07-22 00:47:32 +0200, Stefano Sabatini encoded:
> > On date Wednesday 2010-07-21 21:12:04 +0200, Michael Niedermayer encoded:
> > > On Wed, Jul 21, 2010 at 05:56:27PM +0200, Stefano Sabatini wrote:
> > [...]
> > > > I did more tests and I noticed this problem.
> > > > 
> > > > In the case of a filterchain of the kind:
> > > > 
> > > > buffer -> filter -> ffmpeg_output
> > > > 
> > > > After configuration this results like this:
> > > > 
> > > > buffer [TB1] <-> [TB1] filter [AVTB] <-> [TB1] ffmpeg_output
> > > > 
> > > > while I want to avoid conversions, that is I want this:
> > > > 
> > > > buffer [TB1] <-> [TB1] filter [TB1] <-> [TB1] ffmpeg_output
> > > > 
> > > > This is done configuring by default the output link to make it use the
> > > > same timebase of the *first* input pad if it exists.
> > > 
> > > by default the output tb should be choose so that all input timestamps can be
> > > exactly represented or if this timebase exceeds 32/32bit then AVTB
> > > 
> > > and (inexact) convertion should of course be avoided when possible as its
> > > a recipe for turning timestamps into non strictly increasing sequences
> > > and that will cause problems at the muxer
> > 
> > Note that this isn't possible when configuring each single link, as
> > that requires a global knowledge of the whole filtergraph.
> > 
> > We may still do that as a post configuration operation, for example we
> > could have a sort of avfilter_graph_reconfigure_timebases().
> > 
> > Note that even in this scenario we may have some filter for which the
> > timebase is assumed to be not changeable (e.g. a source which computes
> > the time base depending on the frame rate set).
> > 
> > We may auto-insert some settb filters to manage that, and we would
> > need to define a policy to determine when the timebase can be changed
> > and when not (and we still lack a re-configuration mechanism).
> > 
> > Note that for the use in ffmpeg.c/ffplay.c this practically is not an
> > issue, as most filters (with the only settb exception) don't change
> > the time base, so with this patch we end up with all the filters in
> > the linear sequence from the input source to the output sink using the
> > same time base, with no information loss, so I suggest to apply this
> > patch.
> 
> Patch updated. I'll try to find an acceptable solution in the next
> days...

So we have this scenario:

buffer [TB1] <-> [X] filter [Y] <-> [Z] ffmpeg_output

Z can be set using the TB provided in the output video stream, so we
have:

buffer [TB1] <-> [X] filter [Y] <-> [TB2] ffmpeg_output

Now the problem is how to make filter choose X and Y as timebase,
requirements are that we want to avoid unnecessary conversions if can
be avoided and we want the conversion if unavoidable to be lossless.

During configuration then we start configuing the filter output link,
the logical choice here looks like to use the same timebase as set in
the destination pad of the link if already set (as it should).

So we end up with:
(1)
buffer [TB1] <-> [X] filter [TB2] <-> [TB2] ffmpeg_output

If the input pad of the filter is already set then maybe we should use
the same TB as in the input pad, and we'll have:
(2)
buffer [TB1] <-> [TB3] filter [TB3] <-> [TB2] ffmpeg_output

but at this point we have no guarantee that the conversions TB1 -> TB3
and TB3 ->TB2 are exact. On the other hand we can have this
information only *after* the chain has been established, and so we may
have some form of re-configuration mechanism.

Now we have to choose X for scenario 1. In this case the best solution
looks like to use the same TB as the output pad, and we get:

(1.1)
buffer [TB1] <-> [TB2] filter [TB2] <-> [TB2] ffmpeg_output

even in this case we can't say if TB1 -> TB2 is exact.

So my questions are:
* is the described behavior acceptable?

* how can the reconfiguration for avoiding the PTS conversion loss be
  done? In this case I still have to figure out how to choose a
  timebase X if we have this sequence: TB1 <-> X <-> TB2.

Regards.
-- 
FFmpeg = Fabulous and Faithful Minimal Puritan Erudite Gadget



More information about the ffmpeg-devel mailing list