Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

struct Rav1dFrameContext_lf::lr_lpf_line: Convert to offsets #793

Merged
merged 1 commit into from
Mar 18, 2024

Conversation

randomPoison
Copy link
Collaborator

No description provided.

@randomPoison randomPoison requested review from rinon and kkysen March 11, 2024 17:41
@randomPoison randomPoison force-pushed the legare/Rav1dFrameContext_lf/lr_lpf_line branch from 879f132 to 3849584 Compare March 11, 2024 17:42
Base automatically changed from legare/Rav1dFrameContext_lf/lr_line_buf to main March 11, 2024 17:43
src/lf_apply.rs Outdated
Comment on lines 164 to 167
let dst: [&mut [BD::Pixel]; 3] = [
slice::from_raw_parts_mut(
(f.lf.lr_lpf_line[0] as *mut BD::Pixel).offset(cmp::min(y_span, 0)),
lr_plane_sz[0] as usize,
),
slice::from_raw_parts_mut(
(f.lf.lr_lpf_line[1] as *mut BD::Pixel).offset(cmp::min(uv_span, 0)),
lr_plane_sz[1] as usize / 2,
),
slice::from_raw_parts_mut(
(f.lf.lr_lpf_line[2] as *mut BD::Pixel).offset(cmp::min(uv_span, 0)),
lr_plane_sz[1] as usize / 2,
),
];
let dst_offset: [usize; 2] = [
let yuv_offset: [usize; 2] = [
(tt_off as isize * y_stride - cmp::min(y_span, 0)) as usize,
(tt_off as isize * uv_stride - cmp::min(uv_span, 0)) as usize,
];
let dst_offset = [
f.lf.lr_lpf_line[0].wrapping_add_signed(cmp::min(y_span, 0)) + yuv_offset[0],
f.lf.lr_lpf_line[1].wrapping_add_signed(cmp::min(uv_span, 0)) + yuv_offset[1],
f.lf.lr_lpf_line[2].wrapping_add_signed(cmp::min(uv_span, 0)) + yuv_offset[1],
];
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why can't we keep the original dst as an array of &mut [_]s? They don't overlap, so we should be able to split up lr_line_buf, right?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Splitting up lr_line_buf into separate slices isn't necessary here. We were passing dst[i] plus an offset into backup_lpf, so the most straightforward thing to do is combine the offsets and pass all of lr_line_buf in along with the calculated offset. I don't see any reason to go through the extra steps of split_at_muting the slice only to still pass in a buffer+offset pair.

@kkysen kkysen changed the title Rav1dFrameContext_lf::lr_lpf_line: Convert to offsets struct Rav1dFrameContext_lf::lr_lpf_line: Convert to offsets Mar 11, 2024
@randomPoison
Copy link
Collaborator Author

This is blocked on #801. The test failures we're seeing originate from the out-of-bounds pointer access that is already present on main, and moving to slice operations triggered an array OOB panic. As far as I can tell this change didn't introduce the issue, so we'll need to fix #801 first and rebase this on top.

@randomPoison randomPoison force-pushed the legare/Rav1dFrameContext_lf/lr_lpf_line branch from 3849584 to 21f7300 Compare March 12, 2024 23:50
Comment on lines -50 to -51
let lpf_plane_sz = BD::pxstride(f.lf.lr_buf_plane_sz[(plane != 0) as usize] as isize);
let mut lpf_offset = cmp::max(lpf_stride - lpf_plane_sz, 0);
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@fbossen I ended up removing lpf_plane_sz and lpf_offset in order to make the calculation here the same as the original C. You had added those in #746 to handle negative strides I think. Do we still need those with the fixed pxstride? Was there a reason why we needed those values in Rust but not in the original C?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The reason I added lpf_plane_sz and lpf_offset is that I defined lpf as a slice that begins at the memory section being effectively used and needed the compute the memory location of the beginning of the slice (and cover the case of a negative stride). If, instead of defining a new slice lpf, you use lr_line_buf, then removing lpf_plane_sz and lpf_offset looks appropriate.

@randomPoison randomPoison requested a review from fbossen March 12, 2024 23:54
Copy link
Collaborator

@fbossen fbossen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Upon further testing, it looks like I am hitting an error on one of the test bitstreams. Let me look into it and report more details later.

@fbossen fbossen self-requested a review March 13, 2024 03:46
src/lf_apply.rs Outdated
@@ -161,29 +161,21 @@ pub(crate) unsafe fn rav1d_copy_lpf<BD: BitDepth>(
let y_span = lr_plane_sz[0] as isize - y_stride;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you should be able to remove y_span and uv_span here as well. They were used to compute the base address of the slice. It seems superfluous to subtract y_span in yuv_offset[0] and add it back in dst_offset[0]

@fbossen
Copy link
Collaborator

fbossen commented Mar 13, 2024

Upon further testing, it looks like I am hitting an error on one of the test bitstreams. Let me look into it and report more details later.

The issues boils down to the following: in fn rav1d_decode_frame_init f.lf.lr_line_buf is reallocated if needed. The offsets lr_lpf_line are updated upon reallocation. However, there are cases where f.lf.lr_line_buf doesn't need to be reallocated but the offsets need updating: for example, if the picture width doubles and the pixel size is halved. (e.g., y_stride doesn't change but y_stride_px does).

src/lr_apply.rs Outdated Show resolved Hide resolved
@randomPoison
Copy link
Collaborator Author

The issues boils down to the following: in fn rav1d_decode_frame_init f.lf.lr_line_buf is reallocated if needed. The offsets lr_lpf_line are updated upon reallocation. However, there are cases where f.lf.lr_line_buf doesn't need to be reallocated but the offsets need updating

Huh, is that being caused by the changes in this PR? I haven't changed anything related to when we do the re-allocation and update lr_lpf_line, so I would think the behavior there is the same as before. I can remove the if condition around the initialization logic so that we always resize and recompute lr_lpf_line, that would fix the issue I think.

@randomPoison randomPoison force-pushed the legare/Rav1dFrameContext_lf/lr_lpf_line branch from 21f7300 to 68fda0e Compare March 15, 2024 16:48
@fbossen
Copy link
Collaborator

fbossen commented Mar 15, 2024

Huh, is that being caused by the changes in this PR? I haven't changed anything related to when we do the re-allocation and update lr_lpf_line, so I would think the behavior there is the same as before.

Yes. Changes in this PR cause the issue. If lr_lpf_line was always in units of u8, then there would be no issue. But lr_lpf_line is now in units of u8 or u16 depending on the bit depth. So if the bit depth changes, but the amount (in bytes) of allocated memory doesn't, the values of lr_lpf_line require updating.

@randomPoison randomPoison force-pushed the legare/Rav1dFrameContext_lf/lr_lpf_line branch from 68fda0e to b637376 Compare March 15, 2024 16:58
@randomPoison
Copy link
Collaborator Author

Okay, thanks for confirming! I've removed the conditional logic for initializing lr_lpf_line so it should be updated properly now if the bitdepth changes.

@randomPoison randomPoison requested review from fbossen and kkysen March 15, 2024 23:06
Copy link
Collaborator

@fbossen fbossen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@randomPoison randomPoison merged commit 1e394d7 into main Mar 18, 2024
34 checks passed
@randomPoison randomPoison deleted the legare/Rav1dFrameContext_lf/lr_lpf_line branch March 18, 2024 16:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants