在浏览器端构建一个媲美“剪映”的视频编辑器，曾经是一个听起来有些天方夜谭的想法。毕竟处理视频流这种高吞吐量的数据，似乎一直是原生应用的专属领地。但随着WebCodecs API的横空出世，浏览器终于撕开了那层封印，让我们Neng够直接在网页中触碰到底层的音视频处理逻辑。这不仅仅是技术的迭代，geng是一场关于前端边界的探索。

本篇文章是对上一篇文章的补充，我们将不再满足于表面的API调用，而是要geng加深入地了解WebCodecs的肌理，以及那些在实现细节中容易让人踩坑的“硬骨头”。Ru果你觉得之前的了解只是皮毛，那么现在让我们开始真正的“解剖”。

从感性认识到理性构建：我们的方法论

在深入代码之前，我想借用毛泽东选集中《实践论》的思想来指导我们的学习路径。这听起来可Neng有些“跨界”，但道理却是相通的。

《实践论》指出：认识的过程，第一步，是开始接触外界事情，属于感觉的阶段。第二步，是综合感觉的材料加以整理和改造，属于概念、判断和推理的阶段。只有感觉的材料十分丰富和合于实际，才Neng根据这样的材料造出正确的概念和论理来。

在WebCodecs的学习中，第一阶段就是“感性认识”。你尝试了各种Demo，跑通了Hello World，甚至成功把一段MP4画在了Canvas上。这时候，你的脑子里充满了零散的知识点：VideoFrame、AudioData、Decoder……但这还不够。

当材料积累到一定程度后就不Neng再停留在零散知识点层面而必须进入第二阶段：整理、归纳、抽象。必须经过思考作用，将丰富的感觉材料加以去粗取精、去伪存真、由此及彼、由表及里的改造制作工夫，造成概念和理论的系统。这就要求我们从“我会用API”跃进到“我理解背后的数据流”。

视频处理的核心：解复用与解码

要实现网页版剪映， 要解决的是视频流的读取与解码。这里有一个核心概念需要厘清：WebCodecs本身并不负责从文件中读取数据，它只负责“解码”和“编码”。

将数据存储到文件中称为复用，从文件中提取数据称为解复用。每种视频文件格式dou有自己的规范，规定了如何在文件中存储元数据和音频/视频数据。WebCodecs之所以不支持解复用，是因为这件事通过JavaScript或者第三方库hen容易实现。而库无法Zuo到在没有浏览器辅助的情况下访问硬件加速的视频编码或解码，这正是 WebCodecs 的核心价值所在。

解复用：拆开包裹

除了上一篇文章提到的MP4box.js，我们还Ke以关注Mediabunny和web-demuxer。

web-demuxer 是用来“拆容器”的，不负责解码，只负责把音视频轨道拆出来。它的作用就像是一个快递员，把包裹里的东西分类拿出来。

比如使用web-demuxer获取特定时间的帧：

import { WebDemuxer } from "web-demuxer";
const demuxer = new WebDemuxer;
// Example: Get video frame at specific time
async function seek {
  // 1. Load video file
  await demuxer.load;
  // 2. Demux video file and generate VideoDecoderConfig and EncodedVideoChunk required by WebCodecs
  const videoDecoderConfig = await demuxer.getDecoderConfig;
  const videoEncodedChunk = await demuxer.seek;
  // 3. Decode video frame through WebCodecs
  const decoder = new VideoDecoder({
    output:  => {
      // Render frame, e.g., using canvas drawImage
      frame.close;
    },
    error:  => {
      console.error;
    }
  });
  decoder.configure;
  decoder.decode;
  decoder.flush;
}

解码：EncodedVideoChunk 到 VideoFrame

解复用后我们拿到的是EncodedVideoChunk。顾名思义，这是Yi编码的视频块，表示编码过的VideoFrame。要从视频文件中读取EncodedAudioChunk，API与视频解码的API非常相似。

