Go语言搭建流媒体服务器分享

livego搭建直播服务器github开源代码：https://github.com/L-HeliantHuS/livego
小葫芦直播官网（基于OBS）：https://www.xiaohulu.com/
OBS官网，用于直播推流：
https://obsproject.com/

livego

• 简单高效的直播服务器
• 安装和使用非常简单;
• 纯Golang编写，性能高，跨平台;
• 支持常用的传输协议，文件格式，编码格式;

支持的传输协议

• RTMP
• AMF
• HLS
• HTTP-FLV

支持的容器格式

• FLV
• TS

支持的编码格式

• H264
• AAC
• MP3

安装

git clone https://github.com/gwuhaolin/livego.git

cd liveog && go build

注：这里有可能报错，原因是git后包导入的位置不对

解决：用Goland打开，Alt+Enter再导入一遍（有更好的解决方法请大佬们指教，本人Go语言学习不精）

1.开启推流服务器

go build之后生成exe二进制可执行文件，打开在后台运行

由图可见服务器监听1935端口

2.用直播软件录屏并将Go写的推流服务器配置上

这里推荐国产的小葫芦直播软件（基于OBS）

3.配置服务器，开启抓屏，开始直播（推流）

个人理解：直播码类似于token，在后面获取直播画面时要填
协议：RTMP协议（第一次接触，还不太了解，后面会进行补充）
一般直播时，如某牙，某鱼平台，会给你提供RTMP地址，和直播码
而不是向我这样填，127.0.0.1代表本机的服务器

后台会输出

4.用PotPlayer打开（视频播放神器）

即可看到在小葫芦里推送的录屏画面

最后附上两张拉钩上小葫芦的招聘信息

流媒体服务器学习

流媒体在播放之前都要通过服务器进行过传输，从而实现播放行为

1.什么是流媒体服务器？

流媒体是将一连串的媒体数据压缩后，经过网上分段发送数据，进行网上即时传输，是边下载边观赏影音的一种技术和过程。使得数据包像水流一样发送，如果不适用此技术，必须在使用之前下载整个流媒体文件。

流媒体服务器是流媒体应用的核心系统，在流媒体技术中承担了对音频，视频，图片等进行采集，缓存，调度和传输播放等功能。

流媒体服务器既然是在网络上输送流媒体数据到数据客户端，就一定涉及传输协议。流媒体服务器最常采用的协议有：RTMP,RTP,RTSP等。

2.流媒体服务器的传输方式有哪些？

主要传输方式有：顺序流式传输和实时流式传输

• 顺序流式传输：即顺序下载，在下载文件的同时，用户可以观看在线媒体。如果使用普通的HTTP服务器，将音视频数据通过从头到尾的方式进行发送即为顺序流媒体传输。
• 实时流式传输：总是实时传送，非常适合现场事件。比如视频为现场直播或者是使用专用的流媒体服务器，可以应用像RTSP等专用实时协议。实时流式传输必须要匹配链接宽带，也意味着图像质量会因网络速度的降低而变差。

以上就是流媒体服务器的主要内容和原理，而且在流式传输的过程中，流媒体数据是具有实时性和等时性等基本特点的，流服务器和客户终端需要保证各种媒体之间的同步关系。由此可见，在开发过程中需要注意和兼顾的问题有很多。所以在直播平台建设的过程中，流媒体传输对于最大延时和延时抖动等参数的严格要求是需要特别注意的。

点量流媒体服务器和普通服务器有什么区别？

点量流媒体服务器除了能实现视频服务器所有功能外，点量流媒体流媒体服务器还可以实现直播转播大并发，加密​‌‌防盗，边下边播功能，结合ott点播系统使用效果更佳！

点量流媒体服务器可以把连续的音频和视频信息压缩后​‌‌放到网络服务器上，用户边下载边观看，而不必等待整个文件下载完毕。基于点量流媒体技术的优越性，点量流媒体服务器广泛应用于视频点播、视频会议、远程教育、远程医疗和在线直播系统中：

（1）直播流格式不统一问题

简洁化操作，可将本地UDP、RTP等直播流，转变成M3U8的地址，不改变视频原有的清晰度。视频输入播放器的格式可能是多样的，而通过流媒体中转系统，可以将所有的视频格式转换成播放器都支持的M3U8，解决播放格式不统一问题。

（2）对视频地址加密，防盗链

对于经过流媒体中转系统的直播流地址，可以实现加密，加密后的视频配合点量播放器播放，防止视频源被盗。

（3）直播流的管理

支持对需要管理操作的电视直播流频道地址的手动处理，包括添加删除。

（4）组播地址转变为单播地址

该系统可实现将局域网直播流组播地址，转化为对外的单播地址，解决组播跨网段的问题，同时实现对其加密。

（5）高并发稳定性

通过点量流媒体中转服务器系统后，还可以解决人数高并发时期系统的稳定性。单台流媒体服务器软件，支持并发的用户规模数不少于5000用户

