Opened 7 years ago

Closed 7 years ago

#1359 closed defect (worksforme)

Pic Timing: cpb removal delay calculation causes conformance failures

Reported by: abishop Owned by:
Priority: major Milestone:
Component: Text Version:
Keywords: cpb hrd Cc: bbross, wjhan, jct-vc@…

Description

As I understand it, calculating CPB removal times can have this example path below (HM & x265 have this behavior), which can force non-conformance. Am I understanding these derivations correctly?

What does au_cpb_removal_delay mean for the AU containing a BP message?

---
AU-0

Buffering Period:

concatenation_flag = 0
nal_initial_cpb_removal_delay = 32401

Pic Timing:

au_cpb_removal_delay_minus1 = 0

AuCpbRemovalDelayVal = au_cpb_removal_delay_minus1 + 1 (D-2) = 1
AuNominalRemovalTime[0] = InitCpbRemovalDelay[0] ÷ 90000 (C-10) = 0.36001
AuCpbRemovalTime[0] = AuNominalRemovalTime[0] = 0.36001

AU-1

Pic Timing:

au_cpb_removal_delay_minus1 = 0

AuCpbRemovalDelayVal = 1

  • Violates: "Within one buffering period, the AuCpbRemovalDelayVal values for any two access units shall not be the same."

AuNominalRemovalTime[1] = AuNominalRemovalTime[0] + ClockTick * (AuCpbRemovalDelayVal - CpbDelayOffset) (C-12) = 0.36001 + 0.04171 * (1-0) = 0.40172
AuCpbRemovalTime[1] = AuNominalRemovalTime[1]

AU-2

Pic Timing:

au_cpb_removal_delay_minus1 = 1

AuCpbRemovalDelayVal = 2
AuNominalRemovalTime(2) = AuCpbRemovalTime[2] = 0.44343

AU-3

Buffering Period:

concatenation_flag = 0
nal_initial_cpb_removal_delay = 36001

Pic Timing:

au_cpb_removal_delay_minus1 = 0

AuCpbRemovalDelayVal = 1
AuNominalRemovalTime(3) = baseTime + ClockTick * ( tmpCpbRemovalDelay - CpbDelayOffset ) = 0.40172 (same as AU-1)
AuCpbRemovalTime[3] = AuNominalRemovalTime[3]

  • This breaks the timeline between buffering periods. First instinct is to make have this au_cpb_removal_delay_minus1 encoded as the previous' plus one. But, that would surely cause a duplicate.
  • Given AuNominalRemovalTime[3] - AuCpbRemovalTime[2] < 0, Clause A.4.2.a is forced to fail.

AU-4

Pic Timing:

au_cpb_removal_delay_minus1 = 0

AuCpbRemovalDelayVal = 1

  • Violates: "Within one buffering period, the AuCpbRemovalDelayVal values for any two access units shall not be the same."

AuNominalRemovalTime(4) = 0.40172

  • Given AuCpbRemovalTime[4] - AuCpbRemovalTime[3] == 0, Clause A.4.2.d is forced to fail.

---

Change History (5)

comment:1 Changed 7 years ago by DefaultCC Plugin

  • Cc bbross wjhan jct-vc@… added

comment:2 Changed 7 years ago by ksuehring

Which version of the standard document are you looking at? I think, this has been addressed in the defect report (JCTVC-Q1001), which is also included in the second edition. The modified text defines (semantics of au_cpb_removal_delay_minus1):

The variables AuCpbRemovalDelayMsb and AuCpbRemovalDelayVal of the current picture are derived as follows:
– If the current access unit is the access unit that initializes the HRD, AuCpbRemovalDelayMsb and AuCpbRemovalDelayVal are both set equal to 0.

I think that solves the problem that you are seeing.

Last edited 7 years ago by ksuehring (previous) (diff)

comment:3 Changed 7 years ago by abishop

Version 1: primarily ISO/IEC 23008-2:2013 but referencing JCTVC-L1003_v34. I couldn't find JCTVC-Q1001 but suspect you mean JCTVC-Q1003: the CPB removal time overflow issue reported in JCTVC-P0064.

That fix involves integer overflow and AuCpbRemovalDelayMsb which I don't think impacts my example. AuCpbRemovalDelayMsb is zero anyway, buffering periods occur frequently enough.

The issue I'm seeing occurs at the access unit containing a buffering period that is not the one that initialized the HRD. Subsequent buffering periods don't initialize the HRD and the special case (set AuCpbRemovalDelayVal to 0) doesn't apply. Right?

It seems as though there needs to be a case for access units containing a buffering period message (even if they don't initialize the HRD.)

Given JCTVC-Q1003, when an access unit that contains a buffering period that does not initialize the HRD arrives, there now seems to be an undesired effect upon AuCpbRemovalDelayMsb.

AU-2

BpResetFlag = 0
PT::au_cpb_removal_delay_minus1 = 1
AuCpbRemovalDelayMsb = 0
AuCpbRemovalDelayVal = 2

AU-3

BP
BpResetFlag = 1
prevBpResetFlag = 0
prevAuCpbRemovalDelayMsb = 0
prevAuCpbRemovalDelayMinus1 = 1
PT::au_cpb_removal_delay_minus1 = 0
AuCpbRemovalDelayMsb = 0 + 128 (maxCpbRemovalDelay)
AuCpbRemovalDelayVal = 129

comment:4 Changed 7 years ago by ksuehring

Yes, I meant Q1003.

What configuration did you use? I have tested with a random access based configuration file (GOP 8) with HM-dev. The software keeps increasing au_cpb_removal_delay_minus1 in the picture that starts the second buffering period, which creates consistent CPB removal delays.

I guess, this is more a software issue that a text problem. If you agree, I would change the component to HM.

comment:5 Changed 7 years ago by abishop

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

I updated and re-ran some basic encodes using simple configuration. I too see au_cpb_removal_delay_minus1 incrementing into the new buffering period and believe this to be consistent with the spec definition.

I can't find my TraceEnc/Dec.txt's showing anything else (which I thought I had...) so, I will believe it's been consistent the entire time and I was confused.

However, incrementing au_cpb_removal_delay_minus1 into the new buffering period could easily cause duplicated AuCpbRemovalDelayVal's which was not allowed before Q1003. Buffering period sizes would have had to been strictly decreasing. For me, the defect report reads as though it intended to fix another issue that needed to allow duplicate AuCpbRemovalDelayVal's. Thereby, preemptively solving this ticket's issue as a side effect. Does that make sense?

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

  • Alex Bishop(Reporter, Participant)
  • Benjamin Bross(Subscriber)
  • jct-vc@…(Subscriber)
  • karl.sharman@…(Always)
  • Karsten Suehring(Participant, Always)
  • Woo-Jin Han(Subscriber)