基本概念相关媒体在 Web 开发中，媒体（Media）特指可以通过浏览器播放或显示的多媒体资源，主要包括：类型常见

媒体

在 Web 开发中，媒体（Media）特指可以通过浏览器播放或显示的多媒体资源，主要包括：

类型	常见格式	HTML 标签 / API
视频（Video）	MP4, WebM, HLS, DASH	`<video>`
音频（Audio）	MP3, AAC, WAV, Opus	`<audio>`
图像（Image）	JPEG, PNG, GIF, WebP	`<img>`, Canvas
字幕（Subtitles）	WebVTT, SRT	`<track>`
实时流（Live Stream）	WebRTC 音视频流	`getUserMedia()`, `RTCPeerConnection`

✅ 因此，在前端语境中：
“媒体” = 可被浏览器处理的音视频及相关资源

四、“媒体” vs “文件”

概念	说明
文件（File）	存储在磁盘上的数据（如 `video.mp4`）
媒体（Media）	被解释和消费的内容（如“正在播放的视频流”）

流媒体是什么

流媒体（Streaming Media）是一种通过网络实时传输和播放多媒体内容的技术，用户可以边下载边观看，无需等待整个文件下载完成。

流媒体 = 边传输、边解码、边播放

方式	行为	用户体验
传统下载	先完整下载 → 再播放	大文件等待时间长，浪费存储
流媒体	下载一点 → 播放一点	打开即播，支持拖拽、快进

二、流媒体的两种主要类型

1. 点播（VOD, Video on Demand）

用户随时观看已录制好的内容
例子：Bilibili 视频、Netflix 电影
特点：可暂停、快进、回放

2. 直播（Live Streaming）

实时分发正在发生的音视频
例子：抖音直播、体育赛事、在线会议
特点：有延迟（通常 3–30 秒），不可回放（除非录播）

📌 还有 低延迟直播（LLS） ：通过 WebRTC 或 LL-HLS 实现 < 3 秒延迟，用于互动直播、在线教育。

三、流媒体如何工作？（技术原理）

核心思想：分片 + 按需加载

步骤（以 HLS 为例）：

服务端预处理
- 将原始视频切分为多个小片段（如每段 6 秒）
- 生成播放列表（.m3u8 文件）
- 可选：生成多清晰度版本（480p/720p/1080p）
客户端请求
- 浏览器先请求 master.m3u8
- 解析出可用清晰度和片段列表
- 根据网络状况选择一路（如 720p）
按需下载与播放
- 依次下载 seg1.ts, seg2.ts...
- 播放器缓冲几秒后开始播放
- 拖拽进度 → 直接请求目标时间对应的片段

✅ 用户永远只下载“当前需要”的数据，而非整个文件。

主流流媒体协议

协议	全称	类型	特点	前端支持
HLS	HTTP Live Streaming	自适应流	Apple 开发，基于 `.m3u8` + `.ts`/`.mp4`	Safari 原生；Chrome/Firefox 需 hls.js
DASH	Dynamic Adaptive Streaming over HTTP	自适应流	开放标准（MPEG），基于 `.mpd` + `fMP4`	所有浏览器需 dash.js 或 Shaka Player
WebRTC	Web Real-Time Communication	实时流	超低延迟（< 500ms），P2P	浏览器原生支持（`RTCPeerConnection`）
RTMP	Real-Time Messaging Protocol	实时流	Adobe 开发，需 Flash（已淘汰）	❌ 不推荐用于 Web 播放

✅ Web 前端首选：HLS（兼容性好）或 DASH（开放标准）

分辨率是什么

分辨率是指显示设备或图像能够显示的像素数量，通常用来衡量图像或屏幕的清晰度和细节程度。分辨率通常用 宽度 × 高度 的像素数来表示

主要类型

1. 屏幕分辨率

定义：显示器能显示的像素总数
影响：决定屏幕显示的清晰度和可显示内容的多少

2. 图像分辨率

定义：图片包含的像素数量
单位：像素（px）或每英寸像素数（PPI/DPI）

3. 打印分辨率

定义：打印设备的精度
单位：DPI（Dots Per Inch，每英寸点数）

常见分辨率标准

名称	分辨率	像素总数
HD	1280×720	约92万
Full HD	1920×1080	约207万
2K	2560×1440	约368万
4K	3840×2160	约829万
8K	7680×4320	约3317万

视频为什么需要编码

视频编码是数字视频处理中的核心技术，主要目的是压缩数据、提高传输效率和存储优化。

常见编码标准

传统编码

H.264/AVC：目前最广泛使用
H.263：早期标准
MPEG-2：DVD标准

新一代编码

H.265/HEVC：比H.264效率提升50%
AV1：开源免费标准
VP9：Google开发

编码原理是什么

编码原理是通过数学算法和数据结构技术，将原始数据转换为更紧凑、更适合传输或存储的格式的过程。

有哪些编码方式

常见组合（容器 + 视频编码 + 音频编码）

