| Message ID | 20210109073421.23721-2-nuomi2021@gmail.com |
|---|---|
| State | Superseded |
| Headers | show |
| Series | add vvc raw demuxer, muxer, parser, metadata bsf, vvdec decoder | expand |
| Context | Check | Description |
|---|---|---|
| andriy/x86_make | success | Make finished |
| andriy/x86_make_fate | success | Make fate finished |
| andriy/PPC64_make | success | Make finished |
| andriy/PPC64_make_fate | success | Make fate finished |
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
On Sun, Jan 10, 2021 at 3:09 AM Mark Thompson <sw@jkqxz.net> wrote: > 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. > The VVC_MAX_HEIGHT is 16888, it's higher than 14080. If we limit the VVC_MAX_HEIGHT to 4k, we can reduce it to 135. > > > + // 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 > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
How about we define it as 20, check the size and return error if > 20. 20 should enough for most of clips. hevc used 20. On Sun, Jan 10, 2021 at 9:39 AM Nuo Mi <nuomi2021@gmail.com> wrote: > > > On Sun, Jan 10, 2021 at 3:09 AM Mark Thompson <sw@jkqxz.net> wrote: > >> 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. >> > The VVC_MAX_HEIGHT is 16888, it's higher than 14080. > If we limit the VVC_MAX_HEIGHT to 4k, we can reduce it to 135. > >> >> > + // 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 >> _______________________________________________ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> >> To unsubscribe, visit link above, or email >> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". > >
On 10/01/2021 08:35, Nuo Mi wrote: > On Sun, Jan 10, 2021 at 9:39 AM Nuo Mi <nuomi2021@gmail.com> wrote: >> On Sun, Jan 10, 2021 at 3:09 AM Mark Thompson <sw@jkqxz.net> wrote: >>> 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 @@ >>>> ... >>>> + >>>> + // 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. >>> >> The VVC_MAX_HEIGHT is 16888, it's higher than 14080. >> If we limit the VVC_MAX_HEIGHT to 4k, we can reduce it to 135. > > How about we define it as 20, check the size and return error if > 20. > 20 should enough for most of clips. hevc used 20. I'm specifically asking whether any of the other limits imply a better bound on the number of columns. Can a 32x14080 stream (or something similar) with 440 tiles ever be valid given all of the constraints? 440 is not large enough that it would matter in terms of space used, so if there isn't actually a better implied limit then leave it as 440. (<1kB - constrast that with the entry points, which are already >10kB of almost-never-used space with the current limit.) >>>> + // 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, >>>> ... - Mark
On Tue, Jan 12, 2021 at 6:01 AM Mark Thompson <sw@jkqxz.net> wrote: > On 10/01/2021 08:35, Nuo Mi wrote: > > On Sun, Jan 10, 2021 at 9:39 AM Nuo Mi <nuomi2021@gmail.com> wrote: > >> On Sun, Jan 10, 2021 at 3:09 AM Mark Thompson <sw@jkqxz.net> wrote: > >>> 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 @@ > >>>> ... > >>>> + > >>>> + // 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. > >>> > >> The VVC_MAX_HEIGHT is 16888, it's higher than 14080. > >> If we limit the VVC_MAX_HEIGHT to 4k, we can reduce it to 135. > > > > How about we define it as 20, check the size and return error if > 20. > > 20 should enough for most of clips. hevc used 20. > > I'm specifically asking whether any of the other limits imply a better > bound on the number of columns. Can a 32x14080 stream (or something > similar) with 440 tiles ever be valid given all of the constraints? > > 440 is not large enough that it would matter in terms of space used, so if > there isn't actually a better implied limit then leave it as 440. (<1kB - > constrast that with the entry points, which are already >10kB of > almost-never-used space with the current limit.) > No, I did not see and constraint in spec and the reference code. It does not needed to be 32x14080, it can be 1920x14080 too. > > >>>> + // 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, > >>>> ... > > - 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-request@ffmpeg.org with subject "unsubscribe".
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 @@ +/* + * VVC 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_VVC_H +#define AVCODEC_VVC_H + +/** + * Table 5 – NAL unit type codes and NAL unit type classes + * in T-REC-H.266-202008 + */ +enum VVCNALUnitType { + VVC_TRAIL_NUT = 0, + VVC_STSA_NUT = 1, + VVC_RADL_NUT = 2, + VVC_RASL_NUT = 3, + VVC_RSV_VCL_4 = 4, + VVC_RSV_VCL_5 = 5, + VVC_RSV_VCL_6 = 6, + VVC_IDR_W_RADL = 7, + VVC_IDR_N_LP = 8, + VVC_CRA_NUT = 9, + VVC_GDR_NUT = 10, + VVC_RSV_IRAP_11 = 11, + VVC_OPI_NUT = 12, + VVC_DCI_NUT = 13, + VVC_VPS_NUT = 14, + VVC_SPS_NUT = 15, + VVC_PPS_NUT = 16, + VVC_PREFIX_APS_NUT = 17, + VVC_SUFFIX_APS_NUT = 18, + VVC_PH_NUT = 19, + VVC_AUD_NUT = 20, + VVC_EOS_NUT = 21, + VVC_EOB_NUT = 22, + VVC_PREFIX_SEI_NUT = 23, + VVC_SUFFIX_SEI_NUT = 24, + VVC_FD_NUT = 25, + VVC_RSV_NVCL_26 = 26, + VVC_RSV_NVCL_27 = 27, + VVC_UNSPEC_28 = 28, + VVC_UNSPEC_29 = 29, + VVC_UNSPEC_30 = 30, + VVC_UNSPEC_31 = 31, +}; + +enum VVCSliceType { + VVC_SLICE_TYPE_B = 0, + VVC_SLICE_TYPE_P = 1, + VVC_SLICE_TYPE_I = 2, +}; + +enum { + VVC_MAX_PLANES = 3, + //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, + // 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 */