简介：这是一套基于Qt 5.8开发的跨平台音视频播放器工程，面向音视频开发初学者与嵌入式多媒体应用开发者，解决多路实时流与本地文件的高效解码、渲染与交互控制问题。资源包含1090个文件，以785个C++头文件（h）和32个源文件（cpp）构成核心逻辑，辅以132个动态链接库（dll）、44个静态库（lib）及多路播放配置文件（ini），整体压缩后274.2MB，结构完整、模块清晰，便于理解软硬解码集成与OpenGL渲染优化路径。已有983人学习下载，代码全程注释，涵盖FFmpeg 5.1封装（ctffmpeg.cpp）、DXVA2硬解适配、QOpenGLWidget重写实现YUV→RGB GPU加速、多分屏管理（multivideowidget.cpp）及MP4录像（mp4recorder.cpp）等关键模块，可直接编译运行并深入剖析音视频同步、RTSP拉流、音量调节与进度跳转等实战细节。

1. 这不是又一个“Hello World”播放器：QT音视频框架里真正要啃的硬骨头

你打开 Qt Creator，新建一个 Widget 项目，拖几个按钮、加个 QLabel，跑通 QMediaPlayer + QVideoWidget —— 然后发现：单路本地 MP4 播得挺好，但一接 RTSP 流就卡死；想调音量，发现 setVolume() 对 H.265 实时流完全无效；截图保存成 PNG 后颜色发绿；切换软解/硬解时程序直接崩溃；进度条拖动后画面停顿 3 秒才响应……这些不是配置疏漏，而是 QT 音视频开发中绕不开的底层断层：Qt Multimedia 模块在 5.15+ 版本中已明确标记为「deprecated」，官方推荐路径转向 Qt AV（QtAV）或自建基于 FFmpeg 的 Pipeline。本篇不讲“如何用 QMediaPlayer 播放一个文件”，而是聚焦标题中所有能力点——单/多路、软硬解、YUV/RGB 显示、录像截图、实时流低延迟——全部基于 Qt 5.15.2 + FFmpeg 6.1 + OpenGL 渲染管线 的实操闭环。适合已有 Qt GUI 开发经验、熟悉 C++11、需落地工业级音视频终端的工程师。新手可照着命令和参数跑通最小 demo；老手能从中拿到硬解设备枚举逻辑、YUV→RGB 色域转换精度控制、多路同步时钟对齐等真实战场细节。

2. 从 Qt Multimedia 切换到 FFmpeg Pipeline：为什么必须重写渲染链路

2.1 Qt Multimedia 的弃用本质与 FFmpeg 的不可替代性

Qt 5.15.2 官方文档明确标注 QMediaPlayer 和 QVideoWidget 为 deprecated，核心原因有三：第一，其底层依赖平台原生媒体框架（Windows 上是 DirectShow / Media Foundation，Linux 是 GStreamer），导致跨平台行为不一致——比如同一 RTSP URL 在 Windows 上自动启用硬件加速，Linux 下却强制软解且无错误提示；第二，不支持 YUV 原始帧直出，所有视频帧经内部转换为 RGB32 后再送显，造成 YUV420P → RGB 色彩失真（尤其监控场景常见 BT.601 色域）；第三，无法控制解码器实例生命周期，多路播放时内存泄漏频发。而 FFmpeg 6.1 提供统一 API 层： avcodec_open2() 可显式选择 h264_qsv （Intel Quick Sync）、 h264_nvenc （NVIDIA）、 h264_rkmpp （Rockchip），且 AVFrame->data[] 直接暴露 YUV 平面指针，为后续 OpenGL 纹理上传打下基础。这不是“更高级的轮子”，而是解决标题中“软硬解码”“YUV 显示”“实时流低延迟”的唯一可行路径。

2.2 构建最小可运行 FFmpeg + Qt 渲染环境

