Repository navigation
Avoid eager CUDA context creation during NVDEC capability detection - #1496
alan-george-lk wants to merge 2 commits into
Conversation
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
| RTC_LOG(LS_ERROR) << "Failed to get CUDA device."; | ||
| return; | ||
| } | ||
| supported_formats_ = SupportedNvDecoderCodecs(device); |
There was a problem hiding this comment.
🔴 Unavailable CUDA contexts break video decoding
When cuCtxCreate fails but cuDeviceGet succeeds, supported_formats_ still advertises NVDEC. VideoDecoderFactory::Create then returns the failed NVDEC decoder without trying software decoding.
Learn more
The outer video decoder factory gives NVIDIA formats priority over its software H.264 decoder. Before this change, the NVIDIA factory initialized its CUDA context before publishing formats, so a context creation failure left its format list empty. Now device enumeration can succeed even when cuCtxCreate fails later, such as when the GPU cannot allocate another context. VideoDecoderFactory::Create immediately returns the selected factory's result, including null, without trying the software fallback.
Example: A GPU permits cuDeviceGet(0) but rejects cuCtxCreate under resource pressure. H.264 is advertised through NVDEC; Create chooses NVDEC, gets null, and never reaches its working software H.264 decoder.
Recommended fix: Keep lazy context initialization but ensure that a failed NVDEC Create allows VideoDecoderFactory::Create to try the next implementation. Also account for H.265, which has no software decoder in that factory, when deciding whether formats can be advertised.
Was this helpful? React with 👍 or 👎 to provide feedback.
| CUdevice device; | ||
| if (cuDeviceGet(&device, 0) != CUDA_SUCCESS) { | ||
| RTC_LOG(LS_ERROR) << "Failed to get CUDA device."; | ||
| return; |
There was a problem hiding this comment.
🟡 Direct factory construction loses NVIDIA formats
Constructing NvidiaVideoDecoderFactory before CUDA initialization makes cuDeviceGet fail, leaving supported_formats_ empty. The normal wrapper calls IsSupported first, but direct callers do not.
Learn more
CUDA driver device enumeration requires cuInit(0). Previously the factory's constructor called CudaContext::Initialize, which called cuInit before cuDeviceGet. The wrapper VideoDecoderFactory still calls IsSupported before construction, so it initializes CUDA first; this does not protect direct construction of the public NVIDIA factory.
Example: A caller creates NvidiaVideoDecoderFactory on a fresh process with an available GPU and libnvcuvid.so.1. The constructor's device query fails before initialization and GetSupportedFormats() returns an empty vector, unlike before this change.
Recommended fix: Initialize the CUDA driver with cuInit(0) before querying the device in this constructor. Do not create a CUDA context until decoder creation.
Was this helpful? React with 👍 or 👎 to provide feedback.
0a4acda to
6b1b88b
Compare
Co-authored-by: Cursor <cursoragent@cursor.com>
|
Closing to recreate this branch as an independent PR against main; GitHub does not allow changing the base of a PR already registered in a stack. |
Changeset ✓This PR includes a changeset covering all affected packages:
|
1 participant
Independent NVIDIA lifecycle change; no longer part of the room-deletion fix stack.
Summary
Validation