简介基于QT开发的Windows客户端C/S架构视频会议项目源码面向Windows平台下需要搭建远程会议系统的开发者、在校学生及中小团队适合作为企业会议、在线培训等场景的工程参考。压缩包共456个文件体积仅4.69MB包含286个PNG图像资源界面图标与背景、70个头文件与30个C源文件业务逻辑、37个C源文件底层算法另有UI布局文件、库文件及DLL动态库便于按模块对照学习。源码中可看到AGC自动增益控制、VAD语音活动检测、重采样等音频处理实现同时提供C/S架构的完整交互链路从界面操作到服务端处理均有代码支撑。当前已有135人学习适合具有基础QT知识、希望深入理解音视频会议实现或进行二次开发的读者。1. 一个带着音频处理C源码的QT视频会议客户端建议按这条路拆拿到这套源码的第一眼很多人的反应是它到底是QT界面工程还是C语言算法库目录里躺着nsx_core.c、analog_agc.c、vad_core.c、fft4g.c这些都是 WebRTC 音频处理模块的源文件不是 QT 自带的东西。这意味着项目并非简单的 C/S 架构客户端外壳而是把降噪、自动增益、静音检测、重采样直接编进采集链路的完整 Windows 视频会议客户端。对需要做云视频会议终端或者想在 QT 工程里集成实时音频预处理的团队这批源码很有拆解价值。适合已经有 QT 基础、想弄明白音视频客户端里 C 代码和 C 如何共存的开发者不适合只打算改界面换肤的读者。2. 从 pro 文件到信号槽先把 QT 客户端工程结构和 C/S 边界理清在编译之前先看工程组织。源码包描述里标了 457 个文件其中 286 个 PNG、70 个头文件、37 个 C 源文件、30 个 C 源文件、5 个 UI 文件还有.lib、.dll、.exp和.pri。这个比例说明界面资源和底层算法占了大部分真正的业务逻辑 C 代码反而被压缩在一个很克制的范围内。这种工程形态在视频会议客户端里很常见QT 只负责窗口、事件和网络状态展示音频采集处理交给 C 模块视频渲染交给QOpenGLWidget或者直接走 GDIQT 的multimedia模块有时只用来做摄像头枚举。从huiyi.pro.user.22和huiyi.pro.user.4.8-pre1这两个文件能看出这个工程被不同版本的 Qt Creator 打开过.pro.user保存的是本地构建配置比如 Qt 版本路径、编译套件和命令行参数。它不该进版本库但在下载源码场景里它反而是有用的线索如果里面写了4.8-pre1说明早期代码可能跑在 Qt 4.8 上后来才迁移到 Qt 5。后面做windeployqt发布时要特别留意这种跨版本迁移留下的QDesktopWidget、QSignalMapper这类已废弃接口。.pri文件是这个源码包比单个.pro更值得关注的地方。.pri是 Qt 的工程分片文件可以把音频引擎、网络层、UI 层拆成独立模块。拆开看的好处是能单独编译算法部分不碰 QT 界面。按常见做法我会先把源码重新组织成下面这种目录形态再开始读huiyi/ ├─ huiyi.pro ├─ audioengine/ │ ├─ ns_core.c │ ├─ analog_agc.c │ ├─ digital_agc.c │ ├─ vad_core.c │ ├─ resample.c │ └─ audioengine.pri ├─ client/ │ ├─ meetingclient.h │ ├─ meetingclient.cpp │ └─ client.pri ├─ ui/ │ ├─ mainwindow.ui │ └─ ui.pri └─ bin/ ├─ *.lib └─ *.dll这不是源码原始结构是按编译依赖整理的阅读结构。.pri文件里通常会有SOURCES 、HEADERS 、INCLUDEPATH 把 C 文件和 C 文件放在一起交给 qmake 统一编译。qmake 识别到.c后缀会调用 C 编译器识别到.cpp会调用 C 编译器所以不会出现 C 函数无法链接的问题但要注意 C 头文件里的extern C是否写全。下面是一段典型的audioengine.priQT - gui CONFIG staticlib TEMPLATE lib INCLUDEPATH $$PWD SOURCES \ ns_core.c \ analog_agc.c \ digital_agc.c \ vad_core.c \ resample.c \ fft4g.c HEADERS \ ns_core.h \ analog_agc.h \ digital_agc.h \ vad_core.h \ resample.h这段配置把音频处理代码编成静态库不依赖 QT 的 GUI 模块。CONFIG staticlib是关键它让后续客户端工程只需链接这一个.lib不需要把十几个 C 文件重复加进主工程。INCLUDEPATH $$PWD是为了让 C 文件之间互相 include 时直接写文件名不用带路径。C/S 架构这部分源码里不会直接标出“Server”和“Client”但 C 文件数量和 UI 文件数量已经说明问题。视频会议客户端通常只做三件事信令连接、音视频采集、音视频编解码。信令一般走QTcpSocket或者QUdpSocket音视频媒体流走 RTP。QT 客户端里比较常见的做法是写一个MeetingClient类继承QObject内部持有QTcpSocket通过信号槽把底层网络事件抛给 UIclass MeetingClient : public QObject { Q_OBJECT public: explicit MeetingClient(QObject *parent nullptr); void connectSignaling(const QString host, quint16 port); void sendJoinRoom(const QString roomId); void sendLeaveRoom(); signals: void joinedRoom(const QString roomId); void remoteVideoFrame(const QByteArray frameData); void remoteAudioFrame(const QByteArray encodedData); void socketError(const QString message); private: QTcpSocket *m_signalSocket; };这个类把网络细节封装在 private 区域UI 层只需要订阅信号。sendJoinRoom里会把房间号拼成 JSON 或者自定义二进制协议通过m_signalSocket-write()发出。joinedRoom信号触发后UI 层才开始创建音频设备实例。这种设计的好处是后续替换信令协议时UI 代码不用动。第 2 章核心是把工程边界划清QT 管交互C/S 管连接C 文件管音频处理。拆源码时先按这个边界过滤不要一头扎进vad_core.c的位运算里。下面是文件类型和用途的速查表类型数量作用PNG286UI 皮肤、按钮、摄像头占位图、加载动画.h70算法接口、网络协议结构体、QT 类声明.c37音频采集处理、FFT、VAD、AGC、重采样.cpp30客户端业务、窗口逻辑、网络封装.ui5登录窗口、主会议窗口、设置窗口.pri4工程分片按模块组织源码3. 把 ns_core.c 和 analog_agc.c 接进采集链路降噪和 AGC 的正确顺序很多人拿到ns_core.c会下意识把它当成普通工具函数直接放到工程里编译结果跑起来全是杂音。原因不是代码有问题而是没有理解它在音频采集链路里的位置。ns_core.c是 WebRTC 噪声抑制Noise Suppression的核心实现负责对 10ms 的音频帧做频谱减除衰减稳态噪声比如空调声、风扇声。和它配套的nsx_core.c是扩展版本计算更复杂降噪效果更强但 CPU 占用也更高。fft4g.c是这两者的底层依赖提供实数 FFT 变换NS 算法需要在频域里区分语音和噪声。analog_agc.c是模拟自动增益控制digital_agc.c是数字自动增益控制。模拟 AGC 在数字转换之前调整麦克风硬件增益数字 AGC 在 PCM 数据进入编码器之前调整样本幅值。视频会议里最典型的问题是离麦克风远的发言者声音小离得近的爆音。AGC 的目的是让语音幅度稳定在编码器最佳输入范围内。增益调太大会放大底噪所以必须先做降噪再做增益。常规处理顺序推荐这样安排麦克风采集 - 重采样 - 降噪 NS - VAD 检测 - 数字 AGC - 编码器降噪放在 VAD 之前能让 VAD 拿到的输入信噪比更高静音判断更准。AGC 放在 VAD 之后是因为 VAD 只需要判断有没有语音不依赖绝对响度而编码器需要稳定的电平所以把增益留在最后一步。模拟 AGC 在驱动层配置一般不在用户态处理链里写死。下面这段代码是按旧版 WebRTC C 接口写的调用示例这个源码包里的ns_core.c和analog_agc.c就是从这套代码演化来的函数命名可以从头文件里确认#include stdint.h #include stdlib.h #include webrtc_ns.h #include webrtc_agc.h #define SAMPLE_RATE 48000 #define FRAME_SIZE (SAMPLE_RATE / 100) // 10ms 一帧 static NsHandle *g_ns NULL; static void *g_agc NULL; static int32_t g_mic_level 128; int audio_preprocess_init(void) { WebRtcNs_Create(g_ns); if (WebRtcNs_Init(g_ns, SAMPLE_RATE) ! 0) { return -1; } WebRtcNs_set_policy(g_ns, 2); // 0 轻柔1 中2 强3 极强 WebRtcAgc_Create((void **)g_agc); if (WebRtcAgc_Init(g_agc, 0, 255, /* AgcMode */ 1, SAMPLE_RATE) ! 0) { return -1; } return 0; } int audio_preprocess_frame(int16_t *pcm) { int16_t saturated 0; WebRtcNs_Process(g_ns, pcm, NULL, pcm, NULL); WebRtcAgc_Process( g_agc, pcm, NULL, FRAME_SIZE, pcm, NULL, g_mic_level, g_mic_level, saturated); return saturated; }参数说明WebRtcNs_Init(g_ns, 48000)里的第二个参数是采样率支持 8000、16000、32000、48000必须跟采集设备一致。如果设备采集 44100需要先重采样到 48000 或初始化成 32000。WebRtcNs_set_policy(g_ns, 2)是降噪强度2 是常用档位。在会议室场景麦克风阵列底噪大我会选 3但代价是语音听起来会偏“干”必须配合 AGC 把响度拉回来。WebRtcAgc_Process的FRAME_SIZE是样本数不是字节数。10ms48kHz 是 480 个样本每个样本是int16_t一个帧占 960 字节。这个参数写错会出现分段错误。g_mic_level是麦克风输入电平状态不能每次传固定值要让 AGC 在多次调用之间累积学习否则碰到大小声交替的发言者增益会来回震荡。还有个容易踩的坑ns_core.c和digital_agc.c内部都依赖fft4g.c的全局缓冲区。如果同一份fft4g.c同时被 NS 和 AGC 使用而两个模块又跑在不同线程需要特别注意重入问题。常见做法是在每个实例里维护独立的ip、w数组或者直接给整个音频处理链加一个互斥锁static CRITICAL_SECTION g_audio_lock; void audio_engine_lock(void) { EnterCriticalSection(g_audio_lock); } void audio_engine_unlock(void) { LeaveCriticalSection(g_audio_lock); }如果采集回调线程和 UI 线程同时调用audio_preprocess_frame不加锁会出现频谱数据错乱表现是噪声忽大忽小、偶尔有脉冲爆音。把锁放在audio_preprocess_init和audio_preprocess_frame外部由调用方保证同一时间只有一个线程进入处理链。下表汇总了这批 C 文件中几个核心文件的角色文件模块核心作用关键函数nsx_core.c噪声抑制扩展版频域降噪保留语音WebRtcNsx_InitWebRtcNsx_Processns_core.c噪声抑制基础版低负载频谱处理WebRtcNs_InitWebRtcNs_Processanalog_agc.c模拟 AGC在模数转换前调节增益WebRtcAgc_AnalogAdaptdigital_agc.c数字 AGC编码前稳定语音电平WebRtcAgc_Processfft4g.cFFT 工具给 NS/AGC 提供频谱计算rdftmakewtvad_core.c语音活动检测判断当前帧是否有语音WebRtcVad_Process4. VAD 和重采样协同静音帧丢弃与采样率切换的工程姿势视频会议客户端如果始终用 48kHz 双声道 PCM 推流一个 10ms 帧是48000 / 100 * 2 * 2 1920字节一个小时光音频就消耗接近 700MB 流量。实际上人声有效带宽主要在 300Hz 到 3400Hz16kHz 采样率足够承载宽带语音。协议允许的情况下常见策略是采集用 48kHz处理完降噪后重采样到 16kHz再用 VAD 判断这一段有没有人声没有语音的帧直接丢弃或者编码成 1~2 字节的舒适噪声包。resample.c和resample_by_2_internal.c在这里的角色是把采集率变换成编码率。resample_by_2_internal.c负责 2 倍和 1/2 倍的重采样resample.c负责任意有理数倍比如 48kHz 到 16kHz 可以拆成两步先 3:1 下采样也可以走一次WebRtcResample_Process。每次重采样都会引入一定幅频失真连续搬移采样率会叠加噪声所以最好一次到位。VAD 的接口在源码包里通常长这样#include webrtc_vad.h static VadInst *g_vad NULL; int vad_init(int sample_rate) { if (WebRtcVad_Create(g_vad) ! 0) { return -1; } return WebRtcVad_Init(g_vad, sample_rate); } int vad_has_speech(const int16_t *frame, size_t samples) { WebRtcVad_set_mode(g_vad, 1); // 0 质量优先1 平衡2 激进3 极激进 return WebRtcVad_Process(g_vad, 16000, frame, (int)samples); }WebRtcVad_Process返回 1 表示检测到语音0 表示静音负数表示参数错误。这里要注意frame必须是 10ms 的整数倍如果采样率是 16kHz一次传 160 个样本。VAD 内部有 hangover 机制在检测到语音结束后会保持一段时间的语音状态不会立刻切到静音所以连续 5 帧静音之后再去丢帧是更稳的做法。简单实现是维护一个计数器static int silent_frame_count 0; int should_drop(const int16_t *frame, size_t samples) { if (vad_has_speech(frame, samples) 1) { silent_frame_count 0; return 0; } silent_frame_count; if (silent_frame_count 5) { return 1; } return 0; }这个逻辑是前 5 个静音帧仍然编码发送让接收端有时间生成舒适噪声第 6 帧开始才真正丢弃。这样不会造成语音尾部被切断也不会让对端因为突然收不到包而触发 PLC 误判丢包。VAD 模式的选择要结合网络带宽和听感下面这个表可以直接抄进需求文档VAD 模式阈值倾向适合场景听感影响0保守带宽充足对音质敏感误杀少但静音包多1平衡默认设置偶尔开启时间稍晚2激进低带宽移动网络语音开头可能被掐掉3极激进嵌入式设备尾音和弱音丢失明显视频会议里 VAD 还有一个隐藏作用给编码器提供帧分类标志。同样的码率下语音帧用更高码率编码静音帧用极低码率编码能省出 30% 到 40% 的音频带宽。这个标志不一定要从音频处理链外面传可以在audio_frame结构体里加一个字段struct AudioFrame { int16_t *data; int samples; int sample_rate; bool has_speech; uint32_t timestamp; };采集线程把WebRtcVad_Process的返回值填进has_speech网络线程根据这个字段决定是走正常音视频通道还是静音通道。这里的核心是 VAD 不要单独跑在另一个线程里它必须和降噪、AGC 共享同一个帧顺序。如果 VAD 拿到的帧基准时间比实际推流晚 30ms连续语音状态下问题不大但在一问一答的会议中第一个音节延迟会非常明显。重采样和 VAD 的顺序上我的建议是VAD 放在重采样之后。原因是 VAD 是按采样率配置的16kHz 下的 VAD 计算量远小于 48kHz而且人声判断本身不需要高频信息。如果把 VAD 放在重采样之前不仅浪费 CPU还可能把高频噪声当成语音触发误报。处理链可以调整成48kHz 采集 - 降噪 - 数字 AGC - 重采样到 16kHz - VAD - 编码resample_by_2_internal.c的存在说明工程里很可能用了多级下采样。源码里如果直接调用WebRtcResample_Process它会根据输入输出采样率自动选择内部系数表。常见的关系可以参考这张表源采样率目标采样率重采样比例建议帧长48000160003:1480 样本输入160 输出48000240002:1480 输入240 输出1600080002:1160 输入80 输出4410016000441:160441 输入160 输出44100 到 16000 不是整数倍重采样会产生比较明显的截止频率偏移所以除非声卡强制锁在 44100否则我会在采集层就请求 48000 采样率。5. 发布时把 QT 插件与 C 运行库一起收好windeployqt 和 dumpbin 的实战检查源码能编译通过只算完成了七成视频会议客户端最终要发给不同机器跑发布阶段最容易出问题的是 Qt 插件目录缺失和 C 运行库版本不匹配。推荐直接从构建目录开始发布先把编译产物归拢到一个干净目录再执行windeployqtmkdir deploy cd build\release windeployqt --release --no-translations huiyi.exe --dir ..\..\deploywindeployqt会复制.exe依赖的 Qt DLL、platforms/qwindows.dll、styles和imageformats插件。--no-translations去掉 Qt 自带的翻译文件对纯中文客户端可以减小体积。如果程序里用到了QMediaPlayer还要额外确认mediaservice或multimedia插件是否被复制视频会议客户端经常漏掉这个。复制完顺手查依赖不要等客户报“无法启动此程序”才回头补 DLL。Windows 下用 Visual Studio 自带的dumpbin最直接dumpbin /dependents deploy\huiyi.exe重点看输出里的Qt5Cored.dll。如果出现带d的调试版 DLL说明编译的是 Debug 版本windeployqt --release不会帮它匹配插件发布包一定跑不起来。正常文件列表应该是Qt5Core.dll、Qt5Gui.dll、Qt5Network.dll、Qt5Widgets.dll以及msvcp140.dll、vcruntime140.dll、vcruntime140_1.dll这类 VC 运行库。目标机器没有装 VC Redistributable 时把对应版本的vc_redist.x64.exe一起放进去。如果 C 源文件是用 Qt 的 MSVC 套件编译的发布包里的运行库版本由编译器决定。用 MinGW 套件则要检查libgcc_s_seh-1.dll、libwinpthread-1.dll这些文件在mingw目录的bin下windeployqt不一定收集完整需要手动复制。一个比 dumpbin 更轻的检查方式是用objdump -pobjdump -p deploy\huiyi.exe | findstr DLL Name这个命令在 Git Bash 和 MSYS2 环境里可用适合不打开 Visual Studio Command Prompt 的场景。但objdump只能列 DLL 名不能分析 Qt 插件依赖所以最终还是要跑一次功能验证。多语言和中文乱码也是发布会碰到的典型问题。Qt 5 的默认编码是 UTF-8如果.cpp文件是从旧工程继承来的 GBK 编码MSVC 编译后中文字符串会出现乱码。在.pro文件里加一行可以规避QMAKE_CXXFLAGS /utf-8如果窗口字体仍然是默认宋体界面上看会显得很挤可以在main函数里统一设置QApplication app(argc, argv); QFont font(Microsoft YaHei, 9); app.setFont(font);qt国际化的处理则要靠tr()包裹所有用户可见字符串再配合lrelease生成.qm文件。这套源码里大量.ui文件里的中文字符串如果没有用tr()包裹后续做英文版本时只能靠重新截图。最后一招是检查huiyi.pro.user.4.8-pre1里的 Qt 版本痕迹。如果工程早期在 Qt 4.8 下开发源码里很可能残留QDesktopWidget::screenGeometry()调用在 Qt 5.15 下还能编译但到了 Qt 6 直接移除。迁移时优先把这类 API 替换成QScreen::availableGeometry()。发布前在虚拟机里装一个干净的 Windows Server 或 Win10不装开发环境跑一遍加入会议、打开摄像头、静音检测三个主要路径这一步能筛掉绝大多数 DLL 缺失和插件路径问题。本文还有配套的精品资源点击获取