Search Results for "JVET-Y0190"
Found 8 document(s)
Use number, keyword, author, or MPEG number. Filter by meeting when needed.
JVET-Y0190 AHG2/AHG8: Suggestions for the operation range extensions GCI [J. Gan, Y. Yu, H. Yu (OPPO)] [late]
It is asserted that the current text for general constraints information (GCI) in VVC version 2 contains two bugs. For the first bug, it is asserted that incorrect semantics and handling of gci_num_additional_bits lead to GCI decoding behaviour in VVC version 2 incompatible with VVC version 1 decoders. For the second bug, it is asserted that setting gci_present_flag to 1 and gci_num_additional_bits to 0 leads to undefined constraint behaviour for the 6 coding tools which are governed by the 6 additional GCI flags introduced in VVC version 2.
It is additionally asserted that VTM 15.0 contains a bug related to decoding of GCI as reported by JVET-Y0005.
The same issue is raised as in JVET-Y0049 (aspect 2).
Beyond that, it is pointed out (aspect 1) that a problem might occur when the gci_num_additional_bits has another value than 0 or 6 in version 2. The solution proposed appears appropriate.
Aspect 3 points out a software bug. Aspect 1 and 3 together are likely causing the problem with the conformance bitstreams.
New conformance streams need to be generated with all 6 GCI flags.
In the discussion, it is also mentioned that it might be desirable to rename the syntax element gci_reserved_zero_bit, as it could in have values of 0 or 1. This may however not be necessary.
Side activity with relevant experts, developing an integrated text to fix the bugs.
Follow-up discussion in session 9 Fri 14 Jan. No consensus yet on the question if a decoder should expect that only...
JVET-Y0237 Integrated specification text for JVET-Y0049 and JVET-Y0190 [J. Gan (OPPO), Y.-K. Wang (Bytedance)] [late]
Following presentation of input contributions JVET-Y0005, JVET-Y0049, and JVET-Y0190, it was asserted that several bugs exist in the VVC version 2 specification relating to the general constraints information syntax, two of which were the cause of errors in conformance testing reported by JVET-Y0005. Relevant experts were asked to develop an integrated text to fix the bugs. Although consensus was reached on the majority of the text, differences of opinion still remain on one section of the text, namely the semantics for gci_num_additional_bits. The differences have been captured in three options.
It is proposed to adopt the integrated text for one of options A, B or C. An associated software patch for the chosen option will be provided for VTM 16.0.
Option A would also allow values 1..5 in future, which is undesirable
Option B requires a decoder to ignore the values of GCI flags, in case that a value 1..5 would appear, and values >6.
Option C requires a a decoder to ignore the values of GCI flags, in case that a value >6 would appear (as values 1..5 could never happen). If values 1..5 would appear, this would be a non-conforming bitstream.
It is agreed that option C is the most logical solution.
Decision: Adopt JVET-0237 option C.
JVET-Y0242 AHG8: On SPS extension syntax [Y.-K. Wang (Bytedance)] [late]
JVET-Y0237 provides three text options on GCI extension for the JVET to choose, for fixing some asserted bugs reported in JVET-Y0049 and JVET-Y0190.
This contribution presents a conditional proposal of a change to the SPS extension syntax, depending on JVET's decision on JVET-Y0237 text options. If JVET were to choose option A or B in JVET-Y0237, the SPS extension change would be proposed, for an asserted alignment of the two extensions following the same design principle, in terms of handling different forward and backward compatibilities in similar manners. If JVET were to choose option C in JVET-Y0237, the SPS extension change would not be proposed, for the same purpose.
There was no need for consideration of this, as “option C” was selected for JVET-Y0237.
Test conditions (6)
Contributions in this area were discussed in session 15 at 2100–2240 UTC on Monday 17 Jan. 2022 (chaired by JRO).