做在线教育平台这几年，我踩过最多的坑基本都集中在视频链路上：老师用OBS推流上来，学生端卡成PPT；录播课上传之后，不同手机兼容性天差地别；想上互动连麦，延迟又压不下来。后来我把整套方案沉淀成了一个以EasyDSS为核心的视频技术底座，用RTMP承接推流、HLS/HTTP-FLV做分发、VOD管点播、WebRTC扛低延迟互动，终于把直播、点播、转码、播放这些事统一收口，不再各搞一套。

这篇内容没有教科书式的原理堆砌，全是我在实际部署和调优中验证过的路径。如果你正在搭在线教育的视频服务，或者被直播延迟、点播格式、WebRTC集成这类问题折磨过，这篇应该能帮你省掉不少弯路。我会从整体架构讲起，再逐个拆解推流、编码、转码、点播、WebRTC播放这些环节，最后把常见的坑和排查手段一起整理出来。

1. 在线教育视频底座要解决什么，技术选型怎么考虑

1.1 核心需求拆解：直播、点播、低延迟、高并发

在线教育和普通娱乐直播有一个本质区别：业务的严肃性。普通秀场直播断几秒、卡几下，用户最多抱怨两句；但一堂付费课如果声音画面不同步、老师讲到一半推流断了，那直接影响口碑和退费率。所以做视频底座之前，一定要先把业务场景拆清楚，不能拿着一个直播SDK就打天下。

在线教育常见的视频场景大致有四类：

• 大班直播课：一位老师面对几百上千学生，以单向讲授为主，偶尔有文字互动。这类场景对延迟要求不太苛刻，3到5秒内都能接受，但并发量很大，需要分发链路能扛住突发流量。
• 小班互动课：几个人到几十个人，师生之间需要连麦、实时问答。这种场景对延迟的要求一下就拉到500毫秒以内，普通RTMP直播完全顶不住，必须上WebRTC这类低延迟方案。
• 录播课程点播：老师把课程录好，上传平台供学生随时回看。这类场景对格式兼容性要求极高，同一个视频要在Windows、macOS、iOS、Android、各种小程序里都能放。
• 课后回放：直播结束后，系统自动把整节课生成回放，转成点播URL。这里牵涉到录制、转码、切片、索引生成一条龙。

把这些场景列出来之后，选择技术方案的标准就很明确了：推流侧要稳，分发侧要广，播放侧要兼容，互动侧要低延迟。靠一两个开源组件东拼西凑当然也能跑，但接口不统一、日志不打通、状态难监控，后期维护成本非常高。这也是我当初选择用EasyDSS做底座的原因。

1.2 为什么选EasyDSS做核心服务

我在选型的时候，其实对比过几类方案：纯自研基于SRS/nginx-rtmp拼装、直接用云厂商的直播服务、以及部署EasyDSS这类一体化流媒体服务平台。

先说说自研拼装这条路。SRS做RTMP直播服务确实很强，nginx-rtmp也能快速起一个推拉流环境，但要做到完整商用，后面还有一堆事情等着你：推流鉴权、转码集群、录像回放、HLS切片、WebRTC网关、播放器适配。每一项单独拎出来都是不小的工程，如果团队没有专门做流媒体的人，很容易在某个环节卡住。

用云厂商的直播服务则省心，但问题在于在线教育这种场景经常需要私有化部署，尤其是很多教育机构对数据主权有严格要求，课程内容不能出校门或出公司网络。而且云厂商的计费模型在并发峰值时成本不低，小规模团队初期不一定扛得住。

EasyDSS最吸引我的点是：它把RTMP推流、直播分发、VOD点播、视频转码、WebRTC播放这些能力打包成了一个平台，自带管理后台和RESTful API，部署起来就是一套服务，不用自己东拼西凑。我可以在私有网络里跑起来，也可以放到云服务器上对外服务，一套代码应对不同交付场景。转码这一块尤其省事，后台配置好几个清晰度模板，推流上来之后自动出多路流，点播文件上传之后也自动转成适合不同终端的格式。

