怎么做到微信直播，HTML5直播，低延时

功能模块概述
通过obs客户端推流到nginx流媒体服务器上，对流媒体用ffmpeg将流剪切为若干段ts流文件并保存到临时目录中，通过访问m3u8格式拼接ts流文件段来观看直播。
推流端
采用开源工具OBS客户端进行推流
根据项目的推流地址，填入OBS客户端（下载地址）中，并设置场景，保存后重启，便可开始推流。
为更加稳定的推流，建议使用以上链接中的v0625稳定版本，按提示安装完成后，打开设定在广播设定中，伺服器统一填写我们项目的流媒体接收流地址：
rtmp://127001:1935/hls/
以上这几个数据都是可以更改的。
127001——你的流媒体服务器ip
1935——你的rtmp端口号
hls——你的直播nginx配置模块
具体在下文中也有详细介绍
配置地址
回到主界面，右键来源，选择添加视频捕捉设备或获取窗口等（相关设置默认即可），点击开始串流，便可开始直播。
添加场景
图为添加视频捕捉设备后的直播画面：
直播中
流媒体服务器
Nginx接收推流模块
rtmp_auto_push on;
rtmp {
server {
listen 1935;
application hls {
live on;
hls on;
hls_path /tmp/hls;
on_publish 项目地址/liveOnPublish;
on_publish_done 项目地址/liveOnDone;
notify_method get;
}
}
}
配上我在word上的注解
注解1
Nginx处理直播流模块
>1用-v挂载主机数据卷到容器内
docker run -v /path/to/hostdir:/mnt $container
在容器内拷贝
cp /mnt/sourcefile /path/to/destfile
2直接在主机上拷贝到容器物理存储系统
A 获取容器名称或者id :
$ docker ps
B 获取整个容器的id
$ docker inspect -f '{{Id}}' 步骤A获取的名称或者id
C 在主机上拷贝文件:
$ sudo cp path-file-host /var/lib/docker/aufs/mnt/FULL_CONTAINER_ID/PATH-NEW-FILE
或者
$ sudo cp path-file-host /var/lib/docker/devicemapper/mnt/123abc<<id>>/rootfs/root
例子：
$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
d8e703d7e303 solidleon/ssh:latest /usr/sbin/sshd -D cranky_pare
$ docker inspect -f '{{Id}}' cranky_pare
or
$ docker inspect -f '{{Id}}' d8e703d7e303
d8e703d7e3039a6df6d01bd7fb58d1882e592a85059eb16c4b83cf91847f88e5
$ sudo cp filetxt /var/lib/docker/aufs/mnt/d8e703d7e3039a6df6d01bd7fb58d1882e592a85059eb16c4b83cf91847f88e5
3用输入输出符
docker run -i Ubuntu /bin/bash -c 'cat > /path/to/container/file' < /path/to/host/file/
或者
docker exec -it <container_id> bash -c 'cat > /path/to/container/file' < /path/to/host/file/

RTMP协议规定，播放一个流媒体有两个前提步骤：
第一步，建立一个网络连接（NetConnection）。
第二步，建立一个网络流（NetStream）。
网络连接代表服务器端应用程序和客户端之间基础的连通关系，网络流代表了发送多媒体数据的通道。服务器和客户端之间只能建立一个网络连接，但是基于该连接可以创建很多网络流。

播放一个RTMP协议的流媒体需要经过四个阶段：

下面是使用librtmp执行拉流过程的API调用流，如下：

RTMP定义了较为完善的协议标准，但是每种播放工具的实现略有差异，下面是我使用VLC播放器拉流时抓取的报文，使用wireshark分析过程整理为下面的图文。

先看一张总览图，图中显示的报文和时序包含了握手、建立连接、建立流和播放阶段，如下：

还有申明下，以下的流程是根据实际抓包情况分析出来的，由于不同的工具省略了一些不必要的步骤，故不代表标准结果，仅供参考。

由于讲解握手过程的文档资料比较多，我这里就不重复描述了，摘图如下：

个人认为这张图是最符合标准时序的，细节拿捏得非常讲究，虽然很多实现简化了流程。

包括以下报文和步骤：

协议截图如下：

协议方向：客户端 -> 服务器
块头字段：
     HeaderType: 0
     CSID: 3
     时间戳：0
     BodySize: 201
     TypeID: 0x14
     Stream ID: 0
负载格式：AMF0表示，connect 1 object1
     object1属性列表：
          "app": "live"
          "flashVer": "LNX 9,0,124,2"
          "tcUrl": " rtmp://127001:1935/live "
          "fpad": false
          "capabilities": 15,
          "audioCodes": 4071,
          "videoCodes": 252,
          "videoFunction": 1,
          End Of Object Marker

协议截图如下：

协议方向：服务器 -> 客户端
块头字段：
     HeaderType: 0
     CSID: 2
     时间戳：0
     BodySize: 4
     TypeID: 0x05
     Stream ID: 0
负载格式：4字节整型表示，如5000000

协议截图如下：

协议方向：服务器 -> 客户端
块头字段：
     HeaderType: 0
     CSID: 2
     时间戳：0
     BodySize: 5
     TypeID: 0x06
     Stream ID: 0
负载格式：5字节整型表示，前4字节为带宽，后1字节为标志，如5000000, 2(动态调整)

协议截图如下：

