Web 端非线性编辑器

一、产品解决什么问题

传统流程里，剪辑师在本地非编软件里调色、对轨、叠特效，导演或客户往往要等导出成片才能提意见；若涉及远程协作，还要反复传大文件、版本号满天飞。另一条路径是「纯 Web 剪辑」，又容易在重负载合成、插件生态与色彩管理上碰到天花板。

本方案把能力拆成两层：重合成仍在算力与插件更可控的桌面侧完成；需要即时反馈、远程盯片、运营侧改字换条时，则通过流媒体级通道把实时或准实时画面送到浏览器，并在 Web 侧提供与业务匹配的预览、轻量编辑与成片导出能力。这样既不牺牲专业剪辑上限，又能把「看一眼、改一版」的闭环缩到秒级～分钟级。

二、核心能力

多轨道非线性编辑：音视频在时间线上自由对位、剪切、拼接与包装，支撑常规节目与营销短视频生产。
GPU 加速合成预览：复杂叠化、贴纸与多层效果仍保持可操作的预览帧率，减少「改一个参数卡半天」的体验。
桌面专业端：以桌面应用形态承载时间线、素材管理与重度渲染任务，适合长时间剪辑与键盘精操。
浏览器监看与协同：导演、客户或异地同事用浏览器即可监看当前时间线输出，降低传片与对齐成本。
Web 侧延续工作流：在浏览器中完成成片预览、参数微调、导出等；可按业务开放不同深度的编辑能力。
智能辅助Agent：对话形式调用tools，实现编辑意图的智能化辅助，本页实验形态为 LangChain + 本机 Ollama（Qwen3:8b），见第七节。
B-Roll Agent：贴纸、动效、多层字幕与图形等可在 Web 链路中验证效果，便于与投放物料规范对齐，本页实验形态为 LangChain + 本机 Ollama（Qwen3:8b），见第七节。

三、Demo 说明

下列五段演示视频按推荐顺序播放，对应从桌面专业剪辑到浏览器预览 / 编辑 / 导出，再到智能辅助与复杂包装的完整故事线。

桌面端 · 剪辑与预览：时间线操作与实时画面回显。
浏览器端 · 预览与导出：无需安装重型软件即可查看结果并导出成片。
浏览器端 · 编辑与预览联动：在 Web 上直接调整时间线并即时看到合成结果。
浏览器端 · 智能辅助：与智能化能力结合的交互演示（如脚本、分镜或参数建议）。
浏览器端 · 复杂效果：多层动效与装饰元素的合成表现。

四、Demo 演示

视频为 MP4 格式，可直接在常见浏览器中播放。

五、技术说明

技术栈

图形与合成：OpenGL 或等价 GPU 图形接口承担画布合成、纹理上传与特效链路；桌面侧可结合原生窗口与高性能渲染循环。
桌面宿主：Electron（Chromium + Node）用于整合 Web UI 与本地原生模块，主进程与渲染进程分工，便于复用 C++ 编解码与渲染动态库。
Web 渲染：浏览器侧通过 WebGL / Canvas 或 WebAssembly 承载与桌面侧语义对齐的预览与编辑渲染路径（具体模块划分依工程裁剪）。
实时传输：WebRTC 用于低延迟视频流；信令由 LiveServer 内嵌的 Socket（如 WebSocket）承载，与 SRTP 媒体面分离，实现监看端与剪辑端的秒级反馈；可配合 STUN/TURN 策略适配跨网段场景。
语言与构建：性能敏感路径以 C++ 为主；脚本与工具链可用 Node / Shell；工程组织上常见 CMake 或各平台 IDE 工程。
媒体处理：时间线解码、封装与导出侧可衔接 FFmpeg 等成熟组件，保证格式覆盖与工程可控性。
智能化（本机实验形态）：对话式辅助走 LangChain 发起调用，经其 HTTP 接口对接本机 Ollama 暴露的 API；模型为 Qwen3:8b 量级（磁盘约 5GB 档的小模型），跑在 Mac 笔记本本地。详见下文第七节。

实现原理（概要）

整体可抽象为：时间线与素材语义 → 合成图（帧缓冲）→（可选）编码为视频流或文件 → 传输 → 对端解码与呈现。桌面端负责「算得动、对得准」的重度合成；浏览器端消费同一套协议或中间表示，做轻量交互、监看与导出，从而降低多端分裂带来的色差、帧错位与重复导出。

智能化能力通常以异步服务或本地插件形式接入：当前实验链路由 LangChain 经 HTTP 调用本机 Ollama 拉取生成结果，再解析为结构化建议（分镜、文案、参数包等）写回时间线或包装轨道，避免在实时预览线程内阻塞用户操作。

六、专题：WebRTC 下 Native 与 Web 的交互（只推只收 + 信令）

监看链路可以刻意做成单向媒体：Native（桌面 / LiveServer 一类进程）只负责发送音视频轨；浏览器端只接收并渲染，不向对端回推摄像头 / 麦克风画面。这样外端权限简单、带宽与隐私边界清晰，也避免在监看页误开上行导致回声或多余编码。

信令（Signaling）不在 WebRTC 标准里规定传输方式，但必须有一条可靠、有序的通道，用来交换 SDP（会话描述：编解码、SSRC、方向等）与 ICE candidate（网络路径候选）。在本工程形态里，信令并不是单独拆出去部署的微服务，而是做在 LiveServer 进程内部：用 Socket（实现上常见为 WebSocket）在固定端口监听，浏览器作为客户端连上来，完成 SDP/ICE 的文本往返；LiveServer 内再把消息交给同一进程里的 WebRTC 栈。音视频则仍走 WebRTC 媒体面（SRTP），与 Socket 控制面分离——本机预览时常落在回环上，跨 NAT 时再按需走 STUN/TURN，Socket 通道不承担 RTP 媒体载荷。