提示：以下步骤基于 Windows 10 + MSVC2019 x64 + Qt 5.15.2。Linux 用户将 *.dll 替换为 *.so ，路径分隔符改为 / 即可。

首先下载预编译 FFmpeg 6.1 dev 包（推荐 https://github.com/BtbN/FFmpeg-Builds 的 release-essentials 版本），解压后得到 include/ 、 lib/ 、 bin/ 三目录。在 Qt Creator 的 .pro 文件中添加： 

# .pro 文件关键配置
QT += core widgets opengl
CONFIG += c++11
DEFINES += __STDC_CONSTANT_MACROS

# FFmpeg 头文件路径
INCLUDEPATH += $$PWD/ffmpeg/include

# FFmpeg 库路径与链接项（按实际路径调整）
LIBS += -L$$PWD/ffmpeg/lib \
        -lavcodec -lavformat -lavutil -lswscale -lswresample \
        -lopengl32 -lgdi32

# Windows 下必须复制 DLL 到可执行目录
win32: PRE_TARGETDEPS += $$PWD/ffmpeg/bin/avcodec-60.dll \
                          $$PWD/ffmpeg/bin/avformat-60.dll \
                          $$PWD/ffmpeg/bin/avutil-58.dll \
                          $$PWD/ffmpeg/bin/swscale-7.dll

编译前验证 FFmpeg 是否可用：新建 main.cpp ，加入测试代码： 

#include <QDebug>
extern "C" {
#include <libavcodec/avcodec.h>
#include <libavformat/avformat.h>
}
int main(int argc, char *argv[]) {
    av_log_set_level(AV_LOG_WARNING);
    qDebug() << "FFmpeg version:" << av_version_info(); // 输出类似 "n6.1"
    qDebug() << "Libavcodec build:" << LIBAVCODEC_VERSION_INFO;
    return 0;
}

若输出版本号且无链接错误，则环境搭建成功。注意： 不要使用 Qt 官方维护的 qt5-ffmpeg 插件 ——它仅封装了旧版 FFmpeg 4.x，不支持 AV1 解码与 Vulkan 后端，且硬解设备枚举接口缺失。

2.3 解码器选择策略：软解与硬解的动态切换逻辑

标题要求“支持软硬解码”，关键不在“能切”，而在“何时切、怎么切”。硬解虽省 CPU，但存在三大限制：设备独占（如 Intel QSV 同一时刻仅支持 2 路 1080p）、色彩空间固定（多数硬解器只输出 NV12，不支持 P010）、无 B-frame 丢弃控制（导致低延迟场景花屏）。因此，我们设计三级解码策略：

场景类型 推荐解码器 触发条件 参数设置
本地高清文件（MP4/H.264） h264_qsv （Intel）
h264_nvenc （NVIDIA） 		av_hwdevice_ctx_create() 成功且 codec->capabilities & AV_CODEC_CAP_HARDWARE av_dict_set(&opts, "low_latency", "1", 0)
RTSP 实时流（H.264/H.265） h264_cuvid （NVIDIA）
hevc_cuvid （NVIDIA） 		流 URL 含 rtsp:// 且 av_find_input_format("rtsp") 返回非空 av_dict_set(&opts, "refcounted_frames", "1", 0)
低性能设备/调试模式 libx264 （软解） 硬解初始化失败或 avcodec_open2() 返回负值 av_dict_set(&opts, "threads", "4", 0)

核心代码片段（解码器打开逻辑）： 

