Conversation
|
The RDD process crashes when Firefox tries to encode a video: Logs from the driver: I tested with the following URL: https://webrtc.github.io/test-pages/src/canvas-capture/ |
|
I attempted to reproduce this on the current PR branch (
I used an H.264-only WebRTC loopback test and repeated 100 create/negotiate/teardown cycles. All 100 cycles completed and I did not observe an RDD crash or a minidump. With the system FFmpeg build, Firefox selected Firefox then selected The NVIDIA VA-API driver was nevertheless loaded. I observed repeated I also did not observe the teardown/init overlap shown in the original report. In my runs, The NVIDIA driver version differs significantly: my system uses 570.211.01, while the crash report uses 610.57.04. Could you share the Firefox version, FFmpeg version/encoder list, relevant Firefox preferences, and launch environment used for the crashing run? That would help determine why your Firefox reached a different timing/path. |
|
I'm using Firefox 154.0. I applied the bellow patch on top of our merge request and I have no more crash: diff --git a/src/vabackend.c b/src/vabackend.c
index 7619fed..cb453af 100644
--- a/src/vabackend.c
+++ b/src/vabackend.c
@@ -4118,6 +4118,7 @@ static bool destroyEncodeSession(NVContext *nvCtx) {
LOG("destroyEncodeSession context_id=%d begin recycleCudaContextAfterLastSession", (int) nvCtx->contextId);
recycleCudaContextAfterLastSession(drv, "all_sessions_destroyed");
LOG("destroyEncodeSession context_id=%d done recycleCudaContextAfterLastSession", (int) nvCtx->contextId);
+/*
LOG(
"destroyEncodeSession context_id=%d begin reloadGlobalCodecFunctionsAfterLastSession",
(int) nvCtx->contextId
@@ -4127,6 +4128,7 @@ static bool destroyEncodeSession(NVContext *nvCtx) {
"destroyEncodeSession context_id=%d done reloadGlobalCodecFunctionsAfterLastSession",
(int) nvCtx->contextId
);
+*/
}
pthread_mutex_unlock(&drv->objectCreationMutex);
}
@@ -9465,8 +9467,8 @@ static VAStatus nvTerminate( VADriverContextP ctx )
);
} else {
resetProcessTransientState();
- releaseGlobalCodecFunctions();
- LOG("Released global CUDA/NVDEC/NVENC function tables after last instance shutdown");
+ // releaseGlobalCodecFunctions();
+ // LOG("Released global CUDA/NVDEC/NVENC function tables after last instance shutdown");
}
}
The issue is Edit: This issue can't be reproduced with |
|
@thesword53 Thanks, your diagnosis was correct. I updated the PR so the process-global CUDA/NVDEC/NVENC function tables are no longer released or reloaded during normal VA driver instance teardown. They remain valid until the shared library is unloaded. I tested the updated branch with Firefox 154 using 100 H.264 WebRTC create/negotiate/teardown cycles and observed no RDD crash or minidump. The local VA-API runtime matrix also passed all 21 encode/decode cases, and both GCC and Clang 15 CI jobs pass with My Firefox test still does not fully reproduce your original NVIDIA 610.57.04 environment, so could you please retest the current PR head ( |
|
Thanks for the new patches. Encoding is now working without crash with Firefox. |
|
@thesword53 Thanks for confirming that the Firefox crash is fixed. You were also correct about the HEVC 4:4:4 decode profiles. The driver was combining NVDEC and NVENC profiles, then incorrectly advertising I pushed a fix in GCC and Clang 15 CI pass, and the local VA-API runtime matrix passes all 21 cases. Could you please retest the current PR on your GTX 1060 and confirm that |
|
@ntoskrnl7 With your last changes I have |
2 participants
Summary
This PR adds experimental VA-API encode support backed by NVENC while keeping the existing decode-focused behavior intact.
The new encode path exposes
VAEntrypointEncSliceonly after runtime NVENC capability probing, so the advertised profiles should match the target GPU, driver, and NVENC API support.What changed
vainfoandffmpeg.Limitations
This is intentionally experimental and aimed at transcoding-style workloads.
ntoskrnl7/chrome-vaapi-hotpatch; this PR does not make stock Chrome use the driver by itself.Testing
Tested with:
meson testvainfo --display drm --device /dev/dri/renderD128ffmpegVA-API encode/decode checks for H.264 and HEVCdriver-runtime-vaapi-smokeReference validation documented in the README: