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

[Michael Niedermayer]

On Sun, Oct 10, 2010 at 12:05:56PM +0200, Stefano Sabatini wrote:
> 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.

no, the input cannot be set, like you cannot set the input pts or the input
being interlaced. the input tb is a property of the input

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

If you really think that XML is the answer, then you definitly missunderstood
the question -- Attila Kinali
-------------- 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/be3f2dcd/attachment.pgp>