当然EasyDSS不是万能的，它更像一个“成熟骨架”，业务侧的交互、课件同步、课堂管理这些还是得自己开发。但视频这块的底层能力，它确实帮我省掉了大量重复造轮子的工作。

1.3 协议矩阵：RTMP、HTTP-FLV、HLS、WebRTC怎么分工

很多刚接触流媒体的人会被一堆协议搞晕，我在这里用最直白的话梳理一遍它们的分工。

RTMP是推流侧的老大哥，基于TCP长连接，延迟低，生态成熟，OBS、各种编码器、硬件推流盒子基本都支持。在线教育场景里，老师端用OBS或专业编码器推流，首选就是RTMP。它在播放端已经没落了，因为浏览器不原生支持RTMP，但推流端依然是绝对主力。

HTTP-FLV是播放侧的实用方案。它把RTMP的流封装成FLV格式，通过HTTP传输，浏览器里用flv.js就能播放。延迟能控制在1到3秒，非常适合大班直播课这种“低延迟但不需要连麦”的场景。

HLS则是点播和弱网场景的万金油。它把视频切片成一个个小文件，通过m3u8索引文件按顺序播放。缺点是延迟通常在5秒以上，但兼容性极强，几乎所有端都支持，而且天然适合做录像回放和点播。

WebRTC是互动场景的终极方案。它基于UDP，用SRTP加密传输，端到端延迟能做到几百毫秒，是连麦互动的首选。缺点是对网络要求高，弱网环境下容易花屏断流，而且服务端需要额外的信令和媒体网关支持。

所以我的选择很简单：推流一律RTMP，大班播放用HTTP-FLV，回放和点播走HLS，小班互动用WebRTC。EasyDSS恰好把这些协议都串在了一套体系里，同一个流可以同时输出FLV、HLS和WebRTC，前端按场景选播放方式即可，不用再单独部署多个服务。

2. 从零搭建RTMP推流与直播分发链路

2.1 服务端部署和关键配置

EasyDSS的部署方式有物理机安装包和Docker两种，我强烈推荐Docker，尤其是要频繁迁移环境或者交付给客户私有化部署的时候。一条docker run命令就能起服务，数据目录挂载出来，后续升级也方便。

部署完第一件事不是急着推流，而是改配置。我遇到过不少人在默认配置下跑测试没问题，一上生产就各种奇怪问题，根子就在那些不起眼的配置项上。

首先是直播流的命名规范。生产环境不要用简单的live这样的流名，建议按业务维度设计，比如courseId_teacherId_时间戳，这样后续做鉴权、拉流转发、录制归档都方便追溯。EasyDSS后台可以配置鉴权方式，推流地址和播放地址都可以加上token参数，一定不要嫌麻烦，不鉴权的流媒体服务就是在向全网开放你的直播内容。

其次是存储路径。录播回放和点播文件都会落盘，默认路径往往在系统盘，跑久了容易把磁盘塞满。建议单独挂载一块数据盘，并定期清理过期录像。我在实际项目里遇到过磁盘写满导致转码服务崩溃的事故，排查了半天才发现是历史回放文件没清理。

端口方面，常用的有RTMP的1935、HTTP的80/8080、RTSP的554，以及WebRTC需要的UDP端口范围。部署到云服务器时，安全组和防火墙一定要把这些端口放通。这里有个容易踩的坑：HTTP播放端口和WebRTC的UDP端口不在同一段网络策略里，导致网页能看FLV但连不上WebRTC。

2.2 OBS推流实操与参数建议

服务端就绪后，推流端最常见的工具就是OBS。这里我建议不要把OBS当成傻瓜软件用，几个关键参数直接决定直播质量。

推流地址格式一般是这样的：

rtmp://服务器IP:1935/live/streamName

