This repository has been archived by the owner on Jun 20, 2023. It is now read-only.
Ensure video frames are stored in Rust allocated memory #131
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
added 4 commits
December 19, 2017 16:19
This patch copies video frames coming out of Gecko/C++ and stores the result in an Arc<Vec<u8>>. In a later commit, I'll make the pixel data shared with C++, instead of being copied on every update_current_images() call.
We create a VideoFrameAllocator that stores a list of refcounted Vec<u8>s in which to store data. Each has a handle. When C++ wants to create a new image, it calls into Rust, which creates a new Vec and copies the image into it, and returns the handle to C++. The C++ code will associate the handle with other frame metadata such as timestamp, and pass the handle back to Rust code when the image is to be composited. This should mean that Rust controls the lifetimes of images, as they're stored in ref counted Rust memory.
philn
reviewed
Dec 19, 2017
| }) | ||
| .collect::<Vec<PlanarYCbCrImage>>() | ||
| let mut frames = vec![]; | ||
| let video_frame_allocator = video_frame_allocator.lock().unwrap(); |
There was a problem hiding this comment.
Nit: perhaps use try_unwrap() here?
There was a problem hiding this comment.
I couldn't get this to work, looks like try_unwrap is on Rc only?
|
@bors-servo r=philn |
|
📌 Commit 5ee2696 has been approved by |
bors-servo
pushed a commit
that referenced
this pull request
Dec 19, 2017
Ensure video frames are stored in Rust allocated memory To resolve the problems in issue #112 and to remove the potential use-after-free which can happen if GeckoMedia shuts down and deallocates video frames before the compositor is finished painting video frames, switch to having the video frames stored in Rust allocated Vec<u8>s which are ref counted. This means we won't deallocate the memory until the last Rust or C++ user of the data is destroyed.
|
☀️ Test successful - status-travis |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
To resolve the problems in issue #112 and to remove the potential use-after-free which can happen if GeckoMedia shuts down and deallocates video frames before the compositor is finished painting video frames, switch to having the video frames stored in Rust allocated Vecs which are ref counted. This means we won't deallocate the memory until the last Rust or C++ user of the data is destroyed.