协议方向：服务器 -> 客户端
块头字段：
     HeaderType: 0
     CSID: 2
     时间戳：0
     BodySize: 4
     TypeID: 0x01
     Stream ID: 0
负载格式：4字节整型表示，如4096

协议截图如下：

协议方向：服务器 -> 客户端
块头字段：
     HeaderType: 0
     CSID: 3
     时间戳：0
     BodySize: 190
     TypeID: 0x14
     Stream ID: 0
负载格式：AMF0表示，_result 1 object1 object2
     object1属性列表：
          "fmsVer": "FMS/3,0,1,123"
          "capabilities": 31,
          End Of Object Marker
     object2属性列表：
          "level": "status"
          "code": "NetConnectionConnectSuccess",
          "description": "Connection succeeded",
          "objectEncoding": 0
          End Of Object Marker

协议截图如下：

协议方向：客户端 -> 服务器
块头字段：
     HeaderType: 0
     CSID: 2
     时间戳：0
     BodySize: 4
     TypeID: 0x05
     Stream ID: 0
负载格式：4字节整型表示，如5000000

包括以下报文和步骤：

协议截图如下：

协议方向：客户端 -> 服务器
块头字段：
     HeaderType: 1
     CSID: 3
     时间戳：0
     BodySize: 25
     TypeID: 0x14
负载格式：AMF0表示，createStream 2 object(Null)

协议截图如下：

协议方向：服务器 -> 客户端
块头字段：
     HeaderType: 0
     CSID: 3
     时间戳：0
     BodySize: 29
     TypeID: 0x14
     Stream ID: 0
负载格式：AMF0表示，_result 2 object(Null) Number(1)

包括以下报文和步骤：

协议截图如下：

协议方向：客户端 -> 服务器
块头字段：
     HeaderType: 0
     CSID: 8
     时间戳：0
     BodySize: 30
     TypeID: 0x14
     Stream ID: 1
负载格式：AMF0表示，play 4 Object(Null) String节目ID("a") Number开始时间(-2000)

协议截图如下：

协议方向：客户端 -> 服务器
块头字段：
     HeaderType: 1
     CSID: 2
     时间戳：1
     BodySize: 10
     TypeID: 0x04
负载格式：Event Type，2字节的类型(3) 4字节的流ID(1) 4字节的MS时间单位(3000)

协议截图如下：

协议方向：服务器 -> 客户端
块头字段：
     HeaderType: 0
     CSID: 2
     时间戳：0
     BodySize: 6
     TypeID: 0x04
负载格式：Event Type，2字节的类型(0) 4字节的流ID(1)

协议截图如下：

协议方向：服务器 -> 客户端
块头字段：
     HeaderType: 0
     CSID: 5
     时间戳：0
     BodySize: 96
     TypeID: 0x14
     Stream ID: 1
负载格式：AMF0表示，onStatus 0 Object1(Null) object2
     object2属性列表：
          "level": "status"
          "code": "NetStreamPlayStart",
          "description": "Start live",
          End Of Object Marker

协议截图如下：

协议方向：服务器 -> 客户端
块头字段：
     HeaderType: 0
     CSID: 5
     时间戳：0
     BodySize: 387
     TypeID: 0x12
     Stream ID: 1
负载格式：AMF0表示，onMetaData object
     object属性列表：
          "Server": "NGINX RTMP"
          "width": 480,
          "height": 270,
          "displayWidth": 480,
          "displayHeight": 270,
          "duration": 0,
          "framerate": 16,
          "fps": 16,
          "videodatarate": 193,
          "videocodeid": 7,
          "audiodatarate": 52,
          "audiocodeid": 10,
          "profile": "",
          "level": "",
          End Of Object Marker

协议截图如下：

协议方向：服务器 -> 客户端
块头字段：
     HeaderType: 0
     CSID: 6
     时间戳：0
     BodySize: 209
     TypeID: 0x08
     Stream ID: 1
负载格式：格式头，媒体数据

结合以上分析，总结时序图如下：

另外，关于HeaderType和CSID的运用，先归纳使用情况：
0x14(connect) HeaderType: 0 CSID: 3
0x05(Ack Window Size) HeaderType: 0 CSID: 2
0x06(BrandWidth) HeaderType: 0 CSID: 2
0x01(ChunkSize) HeaderType: 0 CSID: 2
0x14(connect _result) HeaderType: 0 CSID: 3
0x14(createStream) HeaderType: 1 CSID: 3
0x14(createStream _result) HeaderType: 0 CSID: 3
0x14(play) HeaderType: 0 CSID: 8
0x04(SetBufferMS) HeaderType: 1 CSID: 2
0x04(Stream Begin) HeaderType: 0 CSID: 2
0x14(play onStatus) HeaderType: 0 CSID: 5
0x12(onMetaData) HeaderType: 0 CSID: 5
0x08(audioData) HeaderType: 0 CSID: 6
0x09(videoData) HeaderType: 0 CSID: 7

总结：
关于HeaderType的运用，有以下规则：
createStream使用1号HeaderType，借用3号CSID之前的StreamID。
SetBufferMS使用1号HeaderType。
audioData和videoData视情况使用0、1、2、3号HeaderType。
关于CSID的运用，有以下规则：

nginx配合ffmpeg做流媒体服务器的原理是: nginx通过rtmp模块提供rtmp服务, ffmpeg推送一个rtmp流到nginx,
然后客户端通过访问nginx来收看实时视频流 HLS也是差不多的原理,只是最终客户端是通过>