Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

videoio(ffmpeg): handle frame reallocation when resolution or type changes#28212

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

Closed

Conversation

@dheeraj25406
Copy link

What does this PR do?

On Linux, when VIDEO_ACCELERATION_ANY is requested, OpenCV currently tries VAAPI first.
This PR adjusts the default order to try CUDA (NVDEC) before VAAPI when available.

Why?

  • FFmpeg supports CUDA/NVDEC decoding when built with --enable-cuda
  • NVIDIA GPUs are common on Linux servers
  • VAAPI often fails on NVIDIA systems, causing silent CPU fallback

Behavior

  • No behavior change if CUDA is unavailable
  • VAAPI remains as fallback
  • No Windows impact

Related issue

Fixes#28207 (cannot use h264_cuvid decoder from Java API)

Testing

  • Verified FFmpeg h264_cuvid decoding works
  • OpenCV VideoCapture now selects CUDA instead of VAAPI

@dheeraj25406
Copy link
Author

Looks like Windows runner infrastructure failure, not related to code changes. Linux/macOS builds pass.

@dheeraj25406dheeraj25406 changed the titlevideoio(ffmpeg): try CUDA first for VIDEO_ACCELERATION_ANY on Linuxvideoio(ffmpeg): handle frame reallocation when resolution or type changesDec 17, 2025
@asmorkalov
Copy link
Contributor

The patch does not touch CUDA at all.

@dheeraj25406
Copy link
Author

Thanks for the review. Agreed, the title and description were misleading.
I’ll resubmit this as a focused fix if needed in a separate PR with correct scope.

@dheeraj25406
Copy link
Author

The patch does not touch CUDA at all.

Thanks for the review and clarification.
I agree the additional reallocation logic is unnecessary.
No further changes from my side.

Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

can't using h264_cuvid decoder when using java api

2 participants

@dheeraj25406@asmorkalov

[8]ページ先頭

©2009-2025 Movatter.jp