在线流媒体技术演进：从 Blob URL 到自适应流媒体

引言

回想早期网页开发中，在网页中嵌入视频是一件相当简单的事情。一个 <video> 标签配合 src 属性指向视频地址，立即就能完成视频播放。然而，随着流媒体技术的快速发展，现代视频网站早已不是这种简单的模式。打开浏览器调试工具观察主流视频网站的视频加载，会发现视频地址都已变成 blob:http://... 的形式。本文将深入探讨流媒体技术的演进历程，从基础概念到实际应用，全面解析现代网页视频播放的技术原理。

第一章：Blob 与 ArrayBuffer——二进制数据的基础

1.1 认识 Blob 对象

Blob（Binary Large Object）是数据库领域中用于存储二进制数据的对象概念。在 Web 开发中，Blob 对象表示一个只读的原始数据类文件对象。它虽然存储的是二进制原始数据，但具有类似文件对象的特性，因此可以像操作普通文件一样操作 Blob 对象。Blob 对象除了存储原始字节外，还提供了 MIME 类型作为元数据信息，这是它与纯二进制数据的重要区别。

在实际应用中，我们可以通过以下方式创建 Blob 对象：

1
2
3
4
5

const text = `
hello world
`;
const blob = new Blob([text], { type: "text/html" });
// Blob {size: 22, type: "text/html"}

1.2 ArrayBuffer 的工作原理

ArrayBuffer 对象用于表示通用的、固定长度的原始二进制数据缓冲区。通过 new ArrayBuffer(length) 可以获得一片连续的内存空间。需要特别注意的是，ArrayBuffer 不能直接读写，需要通过 TypedArray 视图或 DataView 对象来解释和操作其中的数据。TypedArray 提供了统一类型的读写接口，确保数组成员具有相同的数据类型；而 DataView 则允许在同一缓冲区中存在不同类型的数据成员。

TypedArray 支持的视图类型非常丰富，包括 Int8Array（8 位有符号整数）、Uint8Array（8 位无符号整数）、Int16Array（16 位有符号整数）、Uint32Array（32 位无符号整数）等多种类型，每种类型都有其特定的字节长度和应用场景。

1.3 Blob 与 ArrayBuffer 的转换

Blob 和 ArrayBuffer 虽然都是二进制数据的表示方式，但它们之间存在明显区别。Blob 提供了 MIME 类型作为元数据，而 ArrayBuffer 则没有。在实际开发中，我们经常需要在这两种格式之间进行转换：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

// Blob 转 ArrayBuffer
const blob = new Blob(["hello world"], { type: "text/html" });
const reader = new FileReader();
reader.readAsArrayBuffer(blob);
reader.onload = function() {
  console.log(new Uint8Array(reader.result));
};

// ArrayBuffer 转 Blob
const u8Buf = new Uint8Array([60, 100, 105, 118]);
const blob2 = new Blob([u8Buf], { type: "text/html" });

此外，File 对象继承自 Blob 对象，在其基础上增加了 name、lastModifiedDate、size、type 等基础元数据，这使得文件处理变得更加方便。

第二章：Blob URL 的原理与应用

2.1 URL.createObjectURL 方法详解

Blob URL 是 Web 平台提供的一种特殊 URL 方案，通过 URL.createObjectURL() 方法可以将 File、Blob 或 MediaSource 对象转换为可访问的 URL 地址。这个方法生成的 URL 以 blob: 开头，后面接当前网页的主机名和端口号，格式类似于 blob:<http://localhost:1234/abcedfgh-1234-1234-1234-abcdefghijkl。>

需要特别注意的是，每次调用 URL.createObjectURL() 方法时，即使处理的是相同的二进制数据，也会生成一个不同的 Blob URL。这些 URL 的生命周期与当前网页的存在时间相同，一旦网页刷新或卸载，Blob URL 就会失效。因此，在不再需要使用 Blob URL 时，应当调用 URL.revokeObjectURL() 方法释放内存，允许浏览器进行垃圾回收：

1
2
3

const objectURL = URL.createObjectURL(blob);
// 使用完毕后释放
URL.revokeObjectURL(objectURL);

2.2 实战：图片上传预览

Blob URL 在 Web 开发中有许多实际应用场景，其中最常见的就是图片上传预览功能。传统的图片上传需要先将图片发送到服务器再返回预览地址，而使用 Blob URL 可以直接在客户端完成预览：

1
2
3
4
5
6
7
8

const upload = document.querySelector("#upload");
const preview = document.querySelector("#preview");

