Repository navigation
Conversation
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: Resurgamz The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
Reviewer's GuideThe PR enables VAAPI encoding on LoongArch systems whose driver only supports X11 by letting FFmpeg determine hardware availability, trying the existing default backend before an X11 fallback, and initializing/linking Xlib for safe multithreaded access; failed hardware initialization still falls back to software encoding. Sequence diagram for VAAPI device creation with X11 fallbacksequenceDiagram
participant Encoder
participant FFmpeg
participant VAAPI
participant X11
participant SoftwareEncoder
Encoder->>FFmpeg: av_hwdevice_ctx_create(VAAPI, default)
alt Default backend succeeds
FFmpeg->>VAAPI: Initialize default backend
VAAPI-->>FFmpeg: Hardware device
FFmpeg-->>Encoder: VAAPI device ready
else Default backend fails
Encoder->>FFmpeg: av_hwdevice_ctx_create(VAAPI, connection_type=x11)
FFmpeg->>X11: Open X11 VAAPI backend
X11-->>FFmpeg: Hardware device or failure
alt X11 backend succeeds
FFmpeg-->>Encoder: VAAPI device ready
else Hardware initialization fails
FFmpeg-->>Encoder: Error
Encoder->>SoftwareEncoder: Fall back to software encoding
end
end
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
There was a problem hiding this comment.
Hey - I've found 2 issues
Prompt for AI Agents
Please address the comments from this code review:
## Individual Comments
### Comment 1
<location path="libcam/libcam_encoder/encoder.c" line_range="2329-2335" />
<code_context>
- return NULL;
- }
+ /*
+ * 不再调用 check_vaapi_support() 做自定义探测：
+ * 该函数在 X11 显示上调用 vaQueryConfigProfiles(va_display, NULL, ...) 时，
+ * 本机龙芯 VA 驱动(ls2k3000_vpu.so)会因未处理 NULL 列表而段错误；
+ * 且该探测与下面的 av_hwdevice_ctx_create 重复。
+ * 这里直接由 FFmpeg(connection_type=x11) 做真正的可用性判断，
+ * 失败则走 HW_VAAPI_FAIL5 回退软编。
+ */
//assertions
</code_context>
<issue_to_address>
**Missing VAAPI encoder aborts recording**
When VAAPI device creation succeeds but FFmpeg lacks `h264_vaapi`, `encoder_video_init_vaapi` frees `video_codec_data` twice on the missing-encoder path, so the allocator aborts before `encoder_init` can fall back to software encoding.
Free `video_codec_data` only once on the missing-encoder path.
Also at `libcam/libcam_encoder/encoder.c:2391`.
</issue_to_address>
### Comment 2
<location path="src/main.cpp" line_range="117" />
<code_context>
{
+ // 编码子线程会调用 vaGetDisplay()(libva-x11 -> XOpenDisplay)；
+ // 必须在任何 Xlib/Qt 使用之前开启 Xlib 线程安全，否则子线程里 XOpenDisplay 返回 NULL。
+ XInitThreads();
+
// 将日志配置提前，以确保所有日志没有遗漏
</code_context>
<issue_to_address>
**Xlib remains unsafe after initialization failure**
When `XInitThreads()` returns zero, xlib thread support remains disabled, so concurrent Xlib calls from the encoder and GUI threads can race and fail or crash instead of safely using the X11 backend or falling back to software encoding.
Check the return value and avoid concurrent Xlib use or disable the X11 VAAPI attempt when thread initialization fails.
</issue_to_address>
Comment on lines
+2329
to
+2335
| * 不再调用 check_vaapi_support() 做自定义探测： | ||
| * 该函数在 X11 显示上调用 vaQueryConfigProfiles(va_display, NULL, ...) 时， | ||
| * 本机龙芯 VA 驱动(ls2k3000_vpu.so)会因未处理 NULL 列表而段错误； | ||
| * 且该探测与下面的 av_hwdevice_ctx_create 重复。 | ||
| * 这里直接由 FFmpeg(connection_type=x11) 做真正的可用性判断， | ||
| * 失败则走 HW_VAAPI_FAIL5 回退软编。 | ||
| */ |
There was a problem hiding this comment.
🟠 High · Missing VAAPI encoder aborts recording
When VAAPI device creation succeeds but FFmpeg lacks h264_vaapi, encoder_video_init_vaapi frees video_codec_data twice on the missing-encoder path, so the allocator aborts before encoder_init can fall back to software encoding.
Free video_codec_data only once on the missing-encoder path.
Also at libcam/libcam_encoder/encoder.c:2391.
Prompt for AI agents
In `libcam/libcam_encoder/encoder.c` at lines 2329-2335:
**Missing VAAPI encoder aborts recording**
When VAAPI device creation succeeds but FFmpeg lacks `h264_vaapi`, `encoder_video_init_vaapi` frees `video_codec_data` twice on the missing-encoder path, so the allocator aborts before `encoder_init` can fall back to software encoding.
Free `video_codec_data` only once on the missing-encoder path.
Also at `libcam/libcam_encoder/encoder.c:2391`.| { | ||
| // 编码子线程会调用 vaGetDisplay()(libva-x11 -> XOpenDisplay)； | ||
| // 必须在任何 Xlib/Qt 使用之前开启 Xlib 线程安全，否则子线程里 XOpenDisplay 返回 NULL。 | ||
| XInitThreads(); |
There was a problem hiding this comment.
🟡 Medium · Xlib remains unsafe after initialization failure
When XInitThreads() returns zero, xlib thread support remains disabled, so concurrent Xlib calls from the encoder and GUI threads can race and fail or crash instead of safely using the X11 backend or falling back to software encoding.
Check the return value and avoid concurrent Xlib use or disable the X11 VAAPI attempt when thread initialization fails.
Prompt for AI agents
In `src/main.cpp` at line 117:
**Xlib remains unsafe after initialization failure**
When `XInitThreads()` returns zero, xlib thread support remains disabled, so concurrent Xlib calls from the encoder and GUI threads can race and fail or crash instead of safely using the X11 backend or falling back to software encoding.
Check the return value and avoid concurrent Xlib use or disable the X11 VAAPI attempt when thread initialization fails.
Resurgamz
force-pushed
the
fix/vaapi-x11
branch
3 times, most recently
from
October 29, 2026 05:20
bbc64e1 to
f4a0658
Compare
Resurgamz
changed the title
Resurgamz
force-pushed
the
fix/vaapi-x11
branch
2 times, most recently
from
October 29, 2026 07:06
e492b5b to
f4a0658
Compare
Gate the VAAPI hardware encoder behind the hwEncodeStatus DConfig key so the X11 backend fallback and thread-safe Xlib init apply only to the ZY NL60R customization; other models stay software. 将 VAAPI 硬编改为由 hwEncodeStatus 配置门控，X11 后端回退与 Xlib 线程安全仅对卓怡 NL60R 定制生效，其他机型保持软件编码。 Log: 新增卓怡NL60R硬编定制，按配置启用VAAPI PMS: TASK-397321 Influence: 仅卓怡NL60R开启硬编，其他机型软编行为不变。
Resurgamz
force-pushed
the
fix/vaapi-x11
branch
from
October 29, 2026 07:15
f4a0658 to
78a02b3
Compare
deepin pr auto review🤖 AI 代码审查报告总体评分： 📊 总体评价
🔍 详细分析1. 语法逻辑 ❌评价： 存在逻辑缺陷 ❌ 不通过 潜在问题： 建议： ['1. main.cpp中DConfig使用后应delete encodeCfg; 或合并到第170行已有的DConfig创建逻辑中避免重复创建', '2. encoder.c错误处理路径中，free(video_codec_data)之前添加getAvutil()->m_av_dict_free(&(video_codec_data->private_options))'] 2. 代码质量 ✅评价： 代码结构清晰，注释完整 ✅ 通过 潜在问题： 建议： ['1. 使用后delete encodeCfg，或合并到已有的DConfig创建逻辑中', '2. 考虑复用已创建的DConfig对象，避免重复创建'] 3. 代码性能 ✅评价： 性能良好，资源使用合理 ✅ 通过 潜在问题： 建议： [] 4. 代码安全 🔒评价： 存在0个安全漏洞 ✅ 通过
安全漏洞详情： 建议： [] 💡 改进建议代码示例// src/main.cpp - 修复DConfig内存泄漏 #ifdef DTKCORE_CLASS_DConfigFile {
DConfig *encodeCfg = DConfig::create("org.deepin.camera", "org.deepin.camera.encode");
if (encodeCfg && encodeCfg->isValid() && encodeCfg->keyList().contains("hwEncodeStatus")) {
hwEncodeEnabled = encodeCfg->value("hwEncodeStatus").toBool();
}
if (encodeCfg) {
delete encodeCfg;
}
} #endif
// libcam/libcam_encoder/encoder.c - 修复private_options内存泄漏 if ((ret = getLoadLibsInstance()->m_avcodec_open2(video_codec_data->codec_context, video_codec_data->codec, &video_codec_data->private_options)) < 0) {
fprintf(stderr, "ENCODER: could not open VAAPI video codec: %i - fallback to software\n", ret);
getAvutil()->m_av_dict_free(&(video_codec_data->private_options));
free(video_codec_data->codec_context);
video_codec_data->codec_context = NULL;
video_codec_data->codec = 0;
free(video_codec_data);
is_vaapi = HW_VAAPI_FAIL9;
getAvutil()->m_av_buffer_unref(&hw_device_ctx);
fprintf(stderr, "FAIL to encoder_video_init_vaapi:%d.\n", is_vaapi);
return NULL;
}本报告由 AI 代码审查工具自动生成 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
背景
原方案（本 PR 之前）是为龙芯 3B6000M 平台修复 VAAPI 硬编在 X11 下不可用的问题，属于跨平台改动。现将其改造为仅卓怡 NL60R 生效的定制方案，其他机型行为完全不变。
方案
引入 DConfig 开关
org.deepin.camera.encode/hwEncodeStatus（bool，默认false）：true时才在录制时尝试 VAAPI 硬编，并开启XInitThreads()；true，因此只对该机型生效。改动
src/assets/org.deepin.camera.encode.json：新增hwEncodeStatus（默认 false）。src/main.cpp：读取hwEncodeStatus并传给 libcam；仅开启时调用XInitThreads()。libcam/libcam/camview.c/camview.h：新增set_hw_encode_status()/get_hw_encode_status()。libcam/libcam_encoder/encoder.c：encoder_init()按开关决定是否走encoder_video_init_vaapi()；保留 X11 后端回退、跳过重复能力探测、打开编码器失败回退软编等修复。影响
hwEncodeStatus=true（卓怡 NL60R 的 override）时启用 VAAPI 硬编；PMS: https://pms.uniontech.com/task-view-397321.html
Summary by Sourcery
Add a device-specific configuration path for safely enabling VAAPI hardware encoding while preserving existing software encoding behavior elsewhere.
New Features:
Bug Fixes:
Enhancements:
Build:
Deployment: