声网SDK旁路推流与本地录制，到底有什么区别？

做音视频开发的朋友，估计经常会被这个问题困扰：同样是录制，旁路推流和本地录制到底该怎么选？说实话，我刚开始接触这两个功能的时候也是一脸懵，感觉名字差不多，功能好像也差不多，但实际上完全是两码事。

今天我就用最接地气的方式，把这两个功能的区别给大家讲清楚。保证你看完之后，再也不会混淆它们。

先弄明白：它们解决的根本不是同一个问题

在说区别之前，我们先来想想一个实际的场景。假设你做了一个直播APP，主播正在激情澎湃地直播，这时候你有两个需求：第一个需求是把直播画面同步推到CDN去，让更多观众能够通过网页或者第三方平台观看；第二个需求是把这堂直播课的内容录下来，方便没赶上看直播的用户回放。

第一个需求，解决的就是实时分发的问题，让内容能够实时地传播出去；第二个需求，解决的是内容沉淀的问题，让内容能够被保存下来。旁路推流和本地录制，服务的就是这样两个完全不同的目标。

我记得第一次在项目里同时用到这两个功能的时候，还闹过一个笑话。我把本地录制文件的地址直接给了产品经理说这是推流地址，结果闹了个大红脸。后来才慢慢理解，这两个功能虽然在技术实现上可能都会涉及到音视频数据的采集和处理，但它们的设计理念和使用场景有着本质的差异。

旁路推流：内容的实时分发通道

这玩意儿到底是干什么的？

简单来说，旁路推流就是把实时音视频流从声网的实时互动系统里"旁路"出来，然后推到指定的RTMP地址去。整个过程是实时的，延迟很低，主要用于直播场景的分发。

你可以这么理解：主播在APP里开播，这个直播流在声网的实时网络里跑得飞快，观众在APP里看得也很流畅。但是有些用户可能不在APP里，他们想在网页上看，或者想通过其他平台看，这时候怎么办？总不能让他们也下载APP吧？这时候旁路推流就派上用场了。

旁路推流会把实时直播流推给CDN服务商，然后CDN再把它分发给各个边缘节点。这样一来，无论用户在哪里，只要能访问CDN，就能看到直播。而且因为是实时推流，延迟可以做到很低，用户体验跟在APP里看差不多。

它的几个关键特点

实时性是它的核心竞争力。推流端和观看端之间的延迟通常可以控制在秒级，对于直播这种场景来说完全够用了。你想啊，那些秀场直播、PK直播，不都是讲究一个实时互动吗？观众给主播刷礼物，主播得能即时看到并感谢吧？要是延迟个十几秒，那体验就太糟糕了。

还有一个特点是它需要依赖外部的RTMP接收端。声网本身只是负责把流推出去，你得自己准备一个接收推流的地址，可以是CDN服务商，也可以是你自己的RTMP服务器。这就好比声网是快递公司，它负责把货物送出去，但你得先告诉它货物要送到哪个地址去。

从成本角度来看，旁路推流通常是按流量或者按时长收费的。毕竟它涉及到实时的数据传输和CDN分发，这些都是需要资源的。不过具体的价格策略这里就不多说了，各家的政策可能不太一样。

另外值得一提的是，旁路推流支持多个流的混合和转码。比如你有个连麦场景，主播和两个嘉宾在连麦，你可以设置把三个人的画面混合成一个流推出去，也可以设置分别推三个独立的流。这些都是可以通过配置来灵活调整的。

本地录制：内容沉淀的本地方案

它又是干什么用的？

本地录制就简单直接多了，它是把音视频数据录制到本地存储里。录制完成后，你会得到一个音视频文件，可以是MP4格式，也可以是M4A之类的格式，存在手机里或者服务器上。

打个比方，旁路推流像是在做现场直播，而本地录制像是在拍纪录片。直播是为了让更多人实时看到，拍纪录片是为了把内容保存下来以后看。

本地录制的应用场景也很明确。比如在线教育平台，老师讲课的内容需要录下来，方便学生课后复习；比如社交APP，用户可能想要保存跟朋友的视频通话记录；比如会议系统，会议结束后需要生成会议纪要的视频文件。这些都是本地录制的典型用武之地。

它的几个关键特点

录制质量可控是本地录制的一个大优势。因为文件是存在本地的，你可以根据需要选择不同的视频质量参数。空间够的话就用高质量模式，空间紧张就选低质量模式，自由度很高。而且录制的文件是标准的MP4格式，基本上所有的播放器都能打开，兼容性很好。

不依赖外部服务是另一个特点。本地录制不需要你准备RTMP地址，也不需要CDN，它就是把数据写到本地存储就完事了。这对于一些不需要分发的场景来说，就显得特别简单纯粹。

还有一点是录制时机灵活。你可以选择全程录制，也可以只录制某一段时间。通话结束了再开始录也行，边聊边录也可以。这种灵活性对于很多业务场景来说是非常实用的。

当然，本地录制也有它的局限性。最明显的就是它只能存在本地，如果你的APP支持用户跨设备登录，那在A手机上录的文件在B手机上就看不到了。这个问题可以通过把录制文件上传到云端来解决，但这就涉及到另外的技术方案了。

核心差异对比，一目了然

说了这么多，可能有些朋友还是觉得概念有点抽象。我特意整理了一个对比表格，把关键差异都列出来了，大家可以对照着看。

td>支持大规模分发

对比维度	旁路推流	本地录制
核心目标	实时分发内容到外部平台	保存音视频内容到本地
输出形式	实时流，推送到RTMP地址	录制文件，存储在本地
实时性	强，秒级延迟	弱，录制完成后才能使用
外部依赖	需要RTMP接收端/CDN	仅需本地存储空间
典型场景	直播分发、跨平台观看	课程录制、通话存档、内容沉淀
文件格式	无固定格式（流式传输）	MP4、M4A等标准格式
分发能力	仅限本地访问

这个表格应该能帮助大家快速建立一个整体认知。不过我要提醒一下，这只是一些核心维度的对比，实际应用的时候还需要考虑更多的细节问题。

实际项目中的选型建议

说了这么多理论，我们来看看实际项目中该怎么选择。我分几个常见的场景来说说我的建议。

直播类场景

如果是做直播APP，那旁路推流基本是标配功能。为什么？因为你不可能要求所有观众都下载你的APP吧？总有一些用户是通过公众号、微博或者搜索引擎引流过来的，他们可能只是想快速看一眼，下载APP对他们来说成本太高了。这时候旁路推流就能让这些用户直接在网页上观看直播。

那本地录制在直播场景里有没有用呢？也有。比如有些直播平台支持回放功能，用户可以看完直播之后再看一遍，这个回放视频往往就是通过本地录制生成的。不过这个录制过程通常是在服务端完成的，而不是在客户端。

社交1对1场景

对于1V1视频社交APP来说，本地录制可能用得更多一些。用户在通话过程中可能想要保存这段美好的回忆，把视频录下来以后翻出来看看。这种需求在年轻用户群体里很常见。

那旁路推流在1V1场景里能用吗？其实也能。比如有些平台支持"直播相亲"功能，两个素人通过1V1视频认识之后，如果双方都有意向，可以选择把这场通话公开直播出去，让其他用户围观。这时候就需要用到旁路推流了，把1V1的通话流推到CDN上去分发。

在线教育场景

教育场景对这两个功能的需求都很强烈。旁路推流可以用于公开课的分发，让更多潜在学生能够通过网络看到老师的授课；本地录制则用于课程内容的沉淀，方便学生课后复习，也方便平台积累教学资源。

这里有个细节要注意：教育场景对录制质量的要求通常比较高，毕竟学生是要反复观看的，画面和声音的清晰度直接影响学习效果。所以如果用本地录制的话，建议把质量参数设置得高一些，不要为了省那点存储空间而牺牲画质。

容易踩的坑，提前给你提个醒

在实际开发过程中，这两个功能都有些常见的坑，我来说几个，大家可以提前规避。

关于旁路推流的坑

第一个坑是推流地址的稳定性。如果你用的是CDN服务商的推流地址，要注意这个地址可能会过期。特别是一些CDN服务商为了安全考虑，推流地址会设置有效期，如果你的直播时间比较长，要提前处理好地址续期的问题。

第二个坑是码率控制。推流的时候如果码率设置得太高，可能会导致部分用户播放卡顿。特别是那些网络条件不太好的用户，他们可能看不了高清流。如果你的用户群体网络条件参差不齐，建议考虑自适应码率推流，让CDN端来根据用户的网络情况调整画质。

关于本地录制的坑

第一个坑是存储空间管理。如果你的APP支持用户录制大量视频，要提前考虑存储空间的清理机制。总不能让用户手机里存几十个G的录制视频吧？最好能提供一个自动清理的策略，或者引导用户把视频上传到云端。

第二个坑是录制时机。有些开发者会在通话结束的时候才开始录制，结果发现漏掉了前面的一部分内容。所以一定要在通话开始或者连麦成功之后就启动录制，中间的过程不要中断。

还有一个小细节：如果你的APP支持后台录制，要注意iOS和Android的后台录制策略不太一样。Android相对宽松一些，iOS对后台录音录像的限制比较严格，这个在开发的时候要特别注意适配。

写在最后

好了，说了这么多，其实就是想让大家明白：旁路推流和本地录制虽然看起来都能跟"录制"沾上边，但它们是完全不同的两个功能，服务的是不同的业务场景。

旁路推流解决的是"让更多人实时看到"的问题，适合直播分发这种需要大规模实时分发的场景；本地录制解决的是"把内容保存下来"的问题，适合课程录制、通话存档这种需要内容沉淀的场景。

在实际项目中，你可能会同时用到这两个功能，也可能会根据业务发展需要从只用其中一个逐步扩展到两个都用。关键是理解它们各自的适用场景，不要混为一谈。

技术选型这种事，没有绝对的对错，只有适合不适合。多想想你的用户需要什么，你的业务需要什么，然后再做决定。希望这篇文章能给你一点启发。如果有什么问题，也欢迎大家一起讨论。