AOM decoder output buffers & bit depth

[Marian Aldescu]

Hi everyone,

I have a pretty technical question concerning the memory management of the AOM's decoder output buffers. Not sure if the people who implemented it are still here, but I will still give it a try.

Here's some context.

Depending on the bit depth, a pixel occupy in the output buffer:
- an uint8 for a 8 bit depth

- an uint16 for a 10 / 12 bit depth

, therefore everywhere in the codebase there are uint8_t* and uint16_t* buffers to handle each of the 3 planes (Y, U, V).

The trick comes when switching between these two kind of buffers, according to the bit depth, using 2 Macros.

#define CONVERT_TO_SHORTPTR(x) ((uint16_t *)(((uintptr_t)(x)) << 1))

#define CONVERT_TO_BYTEPTR(x) ((uint8_t *)(((uintptr_t)(x)) >> 1))

The x parameter is the address of the buffer and CONVERT_TO_SHORTPTR is used to pass from an uint8_t* address to an uint16_t* address and CONVERT_TO_BYTEPTR vice-versa.

The thing is that I understand what those 2 macros do from the coding language point of view, but not why.

For example, CONVERT_TO_SHORTPTR return a total different address higher than the previous one.
From my point of view, it implies that it is always a valid address, allocated in advance. Moreover, the choice of using them is not so clear for me even after reading the commit messages of that part of code and "digging" a bit the AOM's code.
Could someone explain me the expected behaviour when using those macros and the reasoning behind the choice of using them?

I know there's a bit of time since the implementation was done, but I cross the fingers that someone still remembers.

Best regards,
Marian Aldescu

[James Zern]

Hi Marian,

This actually comes from the experimental days of VP9 and your intuition is correct, they create invalid intermediate pointers and aren't really necessary. I think they were some attempt at normalizing the type in function parameters, but often void* would have worked with an appropriate cast within the function. Removing these in both codebases would be a big task, but would certainly improve readability and avoid confusion like this.

[Marian Aldescu]

Hi James,

" [...] they create invalid intermediate pointers and aren't really necessary."  I was afraid this would be the case.
Thank you very much for clarifying.

Best regards,
Marian