JVET-AO0052 AHG17/AHG18: Suggested CfP text for ultra-low latency and packet loss resilience category [S. Ikonin, X. Ma, E. Alshina (Huawei)]

This contribution suggests a text for functionality test on ultra-low latency and packet loss resilience as specific category for future Call for Proposals. Based on contribution JVET-AN0204, JVET-AN2039 ULL CTC, CfE evaluation discussion, and discussion of AHG18 teleconference summarised in JVET-AO0049 a marked-up version of JVET-AO0045 “Draft Joint Call for Proposals on video compression with capability beyond VVC (initial text)” covering ultra-low latency and packet loss resilience category is provided.

It was commented that it would be desirable to have more close rate matching, like in the other categories. It was argued that this test would be more about seeing differences in network-caused artifacts rather than compression artifacts.

It was commented that it may be questionable to base the test on specific network conditions (such as WiFi and 5G), as those are quickly changing in the real world.

It was asked if it would be possible to use the same anchors as in the other categories?

It was commented that it seems to be a high number of test cases, and UHD LD would be demanding in terms of encoding. However, not all of them would need to be tested visually.

It was commented that traditionally error resilience is handled on the network side (where some methods that are commonly applied are not used in the proposed test conditions.

It was commented that it might overburden the CfP to include extensive testing on this aspect. It might better be done during standard development.

Other comments were made that this could be a distinguishing feature of a new standard, and from this aspect would be important to be included.

A comment was made that under low latency condition, traditional methods such as external channel coding or retransmission fail, such that building error resilience into the source coding appears important.

Visual testing is important in this context, as no reasonable objective criteria are known.

Generally, diverging opinions about including it. It was suggested that an option might be to define it initially, and drop it when not sufficient interest is observed (e.g., will only be considered if at least X submissions are received).

It was asked to analyze the total number of test points that would need to be submitted per category with the proposed setup, and discuss in context of section 4.17 review options to potentially reduce these.

Follow-up discussion on Tuesday 20 2230-2310:

Questions raised:

• Testing only non-feedback case (would be simpler)? Would feedback require different tools?
• Mandatory to use the given network simulator? Is it representative, and if different ones would be allowed, how would proposals be comparable
• More than one QP point?
• What would be an appropriate anchor?
• How would different proposals be compared?

It was commented that it may be difficult to define conditions that would enable us to distinguish the benefit of tools in comparison to other aspects such as encoder optimization, rate control, error concealment, etc.

There was no objection that the topic is important, but various concerns were raised that the state is not mature enough to be included in the CfP. Would be a very interesting topic for investigation afterwards, in the collaborative phase, and potentially seeking collaboration with other bodies (network).

It was asked whether in the context of low latency error resilience is the most important aspect, or if it is also a matter of tool design.

No consensus was reached to have this included in CfP.