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

Nuo Mi nuomi2021 at gmail.com
Tue Dec 22 14:00:08 EET 2020


On Tue, Dec 22, 2020 at 4:49 AM Mark Thompson <sw at 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 at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".


More information about the ffmpeg-devel mailing list