[FFmpeg-devel] [PATCH 01/13] lavu/frame: extend AVFrame.repeat_pict documentation

[Anton Khirnov]

Quoting Kieran Kunhya (2023-05-07 18:59:22)
> On Sun, 7 May 2023, 14:34 Anton Khirnov, <anton at khirnov.net> wrote:
> 
> > ---
> >  libavutil/frame.h | 18 ++++++++++++++++--
> >  1 file changed, 16 insertions(+), 2 deletions(-)
> >
> > diff --git a/libavutil/frame.h b/libavutil/frame.h
> > index f2b56beebb..ed3f199ce1 100644
> > --- a/libavutil/frame.h
> > +++ b/libavutil/frame.h
> > @@ -491,8 +491,22 @@ typedef struct AVFrame {
> >      void *opaque;
> >
> >      /**
> > -     * When decoding, this signals how much the picture must be delayed.
> > -     * extra_delay = repeat_pict / (2*fps)
> > +     * Number of fields in this frame which should be repeated, i.e. the
> > total
> > +     * duration of this frame should be repeat_pict + 2 normal field
> > durations.
> > +     *
> > +     * For interlaced frames this field may be set to 1, which signals
> > that this
> > +     * frame should be presented as 3 fields: beginning with the first
> > field (as
> > +     * determined by AV_FRAME_FLAG_TOP_FIELD_FIRST being set or not),
> > followed
> > +     * by the second field, and then the first field again.
> > +     *
> > +     * For progressive frames this field may be set to a multiple of 2,
> > which
> > +     * signals that this frame's duration should be (repeat_pict + 2) / 2
> > +     * normal frame durations.
> 
> 
> This isn't correct, a progressive [coded] frame is allowed to have its
> first field repeated.
> 
> There is a difference between the coded type and the display method of a
> frame. The documentation suggests otherwise.

In my understanding the AVFrame interlacing flag relates to how the
decoded frame is supposed to be treated (displayed or processed). It
says nothing about how the frame was coded or what source it comes from.

-- 
Anton Khirnov