Opened 5 years ago

Last modified 5 years ago

#1679 open enhancement

Ability to identify progressive segmented frame material in h.264

Reported by: rmk Owned by:
Priority: wish Component: avcodec
Version: git-master Keywords: h264
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

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?

Change History (1)

comment:1 in reply to: ↑ description Changed 5 years ago by cehoyos

  • Component changed from undetermined to avcodec
  • Keywords h264 added
  • Priority changed from normal to wish
  • Status changed from new to open
  • Version changed from unspecified to git-master

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?

Note: See TracTickets for help on using tickets.