upload.onchange = function() {
  const file = upload.files[0];
  const src = URL.createObjectURL(file);
  preview.src = src;
};

这段代码实现了图片上传前的实时预览功能，用户选择的图片会立即显示而无需上传到服务器。这种技术同样适用于视频预览场景。

2.3 实战：加载网络视频为 Blob URL

如果我们需要将网络视频地址转换为 Blob URL 形式，可以通过 XMLHttpRequest 或 Fetch API 请求视频资源，并将响应类型设置为 blob：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

function loadVideo(url, callback) {
  const xhr = new XMLHttpRequest();
  xhr.open("GET", url);
  xhr.responseType = "blob";
  xhr.onload = function() {
    const blobUrl = URL.createObjectURL(xhr.response);
    callback(blobUrl);
  };
  xhr.send();
}

loadVideo('<https://example.com/video.mp4>', function(url) {
  video.src = url;
});

然而，这种方式存在明显的局限性：必须等到整个视频文件下载完成后才能开始播放。对于小视频文件来说这种方式或许可以接受，但对于大型视频文件，用户需要等待很长时间才能开始观看，这显然无法满足现代视频网站的需求。正因如此，流媒体技术应运而生。

第三章：流媒体协议——边下边播的实现

3.1 流媒体的基本概念

流媒体技术带来的最直观体验就是视频可以"边下边播"。早在宽带普及之前，国内用户就通过某些视频播放器体验过这种技术。Web 端实现流媒体播放有多种协议可选，每种协议都有其特点和适用场景。

现代流媒体协议主要分为两大类：苹果公司主导的 HLS 协议和国际标准组织制定的 MPEG-DASH 协议。这两种协议虽然实现细节不同，但核心思想是一致的——将完整的视频文件切割成大量的小片段，客户端按需加载这些片段进行播放，从而实现流畅的流媒体体验。

3.2 HLS 协议详解

HLS（HTTP Live Streaming）是苹果公司实现的基于 HTTP 的媒体流传输协议。它的工作原理是将视频内容切割成多个小的 TS（Transport Stream）文件，同时生成一个 M3U8 索引文件来记录这些 TS 文件的顺序和时长信息。客户端首先下载 M3U8 文件，然后按照索引顺序加载对应的 TS 文件进行播放。

HLS 协议具有以下显著优势：苹果全系列产品原生支持，无需安装任何插件；基于 HTTP/80 传输，能够穿透大多数防火墙；支持多码率自适应，可以根据网络状况动态调整视频质量；CDN 支持良好，适合大规模分发。

然而，HLS 协议也存在明显的缺点。由于需要将视频切割成大量的小文件，会产生海量的小文件，对存储和缓存系统造成压力；更重要的是，HLS 的延迟通常在 10 秒以上，不适合对实时性要求较高的场景。

3.3 MPEG-DASH 协议详解

DASH（Dynamic Adaptive Streaming over HTTP）是一种国际标准的自适应流媒体技术。与 HLS 类似，DASH 也采用切片的方式将视频分割成短小的片段，每个片段都有多个不同的码率版本。DASH 使用 MPD（Media Presentation Description）文件作为索引，描述视频内容的时间线、各可用码率轨道等信息。

DASH 协议推荐使用 fmp4（Fragmented MP4）作为传输格式，文件扩展名通常为 .m4s。主流视频网站如 YouTube、B 站都采用这种方案。观察 B 站视频播放时的网络请求，可以发现每隔几秒钟就会有几个 .m4s 文件被请求下载。

3.4 其他流媒体协议对比

除了 HLS 和 DASH，还有几种常见的流媒体协议值得关注。RTMP（Real Time Messaging Protocol）是 Adobe 公司为 Flash 播放器开发的实时消息传送协议，工作在 TCP 之上的明文协议，默认使用端口 1935。RTMP 延迟较低，一般在 1-3 秒之间，非常适合视频会议和互动直播场景。但由于它是 Adobe 的私有协议，在 iOS 端需要第三方解码器才能播放。

HTTP-FLV 则是将 RTMP 封装在 HTTP 协议之上的方案，能够更好地穿透防火墙，支持 302 跳转进行负载均衡，并且兼容移动端。其缺点是流媒体资源会缓存在本地客户端，保密性较差。

第四章：MediaSource API——实现自定义流媒体播放

4.1 MediaSource 的工作原理

MediaSource API 是 Web 平台提供的媒体数据容器接口，它允许开发者将多个媒体片段组合成一个连续的视频流。通过 MediaSource，我们可以动态地向播放容器中添加数据，实现真正意义上的流媒体播放。