6.1 角色与媒体方向

Native 发送端：从时间线合成结果得到编码后的帧（或硬件编码器输出），通过 WebRTC 栈作为 sendonly（或等价「仅出站」）轨挂到 RTCPeerConnection；不订阅浏览器侧的上行轨。
Web 接收端：使用标准 RTCPeerConnection，以 recvonly 或「只添加远端轨、本地不调用 addTrack 做上行」的方式建链；远端 ontrack 里把 MediaStream 绑到 <video> 即可监看。
编辑协议（可选）：时间线 JSON、参数同步等可走 LiveServer 同一 Socket 上的独立消息类型，或单独 RTCDataChannel；与单向音视频并不冲突，但需在业务层区分「控制消息」与「媒体轨」。

6.2 LiveServer 内 Socket 信令与建链顺序

典型顺序如下（信令端口随 LiveServer 拉起；同机实验时 ICE 常落在回环地址上）：

Web 与 LiveServer 内置的 Socket 服务（如 WebSocket）建立长连接，完成会话 / 房间注册等应用层约定。
LiveServer 内在 WebRTC 栈创建 offer（SDP），由 Socket 线程将 SDP 推给浏览器。
Web 将远端描述设为该 offer 后生成 answer，经同一 Socket 连接回传；LiveServer 写入本端 RTCPeerConnection。
ICE candidate 仍以文本消息在 Socket 上双向交换（可 trickle），直到 ICE 连通。
媒体面为浏览器 RTCPeerConnection 与 LiveServer 内 PeerConnection 之间的 SRTP，与 Socket 控制面分离；跨复杂网络时再经 TURN 等，与是否内嵌信令无关。

flowchart LR
  subgraph LS["LiveServer（Native，单进程）"]
    ENC[时间线合成与编码] --> PCN["PeerConnection sendonly"]
    SOCK["内置 Socket 信令\n如 WebSocket 监听"]
    SOCK -.->|进程内交给 WebRTC| PCN
  end
  subgraph WEB["Web 接收端"]
    CLI["Socket 客户端"]
    PCW["PeerConnection recvonly"]
    VID[video 元素渲染]
    CLI <-->|SDP / ICE 文本| SOCK
    PCW --> VID
    PCW <-->|SRTP 媒体| PCN
  end

图：信令跑在 LiveServer 内的 Socket 上，不经单独「信令微服务」；媒体仍为 WebRTC SRTP。单向监看时 LiveServer 侧 sendonly、Web 侧 recvonly。

与本方案同源的开源形态、本机 WebSocket 端口与浏览器 API 细节，见技术文章《基于 WebRTC 实现的端到端渲染预览》。

七、专题：本地大模型调用（Qwen3:8b · Ollama · LangChain HTTP）

Demo 中「对话驱动编辑」一类能力，走的是完全本地化的实验栈：Qwen3:8b 作为主力模型（约 5GB 量级的「小」模型权重，相对云端大参数量级而言），通过 Ollama 部署在 Mac 笔记本上常驻服务；业务侧统一用 LangChain 去调大模型——在本地通过 LangChain 提供的 HTTP 风格接口（对接 Ollama 兼容的 REST 端点）发起请求、拿回文本，再交给上层解析成时间线或指令，而不是在应用里手写裸 HTTP 拼 prompt。

7.1 部署与调用路径

模型：Qwen3:8b（8B 参数档；本机磁盘占用约 5GB 量级，视量化与打包略有浮动）。
推理服务：Ollama 在 Mac 上拉起本地进程，对外暴露兼容的 HTTP API（典型为 localhost 端口，由 Ollama 管理）。
应用集成（强调点）：由 LangChain 封装对 Ollama 的访问——使用其面向本地服务的 HTTP 客户端 / Chat 模型封装，统一处理请求体、流式或非流式响应与错误重试边界；应用代码主要与 LangChain 的链或 Runnable 打交道，再取回字符串或结构化结果。

7.2 为何刻意放在本机

这样可以在不外传素材与提示词的前提下联调整条「自然语言 → 协议 / 编辑意图」链路，也方便与 Electron / 本地渲染进程放在同一台开发机上调试。代价是算力与内存都压在笔记本上，和云端大模型相比，首 token、整段生成的延迟会明显更大，交互上要有「等一等」的预期。

7.3 体验与效果边界（如实说明）

在 Mac 笔记本本地跑 8B 档模型，速度偏慢是常态：并发一高、上下文略长，或同时开着非编与预览，都会进一步拉长响应时间。效果上，与当前一线云端大模型或更大参数量相比，指令遵循、长上下文稳定性与「剪辑领域」细节仍会差一截——更适合做原型验证、离线演示与可控成本的迭代；若要做严肃生产，通常会换成更强算力、更大模型或经微调的专用小模型，并重新评估 LangChain 链路与延迟预算。

flowchart LR
  UI[对话 / 编排] --> LC["LangChain\nHTTP 调用封装"]
  LC -->|"Ollama REST"| OLL["Ollama 本机服务\nQwen3:8b 约 5GB"]
  OLL -->|生成文本| LC
  LC -->|解析后写回| UI

图：由 LangChain 走 HTTP 调 Ollama；Qwen3:8b 由 Ollama 加载在 Mac 本机。与 WebRTC / 渲染可同机并存，职责分离。