浏览器环境下的媒体处理已经从简单的文件播放演进到实时采集、处理和传输。JavaScript 不需要依赖 Flash 或任何插件，就能通过标准接口拿到摄像头和麦克风的数据，并在本地进行音频节点处理、视频帧绘制、录制甚至点对点推流。理解这套体系的起点是 MediaStream 对象，它代表一路实时媒体数据，内部由多条 MediaStreamTrack 轨道组成。视频轨道和音频轨道独立存在，意味着可以单独禁用声音、切换摄像头或调节输入增益。
一、媒体流获取：getUserMedia 与轨道模型
如果只是把摄像头画面显示在页面上，核心代码只有几步：调用 navigator.mediaDevices.getUserMedia，传入约束参数，再把返回的流赋给 video 元素的 srcObject 属性。但真正值得理解的是背后那个 MediaStream 的结构。它不是一个扁平的数据缓冲区，而是由多个 MediaStreamTrack 组成，每个 track 都有 kind 属性，值为 video 或 audio。因此一路包含画面和声音的流，至少会有两条轨道。你可以通过 getTracks 方法拿到全部轨道，也可以按类型过滤出来单独控制。
约束参数的作用不只是打开摄像头，它还能影响采集质量。例如 video 约束中的 width、height、frameRate、facingMode 分别控制分辨率、帧率以及前后摄像头选择。audio 约束则可以开启回声消除、噪声抑制和自动增益控制。这些参数并不是所有浏览器都会严格遵循，遇到无法满足的情况时浏览器会尽量匹配接近的值，而不是直接报错。这一点在做移动端适配时尤其重要，你可能会发现同样的约束在桌面端获得 1080p，在部分手机上只能得到 720p。
此外，getUserMedia 只会在安全上下文中工作，也就是 https 或 localhost。如果页面在 http 环境下调用，会直接抛出 NotAllowedError。另一个常见异常是 NotFoundError，通常表示没有找到满足指定约束的摄像头或麦克风。处理这类错误时，除了提示用户检查权限，还可以调用 navigator.mediaDevices.enumerateDevices 获取设备列表，方便在多个摄像头之间切换。
const constraints = {
video: { width: 1280, height: 720, facingMode: "user" },
audio: { echoCancellation: true, noiseSuppression: true }
};
try {
const stream = await navigator.mediaDevices.getUserMedia(constraints);
const video = document.querySelector("video");
video.srcObject = stream;
await video.play();
const tracks = stream.getTracks();
console.log(tracks.map(track => track.kind + ": " + track.label));
} catch (err) {
console.error("获取媒体失败:", err.name, err.message);
}
二、音频流节点化处理：Web Audio API
拿到 MediaStream 之后，如果只是播放声音，直接交给 video 元素就可以。但一旦你想做音量调节、滤波、混音或者可视化波形，就必须引入 Web Audio API。它的核心是 AudioContext，以及由各种 AudioNode 组成的节点图。MediaStreamAudioSourceNode 负责把流中的音频轨道接入节点图，之后可以连接到 GainNode 控制增益，连接 AnalyserNode 获取频域数据，最后再连到 AudioContext.destination 输出到扬声器。
节点图的好处是高度模块化。比如你可以在 GainNode 后面再接一个 BiquadFilterNode，实现低通或高通滤波；也可以同时连接多个 AnalyserNode，一个用于绘制频谱，另一个用于计算音量。由于节点之间传递的是音频信号，整个过程不需要你手动处理 PCM 数据。对于更复杂的实时效果，还可以借助 AudioWorklet 在独立线程中逐样本处理音频，不过它的学习成本明显高于普通节点。
需要注意，AudioContext 在部分浏览器中初始状态是 suspended，尤其是没有用户手势触发时。因此在实际集成中，最好在用户点击按钮后再创建或恢复 AudioContext，否则可能听不到任何声音。另外，MediaStreamAudioSourceNode 只负责读取流，并不会阻断原始流的播放。如果你既想让 video 元素正常出声，又想在节点图中分析数据，只要把 source 连接到 destination 即可，或者保持 video 元素静音，只通过 AudioContext 控制输出。
const audioContext = new AudioContext();
const source = audioContext.createMediaStreamSource(stream);
const gain = audioContext.createGain();
gain.gain.value = 0.8;
const analyser = audioContext.createAnalyser();
analyser.fftSize = 2048;
source.connect(gain);
gain.connect(analyser);
analyser.connect(audioContext.destination);
const buffer = new Uint8Array(analyser.frequencyBinCount);
function draw() {
analyser.getByteFrequencyData(buffer);
requestAnimationFrame(draw);
}
draw();
三、本地录制与屏幕捕获：MediaRecorder 与 captureStream
媒体流除了实时显示和处理，另一个高频需求是本地录制。MediaRecorder 可以把 MediaStream 直接编码成 WebM 等容器格式，使用门槛并不高。它通过 start 和 stop 控制录制过程，在 dataavailable 事件中不断收到分片数据，最后把这些分片合并成一个 Blob。这个 Blob 可以用于预览，也可以创建一个下载链接触发保存。
选择编码格式时最好先检查浏览器支持情况。Chrome 和 Firefox 对 video/webm 支持较好，而 Safari 比较特殊，新版本对 video/mp4 支持更稳定。如果指定了浏览器不支持的 mimeType，MediaRecorder 构造时会抛出异常。因此更稳妥的做法是使用 MediaRecorder.isTypeSupported 做一次能力检测，然后选择第一个可用的格式。
录制场景不仅限于摄像头。屏幕共享通过 getDisplayMedia 获取，它同样返回 MediaStream，因此录制流程几乎一致。另一个容易忽略的场景是 Canvas 动画录制。Canvas 提供了 captureStream 方法，可以把画布里实时绘制的内容转成视频流，再交给 MediaRecorder 录制。这非常适合生成演示视频、教学动画或者纯前端合成的视频内容。配合 requestAnimationFrame，你可以逐帧绘制图形，同时保持视频流连贯输出。
const options = { mimeType: "video/webm;codecs=vp9" };
const recorder = new MediaRecorder(stream, options);
const chunks = [];
recorder.ondataavailable = e => {
if (e.data.size > 0) {
chunks.push(e.data);
}
};
recorder.onstop = () => {
const blob = new Blob(chunks, { type: "video/webm" });
const url = URL.createObjectURL(blob);
const a = document.createElement("a");
a.href = url;
a.download = "recording.webm";
a.click();
URL.revokeObjectURL(url);
};
recorder.start();
setTimeout(() => recorder.stop(), 5000);
四、实时传输与底层解码：RTCPeerConnection 与 WebCodecs
如果要实现视频通话或直播推流，把本地流传给远端就不能靠录制文件了。WebRTC 的 RTCPeerConnection 专门负责实时媒体传输，底层会处理网络地址转换穿透、回声消除、加密传输和带宽自适应。它的基本思路是：先通过 getUserMedia 获取本地流，然后调用 addTrack 把轨道加到连接对象中，接着交换 SDP 描述和 ICE 候选地址，双方完成后就能收到对方的流。
SDP 和 ICE 的交换需要一个信令通道，比如 WebSocket 或者服务端的推送服务。这个信令通道只负责传输控制信息，并不承载音视频数据。也就是说，浏览器之间的媒体数据是点对点传输的，延迟可以降到很低，适合通话场景。RTCPeerConnection 的配置中可以指定 STUN 和 TURN 服务器，前者用于发现公网地址，后者用于在对称 NAT 环境下中继流量。如果没有 TURN 服务器，部分网络环境中的连接可能无法建立。
WebRTC 解决了传输问题，但如果你的需求是处理本地文件中的编码数据，或者自己实现一个解码播放器，那就需要 WebCodecs。它暴露了 VideoDecoder、AudioDecoder、VideoEncoder 等底层接口，可以直接操作编码后的帧数据。相比 MediaRecorder 只能处理完整流，WebCodecs 给了更细粒度的控制，适合做低延迟播放、自定义封装格式解析或者帧级处理。不过它的复杂度也更高，通常不是媒体处理入门的第一步。
const pc = new RTCPeerConnection({
iceServers: [{ urls: "stun:stun.l.google.com:19302" }]
});
stream.getTracks().forEach(track => {
pc.addTrack(track, stream);
});
const offer = await pc.createOffer();
await pc.setLocalDescription(offer);
// 通过信令服务器把 offer 发给对方，收到 answer 后调用 setRemoteDescription
pc.ontrack = event => {
remoteVideo.srcObject = event.streams[0];
};
综合来看，JavaScript 媒体处理并不是某一个单一 API 的任务，而是多个接口围绕 MediaStream 形成的协作体系。可以根据具体场景选择不同组合：只做视频通话就重点掌握 getUserMedia 和 RTCPeerConnection；做音频特效和分析就加上 Web Audio API；做本地录制和动画导出就结合 MediaRecorder 与 captureStream；而需要深入编码层时，再考虑 WebCodecs。把这些接口的职责边界弄清楚，后续遇到复杂需求时就能更准确地选择方案，而不是把所有逻辑堆在一个回调里。
JavaScript媒体处理MediaStreamMediaRecorder修改时间：2026-09-26 13:28:01