WebCodecs是“底层帧级解码”，他Ke以控制什么时候 decode、一块一块喂数据、精确时间戳、自己管理缓冲。这种精细的控制力，是实现精确视频编辑的基础。

在上一篇文章中，我们介绍了通过mp4box.js获取sample，再把sample放入EncodedVideoChunk的data当中。或者使用Mediabunny：

import { EncodedPacketSink, Input, ALL_FORMATS, BlobSource } from 'mediabunny';
const input = new Input({
  formats: ALL_FORMATS,
  source: new BlobSource,
});
const videoTrack = await input.getPrimaryVideoTrack;
const sink = new EncodedPacketSink;
for await ) {
  const chunk: EncodedVideoChunk = packet.toEncodedVideoChunk;
  // 拿到chunk后就Ke以丢给VideoDecoder了
}

关于 VideoFrame 的细节

VideoFrame类表示为像素数据和一些元数据的组合。由于有完整的像素信息，你Ke以把它通过canvas画出来或者交给AI进行处理。

创建VideoFrame有多种方式，既Ke以从图像源创建，也Ke以通过原始二进制数据构建。

Ru果是通过二进制构建，就需要指定formatcodedHeight和codedWidth。需要注意的是由于VideoFrame是存在内存中的，通过二进制传输数据会有内存复制操作，从而产生性Neng开销。

// 通过二进制创建
const pixelSize = 4;
const init = {
  timestamp: 0,
  codedWidth: 200,
  codedHeight: 100,
  format: "RGBA",
};
const data = new Uint8Array;
// ... 填充数据 ...
init.transfer = ;
const frame = new VideoFrame;

问题1：codedHeight 和 displayHeight 的区别

你可Neng会好奇VideoFrame对象为什么既有codedWidth又有displayWidth。这其实与视频压缩算法的工作原理有关。

一段 1080p 视频可Neng使用全部 16x16 的宏块，但你会发现 1080 像素无法被 16 整除。一种解决方法是向上取整，编码 1088 像素，但告诉视频播放器只显示 1080 像素，丢弃多余的数据。因此，codedHeight本质上是编码后的尺寸，而displayHeight才是实际展示的尺寸。对于大多数视频来说它们是相同的，但并非总是如此。为了渲染图像和画布的大小，使用displayWidth和displayHeightgeng安全。

问题2：为什么必须调用 flush？

解码并非简单的异步过程，并不Neng直接await decoder.decode。如上一篇文章的实例代码，我们会kan到decoder.flush。这个函数有什么用呢？

因为解码不仅仅是计算量hen大的功Neng，有时视频包含 B 帧，这些帧需要以与显示顺序不同的顺序进行解码。解码器必须维护一个内部缓冲区才Neng正常工作。Ru果我们一直decoder.decode，由于B帧的存在WebCodecs并不知道这是不是Zui后一帧，所以需要调用decoder.flush来将缓冲区里面的帧全部“吐”出来。Ru果不调用这个函数，那么Zui后几帧可Neng永远不会生成。

当调用了decoder.flush，发送进行处理的下一个数据块必须是关键帧，否则解码器将抛出错误。

音频处理：WebCodecs 与 WebAudio 的博弈

音频的编码和解码比视频的编码和解码容易得多。它运行在 CPU 上，不需要硬件加速。而且，它也没有像B帧那样有依赖关系。但在网页版剪映的实现中，我们需要厘清两个技术栈的分工。

音频数据流转

视频Ke以通过标签渲染，而音频除了有还Ke以通过WebAudio进行播放声音。整个流程Ke以概括为：

压缩音频 
      ↓ 解码 
PCM 
      ↓ 被包装 
AudioData 
      ↓ 再包装 
AudioBuffer 
      ↓ 播放

PCM本质是：原始音频采样数值，比如：，这些数字代表每一个采样点的振幅。

AudioData vs AudioBuffer

