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.

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

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.

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?