[FFmpeg-devel] [PATCH 2/4] Change the PTS time base to AV_TIME_BASE before to process a frame in the filter chain, and change it back to the stream time base in the filtered frame.
Stefano Sabatini
stefano.sabatini-lala
Thu Jul 22 00:47:32 CEST 2010
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.
Regards.
--
FFmpeg = Fierce and Friendly Mastodontic Portentous Erratic Generator
More information about the ffmpeg-devel
mailing list