1. 课程导学：H265与WebRTC结合的价值、应用场景与前置知识

各位同学好，我是这门课的主讲。在流媒体这个行当摸爬滚打了十几年，从早期的H.264编码到现在的H.265/HEVC，从传统的RTMP推流到如今的WebRTC实时通信，我踩过的坑确实不少。今天咱们开篇先聊聊，为什么要把H.265和WebRTC绑在一起？这事儿到底值不值得学？

1.1 为什么是H.265？为什么是现在？

先说说编码这事儿。H.264统治了流媒体行业十几年，确实稳定可靠。但问题来了——4K、8K视频越来越普及，视频会议从720p升级到1080p甚至4K，监控摄像头动辄几百万像素。H.264的压缩率已经快撑不住了。

H.265（HEVC）在同等画质下，码率能比H.264降低30%~50%。我做过一个实际测试：同样一段1080p/30fps的视频，H.264需要4Mbps才能保持清晰，H.265只需要2.5Mbps左右。在移动网络环境下，这个差距就是「能看」和「卡成PPT」的区别。

但问题也来了——WebRTC原生只支持H.264和VP8/VP9。H.265不在标准支持列表里。这就尴尬了：浏览器里跑WebRTC，默认用不了H.265。所以我们需要一套方案，把H.265「塞进」WebRTC的管道里。

1.2 应用场景：哪些地方最需要H.265+WebRTC？

我梳理了三个最典型的场景，也是我在项目中实际交付过的。

场景	核心痛点	H.265+WebRTC的价值
视频会议	多人会议带宽占用高，移动端发热卡顿	同等画质下带宽降低40%，硬件编码降低功耗
直播	推流端上行带宽有限，观众端需要低延迟	H.265编码降低推流码率，WebRTC保证秒级延迟
监控	7×24小时录制存储成本高，远程查看延迟大	H.265节省50%存储空间，WebRTC实现实时预览

视频会议——这个我最有发言权。之前给一家教育公司做在线课堂，他们要求1080p双流（老师+课件）。用H.264时，4人会议就需要8Mbps上行带宽，很多老师家里的宽带根本扛不住。换成H.265后，同样的画质只需要4~5Mbps，体验提升非常明显。

直播——特别是移动直播。主播用手机4G推流，上行带宽通常只有2~3Mbps。H.264只能推720p，H.265可以稳定推1080p。而且WebRTC的延迟在200~500ms，比传统的RTMP/HLS方案低一个数量级。

监控——嗯，这里要注意。监控场景对延迟要求没那么苛刻，但对存储成本极其敏感。一个4路1080p的NVR，用H.264一天大概需要80GB，H.265只要40GB。再加上WebRTC的P2P能力，远程查看时不需要经过服务器中转，延迟和成本都降下来了。

1.3 核心挑战：H.265进WebRTC到底难在哪？

说白了，就三个字——不支持。WebRTC的编码协商走的是SDP（Session Description Protocol），里面用FMTP参数来描述编码能力。H.265的FMTP参数定义在RFC 7798里，但Chrome、Firefox、Safari都没有原生实现。

我曾经在项目里尝试过直接修改SDP，把H.265的payload type硬塞进去。结果呢？Chrome直接报错，说「不支持的编码格式」。后来我才搞清楚，WebRTC内部有一个编码器注册表，不支持的编码格式根本不会进入协商流程。

所以解决方案只有两条路：

1. 改造WebRTC底层——修改libwebrtc源码，注册H.265编码器。这条路适合有源码控制权的场景（比如自研SDK）。
2. 在应用层做转码/封装——用WebSocket或DataChannel传输H.265裸流，绕过标准的媒体通道。这条路兼容性更好，但延迟会高一些。

1.4 知识体系全景图

下面这张图是我梳理的课程知识结构。你可以把它当成一张地图，后面每章都会对应到其中的一个模块。

1.5 前置知识要求：你最好先会这些

这门课不是零基础入门。我假设你已经具备以下能力：

• JavaScript/TypeScript基础——至少能写异步代码，理解Promise、async/await。WebRTC的API全是异步的。
• WebRTC基础概念——知道什么是PeerConnection、MediaStream、SDP。如果你完全没接触过WebRTC，建议先看MDN的入门教程。
• 视频编码常识——了解I/P/B帧、GOP、码率、分辨率这些基本概念。不需要你写过编码器，但得知道它们是什么。
• Linux基础操作——编译FFmpeg、部署信令服务器、抓包分析，这些都会用到命令行。