summaryrefslogtreecommitdiff
path: root/libavcodec/h264_ps.c
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.c
parent99cf943339a2e5171863c48cd1a73dd43dc243e1 (diff)
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.c')
-rw-r--r--libavcodec/h264_ps.c10
1 files changed, 9 insertions, 1 deletions
diff --git a/libavcodec/h264_ps.c b/libavcodec/h264_ps.c
index 4a56c738bf..d1b4280713 100644
--- a/libavcodec/h264_ps.c
+++ b/libavcodec/h264_ps.c
@@ -439,6 +439,15 @@ int ff_h264_decode_seq_parameter_set(GetBitContext *gb, AVCodecContext *avctx,
sps->gaps_in_frame_num_allowed_flag = get_bits1(gb);
sps->mb_width = get_ue_golomb(gb) + 1;
sps->mb_height = get_ue_golomb(gb) + 1;
+
+ sps->frame_mbs_only_flag = get_bits1(gb);
+
+ if (sps->mb_height >= INT_MAX / 2) {
+ av_log(avctx, AV_LOG_ERROR, "height overflow\n");
+ goto fail;
+ }
+ sps->mb_height *= 2 - sps->frame_mbs_only_flag;
+
if ((unsigned)sps->mb_width >= INT_MAX / 16 ||
(unsigned)sps->mb_height >= INT_MAX / 16 ||
av_image_check_size(16 * sps->mb_width,
@@ -447,7 +456,6 @@ int ff_h264_decode_seq_parameter_set(GetBitContext *gb, AVCodecContext *avctx,
goto fail;
}
- sps->frame_mbs_only_flag = get_bits1(gb);
if (!sps->frame_mbs_only_flag)
sps->mb_aff = get_bits1(gb);
else