MediaSource 与 HTMLMediaElement（video 元素）的绑定方式非常巧妙：不能直接将 MediaSource 对象赋值给 video.src，而是需要先通过 URL.createObjectURL() 方法创建一个 Blob URL，然后将该 Blob URL 赋值给 video.src。这种设计使得 video 元素可以像处理普通视频文件一样处理动态添加的媒体数据。

4.2 实现自适应流媒体播放

使用 MediaSource 实现流媒体播放的基本流程如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

const video = document.querySelector('video');
const assetURL = "<https://example.com>";
const mimeCodec = 'video/mp4; codecs="avc1.42E01E, mp4a.40.2"';

if ('MediaSource' in window && MediaSource.isTypeSupported(mimeCodec)) {
  const mediaSource = new MediaSource();
  video.src = URL.createObjectURL(mediaSource);
  mediaSource.addEventListener('sourceopen', sourceOpen);
} else {
  console.error('Unsupported MIME type or codec');
}

function sourceOpen() {
  const mediaSource = this;
  const sourceBuffer = mediaSource.addSourceBuffer(mimeCodec);
  let segmentIndex = 1;

  function loadNextSegment() {
    fetch(`${assetURL}/segment${segmentIndex}.mp4`)
      .then(response => response.arrayBuffer())
      .then(data => {
        sourceBuffer.appendBuffer(data);
        segmentIndex++;
      });
  }

  sourceBuffer.addEventListener("updateend", function() {
    if (segmentIndex === 1) {
      video.play();
    }
    if (segmentIndex <= totalSegments) {
      loadNextSegment();
    } else {
      mediaSource.endOfStream();
    }
  });

  loadNextSegment();
}

这段代码展示了 MediaSource 的基本使用模式：通过 addSourceBuffer() 创建源缓冲区，使用 appendBuffer() 方法动态添加媒体数据，通过 updateend 事件监听数据更新完成状态。关键在于，这种添加数据的方式不会影响当前的视频播放，实现了边下边播的效果。

4.3 视频分片与格式转换

实现 MediaSource 播放需要特定的视频格式支持。普通的 MP4 文件需要转换为 Fragmented MP4（fmp4）格式才能被 MediaSource 正确处理。使用 FFmpeg 可以轻松完成格式转换：

1

ffmpeg -i input.mp4 -movflags empty_moov+default_base_moof+frag_keyframe -f mp4 output.mp4

其中 empty_moov 参数确保 MP4 文件有一个空的 moov atom，便于流媒体播放；frag_keyframe 参数则将文件切割成以关键帧开始的片段。如果转换时缺少 default_base_moof 参数，网页中的 MediaSource 处理视频时可能会报错。

对于需要将 MP4 切割成多个片段的场景，可以使用 Bento4 工具包的 mp4split 命令：

1

mp4split video.mp4 --media-segment video-%llu.mp4 --pattern-parameters N

第五章：二进制文件下载与处理

5.1 前端下载 Blob 文件

除了视频播放，Blob 技术在前端文件下载场景中也有广泛应用。当后端返回 ArrayBuffer 或 Blob 类型的文件数据时，前端可以通过以下方式实现文件下载：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

function downloadFile(apiUrl, params, blobType, fileSuffix) {
  return axios.get(apiUrl, {
    params,
    responseType: 'arraybuffer'
  }).then(resp => {
    const blob = new Blob([resp], { type: blobType });
    const blobUrl = window.URL.createObjectURL(blob);

    const link = document.createElement('a');
    link.href = blobUrl;
    link.download = `${params.fileName}.${fileSuffix}`;
    document.body.appendChild(link);
    link.click();
    document.body.removeChild(link);

    setTimeout(() => {
      window.URL.revokeObjectURL(blobUrl);
    }, 100);
  });
}

这段代码展示了完整的前端文件下载流程：请求二进制数据 → 创建 Blob 对象 → 生成 Blob URL → 创建下载链接并触发点击 → 清理资源。关键技术点在于正确设置 responseType 和 Blob 的 MIME 类型。

5.2 防盗链机制与应对

现代云存储服务普遍支持 Referer 防盗链机制。当客户端请求资源时，请求头会包含发起请求的页面地址（Referer），服务器据此判断请求是否来自授权的页面。如果 Referer 为空或不在白名单内，则拒绝响应请求。

应对 Referer 防盗链的方法包括：在请求时设置正确的 Referer 头、使用代理服务器等手段。但需要强调的是，这些技术应当仅用于合法的开发测试场景，不应用于突破正当的版权保护措施。