在OBS里，服务器填 rtmp://服务器IP:1935/live ，串流密钥填 streamName ，如果开了鉴权就在URL后面拼接token参数。很多人第一次推流失败，就是因为把整个推流地址当成串流密钥填进去了。

编码设置上，在线教育场景我一般推荐这样配：

• 视频编码器用H.264，不要用H.265。虽然H.265压缩率更高，但很多老旧设备解码不了，而且推流端的CPU占用会明显上升。
• 码率根据分辨率来：1080p建议4000到6000Kbps，720p建议2000到3000Kbps。上课如果以PPT和屏幕共享为主，静态画面多，码率可以保守一点；如果有大量板书、手写动画，码率可以调高。
• 关键帧间隔（GOP）建议设为2秒。这个参数很多人忽略，但它直接影响播放端的起播延迟和卡顿率。间隔太大会导致切片起步慢，太小又增加编码压力。在OBS的输出设置里，关键帧间隔填2，对应帧率30fps就是60帧一个GOP。
• 音频用AAC编码，44.1kHz采样率，码率128Kbps足够清晰。语音课不要用太高码率，浪费带宽而且容易出回声问题。

还有音频采样率要统一。之前调试一个客户环境，老师端OBS用48kHz，播放端某个安卓机型就是没声音，查了半天才发现是采样率不匹配导致EasyDSS转码时音频流出错。统一用44.1kHz之后问题消失。

2.3 公开RTMP测试地址怎么用

调试阶段，很多人在网上找公开的RTMP测试地址，比如一些播放器厂商提供的公共测试流。这些地址用来验证播放器解码能力确实方便，但不能依赖，原因有三点：这些公共流随时可能下线、延迟不稳定、而且大多数没有鉴权不适合做业务联调。

我更推荐自己搭一个最小测试环境。EasyDSS部署完后，用OBS往一个测试流名推流，然后用VLC或者网页播放器拉流验证，这个闭环了就说明整条链路是通的。同时，在EasyDSS后台能看到推流状态、码率、帧率等指标，比用公共地址黑盒调试靠谱得多。

安卓端对RTMP的支持也值得注意。很多安卓播放器早期支持RTMP播放，但新版系统对RTMP的兼容性参差不齐。我的做法是：安卓端统一使用HTTP-FLV或HLS播放，RTMP只承担推流职责，播放一律不走RTMP，这样兼容性问题和延迟问题一次解决。

3. 视频编码与转码：让一个视频处处能播

3.1 编码选型：H.264与H.265怎么选

做在线教育内容生产，编码格式选型是个看似基础但影响深远的问题。我服务过的平台里，有坚持全部用H.265的，结果不少老平板和低端手机就是放不了，老师在后台收到一堆学生投诉；也有全部用H.264的，存储和带宽成本压得难受。

我的建议是分场景对待。直播链路统一用H.264，因为低延迟直播最怕的是解码不及时，H.264在端侧解码速度和兼容性上依然最优。点播场景可以拥抱H.265，录播课程往往是提前制作好的，有充足时间转码，H.265比H.264节省约30%到50%的码率，对存储成本和用户看课的流量成本很有帮助。

还有一种情况是视频编码课程里经常出现的：老师直接用手机录屏上传，源文件可能是H.265编码、60fps、分辨率还特别大。这类文件不统一规格就直接上线，播放体验会非常随机。所以点播VOD一定要设置转码任务，把源文件归一化。

3.2 转码模板设计：多码率自适应

转码模板不只是一张清晰度列表，它其实是综合了分辨率、码率、帧率、编码档位的一套策略。我在EasyDSS里一般配置三个档位：

• 高清：1080p，H.264，3000Kbps，30fps，适合PC端大屏观看。
• 标清：720p，H.264，1500Kbps，30fps，适合移动端标准网络。
• 流畅：480p，H.264，800Kbps，25fps，适合弱网环境。