AVCodecContext* create_decoder_context(const char* url, AVCodecParameters* par) {
    const AVCodec* codec = nullptr;
    AVCodecContext* ctx = nullptr;
    AVDictionary* opts = nullptr;

    // 1. 根据 URL 类型预判解码器
    bool is_rtsp = strstr(url, "rtsp://") != nullptr;
    bool is_h265 = par->codec_id == AV_CODEC_ID_HEVC;

    if (is_rtsp && !is_h265) {
        codec = avcodec_find_decoder_by_name("h264_cuvid");
    } else if (is_rtsp && is_h265) {
        codec = avcodec_find_decoder_by_name("hevc_cuvid");
    } else {
        // 本地文件优先硬解
        codec = avcodec_find_decoder_by_name("h264_qsv");
        if (!codec) codec = avcodec_find_decoder_by_name("h264_nvenc");
        if (!codec) codec = avcodec_find_decoder(AV_CODEC_ID_H264);
    }

    ctx = avcodec_alloc_context3(codec);
    avcodec_parameters_to_context(ctx, par);
    
    // 2. 硬解需创建硬件设备上下文
    if (codec && (codec->capabilities & AV_CODEC_CAP_HARDWARE)) {
        AVBufferRef* hw_device_ctx = nullptr;
        int ret = av_hwdevice_ctx_create(&hw_device_ctx, AV_HWDEVICE_TYPE_QSV,
                                         nullptr, nullptr, 0);
        if (ret >= 0) {
            ctx->hw_device_ctx = av_buffer_ref(hw_device_ctx);
            av_dict_set(&opts, "low_latency", "1", 0); // 关键！RTSP 必设
        }
    }

    // 3. 打开解码器
    int ret = avcodec_open2(ctx, codec, &opts);
    if (ret < 0) {
        qWarning() << "Failed to open decoder:" << av_err2str(ret);
        // 回退到软解
        avcodec_free_context(&ctx);
        codec = avcodec_find_decoder(par->codec_id);
        ctx = avcodec_alloc_context3(codec);
        avcodec_parameters_to_context(ctx, par);
        avcodec_open2(ctx, codec, nullptr);
    }
    return ctx;
}

注意： av_hwdevice_ctx_create() 的返回值必须检查。Intel QSV 在某些主板 BIOS 中被禁用时会静默失败，此时必须降级到软解，否则整个播放器卡死无日志。

3. YUV 原始帧到 OpenGL 纹理的零拷贝渲染：解决色彩失真与性能瓶颈

3.1 为什么 QLabel/QGraphicsView 无法胜任 YUV 显示

标题明确要求“YUV 与 RGB 显示”，这绝非 UI 控件切换那么简单。 QLabel::setPixmap() 内部强制将输入图像转为 QImage::Format_RGB32 ，而 YUV420P（最常见监控格式）到 RGB 的转换默认使用 ITU-R BT.601 标准，但多数摄像头厂商输出的是 BT.709（高清标准）。一次转换误差约 15% 色彩偏移，叠加 Qt 自身 RGB Gamma 校正，最终显示严重泛白或偏青。更致命的是， QImage 构造函数会执行深拷贝——1080p YUV420P 帧需 3MB 内存拷贝，60fps 下每秒 180MB 带宽，远超 PCIe 3.0 x4 的理论带宽上限（~4GB/s），成为多路播放的性能天花板。

3.2 OpenGL 多纹理绑定方案：NV12/YUV420P 原生支持

我们采用 OpenGL ES 3.0 兼容方案（全平台支持），对 YUV420P 帧使用三纹理绑定（Y/U/V 平面分离），对 NV12（Intel/NVIDIA 硬解输出）使用双纹理（Y + UV 平面合并）。核心步骤：

  1. 创建 OpenGL 上下文（继承 QOpenGLWidget ）
  2. 为每帧 YUV 数据生成三个 GLuint 纹理 ID
  3. 使用 glTexSubImage2D() 直接写入 AVFrame->data[0/1/2] 指针，避免 memcpy
  4. 编写 GLSL 片元着色器完成 YUV→RGB 转换（支持 BT.601/BT.709 切换）

关键 OpenGL 初始化代码： 

