aboutsummaryrefslogtreecommitdiffstats
path: root/libavcodec/h264_ps.h
diff options
context:
space:
mode:
authorAnton Khirnov <anton@khirnov.net>2016-07-02 16:48:26 +0200
committerAnton Khirnov <anton@khirnov.net>2016-07-11 16:29:57 +0200
commita8cbe5a0ccebf60a8a8b0aba5d5716dd54c1595c (patch)
tree95f33fe4d224c4a718bb204c02dbc25028fc42a8 /libavcodec/h264_ps.h
parent99cf943339a2e5171863c48cd1a73dd43dc243e1 (diff)
downloadffmpeg-a8cbe5a0ccebf60a8a8b0aba5d5716dd54c1595c.tar.gz
h264_ps: export actual height in MBs as SPS.mb_height
Currently, SPS.mb_height is actually what the spec calls PicHeightInMapUnits, which is half the frame height when interlacing is allowed. Calling this 'mb_height' is quite confusing, and there are at least two associated bugs where this field is treated as the actual frame height - in the h264 parser and in the code computing maximum reordering buffer size for a given level. Fix those issues (and avoid possible future ones) by exporting the real frame height in this field.
Diffstat (limited to 'libavcodec/h264_ps.h')
-rw-r--r--libavcodec/h264_ps.h3
1 files changed, 2 insertions, 1 deletions
diff --git a/libavcodec/h264_ps.h b/libavcodec/h264_ps.h
index 2835b870ca..9a32d932f7 100644
--- a/libavcodec/h264_ps.h
+++ b/libavcodec/h264_ps.h
@@ -56,7 +56,8 @@ typedef struct SPS {
int ref_frame_count; ///< num_ref_frames
int gaps_in_frame_num_allowed_flag;
int mb_width; ///< pic_width_in_mbs_minus1 + 1
- int mb_height; ///< pic_height_in_map_units_minus1 + 1
+ ///< (pic_height_in_map_units_minus1 + 1) * (2 - frame_mbs_only_flag)
+ int mb_height;
int frame_mbs_only_flag;
int mb_aff; ///< mb_adaptive_frame_field_flag
int direct_8x8_inference_flag;