为什么这么设？不是拍脑袋定的，而是根据在线教育的画面特点：PPT文字、板书线条占画面主体，一旦码率不足就会产生明显的文字模糊和毛边。1080p的码率如果低于2500Kbps，满屏文字的PPT切过来时画面就会糊成一片。反之，静态画面多的时候，码率上限也不必过高，3000Kbps在静态授课场景里已经足够锐利。

转码还有一个容易被忽略的作用：归一化。不同老师上传的录屏文件，编码格式、分辨率、音视频封装五花八门，通过转码模板统一打包成平台标准格式后，播放器不需要区分文件来源，体验一致性会提升很多。EasyDSS后台的转码任务可以在上传点播文件时自动触发，不用每个文件手动操作。设好模板后，新上传的视频文件会自动生成所有档位，前端播放器再根据网络带宽自动切换。

3.3 VOD点播与HLS分片的“坑”

点播VOD的基础流程是：上传视频文件，服务端转码，切HLS分片，生成m3u8索引，然后播放器拉流播放。这块表面上很自动化，实际暗坑不少。

最常见的问题就是分片文件不匹配。HLS的m3u8索引里面列了分片文件名（通常是.ts或.m4s），播放器会严格按顺序去请求。如果索引和实际文件对不上，播放就会卡在某个分片之后停止。我在排查一个回放故障时发现，某节课的m3u8索引里，分片文件后缀居然是 .png 。也就是说索引语法是合法的HLS点播清单，但分片链接全部指向PNG图片，播放器当然拉不到视频数据。

这里要提醒一下：遇到这种诡异现象，先不要怀疑服务端转码本身，更常见的原因是源文件有问题。当时那个案例最终查下来，是课程平台在导入外部视频时，文件被加过水印或防盗链策略，下载下来的内容并不是真正的视频流，而是一张带有播放按钮的图片。服务端转码程序不具备识别能力，把图片也当作视频去切片了，结果生成了“伪HLS”文件。

所以说，VOD点播链路中，源文件校验必不可少。我在实际项目中加了一道前置校验流程：文件上传后，先做一次探测，确认视频轨和音频轨都存在，且时长大于0，再进入转码队列。EasyDSS本身提供了对视频文件的探测能力，利用好它就能挡掉大量脏源文件。

分片时长也需要根据场景调整。HLS默认的切片时长常见是4到6秒。点播场景这个参数无所谓，但直播回放场景会影响起播速度和拖动进度条的粒度。切片越短，起播越快，但分片数量越多，请求压力越大。在线教育回放我习惯设为4秒，配合2秒的GOP长度，正好每个分片包含两个关键帧，拖动进度条时能很快定位到最近的关键帧位置。

4. WebRTC低延迟播放与端侧集成

4.1 从RTSP/RTMP到WebRTC的转流方案

前面提到小班互动课需要毫秒级延迟，这个场景RTMP确实顶不住。但老师的推流设备、摄像头、录播主机很多只支持RTSP或RTMP，并不会直接输出WebRTC。所以要让互动课跑起来，得有一个“转流”的环节。

以EasyDSS做转流网关的方案大致是这样的：老师端用RTSP或RTMP推流到服务端，服务端接收到流之后，再通过WebRTC网关把媒体流转成WebRTC的SRTP流，同时附带信令服务。学生端浏览器只需要连接WebRTC地址，不需要关心源流是RTSP还是RTMP。

动手验证的时候，我建议先拿一个RTSP摄像头来做测试。很多摄像头支持RTSP输出，EasyDSS后台添加RTSP拉流代理之后，就能获得一个直播流ID，然后直接生成WebRTC播放地址。这里提一个经验：RTSP拉流对网络稳定性非常敏感，摄像头和服务端在同一局域网时基本没问题，跨公网拉流就得考虑丢包重传和连接保活，否则拉流会话容易被断开。

WebRTC播放地址和RTMP/HTTP-FLV地址不是一个概念。播放器拿到WebRTC地址后，要先经过信令交换（SDP协商）、ICE连接建立，才能进入音视频传输阶段。整个流程对网络环境有硬性要求——UDP端口要通。很多部署失败案例都出在网络层面：服务器的UDP端口没放通，双方ICE协商一直失败，连接建立不起来。TCP/TURN方式可以作为兜底，但延迟会明显上升，所以有条件的话尽量保证UDP链路畅通。

