On Mon, Jan 27, 2014 at 4:19 PM, Vittorio Giovara <[email protected]> wrote: > --- > libavutil/frame.h | 18 ++++++++++++++++++ > libavutil/version.h | 2 +- > 2 files changed, 19 insertions(+), 1 deletion(-) > > diff --git a/libavutil/frame.h b/libavutil/frame.h > index 5b04291..fd02ded 100644 > --- a/libavutil/frame.h > +++ b/libavutil/frame.h > @@ -74,6 +74,19 @@ typedef struct AVFrameSideData { > } AVFrameSideData; > > /** > + * AVFieldState describes the interlacing mode of a frame (if any). > + * You can quickly check if a frame is interlaced using AV_FRAME_INTERLACED > + * as a bitmask. > + */ > +enum AVFieldState { > + AV_FRAME_UNKNOWN = 0x02, //< unknown frame field information > + AV_FRAME_INTERLACED = 0x01, //< interlaced frame, unknown field mode > + AV_FRAME_INTERLACED_TFF = 0x03, //< interlaced frame, top field first > + AV_FRAME_INTERLACED_BFF = 0x05, //< interlaced frame, bottom field field > + AV_FRAME_PROGRESSIVE = 0x04, //< progressive frame > +};
just out of curiosity, what would be correct to expect for a frame that was decoded from progressive segmented frame material? I am asking because it would be nice to be able to detect that as an API user and with current (old) API this is not possible (and I am not aware of it being checked for for any codec but it is AFAICS at least doable for h.264, see http://trac.ffmpeg.org/ticket/1679). So IMHO the choices here would be, 1) it should be flagged as AV_FRAME_PROGRESSIVE because for all practical purposes it is (i.e. the frame data needs no deinterlacing) 2) a new constant AV_FRAME_INTERLACED_PSF should be introduced leaving the information that the frame was decoded from a bitstream that is indeed technically stored as interlaced but with fields of one frame having the same timestamps (basically the definition of PsF). What is your opinion on this? _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
