struct Rav1dFrameContext_lf::cdef_line: Convert pointers to offsets

[randomPoison]

The pointers in cdef_line were pointing into the buffer owned by cdef_line_buf. In converting them to offsets, I had to make sure that that offsets were consistently in terms of pixels (rather than bytes). The original code was inconsistent here, with the logic working with u8 pointers (and so was using byte offsets), but the code that uses cdef_line treats the pointers as BD::Pixel pointers, so the offset logic is calculated in terms of pixels. In converting to offsets I normalized on pixel offsets. To do so I had to add a couple of helpers:

• BPC::pxstride - Does the same thing as BitDepth::pxstride, but works in non generic code. This was needed to calculate pixel offsets during the initialization logic.
• BitDepth::cast_pixel_slice{_mut} - Converts a &[u8] to a &[Pixel]. This was needed so that we could index into the buffer using pixel indices within our bidepth-dependent code.

In practice most of the usages of cdef_line is to calculate pointers to be passed into asm functions, so the cleaned up code is still doing some pointer arithmetic, though we never dereference those pointers from Rust code.

[kkysen]

I had some comments about the pixel casting checks, but the rest of the offset stuff all looks good.

[kkysen]

We don't want to have to check this everytime we access the pixels, so it'd be better to check it once during creation. I'd been planning to create a type for this. This is probably fine in the meantime, though, just worst perf.

[randomPoison]

What were you thinking wrt making a custom type to handle it? Something like a PixelBuf type that wraps a Vec<u8> and has helpers for accessing the buffer as either a &[u8] or a &[Pixel]?

[kkysen]

What were you thinking wrt making a custom type to handle it? Something like a PixelBuf type that wraps a Vec<u8> and has helpers for accessing the buffer as either a &[u8] or a &[Pixel]?

Yeah, basically. It's a bit trickier for Rav1dPicture::data specifically since it supports custom allocators, but that'd be the gist. The alignment/length stuff would all be checked during construction, and so these safe transmute casts would be no-ops other than dividing the length.

[kkysen]

I think you merged the changes from #780 wrong; they're all overwritten here with the old versions.

[randomPoison]

Oh weird, idk how I did that. Should be fixed now.