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

[Michael Niedermayer]

On Tue, Sep 28, 2010 at 02:34:05AM +0200, Stefano Sabatini wrote:
> 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

X=TB1
Y=X unless filter wants something else
Z=Y
ffmpeg has to configure itself to use Z or rescale, there never is a timebase
moving backward in the graph

or in other words i fail to see where the problem you seem to have comes from
but i might be missing something of course

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Frequently ignored awnser#1 FFmpeg bugs should be sent to our bugtracker. User
questions about the command line tools should be sent to the ffmpeg-user ML.
And questions about how to use libav* should be sent to the libav-user ML.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100928/915c8f35/attachment.pgp>