Ability to identify progressive segmented frame material in h.264

[rmk]

It is desirable to be able to identify progressive segmented frame (PsF) material (i.e. a progressively scanned frame encoded as two fields with the same timestamp) in an h.264 stream as that gives applications using libavcodec the possibility to correctly report to the user that the underlying material is really progressive and no deinterlacing makes sense.

From the h.264 spec:
clock_timestamp_flag[ i ] equal to 1 indicates that a number of clock timestamp syntax elements are present and follow immediately. clock_timestamp_flag[ i ] equal to 0 indicates that the associated clock timestamp syntax elements are not present. When NumClockTS is greater than 1 and clock_timestamp_flag[ i ] is equal to 1 for more than one value of i, the value of clockTimestamp shall be non-decreasing with increasing value of i.
ct_type indicates the scan type (interlaced or progressive) of the source material as follows:
Two fields of a coded frame may have different values of ct_type.
When clockTimestamp is equal for two fields of opposite parity that are consecutive in output order, both with ct_type equal to 0 (progressive) or ct_type equal to 2 (unknown), the two fields are indicated to have come from the same original progressive frame. Two consecutive fields in output order shall have different values of clockTimestamp when the value of ct_type for either field is 1 (interlaced).

AFAICS in the code in h264.c the information required to make that determination is not parsed, which should not be difficult to add. However, once one has that information, how do I give this back to the API user? Currently there is only the field top_field_first in AVFrame.

What would be the recommended/accepted way of modeling this? If no API change would be accepted for this, would it be ok to sets this as frame metadata via av_frame_set_metadata?

[Carl Eugen Hoyos]

Replying to rmk:

What would be the recommended/accepted way of modeling this? If no API change would be accepted for this, would it be ok to sets this as frame metadata via av_frame_set_metadata?

Maybe write a PoC for the method that you prefer and works in your application and post it to ffmpeg-devel?

[Balling]

You mean like in here? #6588 File tagged as progressive but has fields. Anyway, this is just soft telecine, and hevc needs it too.