Opened 11 years ago

Closed 11 years ago

#1107 closed defect (fixed)

Possible contradiction with regard to picture latency

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

Description

This ticket relates to spec sections 7.4.3.2 and C.5.2.3.

Say I have a CVS with the following pictures (given in decoding order):

POC 1 4 2 5 3
Reorder 0 0 1 0 2
Latency 0 2 0 1 0

The reorder and latency values have been arrived at using the definitions in section 7.4.3.2:

Reorder: the maximum allowed number of pictures that can precede any picture in the CVS in decoding order and follow that picture in output order

Latency: the maximum number of pictures that can precede any picture in the CVS in output order and follow that picture in decoding order

So in the SPS for this CVS, I have sps_max_num_reorder_pics=2 and sps_max_latency_increase_plus1=1, giving 2 as the maximum value for reorder and latency.

Now I come to decode this CVS using the procedure in C.5.2.3. The process goes like this:

1.Decode POC 1. Store in DPB as 'needed for output'. No bumping on this step. DPB at end of this step:

POC 1
PicLatencyCount 0
  1. Decode POC 4. No output. DPB at end of this step:
POC 1 4
PicLatencyCount 1 0
  1. Decode POC 2. As NumDPB>2, invoke bumping and output POC 1. DPB at end of this step:
POC 4 2
PicLatencyCount 1 0
  1. Decode POC 5. As NumDPB>2, invoke bumping and output POC 2. As PicLatencyCount for POC 4 is now 2, invoke bumping again and output POC 4. DPB at end of this step:
POC 5
PicLatencyCount 0

The order of output will now end up as 1,2,4,3,5 instead of the expected 1,2,3,4,5. It seems like the condition in C.5.2.3 should be that PicLatencyCount is greater than SpsMaxLatencyPictures, rather than greater than or equal to.

Change History (4)

comment:1 Changed 11 years ago by DefaultCC Plugin

  • Cc bbross wjhan jct-vc@… added

comment:2 Changed 11 years ago by adarsh

I think you have a point. However, the source of the issue is not "greater than" vs. "greater than or equal to". I think it is rather the following, which I think is a bug in the Spec. in Sec. C.5.2.3

For each picture in the DPB that is marked as "needed for output", the associated variable PicLatencyCount is set equal to PicLatencyCount + 1.

This should rather be

For each picture in the DPB that is marked as "needed for output" and succeeds the current picture in output order, the associated variable PicLatencyCount is set equal to PicLatencyCount + 1.

Also (unrelated) in the example, I think you should have your DPB size as 3, not 2.

comment:3 Changed 11 years ago by jackh

Agreed. As regards the DPB size, I was showing the DPB after each picture had been output and dropped from the DPB. I agree that it would need to have three buffers in order to store everything for this example - is this what you meant?

Related to this issue, the reference decoder currently has a test in xWriteOutput() to ensure it never outputs a picture out of order. I don't think this test is currently mentioned in the spec. I think that for valid streams with the alteration to the spec you propose, the test should never be needed, so I'd say it should probably be removed from the reference decoder, so as to show up dodgy streams. Currently the test covers this problem by dropping the out of order frame.

comment:4 Changed 11 years ago by bbross

  • Resolution set to fixed
  • Status changed from new to closed

Fixed in JCTVC-N0041_v1

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

  • Adarsh Krishnan Ramasubramonian(Participant)
  • Benjamin Bross(Subscriber, Participant)
  • Jack Haughton(Reporter, Participant)
  • jct-vc@…(Subscriber)
  • karl.sharman@…(Always)
  • Karsten Suehring(Always)
  • Woo-Jin Han(Subscriber)