// 在 QOpenGLWidget::initializeGL() 中
void VideoGLWidget::initializeGL() {
    initializeOpenGLFunctions();
    
    // 创建 YUV 三平面纹理
    glGenTextures(3, m_yuvTextures);
    for (int i = 0; i < 3; ++i) {
        glBindTexture(GL_TEXTURE_2D, m_yuvTextures[i]);
        glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
        glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
        glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE);
        glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE);
    }
    
    // 编译着色器（此处省略 shader source，见下表）
    m_program.addShaderFromSourceCode(QOpenGLShader::Vertex, vertexShaderSource);
    m_program.addShaderFromSourceCode(QOpenGLShader::Fragment, fragmentShaderSource);
    m_program.link();
}

3.3 GLSL 着色器中的色域控制：BT.601 与 BT.709 的精确切换

YUV→RGB 转换系数由色域标准决定。BT.601（标清）与 BT.709（高清）的 Y 系数差异达 12%，直接导致肤色还原错误。我们在 GLSL 中通过 uniform 变量动态切换： 

// fragment.glsl
uniform sampler2D yTexture;
uniform sampler2D uTexture;
uniform sampler2D vTexture;
uniform float yuvMode; // 0.0=BT.601, 1.0=BT.709

void main() {
    vec3 yuv;
    yuv.x = texture(yTexture, texCoord).r;
    yuv.y = texture(uTexture, texCoord).r - 0.5;
    yuv.z = texture(vTexture, texCoord).r - 0.5;

    vec3 rgb;
    if (yuvMode < 0.5) { // BT.601
        rgb.r = yuv.x + 1.402 * yuv.z;
        rgb.g = yuv.x - 0.344 * yuv.y - 0.714 * yuv.z;
        rgb.b = yuv.x + 1.772 * yuv.y;
    } else { // BT.709
        rgb.r = yuv.x + 1.5748 * yuv.z;
        rgb.g = yuv.x - 0.1873 * yuv.y - 0.4681 * yuv.z;
        rgb.b = yuv.x + 1.8556 * yuv.y;
    }
    gl_FragColor = vec4(rgb, 1.0);
}

C++ 端控制色域切换： 

// 在 paintGL() 中
void VideoGLWidget::paintGL() {
    glClear(GL_COLOR_BUFFER_BIT);
    
    // 绑定 YUV 纹理
    glActiveTexture(GL_TEXTURE0);
    glBindTexture(GL_TEXTURE_2D, m_yuvTextures[0]); // Y
    glActiveTexture(GL_TEXTURE1);
    glBindTexture(GL_TEXTURE_2D, m_yuvTextures[1]); // U
    glActiveTexture(GL_TEXTURE2);
    glBindTexture(GL_TEXTURE_2D, m_yuvTextures[2]); // V
    
    // 传递色域模式（根据摄像头型号自动识别）
    GLint yuvModeLoc = m_program.uniformLocation("yuvMode");
    glUniform1f(yuvModeLoc, m_isBT709 ? 1.0f : 0.0f);
    
    // 绘制全屏四边形
    m_vao.bind();
    glDrawArrays(GL_TRIANGLE_STRIP, 0, 4);
}

提示： m_isBT709 不应由用户手动选择，而应在 RTSP SDP 解析阶段读取 a=fmtp: 行中的 colorimetry=bt709 字段自动设置。本地文件则通过 AVStream->codecpar->color_space 获取（ AVCOL_SPC_BT709 或 AVCOL_SPC_BT470BG ）。

4. 多路同步播放与实时流低延迟控制：时钟对齐与缓冲区策略

4.1 多路播放的时钟漂移问题：为什么简单启停无法同步

标题要求“支持单路与多路播放”，但多路并非简单复制解码线程。实测发现：4 路 1080p RTSP 流在相同硬件上，各路解码耗时方差达 ±12ms，单纯靠 QTimer::singleShot() 触发渲染会导致画面不同步（最慢一路拖慢整体）。根本原因是 FFmpeg 的 av_read_frame() 默认启用内部缓冲（ AVFormatContext->max_delay 默认 500000us），且各路 AVPacket 时间戳（DTS/PTS）基于各自流的时钟基（ AVStream->time_base ）计算，未做全局归一化。

