Opened 12 years ago Closed 12 years ago #1100 closed defect (invalid)Calculation for PicWidthInCtbsY doesn't seem to match the spec
Description
In TComSampleAdaptiveOffset::create(), there are four lines which I believe correspond to equations 7-15 and 7-17 in the spec: m_iNumCuInWidth = m_iPicWidth / m_uiMaxCUWidth; m_iNumCuInWidth += ( m_iPicWidth % m_uiMaxCUWidth ) ? 1 : 0; m_iNumCuInHeight = m_iPicHeight / m_uiMaxCUHeight; m_iNumCuInHeight += ( m_iPicHeight % m_uiMaxCUHeight ) ? 1 : 0;
Spec:
In order to match the spec, should these lines not read: m_iNumCuInWidth = m_iPicWidth / m_uiMaxCUHeight; m_iNumCuInWidth += ( m_iPicWidth % m_uiMaxCUHeight ) ? 1 : 0; m_iNumCuInHeight = m_iPicHeight / m_uiMaxCUHeight; m_iNumCuInHeight += ( m_iPicHeight % m_uiMaxCUHeight ) ? 1 : 0;
instead? Seems like the division should be by the same quantity for both equations.
Change History (4)comment:1 Changed 12 years ago by DefaultCC Plugin
comment:2 Changed 12 years ago by bbrosscomment:3 Changed 12 years ago by jackh
You're right - I was misled because the issues addressed in ticket #1101 were overwriting memory, so the two variables were ending up with different contents. Apologies for the confusion. comment:4 Changed 12 years ago by fbossen
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
|
There is no mismatch because m_uiMaxCUHeight is always equal to m_uiMaxCUWidth. That might become interesting again for the range extensions where you could have non-square coding blocks for 422 but for version 1, I see no issue here.