[FFmpeg-devel] [PATCH v2 01/11] avcodec/vvc: add shared header for vvc

[Mark Thompson]

On 09/01/2021 07:34, Nuo Mi wrote:
> ---
>   libavcodec/vvc.h | 124 +++++++++++++++++++++++++++++++++++++++++++++++
>   1 file changed, 124 insertions(+)
>   create mode 100644 libavcodec/vvc.h
> 
> diff --git a/libavcodec/vvc.h b/libavcodec/vvc.h
> new file mode 100644
> index 0000000000..0bd2acac1d
> --- /dev/null
> +++ b/libavcodec/vvc.h
> @@ -0,0 +1,124 @@
> ...
> +
> +enum {
> +    VVC_MAX_PLANES = 3,

MAX_SAMPLE_ARRAYS, with reference to 6.2?  The term "plane" is never used in the specification at all.

> +    //7.4.3.3 The value of vps_max_sublayers_minus1 shall be in the range of 0 to 6, inclusive
> +    VVC_MAX_SUBLAYERS = 7,
> +
> +    // 7.3.2.3: vps_video_parameter_set_id is u(4).
> +    VVC_MAX_VPS_COUNT = 16,
> +    // 7.3.2.4: sps_seq_parameter_set_id is u(4)
> +    VVC_MAX_SPS_COUNT = 16,
> +    // 7.3.2.5: pps_pic_parameter_set_id is u(6)
> +    VVC_MAX_PPS_COUNT = 64,
> +
> +    // 7.4.4.1: ptl_num_sub_profiles is u(8)
> +    VVC_MAX_SUB_PROFILES = 256,
> +
> +    // A.4.2: according to (1577), MaxDpbSize is bounded above by 2 * maxDpbPicBuf(8)
> +    VVC_MAX_DPB_SIZE = 16,
> +
> +    //7.4.3.4 sps_num_ref_pic_lists in range [0, 64]
> +    VVC_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]
> +    VVC_MAX_POINTS_IN_QP_TABLE = 75,
> +
> +    // 7.4.6.1: hrd_cpb_cnt_minus1 is in [0, 31].
> +    VVC_MAX_CPB_CNT = 32,
> +
> +    // A.4.1: the highest level allows a MaxLumaPs of 35 651 584.
> +    VVC_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.
> +    VVC_MAX_WIDTH  = 16888,
> +    VVC_MAX_HEIGHT = 16888,
> +
> +    // A.4.1: table A.1 allows at most 440 tiles for any au.
> +    VVC_MAX_TILE_ROWS    = 440,

Is this bound really the best we can do?

That is, is it actually possible to construct a valid stream with 440 tile rows?  It must have a single tile column and a height of at least 14080 (for 440 rows of 32x32 CTUs), which feels extreme enough that it might hit some of the other level constraints.

> +    // A.4.1: table A.1 allows at most 20 tile columns for any level.
> +    VVC_MAX_TILE_COLUMNS = 20,
> +
> +    // A.4.1 table A.1 allows at most 600 slice for any level.
> +    VVC_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).
> +    VVC_MAX_ENTRY_POINTS = VVC_MAX_TILE_COLUMNS * 135,
> +};
> +
> +#endif /* AVCODEC_VVC_H */

- Mark