JVET-AE0145 AHG 12: Flexible GDR [L. Wang, S. Hong, K. Panusopone (Nokia)]

In the current GDR design in VVC/ECM, an initial refreshed area starts on the left of a GDR picture and gradually expends over the associated recovering pictures. The most meaningful content information of a video sequence, however, may not necessarily always be in the left part of pictures. This contribution proposes a flexible GDR, where an initial refreshed area can be in any location in a GDR picture. To support such flexible GDR, each virtual boundary in GDR/recovering picture is assigned a flag (new syntax element), specifying which side of the virtual boundary is in refreshed area. The proposed flexible GDR is implemented in ECM-9.0. Simulations were conducted for the flexible GDR with an initial refreshed area starting from the left, the middle and the center of GDR pictures. The middle/center GDR present interesting content information much earlier than the left GDR. The overall BD rate measurements of the middle/center GDR over the left GDR were not yet available.

Bit rate increased due to larger number of virtual boundary (at least if more activity in the center, such as in videoconferencing). Up to 4 would be supported by the proposal, instead of one currently.

The encoder decides where to start the refresh, including left/right/top/bottom, four corners, etc.

It was commented that this would not be favorable if the memory consumption becomes larger (JVET-AE0180) reports unnecessary memory consumption by GDR (in the report on JVET-AE0180, this was later corrected to be caused by wraparound MC, not GDR).

It was commented that GDR access of a user can start at any frame (not only IRAP, as demonstrated here). However, in VVC, a GDR picture is not possible at any frame, and a decoder has to wait until seeing a GDR picture.

It was pointed out that some of these aspects can be done non-normatively, e.g. by using subpictures

The effect may be very specific to specific content, such as videoconference with one person in the middle.

GDR is not of high importance in the ECM, and the software should not become overcomplicated by even more complicated variants of it that may not be needed practically. According to the software coordinator, GDR impacts many tools in the ECM, which likely would become more complicated with additional VBs.

No action was taken on this.