解决方案：建立主控时钟（Master Clock），所有解码线程以该时钟为基准进行帧调度。主时钟源必须来自其中一路流（通常选第一路），其他路通过 av_rescale_q() 将自身 PTS 转换到主时钟时间基： 

// 主时钟类（单例）
class MasterClock {
public:
    static MasterClock& instance() { static MasterClock inst; return inst; }
    AVRational getBaseTimeBase() const { return m_baseTimeBase; }
    int64_t getMasterPts() const { return m_masterPts; }
    
    void updateMasterPts(int64_t pts, AVRational tb) {
        if (m_baseTimeBase.num == 0) {
            m_baseTimeBase = tb; // 锁定第一路的时间基
        }
        int64_t pts_us = av_rescale_q(pts, tb, AV_TIME_BASE_Q);
        if (pts_us > m_masterPts) m_masterPts = pts_us;
    }
private:
    AVRational m_baseTimeBase = {0};
    int64_t m_masterPts = 0;
};

// 在解码线程中
void decodeThread() {
    while (running) {
        AVPacket pkt;
        int ret = av_read_frame(fmt_ctx, &pkt);
        if (ret < 0) break;
        
        // 将当前流 PTS 转换到主时钟时间基
        AVRational src_tb = stream->time_base;
        int64_t pts_us = av_rescale_q(pkt.pts, src_tb, AV_TIME_BASE_Q);
        int64_t master_pts = MasterClock::instance().getMasterPts();
        
        // 计算该帧应在主时钟下的显示时间
        int64_t target_us = pts_us + (master_pts - pts_us) * 0.3; // 0.3 为平滑系数
        
        // 丢弃过期帧（延迟 > 200ms）
        if (av_gettime_relative() - target_us > 200000) {
            av_packet_unref(&pkt);
            continue;
        }
        
        // 解码并推送至渲染队列（带 target_us 时间戳）
        ...
    }
}

4.2 实时流低延迟关键参数：从网络层到渲染层的全链路调优

RTSP 流端到端延迟 = 网络传输延迟 + 解码延迟 + 渲染延迟。标题中“实时视频播放”要求总延迟 ≤ 300ms，需逐层优化：

层级 参数 推荐值 作用
网络层 rtsp_transport tcp （非 udp ） UDP 易丢包导致解码卡顿，TCP 虽增 20ms 延迟但保障连续性
协议层 stimeout 5000000 （5秒） 防止网络抖动时 av_read_frame() 长阻塞
解码层 skip_frame AVDISCARD_NONREF 跳过非参考帧（B帧），降低解码耗时 15%
渲染层 OpenGL glFinish() 禁用 改用 glFlush() + 双缓冲，避免 GPU 管线阻塞

关键 FFmpeg 打开选项设置： 

AVDictionary* rtsp_opts = nullptr;
av_dict_set(&rtsp_opts, "rtsp_transport", "tcp", 0);
av_dict_set(&rtsp_opts, "stimeout", "5000000", 0);
av_dict_set(&rtsp_opts, "buffer_size", "2097152", 0); // 2MB 缓冲
av_dict_set(&rtsp_opts, "reorder_queue_size", "0", 0); // 禁用帧重排

// 打开 RTSP 流
if (avformat_open_input(&fmt_ctx, url, nullptr, &rtsp_opts) < 0) {
    qCritical() << "Cannot open RTSP stream";
}

注意： reorder_queue_size=0 强制禁用 FFmpeg 内部帧重排队列，配合 skip_frame=AVDISCARD_NONREF ，可将解码延迟从 120ms 降至 45ms（实测海康 DS-2CD3T47G2-L 流）。

5. 录像截图与音量调节的工程化实现：避免常见陷阱

5.1 截图功能：YUV 帧直接转 PNG/JPEG 而非屏幕抓取

