[FFmpeg-devel] [PATCH] lavfi: add duration field to AVFilterBufferRef

[Stefano Sabatini]

On date Monday 2012-07-30 19:20:32 +0200, Nicolas George encoded:
> Le tridi 13 thermidor, an CCXX, Stefano Sabatini a écrit :
> > ---
> >  libavfilter/audio.c       |    1 +
> >  libavfilter/avcodec.c     |    2 ++
> >  libavfilter/avfilter.h    |    7 +++++++
> >  libavfilter/buffer.c      |    1 +
> >  libavfilter/f_settb.c     |   10 ++++++----
> >  libavfilter/vf_showinfo.c |    6 ++++--
> >  6 files changed, 21 insertions(+), 6 deletions(-)
> 
> I must say, after some thought since last time it was suggested, I am not
> completely sure it is such a good idea.
> 

> What happens with filters such as select? Is it supposed to wait for the
> next accepted frame in order to adjust the duration?

Uh, why? Expressions which only relies on the pts won't be affected by
the duration.

> And what if the duration and the next timestamp are inconsistent?
> 
> This is not an easy issue.

The current problem is that we lack the duration information, in case
of an ending stream we only have the last frame PTS, and the only way
to compute the duration of the last frame is by guessing. Also we
can't always assume *continuous* streams, we could have gaps inside a
video stream and with the current information we have no way to detect
them.

If case of duration / next timestamp inconsistency, they should be
addressed by each single filter. I expect that most filters will only
rely on the pts information, and we can fix the duration/pts
information with the setpts filter (and asetpts, which we still miss).

[...]
> > diff --git a/libavfilter/avfilter.h b/libavfilter/avfilter.h
> > index b7155a0..772d811 100644
> > --- a/libavfilter/avfilter.h
> > +++ b/libavfilter/avfilter.h
> > @@ -174,6 +174,13 @@ typedef struct AVFilterBufferRef {
> >      int perms;                  ///< permissions, see the AV_PERM_* flags
> >  
> >      enum AVMediaType type;      ///< media type of buffer data
> > +
> > +    /**
> > +     * duration timestamp. The time unit may change during filtering,
> > +     * as it is specified in the link and the filter code may need to
> > +     * rescale the duration accordingly.
> 
> Missing required information: is it mandatory? If not, what is the value to
> mean "unspecified"? AV_NOPTS_VALUE? 0?

Same semantic as the pkt_duration field in AVFrame, a duration of 0
means unspecified, a negative value should be regarded as invalid
(unless we have some use for a negative duration??). I'll update the
patch accordingly.

[...]
-- 
FFmpeg = Faithful and Fierce Miracolous Programmable Ecumenical Gem