[FFmpeg-devel,1/6] avcodec/h266: add shared header for h266

---
 libavcodec/h266.h | 121 ++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 121 insertions(+)
 create mode 100644 libavcodec/h266.h

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

On 12/21/2020 5:42 PM, Mark Thompson wrote:
> 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.

It can be used at some point down the line.

hevcdec for example names its enum and then uses it when it takes it as 
input argument in ff_hevc_nal_is_nonref().

> 
>> +    H266_NAL_TRAIL       = 0,
> 
> Probably clearer as H266_NAL_UNIT_TYPE_FOO or H266_NUT_FOO?

The way he named them is consistent with H264 and HEVC defines, so i'm 
inclined to leave it this way.

> 
>> +    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.

Changing this one i'm ok with.

> 
>> +    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-request@ffmpeg.org with subject "unsubscribe".

On Tue, Dec 22, 2020 at 4:49 AM Mark Thompson <sw@jkqxz.net> wrote:

> 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.
>
I just follow the hevc,  It's pretty bad since we can't map 1:1 from spec
to code.
How about we prefix names in table with a prefix, like
H266_TRAIL_NUT,
..
H266_IDR_W_RADL,
...
H266_SPS_NUT

so readers can easily cross-check between spec and code.


> > +    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.
>
It's defined by (1577).  I will add it.


>
> > +    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.
>
Oh, sorry for this, seems we need to define it as 440.

>
> > +    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.
>
Yes, we use sps_log2_ctu_size_minus5 to signal ctu size. So the min ctu
size is 1<<5 = 32.
Suppose 8k is 7680 × 4320, we have 4320/32 = 135 rows in maximum.

>
> > +    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-request@ffmpeg.org with subject "unsubscribe".

On Tue, Dec 22, 2020 at 4:49 AM Mark Thompson <sw@jkqxz.net> wrote:

> 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 @@
> > +/**
> > + * 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.
>
It just follows the hevc, maybe we need it in the native decoder.

>
> > +    H266_NAL_TRAIL       = 0,
>
> Probably clearer as H266_NAL_UNIT_TYPE_FOO or H266_NUT_FOO?
>
Done, I mapped spec name XXX to VVC_XXX

>
> > +    H266_NAL_AUD         = 20,
> > +    H266_NAL_EOS_NUT     = 21,
> > +    H266_NAL_EOB_NUT     = 22,
>
> The redundant _NUT suffixes are inconsistent.
>
Fixed, but spec names are inconsistent.

>
>
> > +
> > +enum H266SliceType {
>
> This type name too.
>
> > +    H266_SLICE_B = 0,
>
> H266_SLICE_TYPE_B
>
Done


>
> > +    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.)
>
done

>
> > +    H266_MAX_SPS_COUNT = 16,
> > +    // 7.3.2.5: pps_pic_parameter_set_id is in [0, 63].
>
> u(6)
>
Done

>
> > +    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.
>
Done

>
> > +    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.)
>
Done

>
> > +    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.
>
changed to 440(MaxTilesPerAu),

>
> > +    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.
>
Yes, we use sps_log2_ctu_size_minus5 to signal ctu size. So the min ctu
size is 1<<5 = 32.
Suppose 8k is 7680 × 4320, we have 4320/32 = 135 rows in maximum.

>
> > +    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-request@ffmpeg.org with subject "unsubscribe".