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

[Michael Niedermayer]

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

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

Observe your enemies, for they first find out your faults. -- Antisthenes
-------------- 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/20101010/871ceff9/attachment.pgp>