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

Stefano Sabatini stefano.sabatini-lala
Sun Oct 10 12:05:56 CEST 2010


On date Sunday 2010-10-10 01:38:31 +0200, Michael Niedermayer encoded:
> On Sun, Oct 10, 2010 at 01:29:02AM +0200, Stefano Sabatini wrote:
> > On date Saturday 2010-10-09 16:03:23 +0200, Michael Niedermayer encoded:
> > > On Thu, Oct 07, 2010 at 03:03:38PM +0200, Stefano Sabatini wrote:
> > > > On date Thursday 2010-10-07 03:08:40 +0200, Michael Niedermayer encoded:
> > > > > On Wed, Oct 06, 2010 at 11:32:42PM +0200, Stefano Sabatini wrote:
> > > > > > On date Wednesday 2010-10-06 22:48:16 +0200, Michael Niedermayer encoded:
> > > > > > > On Wed, Oct 06, 2010 at 10:07:54PM +0200, Stefano Sabatini wrote:
> > > > [...]
> > > > > > > > BTW we need to set the timebase in the two ends of a link (either in
> > > > > > > > the link itself or in the input and output pads) if we want to keep
> > > > > > > > the timestamp conversion code in the framework rather than in the
> > > > > > > > filters code.
> > > > > > > 
> > > > > > > when does this design simplify filters?
> > > > > > > do you have an example?
> > > > > > > it seems simpler to have just one tb per link
> > > > > > 
> > > > > > A filter in general may to set the output timebase, and another filter
> > > > > > the input timebase.
> > > > > > 
> > > > > > Think for example of a source, which generates video frames with given
> > > > > > framerate, or a movie sink which needs to use the same timebase as set
> > > > > > in the muxer, so I believe this in general is a useful feature that we
> > > > > > want to keep.
> > > > > 
> > > > > the movie sink can contain that 1 line of code to rescale
> > > > > any other filters that would need that?
> > > > > 
> > > > > if not then this really seems the more logic approuch
> > > > 
> > > > The problem with the timebase in the link approach is that it may
> > > > require each filter to automatically check in start_frame()
> > > > if the input/output link timebases changes accordingly (so we'd have
> > > > to add code to many already existing filters).
> > > 
> > > timebases cannot change, not without reinitalizing the filters IMHO
> > 
> > No I wasn't clear, I mean that each start_frame() should check if
> > input timebase != output timebase and do the timebase conversion
> > accordingly.
> > 
> > Note that this will not be necessary most of the times as usually (but
> > for the settb filter) the input timebase is configured the same as the
> > output timebase.
> > 
> > Anyway that's not a big problem, as the conversion code is just two
> > lines and I already implemented the check+conversion in the default
> > start_frame() code (still waiting for your review).
> 
> This only affects filters that either have more than 1 input or that change
> the timebase themselfs. For normal 1 input, 1 output filters input and output
> timebase should match

Yes but in a filterchain filter N+1 may change its input timebase.

For example we could implement the settb filter to make it set the
timebase of its input link rather then the timebase of the output.

Regards.
-- 
FFmpeg = Friendly & Furious Mega Puritan Ephemeral God



More information about the ffmpeg-devel mailing list