The following note in sub-clause F.7.4.2.4.2 in W1005-v4 seems to be contradictory due to a missing "not" in the sentence. The first sentence of the note says that the SPS ID space is shared, but the second sentence says that SPS with a particular SPS_ID and a different layer ID would update the SPS of the same SPS_ID. This needs to be corrected.

Any SPS NAL unit with any nuh_layer_id value containing the value of sps_seq_parameter_set_id for the active SPS RBSP for a particular layer shall have the same content as that of the active SPS RBSP for the particular layer unless it follows the access unit auA containing the last coded picture for which the active SPS RBSP for the particular layer is required to be active for the particular layer and precedes the first NAL unit succeeding auA in decoding order that activates an SPS RBSP with the same value of seq_parameter_set_id.

NOTE 2 – All SPSs, regardless of their values of nuh_layer_id, share the same value space for sps_seq_parameter_set_id. In other words, an SPS with nuh_layer_id equal to X and sps_seq_parameter_set_id equal to A would update the previously received SPS with nuh_layer_id not equal to X and sps_seq_parameter_set_id equal to A.

Also, in order that the note be complete w.r.t to the text in the paragraph above it, the scope should also be added to the latter sentence in the note. Suggested text for the Note is below (additions highlighted with bold font).

NOTE 2 – All SPSs, regardless of their values of nuh_layer_id, share the same value space for sps_seq_parameter_set_id. In other words, an SPS with nuh_layer_id equal to X and sps_seq_parameter_set_id equal to A would not update the previously received SPS with nuh_layer_id not equal to X and sps_seq_parameter_set_id equal to A unless the SPS with nuh_layer_id equal to X and sps_seq_parameter_set_id equal to A succeeds the last access unit containing a picture belonging to a CLVS for which the SPS with nuh_layer_id not equal to X and sps_seq_parameter_set_id equal to A is active.

JCTVC-W1005-v4 says,

r[ x ][ y ] = ( rotateCoeffs ? d[ nTbS − x −1 ][ nTbS − y − 1 ] : d[ x ][ y ] << tsShift ) (8‑300)

but it should be,

r[ x ][ y ] = ( rotateCoeffs ? d[ nTbS − x −1 ][ nTbS − y − 1 ] : d[ x ][ y ] ) << tsShift (8‑300)

because "<<" operation was applied before "x?:y:z" operation according to Table 5-1 (Operation precedence).

The (8-5) is:

pocLt += PicOrderCntVal − DeltaPocMsbCycleLt[ i ] * MaxPicOrderCntLsb − PicOrderCntVal & ( MaxPicOrderCntLsb − 1 )

If reader assumes arithmetic operations are of higher priority than bitwise &, line in C/C++, then formula contains somewhat strange PicOrderCntVal- PicOrderCntVal.