On 21/12/2020 06:07, Nuo Mi wrote:
---
libavcodec/h266.h | 121 ++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 121 insertions(+)
create mode 100644 libavcodec/h266.h
diff --git a/libavcodec/h266.h b/libavcodec/h266.h
new file mode 100644
index 0000000000..d5793b76fc
--- /dev/null
+++ b/libavcodec/h266.h
@@ -0,0 +1,121 @@
+/*
+ * H.266 shared code
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#ifndef AVCODEC_H266_H
+#define AVCODEC_H266_H
+
+/**
+ * Table 5 – NAL unit type codes and NAL unit type classes in
+ * T-REC-H.266-202008
+ */
+enum H266NALUnitType {
You don't use this type name anywhere. I don't think there is any use in
including it.
+ H266_NAL_TRAIL = 0,
Probably clearer as H266_NAL_UNIT_TYPE_FOO or H266_NUT_FOO?
+ H266_NAL_STSA = 1,
+ H266_NAL_RADL = 2,
+ H266_NAL_RASL = 3,
+ H266_NAL_RSV_VCL_4 = 4,
+ H266_NAL_RSV_VCL_5 = 5,
+ H266_NAL_RSV_VCL_6 = 6,
+ H266_NAL_IDR_W_RADL = 7,
+ H266_NAL_IDR_N_LP = 8,
+ H266_NAL_CRA_NUT = 9,
+ H266_NAL_GDR_NUT = 10,
+ H266_NAL_RSV_IRAP_11 = 11,
+ H266_NAL_OPI = 12,
+ H266_NAL_DCI = 13,
+ H266_NAL_VPS = 14,
+ H266_NAL_SPS = 15,
+ H266_NAL_PPS = 16,
+ H266_NAL_PREFIX_APS = 17,
+ H266_NAL_SUFFIX_APS = 18,
+ H266_NAL_PH = 19,
+ H266_NAL_AUD = 20,
+ H266_NAL_EOS_NUT = 21,
+ H266_NAL_EOB_NUT = 22,
The redundant _NUT suffixes are inconsistent.
+ H266_NAL_PREFIX_SEI = 23,
+ H266_NAL_SUFFIX_SEI = 24,
+ H266_NAL_FD_NUT = 25,
+ H266_NAL_RSV_NVCL_26 = 26,
+ H266_NAL_RSV_NVCL_27 = 27,
+ H266_NAL_UNSPEC_28 = 28,
+ H266_NAL_UNSPEC_29 = 29,
+ H266_NAL_UNSPEC_30 = 30,
+ H266_NAL_UNSPEC_31 = 31,
+};
+
+enum H266SliceType {
This type name too.
+ H266_SLICE_B = 0,
H266_SLICE_TYPE_B
+ H266_SLICE_P = 1,
+ H266_SLICE_I = 2,
+};
+
+enum {
+ H266_MAX_PLANES = 3,
+ //7.4.3.3 The value of vps_max_sublayers_minus1 shall be in the range of 0
to 6, inclusive
+ H266_MAX_SUB_LAYERS = 7,
+
+ // 7.3.2.3: vps_video_parameter_set_id is u(4).
+ H266_MAX_VPS_COUNT = 16,
+ // 7.3.2.4: sps_seq_parameter_set_id is in [0, 15].
It's u(4), not a stated constraint. (Unlike in H.264, where these ids very
ue(v) with a constraint in the text.)
+ H266_MAX_SPS_COUNT = 16,
+ // 7.3.2.5: pps_pic_parameter_set_id is in [0, 63].
u(6)
+ H266_MAX_PPS_COUNT = 64,
+
+ // A.4.2: MaxDpbSize is bounded above by 16.
The definition in terms of maxDpbPicBuf is clearer than it was in H.265, so I
think say that rather than just the result.
+ H266_MAX_DPB_SIZE = 16,
+
+ //7.4.3.4 sps_num_ref_pic_lists in range [0, 64]
+ H266_MAX_REF_PIC_LISTS = 64,
+
+ //7.4.3.3 sps_num_points_in_qp_table_minus1[i] in range [0, 36 −
sps_qp_table_start_minus26[i]],
+ //sps_qp_table_start_minus26[i] in range [sps_qp_table_start_minus26[i]
−26 − QpBdOffset, 36]
+ //for 10 bitsQpBdOffset is 12, so sps_num_points_in_qp_table_minus1[i] in
range [0, 74]
+ H266_MAX_POINTS_IN_QP_TABLE = 75,
+
+ // 7.4.6.1: hrd_cpb_cnt_minus1 is in [0, 31].
+ H266_MAX_CPB_CNT = 32,
+
+ // A.4.1: in table A.6 the highest level allows a MaxLumaPs of 35 651 584.
Table A.1 is the reference for MaxLumaPs. (Table A.6 is only informative,
though this value does appear for 8K.)
+ H266_MAX_LUMA_PS = 35651584,
+ // A.4.1: pic_width_in_luma_samples and pic_height_in_luma_samples are
+ // constrained to be not greater than sqrt(MaxLumaPs * 8). Hence height/
+ // width are bounded above by sqrt(8 * 35651584) = 16888.2 samples.
+ H266_MAX_WIDTH = 16888,
+ H266_MAX_HEIGHT = 16888,
+
+ // A.4.1: table A.1 allows at most 20 tile rows for any level.
No it doesn't? I don't see any reference to tile rows in table A.1.
+ H266_MAX_TILE_ROWS = 20, > + // A.4.1: table A.1 allows at most 20
tile columns for any level.
+ H266_MAX_TILE_COLUMNS = 20,
+
+ // A.4.1 table A.1 allows at most 600 slice for any level.
+ H266_MAX_SLICES = 600,
+
+ // 7.4.8: in the worst case (tiles_enabled_flag and
+ // entropy_coding_sync_enabled_flag are both set), entry points can be
+ // placed at the beginning of every Ctb row in every tile, giving an
+ // upper bound of (num_tile_columns_minus1 + 1) * PicHeightInCtbsY - 1.
+ // Only a stream with very high resolution and perverse parameters could
+ // get near that, though, so set a lower limit here with the maximum
+ // possible value for 8K video (at most 135 32x32 Ctb rows).
Is this text copied from H.265 still accurate? NumEntryPoints is implicitly
calculated rather than appearing in the bitstream here.
+ H266_MAX_ENTRY_POINT_OFFSETS = H266_MAX_TILE_COLUMNS * 135,
+};
+
+#endif /* AVCODEC_H266_H */
- Mark
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