Webrtc 初探

webrtc是一种免费开源的实时通信技术，集成了音视频采集、编解码、流媒体传输、渲染等功能，并在Native代码基础上，封装了简单的JavaScript api，仅通过几行代码即可实现点对点通信，且具有良好的跨平台特性，目前主流的浏览器都已支持。

基本概念

SDP： 即会话描述协议，主要保存当前会话的媒体和传输信息，其中媒体信息包括媒体类型、传输协议、媒体格式等，传输信息包括媒体的远程地址信息、带宽等；它由多行kv格式的文本信息组成，具体可参考这里。（https://tools.ietf.org/pdf/draft-nandakumar-rtcweb-sdp-08.pdf）
Offer： 通信的发起方对自己的sdp描述
Answer： 通信的接收方对自己的sdp描述
信令： 协调发起方、接收方通信的数据信息，其中包括sdp描述信息、会话控制信息（节点加入、退出及各类的业务控制信息等）、网络信息、错误信息等。

webrtc通信

基于webrtc的点对点音视频通信示意图如下图所示：

Webrtc与直播：

1.rtmp方式

众所周知，目前主流的直播方案一般采用rtmp方式，首先客户端采集音视频流，并通过rtmp协议推流到流媒体服务器，流媒体服务器做一些编码处理等将流分发给各个客户端，进而拉流播放。出于成本、安全等考虑，可能会将不同流按照一定的配比推送到不同的流媒体服务商，在特殊情况下可采用调度方式进行切流处理。

优点：

• CDN 支持良好，主流的 CDN 厂商都支持
• 技术比较成熟，集成方便，例如声网、即构等，集成对应平台的sdk即可进行推流。
• 相较于端对端的webrtc方式，并发度高，适合多人直播场景；

缺点：

• 协议基于tcp，相对于webrtc方式延时较大，对于某些低延时场景体验较差；
• 不支持浏览器推流等；

2、基于端对端的webrtc

基于端对端的webrtc方式，严格来说不属于常规的直播场景，其主要适用于人数较少的视频会议等场景，各个节点分别建立p2p连接进行音视频的传输，主要工作流程如上边webrtc所示。

优点：

• 在web端，对于开发者和使用者来说，音视频通信的开发和使用简单化；对于开发者来说，门槛低，不必熟悉流媒体，仅调用js api即可实现；对于使用者来说，打开浏览器等浏览器即可。
• 点对点通信，节省服务器带宽费用。
• 相对于基于tcp的rtmp推拉流方式，支持udp的webrtc方式延时低。

缺点：

• 客户端浏览器的性能有局限。如果是1v1方式的直播连麦，尚好；如果多人同时进行直播连麦，浏览器需要同时给多人进行视频传输，性能欠佳。
• 音视频处理相对来说比较困难。webrtc开放的api接口较少，集成第三方音视频处理方案较难，比如秀场直播的美颜等。
• 音视频的传输质量难以保障，尤其在跨地区、跨运营商的情况下，仅能做一下端对端质量控制算法，无法保障。
• 兼容性问题。在pc端，目前的主流浏览器都支持webrtc，但是在移动端，只有部分浏览器支持（目前国内的主流手机浏览器均不支持）。
• 关于直播内容的后续工作不好展开，内容质量难以把控。比如rtmp推拉流方式生成的回放、内容审核等很难处理了。

3、基于媒体服务器的webtrc直播：

基于端对端的webrtc受限于客户端性能、连接人数等限制，很难适用于直播场景。为了解决这些问题，可以引入媒体服务器，客户端仅传输一路音视频流到媒体服务器，其余客户端通过与媒体服务器建立连接进行音视频显示。

目前开源的主流webrtc媒体服务器如下：

Kurento https://github.com/Kurento/kurento-media-server
licode https://github.com/lynckia/licode
janus https://github.com/meetecho/janus-gateway

优点：

• 相对于端对端的webrtc方式，避免了客户端性能低、音视频处理、内容审核等问题，支持更为复杂的应用场景；

• 支持多人进行同时观看直播，并发度高；

• 在web端集成相对简单容易，采用浏览器即可接入，且延时较低；
  缺点：

• 该种方式相对于端对端的webrtc方式，开发成本较高，需要实现自己的媒体服务器，而目前没有比较成熟的方案。

• 相对于成熟的rtmp配套解决方案，周边设施相对较少。

综上所述，基于端对端的webrtc直播的方式不适合直播场景；基于媒体服务器的webtrc直播，目前还没有成熟的解决方案，需要自己实现媒体服务器，门槛较高，具体可根据开发成本与收益进行定夺。

学习内容来自：
https://cloud.tencent.com/developer/article/1404542
https://www.bilibili.com/video/av63365608
https://github.com/L-HeliantHuS/livego
https://cloud.tencent.com/developer/article/1335458
https://mp.weixin.qq.com/s/ckoqEb07agM9N6NBMwWRew