Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork56.4k
videoio(ffmpeg): fix AVFrame lifetime handling on early return#28221
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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
base:4.x
Are you sure you want to change the base?
Conversation
Uh oh!
There was an error while loading.Please reload this page.
dheeraj25406 commentedDec 18, 2025
Thanks for the review! The additional frame reallocation change is not essential. Happy to adjust if you’d prefer splitting or dropping commits. |
asmorkalov commentedDec 18, 2025
Yes, drop not relevant changes please. |
8c29aff toea043cdComparedheeraj25406 commentedDec 18, 2025
Done. |
asmorkalov commentedDec 18, 2025 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
There are more cases in the function bellow with early exit. Please handle them too. M.b. use some smart pointer here? |
…FrameEnsure hardware-decoded frames are transferred to system memorywith proper lifetime handling in retrieveFrame().Enforce UMat output requirement in retrieveHWFrame() to avoidinvalid CPU-side usage for GPU-to-GPU transfers.
dheeraj25406 commentedDec 18, 2025
I’ve addressed both points:
Changes are minimal and limited to cap_ffmpeg_impl.hpp. |
| // must be UMat for GPU->GPU copy | ||
| if (!output.isUMat()) | ||
| returnfalse; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Why?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
retrieveHWFrame() performs a GPU to GPU path using hw_copy_frame_to_umat() which writes into an OpenCL backed UMat.
Allowing Mat here would either:
- silently fall back to an implicit GPU to CPU transfer
OR - require duplicating logic already handled by retrieveFrame()
Enforcing UMat makes the contract explicit and avoids ambiguous behavior or hidden performance penalties.
If you prefer, I can alternatively add a clear error log instead of returning false or redirect non-UMat output to retrieveFrame() for HW to SW transfer.
This PR fixes a memory leak in CvCapture_FFMPEG::retrieveFrame when
hardware-accelerated frames are used.
If av_hwframe_transfer_data() succeeds but retrieveFrame exits early
due to missing data, the allocated AVFrame was not freed.
The fix ensures:
Related to#25997