标题要求“录像截图”，但 QScreen::grabWindow() 截的是 OpenGL 渲染后的 RGB 图像，存在两大缺陷：一是色彩已受 GLSL 转换影响，无法还原原始 YUV 数据；二是多路播放时截到的是当前激活窗口，非目标路视频。正确做法是截取解码后的 AVFrame 原始数据。

对于 YUV420P 帧，使用 sws_scale() 转为 RGB24 后编码： 

void saveScreenshot(AVFrame* yuvFrame, const QString& filename) {
    // 1. 创建 RGB24 输出帧
    AVFrame* rgbFrame = av_frame_alloc();
    rgbFrame->format = AV_PIX_FMT_RGB24;
    rgbFrame->width = yuvFrame->width;
    rgbFrame->height = yuvFrame->height;
    av_frame_get_buffer(rgbFrame, 32);

    // 2. 创建缩放上下文（复用，避免重复创建开销）
    static SwsContext* swsCtx = nullptr;
    if (!swsCtx) {
        swsCtx = sws_getContext(
            yuvFrame->width, yuvFrame->height, (AVPixelFormat)yuvFrame->format,
            rgbFrame->width, rgbFrame->height, AV_PIX_FMT_RGB24,
            SWS_BILINEAR, nullptr, nullptr, nullptr
        );
    }

    // 3. 执行转换
    sws_scale(swsCtx, yuvFrame->data, yuvFrame->linesize,
              0, yuvFrame->height, rgbFrame->data, rgbFrame->linesize);

    // 4. 编码为 PNG（使用 libpng，非 Qt QImage）
    FILE* f = fopen(filename.toStdString().c_str(), "wb");
    if (f) {
        write_png(f, rgbFrame->data[0], rgbFrame->width, rgbFrame->height,
                  rgbFrame->linesize[0]);
        fclose(f);
    }
    av_frame_free(&rgbFrame);
}

提示： write_png() 函数需自行实现或集成 libpng。 严禁使用 QImage(yuvFrame->data[0], w, h, format) —— QImage 不理解 YUV 布局，会将 Y 平面误读为 RGB，导致截图全绿。

5.2 音量调节：绕过 Qt 音频栈，直接操作 FFmpeg 音频重采样

标题要求“音量调节”，但 QAudioOutput 的 setVolume() 对 FFmpeg 解码的音频流无效，因其工作在播放设备层，而我们的音频解码在 FFmpeg 内部。正确路径是：在 swr_convert() 重采样阶段，对 int16_t PCM 数据做幅度缩放。 

// 音频重采样上下文创建时启用音量控制
SwrContext* swrCtx = swr_alloc_set_opts(nullptr,
    av_get_default_channel_layout(2), AV_SAMPLE_FMT_S16, 44100,
    av_get_default_channel_layout(2), AV_SAMPLE_FMT_FLTP, 44100,
    0, nullptr);
swr_set_matrix(swrCtx, nullptr, 0); // 禁用声道矩阵
swr_init(swrCtx);

// 在音频解码循环中
int16_t* pcm_data = (int16_t*)frame->data[0];
int samples = frame->nb_samples;
for (int i = 0; i < samples * 2; ++i) { // stereo
    float vol = m_volumeLevel; // 0.0 ~ 2.0
    int32_t scaled = (int32_t)(pcm_data[i] * vol);
    pcm_data[i] = (int16_t)qBound(-32768, scaled, 32767);
}

5.3 录像功能：MP4 封装的线程安全写入

录像需同时处理音视频帧时间戳对齐。FFmpeg av_interleaved_write_frame() 要求音视频 DTS 严格递增，而多线程写入易导致顺序错乱。解决方案：使用环形缓冲区 + 单写线程。 

struct AVPacketQueue {
    std::mutex mtx;
    std::queue<AVPacket*> queue;
    size_t maxSize = 1000;
    
