Missing definition of entry_point_offsets_present_flag and clarification of entroy_point_offset existence

[leesh007]

In current spec, there is no definition about the "entry_point_offsets_present_flag" syntax elements.

Also, there is some possibilities to generate streams without entry_point_offset in case of "single slice/multi tile" composition because there is no restrictions regarding "entry_point_offsets_present_flag".

Is it possible in VVC specs?
If it is possible, it would be impossible to partial decoding of some specific tiles in slices.

[Tomohiro Ikai]

Thank you for reporting. A description can be

entry_point_offsets_present_flag equal to 1 specifies that offset_len_minus1 and entry_point_offset_minus1[ i ] may be present in slice headers referring to the PPS. entry_point_offsets_present_flag equal to 0 specifies that offset_len_minus1 or entry_point_offset_minus1[ i ] are not present in slice headers referring to the PPS.

there is some possibilities to generate streams without entry_point_offset in case of "single slice/multi tile" composition because there is no restrictions regarding "entry_point_offsets_present_flag". Is it possible in VVC specs?

Yes, no entry_point_offset is possible.
This point has been discussed in the JVET-O meeting and the decision was made that we allow no entry point bitstreams. In my memory, there's at lease two use-cases:

• Encoder only parallelism. In this use-case, decoder doesn't apply parallel decoding. Thus entry_point_offset is not necessary.
• System may provide segment information. If system side encapsulates each or sets of segments, the decoder would understand the staring points without entry_point_offset information.

[leesh007]

Thank you for kind information.
I didn't participate in HLS discussion in Gothenburg meething thus I missed it. Regarding the "No" entry point bitstreams, I think we need to discuss more about this in AhG16 because this feautre may affect in hardware implementation.

[yk]

Fixed by actions taken at the 17th JVET meeting.