On Tue, Jan 28, 2014 at 9:41 AM, Robert Krüger <[email protected]> wrote: > On Mon, Jan 27, 2014 at 4:19 PM, Vittorio Giovara > <[email protected]> wrote: > > 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).
That's an interesting topic, do you have any h264 sample encoded in psf mode? I noticed this feature is also available in many other codecs, but implementing support for them should be in a separate patchset. > 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? Technically frames are interlaced, but they should not be treated as such because content is progressive, so it's quite difficult to signal. I'd be tempted to mark them as progressive for simplicity, but that wouldn't help applications. Maybe a new field could be introduced (like the one you propose) which is *not* bitmask-compatible with AV_FRAME_INTERLACED; I'm not sure it's worth/necessary to also keep the field information of the current frame (tff/bff). What does the group think about this? Vittorio _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