4.2 Vue项目里集成WebRTC播放器

学生端播放器，我这边主要集中在Web端，技术栈是Vue。EasyDSS自带WebRTC播放SDK，整体封装度比较高，直接引入页面就能用。我在项目里的做法是封装一个 WebRtcPlayer 组件，在Vue的生命周期里处理连接和销毁。

import EasyDSSWebRTCPlayer from 'easydss-webrtc-sdk'

export default {
  name: 'WebRtcPlayer',
  props: {
    playUrl: {
      type: String,
      required: true,
    },
  },
  data() {
    return {
      player: null,
    }
  },
  mounted() {
    this.player = new EasyDSSWebRTCPlayer({
      url: this.playUrl,
      container: this.$refs.videoContainer,
    })
    this.player.play()
  },
  beforeUnmount() {
    if (this.player) {
      this.player.destroy()
    }
  },
}

这个封装里面有三个细节要特别注意。第一，不要忘记销毁播放器。WebRTC连接是持续性的，组件切走之后如果不销毁，连接还挂在背后，既占带宽又容易造成浏览器崩溃。第二，要监听ICE连接状态，网络切换或者断网重连时，WebRTC连接可能会断开，这时候需要手动重新触发play。第三，页面上同时最多不要开太多WebRTC连接，这是给浏览器CPU和带宽上强度，我实测超过四路同时播放时，低端设备基本就卡死了。所以多人互动课堂可以限制一下视频墙路数，或者把只听课不发言的学生切到HTTP-FLV。

4.3 小程序播放WebRTC的局限与替代

Web端搞定之后，小程序是另一个大头的客户端。小程序能不能直接播WebRTC？答案有点尴尬：小程序原生播放器不直接支持WebRTC，尤其是微信小程序，它的live-player组件支持RTMP和FLV，但WebRTC需要配合服务端做转协议或者使用配套插件。

实际开发中我用的替代策略是：

• 学生端看直播课：优先用live-player组件播放HTTP-FLV/RTMP地址，配合EasyDSS的HLS地址做降级。小程序的live-player对FLV支持相对稳定，延迟3秒左右，大班课完全够用。
• 互动连麦：小程序端通过原生live-pusher组件推流到服务端，再借助WebRTC网关由服务端做媒体转发，实现类似连麦的体验。这不是端到端WebRTC，但工程上可行。
• 如果业务确实需要在小程序里跑WebRTC，可以选择基于小程序web-view内嵌一个支持WebRTC的H5页面，但要注意web-view的限制和跳转策略。

安卓原生App的播放则简单很多，EasyDSS提供了RTMP、HTTP-FLV、HLS三套播放地址，Android原生播放器拿地址基本都能播。唯一要留意的是，Android 8.0以后版本对RTMP协议的原生支持并不一致，我用过几款播放器内核，最后还是统一走HTTP-FLV最稳。

5. 问题排查与安全加固实录

5.1 RTMP推流失败常见原因定位

做流媒体时间长了，你会发现推流失败的原因就那么几类，但每类现场表现都不一样。我把最常见的几个结合排查思路整理一下，直接当速查表用。

第一个是端口不通。现象是OBS一直转圈，提示无法连接服务器。这时优先确认服务器的1935端口是否放通。在本机用telnet测一下： telnet 服务器IP 1935 。连不上就先处理防火墙和安全组。我自己经常犯的错是只放了云控制台的防火墙，忘了服务器内部还有一层iptables。

第二个是串流名冲突。同一个live streamName如果已经有人在推，新的推流端会连接失败或者被踢掉。EasyDSS后台能看到当前活跃流列表，遇到“推流连接被重置”的提示，先去看看是不是streamName重了。尤其是在多人同时开课的时段，流名不带唯一标识就很容易撞车。

