How does HEVC/H.265 support Interlaced Video?
This is a follow up post to the entry 'Does HEVC/H.265 support Interlaced video efficiency?'
As background information H.264/AVC allows for multiple techniques to be used:
Allows for static "frame coding", where the 2 pictures (fields) are combined together to create a single picture and encode as one.
Allows for static "field coding", where the 2 pictures (fields) are keep independently encode as two individual pictures.
Allows for “picture adaptive frame-field (PAFF) [JVT-B071], where the encoder can decide at every picture if to use frame coding or field coding.
Allows for “Macro-block adaptive frame-field (MBAFF) [JVT-B106], where the encoder can decide at every Macro-block if to use frame coding or field coding.
In general, pictures with low motion favored frame coding.
In general, fast action pictures favored field coding.
Generally Frame or Field coding alone are not a good options. It is best to adapt to changes from one type to the other. There are 3 options: at the sequence level (where motion changes), at the picture level or at the MB level (in case of mixed motion).
The HEVC specification allows for:
Static "frame coding", where the 2 pictures (fields) are combined together to create a single picture and encode as one.
Static "field coding", where the 2 pictures (fields) are keep independently encode as two individual pictures.
“Sequence adaptive frame-field", where the encoder can decide at every sequence if to use frame coding or field coding a sequence can be signalled at any picture. Field-Frame sequence based signalling could be considered similar to what is available on H.264/AVC by using PAFF, but with the constraint that it is required to have a new sequence and it has a penalty associated with that.
HEVC does not allow Block level (CTB based) adaptive frame-field as MBAFF in H.264/AVC as the complexity-performance trade-off was consider too high to be included on the HEVC specification and interlace coding was better understood after many years of using the interlace coding tools available on H.264/AVC [JVT-B071] [JVT-B106].
HEVC has the following SEI messages to indicate Interlace or Progressive:
source_scan_type equal to 1 indicates that the source scan type of the associated picture should be interpreted as progressive or source_scan_type equal to 0 indicates that the source scan type of the associated picture should be interpreted as interlaced.
pic_struct: in essence, conveys the meaning of the coded picture in terms of both how it was captured and how it is intended to be output after decoding, this is similar to how it was in H.264/AVC.
duplicate_flag equal to 1 indicates that the current picture is indicated to be a duplicate of a previous picture in output order or duplicate_flag equal to 0 indicates that the current picture is not indicated to be a duplicate of a previous picture in output order.
By using this SEI messages it is possible to support the commonly interlace use cases, including the pure progressive, the inter-leaved frame coding (bottom or top), the pure field coding (bottom or top), the progressive field sequence (bottom or top) and the duplicate (i.e 3:2 pull down) uses cases.
JVT-B071, Adaptive Frame/Field Coding for JVT, JVT Document JVT-B071, January 2002
JVT-B106, MB-Level Adaptive Frame/Field Coding for JVT. JVT Document JVT-B106, January 2002
JVT-B001, draft 5 JVT 2nd Meeting Report, Document JVT-B001, Feb 1 2002
JVT-C139, Macroblock Adaptive Frame/Field Coding for Interlace Sequences, May, 2002