video: Reduce allocations/copies when decoding frames - #24135
Conversation
|
This might even have to evolve a bit further in the future, to use a buffer pool of some sorts. |
|
Tested various video SWF files; everything seems to be in working order. |
| } | ||
| } | ||
|
|
||
| #[inline] |
There was a problem hiding this comment.
Huh, somehow this method and the one below are considered uncovered despite their callers being covered?
Lord-McSweeney
left a comment
Lord-McSweeney
left a comment
There was a problem hiding this comment.
I'm completely unfamiliar with this area but the code LGTM
147948f to
26cc366
Compare
|
I've been meaning to review this a couple times but ... uh ... life 🫥 |
Outline the entirety of the 'wrong-size' path into a cold function, and re-slice instead of allocating a new `Vec` when an `&[u8]` is too big.
This will allow decoders to reuse internal buffers to hold decoded frames.
…coded frames This saves two allocations by `decode_frame` call.
This saves one allocation per `decode_frame` call.
This saves one allocation per `decode_frame` call.
- Update the last frame in-place in `decode_v1` instead of working on a copy (this will affect output for corrupted streams, which is probably OK) - Build the final RGB frame into the preexisting `tile` sratch buffer instead of creating a fresh `Vec` These changes save two allocations per `decode_frame` call.
This saves several allocations and copies for each `decode_frame` call.
26cc366 to
1438c01
Compare
3 participants
Description
Currently, the
VideoDecoder::decode_framemethod returns ownedBitmap<'static>s, forcing decoders to allocate a fresh buffer for each decoded frame.This PR changes the API to instead provide a short-lived buffer through a callback, and updates the decoders to take advantage of this by reusing buffers more aggressively.
Testing
All
visual/videotests pass on native, but I still need to do a visual check with my human eyes, and properly test the web decoder.Checklist