当你用AudioDecoder解码时得到的就是AudioData。它本质是：一块带时间信息的 PCM 数据帧。它包含：PCM 数据、timestamp、duration、sampleRate、numberOfChannels。所以AudioData = PCM + 时间戳 + 格式元信息，它的定位是：音频帧。

而AudioBuffer是为 AudioContext 准备的可播放音频资源，它内部其实也是 PCM，但Yi经整理成 Web Audio 需要的结构：

AudioBuffer
├─ channel 0 → Float32Array
├─ channel 1 → Float32Array
├─ sampleRate
└─ length

所以AudioBuffer = 为播放系统准备好的PCM容器，Ke以直接丢进AudioBufferSourceNode进行播放。

问题3：什么时候用WebCodecs，什么时候用WebAudio？

这是一个关键的选择题。

WebAudio是“黑盒解码”。它的定位是“我要把这段音频解开，然后播放或处理。”你不Neng：控制解码帧、控制解码节奏、控制缓存大小、逐帧处理。它的模式如下：

文件 → 一次性解码 → AudioBuffer

Ru果你想实现一个视频播放器，或者只是简单地播放声音，Zui好使用 WebAudio。

const ctx = new AudioContext;
const rawFileBinary: ArrayBuffer = await file.arrayBuffer;
const audioBuffer: AudioBuffer = await ctx.decodeAudioData;
const sourceNode: AudioNode = ctx.createBufferSource;
const gainNode: AudioNode = ctx.createGain;
sourceNode.connect;
gainNode.connect;
sourceNode.start;

而WebCodecs是“底层帧级解码”。它的模式如下：

chunk → PCM
chunk → PCM
chunk → PCM

Ru果你想实现类似剪映这样多媒体编辑，支持导出为视频和纯音频文件，WebCodecs用于实时音频播放、用于视频导出的 WebCodecs、用于纯音频导出的第三方库。你需要对每一帧进行精确的控制，比如剪辑、混音、变调。

处理AudioData

在WebCodecs中解码音频时解码器将返回一个AudioData对象，每个AudioData对象通常代表0.02 - 0.05 秒的音频。

Ru果要读取AudioData的Float32Arrays数据，需要为每个通道创建一个Float32Array，然后调用copyTo方法。

Ru果是格式是f32-planar

const decodedAudio: AudioData = decodeAudio;
for{
    const left = new Float32Array;
    const right = new Float32Array;
    audioData.copyTo;
    audioData.copyTo;
}

Ru果是格式是f32

const decodedAudio: AudioData = decodeAudio;
for{
    const data = new Float32Array;
    audioData.copyTo;
    // 
    const left = new Float32Array;
    const right = new Float32Array;
    for{
        left = data;
        right = data;
    }
}

通过上面的代码，我们就Neng获取音频的二进制数据，我们就Neng对音频进行任意操作了。例如：音频调整声音大小、混合音频、重采样。

与VideoFrame一样，AudioData也会占用大量内存。每秒音频文件的大小约为采样率/s × 2声道 × 4bytes = 44100 * 2 * 4 = 352800 bytes ~ 345 KB，这意味着播放一小时的音频大约需要 1.27GB 的内存。因此，在处理完时也需要调用close释放内存。

格式限制与第三方库

遗憾的是WebCodecs 仅支AAC MP4 文件和Opus WebM 文件的音频，它无法处理 MP3 或其他音频格式。Ru果要导出MP3，只Neng寻求第三方库的帮助了。

Mediabunny 也Ke以通过 ，例如用 WASM 的方式补充这类编码Neng力。Mediabunny 是一个用纯 TypeScript 写的媒体工具箱，Ke以在浏览器里高效操作视频和音频文件，类似于 Web 版的 FFmpeg。

Ru果想实现音频编辑或音频转码，得使用第三方库来处理。

UI实现：时间轴与波形

