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

[Stefano Sabatini]

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...

Regards.
-- 
FFmpeg = Fancy Fiendish Minimal Pitiless Esoteric Gigant