第七章：前端视频资源获取与处理

7.1 合法场景下的视频获取

在 Web 开发中，我们经常需要获取和处理视频资源。合法场景包括：获取用户上传的视频文件、处理后端返回的视频数据、展示已授权的公开视频资源等。理解这些获取机制对于视频应用的开发至关重要。

对于用户通过 input 元素上传的视频，浏览器会自动将其封装为 File 对象，我们可以直接获取并进行各种处理：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

const fileInput = document.querySelector('input[type="file"]');
fileInput.addEventListener('change', function() {
  const file = this.files[0];
  console.log('文件名:', file.name);
  console.log('文件大小:', file.size);
  console.log('文件类型:', file.type);
  // 可以通过 FileReader 读取文件内容
  const reader = new FileReader();
  reader.onload = function(e) {
    // 处理文件内容
  };
  reader.readAsArrayBuffer(file);
});

7.2 Blob URL 的下载应用

前端获取的视频数据可以通过 Blob URL 实现客户端下载，这在以下场景中非常有用：用户编辑视频后的导出、报表类二进制文件的生成、数据备份与恢复等。

需要强调的是，所有这些操作都应当在获得适当授权的前提下进行。开发者有责任确保所处理的视频资源来源合法、使用正当。

7.3 开发实践建议

在实际开发中处理视频资源时，应当注意以下几点：合理设置请求的 responseType 以正确接收二进制数据；及时释放不再需要的 Blob URL 以避免内存泄漏；根据实际需求选择合适的下载方式；遵守相关法律法规和平台政策。

第八章：技术演进与未来趋势

6.1 从 Flash 到 HTML5

回顾网页视频播放的历史，技术演进之路清晰可见。早期的网页视频主要依赖 Flash 插件，RTMP 协议是当时的主流方案。随着 HTML5 标准的成熟和浏览器对 video 标签的原生支持，以及 Flash 技术的逐渐淘汰，基于 HTTP 的流媒体协议开始占据主导地位。

这一转变带来了深远的影响：视频播放不再需要插件，提升了用户体验和安全性；标准化的 Web API 使得视频开发变得更加简单；自适应码率技术使得视频可以在不同网络条件下流畅播放。

6.2 WebCodecs 与未来方向

最新的 WebCodecs API 为浏览器提供了直接访问音视频编解码器的能力，允许开发者更灵活地处理媒体数据。结合 MediaStream 实时媒体处理接口，Web 平台的媒体处理能力正在变得越来越强大。

WebCodecs 的核心优势在于其高性能和低延迟的特性。开发者可以直接操作视频帧和音频样本，实现自定义的编解码流程。这为视频编辑、实时通信、媒体分析等应用场景提供了强大的技术支撑。

展望未来，我们可以期待：更低的播放延迟、更高效的压缩算法、更智能的自适应码率控制，以及与 WebAssembly 等新技术的深度融合。WebGPU 的发展也将为浏览器端的视频处理带来新的可能性。这些发展将持续推动在线视频技术的进步。

结语

从简单的 video.src 加载，到 Blob URL 的巧妙运用，再到 MediaSource API 实现的自定义流媒体播放，Web 平台在视频处理领域已经取得了长足的进步。理解这些底层技术原理，不仅有助于我们更好地进行 Web 开发，也能够让我们在面对复杂的媒体处理需求时游刃有余。

流媒体技术的发展是一个持续演进的过程，新的协议、新的 API 不断涌现。作为开发者，保持对新技术的关注和学习热情，才能在这个快速变化的领域中保持竞争力。希望本文能够帮助读者建立起对在线流媒体技术的系统认识，为后续的深入学习和实践打下坚实的基础。

在实践过程中，请始终注意：确保所处理的视频资源来源合法、使用正当；遵守各平台的使用条款和 API 使用规范；尊重内容创作者的版权权益。只有在合法合规的前提下，技术才能发挥其真正的价值。

参考资源

• MDN Web Docs: Blob, ArrayBuffer, MediaSource

• MDN: URL.createObjectURL()

• 阮一峰 JavaScript 标准参考教程：二进制数组

• FFmpeg 官方文档：https://ffmpeg.org/

• Bento4 官方文档：https://www.bento4.com/

• Apple HLS 规范：https://developer.apple.com/documentation/http_live_streaming

• MPEG-DASH 标准：https://mpeg.chiariglione.org/standards/mpeg-dash

• W3C Media Source Extensions 规范：https://www.w3.org/TR/media-source/

• B站技术博客：我们为什么使用 DASH