Opened 4 years ago

Last modified 4 years ago

#1110 new defect

Clarification needed in SPS ordering information semantics

Reported by: jackh Owned by:
Priority: minor Milestone:
Component: Text Version: D10 (L1003) v33
Keywords: Cc: bbross, wjhan, jct-vc@…


The definitions of sps_max_dec_pic_buffering_minus1, sps_max_num_reorder_pics and sps_max_latency_increase_plus1, which define ranges based on the corresponding parameters in the VPS, don't state what should be done in the case where vps_max_sub_layers_minus1!=sps_max_sub_layers_minus1. This is particularly a problem if vps_max_sub_layers_minus1<sps_max_sub_layers_minus1, as some elements of these parameters won't have corresponding elements in the VPS. Unless I've missed something in the spec?

Change History (3)

comment:1 Changed 4 years ago by DefaultCC Plugin

  • Cc bbross wjhan jct-vc@… added

comment:2 Changed 4 years ago by yk

The semantics of vps_max_sub_layers_minus1 and sps_max_sub_layers_minus1 imply that vps_max_sub_layers_minus1 is always equal to or greater than sps_max_sub_layers_minus1. However, I agree that it would have been clearer if we add in the semantics of sps_max_sub_layers_minus1 that "The value of sps_max_sub_layers_minus1 shall be less than or equal to vps_max_sub_layers_minus1". Would explicitly saying the implicit restriction sufficiently address this issue?

comment:3 Changed 4 years ago by jackh

Thanks for the reply - yes, that would be fine.

Note: See TracTickets for help on using tickets.

This list contains all users that will be notified about changes made to this ticket.

These roles will be notified: Reporter, Owner, Subscriber, Participant

  • Benjamin Bross(Subscriber)
  • David Flynn(Always)
  • Jack Haughton(Reporter, Participant)
  • jct-vc@…(Subscriber)
  • Karl Sharman(Always)
  • Karsten Suehring(Always)
  • Woo-Jin Han(Subscriber)
  • Ye-Kui Wang(Participant)