用途	容器	视频编码	音频编码	兼容性
通用 Web 视频	MP4	H.264	AAC	⭐⭐⭐⭐⭐
现代 Web（省带宽）	WebM	VP9 或 AV1	Opus	⭐⭐⭐⭐
Apple 生态	MP4 / MOV	H.264 / HEVC	AAC	⭐⭐⭐⭐（限 Apple）
WebRTC 实时通信	—	VP8 / VP9 / H.264	Opus	⭐⭐⭐⭐
YouTube 内部	—	AV1 / VP9 / H.264	Opus / AAC	自适应

主流编码一览表

类型	编码	专利	压缩效率	浏览器支持	推荐用途
视频	H.264	有（但广泛豁免）	中	✅ 全平台	通用 Web 视频
	VP9	无	高	✅ Chrome/Firefox/Edge ⚠️ Safari 16.4+	现代 Web
	AV1	无	最高	✅ Chrome/Firefox/Edge ✅ Safari 17+	未来主流
	HEVC	有（复杂）	高	❌ 仅 Safari	Apple 生态
音频	AAC	有（但广泛支持）	高	✅ 全平台	通用音频
	Opus	无	极高（尤其语音）	✅ 全现代浏览器	WebRTC、Web 音频

短期：H.264 + AAC 仍是兼容性基石
中期：VP9 + Opus 在 Web 广泛部署
长期：AV1 + Opus 将成为开放 Web 的黄金组合（免专利、高效）

💡 建议：新项目优先提供 AV1/VP9 + Opus 版本，并保留 H.264/AAC 作为 fallback。

格式和编码之间的关系

格式（容器）是“盒子”，编码（Codec）是“盒子里的东西”。

格式（File Format / Container） ：决定文件如何组织数据（如 .mp4, .webm）
编码（Codec） ：决定音视频数据如何被压缩和解压（如 H.264, AAC）

✅ 同一个格式可以装不同的编码
✅ 同一个编码可以放在不同的格式中

1. 格式（Container Format）

定义文件的结构和元数据存储方式
可包含：
- 视频流（Video Stream）
- 音频流（Audio Stream）
- 字幕（Subtitles）
- 章节信息、封面图等
不负责压缩，只负责“打包”

常见容器格式：

.mp4（MPEG-4 Part 14）
.webm
.mkv（Matroska）
.avi（Audio Video Interleave）
.mov（QuickTime）
.flv（Flash Video）

2. 编码（Codec）

COder + DECoder
负责**压缩（编码）和解压（解码）**原始音视频数据
分为：
- 视频编码：H.264、VP9、AV1、HEVC
- 音频编码：AAC、MP3、Opus、Vorbis

🔍 编码决定了：

文件大小

画质/音质

播放兼容性

CPU 解码压力

常见组合规范（推荐）

容器格式	推荐视频编码	推荐音频编码	用途
MP4	H.264	AAC	通用 Web 视频（最大兼容）
WebM	VP9 或 AV1	Opus	现代 Web（省带宽、免专利）
MP4	AV1	Opus	未来方向（Safari 17+ 支持）
MKV	任意	任意	本地播放、专业编辑（不用于 Web）

关系图

    ┌──────────────┐
    │   容器格式    │  ← .mp4, .webm, .mkv
    └──────┬───────┘
           │ 包含
┌──────────▼──────────┐
│  视频流（编码：H.264/VP9/AV1） │
├─────────────────────┤
│  音频流（编码：AAC/Opus/MP3） │
└─────────────────────┘

概念	决定什么	是否影响播放兼容性
格式（容器）	文件结构、扩展名	间接影响（浏览器对容器有偏好）
编码（Codec）	压缩算法、画质/体积	直接影响（浏览器必须支持该编码）

MSE/EME是什么

MSE（Media Source Extensions） 是一项强大的 Web API，它允许 JavaScript 动态构建媒体流并喂给 <video> 或 <audio> 元素，从而实现原生不支持的流媒体协议（如 DASH、HLS 在非 Safari 浏览器）、自定义播放逻辑、视频编辑预览等高级功能。

一、为什么需要 MSE？

原生 `<video>` 的局限：

只能播放完整 URL 指向的媒体文件
无法处理分片传输（如 .ts 片段、DASH 的 fMP4）
不支持动态拼接视频片段

💡 MSE 的核心价值：让前端“自己组装”视频流！

二、MSE 是什么？

MSE = Media Source + SourceBuffer

MediaSource：一个虚拟的“媒体源”，可挂载到 <video> 的 src
SourceBuffer：用于向 MediaSource 中追加媒体数据片段（ArrayBuffer）

MSE 能做什么？（典型应用场景）

1. 播放 DASH / HLS（非 Safari）

hls.js 和 dash.js 底层都基于 MSE
它们下载 .ts 或 fMP4 片段 → 转为 ArrayBuffer → 通过 MSE 喂给 <video>

✅ 2. 自适应码率切换

根据网络状况动态选择不同清晰度的片段
无缝切换（因为 MSE 支持连续追加不同码率的片段）

✅ 3. 视频编辑预览

将多个视频片段拼接后实时预览（无需服务端合成）
例如：剪辑 App 中的“时间线预览”

✅ 4. 直播低延迟播放

接收 WebSocket 或 HTTP 流式数据 → 实时 append 到 SourceBuffer

✅ 5. DRM 内容播放（配合 EME）

MSE + Encrypted Media Extensions (EME) = 支持 Widevine、PlayReady 等 DRM

基本概念相关

媒体