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

h264: Use consistent size of scaling buffer #1785

Merged
merged 2 commits into from
Aug 19, 2024

Conversation

any1
Copy link
Contributor

@any1 any1 commented Jul 22, 2024

This fixes out-of-bounds writes when there is a mismatch between the pixel buffer's stride and the rect's width or between the frame's height and the rect's height.

Copy link
Member

@CendioOssman CendioOssman left a comment

Choose a reason for hiding this comment

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

Thanks for your PR.

There are two fixes in this commit, which are conceptually quite different. One is also a pure bug, whilst the other is more controversial. Please split them to separate commits.

common/rfb/H264LibavDecoderContext.cxx Outdated Show resolved Hide resolved
common/rfb/H264LibavDecoderContext.cxx Outdated Show resolved Hide resolved
Copy link
Member

@CendioOssman CendioOssman left a comment

Choose a reason for hiding this comment

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

I guess the Windows backend also needs to be able to cope with oversized frames?

@any1
Copy link
Contributor Author

any1 commented Jul 30, 2024

I guess the Windows backend also needs to be able to cope with oversized frames?

Sure, but I don't use Windows and I do not have any computer set up with Windows, so I'm not your guy for that.

@CendioOssman
Copy link
Member

Windows needs to be figured out, as I'm not ready to claim compatibility with neatvnc if it doesn't work on all platforms. :/

@mmozeiko, @xornet-sl, do you think you can have a look? There looks to be some cropping code already in place?

@any1
Copy link
Contributor Author

any1 commented Jul 31, 2024

There looks to be some cropping code already in place?

That code is manually applying the cropping region specified by the SPS. It does not seem to take into account the size of the rect.

Edit: Actually, the windows code looks right to me. It should work fine as is and should not crash, no matter how badly the server behaves.

@any1
Copy link
Contributor Author

any1 commented Jul 31, 2024

Come to think of it, and looking at the linux kernel implementation of the bcm2835-codec driver, it does actually look like it's setting the cropping region. I haven't verified this by actually looking at the SPS though.

Thus, this is really just a matter of proper alignment and padding, and not misbehaving encoders, although they should definitely be guarded against.

@cgm999
Copy link

cgm999 commented Aug 8, 2024

@CendioOssman what is the next step to merge the PR ? I think this will benefit for some users (I have PiKVM in mind now)

@CendioOssman
Copy link
Member

It's not currently building properly, so that would need to be fixed. Otherwise, I don't think there are any open issues.

@any1
Copy link
Contributor Author

any1 commented Aug 9, 2024

It's not currently building properly, so that would need to be fixed. Otherwise, I don't think there are any open issues.

We can disable h264 depending on whether av_scale_frame exists or not. Would that be good enough?

@CendioOssman
Copy link
Member

I thought we already checked for swscale? Or is that some feature that requires a very new ffmpeg?

@cgm999
Copy link

cgm999 commented Aug 12, 2024

it requires one that have swscale_frame (which was added in Sep2021 in ffmpeg) . However I can we can rewrite that .. if we do not want to depend on a newer ffmpeg

@CendioOssman
Copy link
Member

That sounds like it might not be included in EPEL 8 and Ubuntu 20.04. So if it's possible to support those as well, then it would be appreciated.

@any1
Copy link
Contributor Author

any1 commented Aug 13, 2024

This feature was added in version 1.13.0, so I suppose that this fix should be backported to 1.13.

Jammy has 1.12.0: https://launchpad.net/ubuntu/jammy/+package/tigervnc-viewer

Older version of Ubuntu are bound to have older releases. The Ubuntu versions on which the build fails are not going to receive this update unless a user wants to compile manually.

I don't see the point in chasing old software, but if that's how you want things, I can make this work with older ffmpeg. Some time might pass until I find the time to do so.

@CendioOssman
Copy link
Member

We don't do bugfix releases for older branches, so you don't need to worry about those.

We also do our Ubuntu packages, which we do for all currently active Ubuntu versions. It is not an absolute requirement that every feature should be available on all of them, but we should try.

This ensures that the buffer is allocated with the correct alignment and
padding for use with sws_scale.

This fixes out-of-bounds writes which would in some cases cause
segmentation faults and/or heap corruption.
This fixes a memory leak
@any1
Copy link
Contributor Author

any1 commented Aug 16, 2024

It should compile on those old Ubuntus now.

I also have a colour space fix lined up for this, but I can make a separate PR for that when this is merged.

@cgm999
Copy link

cgm999 commented Aug 17, 2024

Looks good to me.

Copy link
Member

@CendioOssman CendioOssman left a comment

Choose a reason for hiding this comment

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

Great. Thanks for getting all the details sorted!

@CendioOssman CendioOssman merged commit e6fb057 into TigerVNC:master Aug 19, 2024
11 checks passed
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