On Tue, Jan 12, 2021 at 6:01 AM Mark Thompson <s...@jkqxz.net> wrote:
> On 10/01/2021 08:35, Nuo Mi wrote: > > On Sun, Jan 10, 2021 at 9:39 AM Nuo Mi <nuomi2...@gmail.com> wrote: > >> On Sun, Jan 10, 2021 at 3:09 AM Mark Thompson <s...@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-requ...@ffmpeg.org with subject "unsubscribe". _______________________________________________ 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".