第三个是编码参数不被服务端接受。EasyDSS默认对H.264和AAC做了兼容，但如果推流端选了H.265视频或者Opus音频，服务端不一定能直接处理，产生的结果可能是能推但播放端黑屏。遇到这种情况，先检查OBS的输出设置，把视频编码切到H.264。

第四个是鉴权失败。开了推流鉴权后，URL里的token过期或者参数拼错，都会在连接阶段被拒绝。要留意EasyDSS的鉴权时间戳默认使用的是服务器时间，如果客户端设备和服务器时间差太多，鉴权会直接失败。很多“昨天还能推今天不行了”的问题就是这么来的。

5.2 延迟优化：从“能用”到“好用”

在线教育里延迟是衡量体验的核心指标。我对延迟的定位很简单：大班课3秒以内、小班互动500毫秒以内，在这个标准下，延迟优化才有讨论意义。

先说大班课延迟优化。链路是“老师端推流 -> 服务端分发 -> 播放器拉流”，每个环节都有优化空间。推流端把GOP设为2秒，服务端关闭多余的缓冲，播放器优先用HTTP-FLV，这几点做下来延迟基本稳定在1到3秒。很多团队把精力放在服务端调优上，却忽略了播放器缓冲设置，导致服务端明明很快，播放端还是攒了好几秒的buffer。

再说小班互动的延迟优化。WebRTC链路中，影响延迟的因素是jitter buffer和带宽估计，这两项大多由浏览器内部动态调整，服务端能介入的空间有限。我们能做的是保证网络质量，UDP端口畅通、丢包率低于1%、带宽足够。这里有个容易忽略的点：如果老师端用的是RTSP摄像头，摄像头本身会有延迟。我实测过一些IPC摄像头，画面延迟300到500毫秒是常态，再加上WebRTC传输的延迟，整条链路就会突破1秒。所以做连麦互动时，老师端设备选型也非常关键，尽量选延迟低的USB摄像头或者手机推流。

5.3 流媒体安全：从“WebRTC泄露”谈加固

网络安全这块，我想专门说一下“WebRTC泄露”这个话题。它指的是WebRTC在建立连接时，为了让通信双方尽快连上，会主动收集并交换本机的所有网络地址，包括内网IP和公网IP。这个过程在用户不知情的情况下，可能把使用者的真实IP暴露给对端或者信令服务。

在在线教育场景里，这意味着什么？如果平台的WebRTC信令通道没有做好权限隔离，学生端或老师端连接时，对端有可能通过信令通道获取到对方的IP信息。对于注重隐私的师生用户来说，这是不可接受的。

加固措施其实不复杂，但很多人想不到去做。我在部署时的做法：信令服务只对已登录且鉴权通过的设备开放，每个播放会话绑定用户身份；STUN/TURN服务按需关闭不可信的地址收集策略，让连接完全由TURN服务器中转；同时对信令信道的WSS加密、心跳超时做完整配置。另外，WebRTC连接地址要定期更换，避免长期有效的播放地址被爬取或盗用。

不仅是WebRTC，RTMP推流、HLS播放、VOD点播的地址都应该纳入防盗链体系。EasyDSS后台提供了播放地址的Referer防盗链和Token鉴权机制，我建议生产环境全部开启。虽然这会增加一些联调成本，但等到盗播事件发生再补救，代价就大得多了。

---

最后再分享一个小技巧。无论是RTMP推流、HLS点播还是WebRTC播放，排查问题最有效的手段不是盯着后台日志猜，而是把整条链路的日志串起来看：推流端连接失败看服务端的接入日志，播放卡顿看服务端的分发日志和客户端网络请求日志，鉴权失败看后台的鉴权记录。把日志格式统一、带上请求ID，大部分问题都能在半小时内找到根因。这套底座跑起来之后，我最大的感受是：视频这块的“紧急救火”明显变少了，团队可以把时间花在打磨课堂体验这些真正影响用户的事情上。