    void push(AVPacket* pkt) {
        std::lock_guard<std::mutex> lock(mtx);
        if (queue.size() >= maxSize) {
            av_packet_free(&queue.front());
            queue.pop();
        }
        queue.push(av_packet_clone(pkt));
    }
    
    AVPacket* pop() {
        std::lock_guard<std::mutex> lock(mtx);
        if (queue.empty()) return nullptr;
        AVPacket* pkt = queue.front();
        queue.pop();
        return pkt;
    }
};

// 录像写入线程
void recordThread() {
    while (recording) {
        AVPacket* pkt = packetQueue.pop();
        if (pkt) {
            // 确保 DTS 递增（修正异常时间戳）
            if (pkt->dts != AV_NOPTS_VALUE && pkt->dts <= m_lastDts) {
                pkt->dts = m_lastDts + 1;
            }
            if (pkt->pts != AV_NOPTS_VALUE && pkt->pts <= m_lastPts) {
                pkt->pts = m_lastPts + 1;
            }
            m_lastDts = pkt->dts;
            m_lastPts = pkt->pts;
            
            av_interleaved_write_frame(fmt_ctx, pkt);
            av_packet_free(&pkt);
        }
        QThread::msleep(1);
    }
}

注意： av_interleaved_write_frame() 必须在同一个线程中调用，且 AVFormatContext 不能被多线程共享。每个录像任务应创建独立 AVFormatContext 实例。

本文还有配套的精品资源，点击获取 menu-r.4af5f7ec.gif

Logo
火山引擎视频云技术社区

火山引擎视频云技术社区，是面向 AI 音视频开发者的技术交流平台。这里汇聚源自抖音、豆包等亿级 DAU 产品的 RTC、直播、点播、AI 媒体处理、音视频互动技术，提供接入指南、最佳实践、性能调优、场景案例、Demo 代码、开源项目、白皮书和 API 文档。社区汇聚官方工程师与一线开发者，为 AI 视频通话、数字人、AI 视频处理等应用的开发与落地提供技术支持。

更多推荐

洛雪音乐桌面版完整实战：找歌、攒列表、定制与排障一次讲清

装完洛雪音乐桌面版（lx-music-desktop），很多人卡在同一件事上：歌是搜到了，播放却不一定响得起来，或者听了几首歌就不知道往哪放。这个基于 Electron + Vue 3 开发的开源播放器，默认设置并不刻意迁就新手，但它的五个在线音乐源、本地列表管理、桌面歌词和音效模块，只要按顺序摸一遍，日常使用就足够了。这篇指南按"找歌 → 攒列表 → 调体验 → 进阶玩法 → 故障排查"五个环节

avatar 火山引擎视频云技术社区

基于 WebRTC-Experiment 的 Firefox 屏幕捕获扩展：从自定义域名到 AMO 发布全指南

> 本文以 [Firefox-Extensions/README.md](https://link.gitcode.com/i/d51aa89ee4d31cc869ed4221467fa333) 为主体，结合仓库内 `enable-screen-capturing` 等目录的源码，讲解如何通过 Firefox 扩展为 WebRTC 页面启用屏幕捕获能力：包括扩展的工作原理（preference 白

avatar 火山引擎视频云技术社区

洛雪音乐桌面版：5 个快捷键加 3 个启动参数，把找歌速度提上来

深夜想找那首老歌，搜索页卡了十秒。洛雪音乐聚合多个音乐源，基于 Electron+Vue 3。掌握洛雪音乐快捷键，搜索到播放只需两步。## 洛雪音乐 30 秒上手：打开、搜索、播放1. 打开软件，焦点默认在搜索框（随时按 `F1` 重新聚焦），输入歌名，结果直接出来。2. 单击歌曲即可试听，默认会先加入"我的列表"的试听列表再播放。3. 想连续听多首，按下节的顺序多选并建歌单。[!

avatar 火山引擎视频云技术社区