JVET-R0256 AHG9: Virtual boundaries in increasing order using u(v) [M. Damghanian, M. Pettersson, R. Sjöberg, Z. Zhang, J. Enhorn, R. Yu, J. Ström (Ericsson)]
This contribution proposes constraining the virtual boundaries to be signalled strictly in left to right and top to bottom order for VVC. The proponents claim that there are currently no ordering constraints for the virtual boundaries in the VVC specification and that arbitrary order therefore is allowed. The proponents further claim that there is no benefit from allowing arbitrary order and that a cleaner design would be to enforce an order from lower values to higher.
This contribution further proposes to change the signalling from u(13) to u(v) with the length depending on the picture width and height. The proponents say that u(v) was originally used for virtual boundary signalling but that this was changed to u(13) in Gothenburg (July 2019).
The number of boundaries is a 2-bit syntax element, so there are never more than 3 of them in each direction.
The picture is processed from left to right (top to bottom), so the decoder would presumably want them in that order.
Proposal 1, adding constraints:
- Constrain the virtual boundary syntax elements to be signalled in order from left to right for vertical virtual boundaries and from top to bottom for horizontal virtual boundaries.
It was commented that if we do this, perhaps we should structure the syntax to send deltas instead of values so that it is not possible to express a violation of the constraint.
It was commented that since there are at most 3 of these, it doesn’t matter what order they are sent in and we should just not worry about it. No action was thus taken on this.
Proposal 2, alternative signalling:
- Change the signalling of the virtual boundaries from u(13) to u(v) in SPS and PH, where v is derived from the maximum picture size for syntax elements in the SPS and derived from the picture size for syntax elements in the PH.
Proposals 1 and 2 are assessed by the proponents to be independent.
JVET-R0266 aspect 6 is about the same thing. It proposes to use ue(v) to avoid the decoder needing to derive the number of bits that will be used for it from the width/height maxima. The proponent of JVET-R0256 said u(v) would probably be more bit efficient.
It was commented that the reason for u(13) was a historical accident and that u(v) seems like a straightforward approach.
It was commented that extraction should not change the parsing and could cause a problem with u(v).
Picture width and height already use ue(v).
There was a problem with the proposal for very small picture widths (e.g. a picture width of 8 or less).
Decision (cleanup): Code virtual boundary positions using ue(v). The proponent of JVET-R0266 can provide the software.