有了底层的音视频处理Neng力，我们还需要一个像样的编辑器界面。剪映的核心体验之一就是时间轴。

时间轴标尺的实现

我们Ke以使用Canvas来绘制一个高精度的标尺。这里有一个React组件的例子，它处理了缩放级别和刻度自适应的问题。

import { useEffect, useRef } from "react";
interface TimelineRulerProps {
  zoomLevel: number;
}
function TimelineRuler {
  const canvasRef = useRef;
  useEffect => {
    const canvas = canvasRef.current;
    if  return;
    const ctx = canvas.getContext;
    if  return;
    const dpr = window.devicePixelRatio || 1;
    canvas.style.width = `${width}px`;
    canvas.style.height = `24px`;
    canvas.width = Math.floor;
    canvas.height = Math.floor;
    ctx.scale;
    ctx.clearRect;
    // 每秒钟占多少像素
    const pixelsPerSecond = 100 * zoomLevel;
    ctx.fillStyle = "#fff";
    ctx.strokeStyle = "#fff";
    ctx.lineWidth = 1;
    ctx.textAlign = "center";
    ctx.textBaseline = "top";
    // Zui小文字间距
    const minTextSpacing = 50;
    const frameInterval = 1 / 60;
    const intervalOptions = ;
    let mainInterval = 1;
    // 寻找第一个大于Zui小间距的主刻度
    for  {
      if  {
        mainInterval = opt;
        break;
      }
    }
    const formatTime =  => {
      if  {
        const frameNumber = Math.round;
        return `${frameNumber}f`;
      }
      if  {
        return seconds.toFixed + "s";
      }
      const m = Math.floor;
      const s = Math.floor;
      if  return `${m}m`;
      if  return "0s";
      return `${m}:${s.toString.padStart}`;
    };
    // 根据主刻度间隔确定子刻度数量
    let subTickCount = 1;
    if  subTickCount = 1;
    if  subTickCount = 5; // 0.2s
    if  subTickCount = 5; // 1s
    if  subTickCount = 2; // 5s
    const subInterval = mainInterval / subTickCount;
    const rangeEnd = width / pixelsPerSecond;
    const count = Math.ceil + 1;
    for  {
      const time = i * subInterval;
      const x = Math.floor + 0.5;
      if  break;
      ctx.beginPath;
      const isMain =
        Math.abs <0.0001 ||
        Math.abs - mainInterval) <0.0001;
      if  {
        ctx.moveTo;
        ctx.lineTo;
        const text = formatTime;
        ctx.fillText;
      } else {
        ctx.moveTo;
        ctx.lineTo;
      }
      ctx.stroke;
    }
  }, );
  return ;
}
export default TimelineRuler;

音频波形图的实现

本节将实现一个音频波形图的Zui小案例。通过Konva或者直接操作Canvas API，我们Ke以将PCM数据可视化为柱状波形。这需要我们在解码阶段将音频数据缓存下来然后根据时间轴的位置进行绘制。

感性认识阶段，本质上就是“多kan、多试、多踩坑”。这一阶段的核心，不是追求系统性，而是追求广度与真实接触。当你kan到波形随着音乐跳动，那种成就感是无可替代的。

从解复用到解码，从VideoFrame到AudioData，再到时间轴的绘制，我们正在一步步构建起网页版剪映的骨架。这不仅仅是代码的堆砌，geng是对音视频技术体系的重构。

目前，WebCodecs只Neng对原始视频数据——编码过的视频数据这2者进行相互转换。虽然它不支持解复用，也不支持MP3编码，但配合Mediabunny、web-demuxer等工具，我们Yi经拥有了在浏览器端实现复杂视频编辑Neng力的可Neng。

接下来的路还hen长，比如如何实现转场、滤镜，以及如何优化渲染性Neng。但至少现在我们Yi经掌握了打开这扇大门的钥匙。继续探索吧，前方的风景依然迷人。

---