PS:
推流地址为rtmp://localhost:1935/appname/streamname自己写解码264文件，如果用view显示，就需要转成bitmap显示，或者使用opengl可以显示yuv数据
如果已经保存成MP4格式的文件，就不需要解码了，通过mediaplayer就能播1: Module Configuration Struct(s)模块配置结构
这个结构的命名规则为ngx_>主程序启动后，会根据config判断是控制台模式还是后台运行模式，之后进入run_hybrid_server启动各种服务,rtmp,>这个比较麻烦，需要先从MP4中读取出H264和音频裸流，尤其是要注意关键帧的查找，然后用librtmp推送给RED5。不知道你为何要这样做，既然已经是文件了，直接把文件放到RED的相应目录下面不就可以了么RTMP协议规定，发布一个流媒体有两个前提步骤：
第一步，建立一个网络连接（NetConnection）。
第二步，建立一个网络流（NetStream）。
网络连接代表服务器端应用程序和客户端之间基础的连通关系，网络流代表了发送多媒体数据的通道。服务器和客户端之间只能建立一个网络连接，但是基于该连接可以创建很多网络流。
发布一个RTMP协议的流媒体需要经过四个阶段：
下面是使用librtmp执行推流过程的API调用流，如下：
RTMP定义了较为完善的协议标准，遵循规范，我们可以使用合适的工具进行推流，但是由于有些 *** 作是可选的，因而抓包过程又略有差异，下面是我使用ffmpeg工具推流时抓取的报文，使用wireshark分析过程整理为下面的图文。
先看一张总览图，图中显示的报文和时序包含了握手、建立连接、建立流和推流阶段，如下：
还有申明下，以下的流程是根据实际抓包情况分析出来的，由于不同的工具省略了一些不必要的步骤，故不代表标准结果，仅供参考。
由于讲解握手过程的文档资料比较多，我这里就不重复描述了，摘图如下：
个人认为这张图是最符合标准时序的，细节拿捏得非常讲究，虽然很多实现简化了流程。
包括以下报文和步骤：
协议截图如下：
协议方向：客户端 -> 服务器
块头字段：
HeaderType: 0
CSID: 3
时间戳：0
BodySize: 143
TypeID: 0x14
Stream ID: 0
负载格式：AMF0表示，connect 1 object1
object1属性列表：
"app": "live"
"type": "nonprivate"
"flashVer": "LNX 9,0,124,2"
"tcUrl": " rtmp://127001:1935/live "
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: 0x01
Stream ID: 0
负载格式：4字节整型表示，如4096
包括以下报文和步骤：
协议截图如下：
协议方向：客户端 -> 服务器
块头字段：
HeaderType: 1
CSID: 3
时间戳：0
BodySize: 30
TypeID: 0x14
负载格式：AMF0表示，releaseStream 2 object(Null) String("a")
协议截图如下：
协议方向：客户端 -> 服务器
块头字段：
HeaderType: 1
CSID: 3
时间戳：0
BodySize: 26
TypeID: 0x14
负载格式：AMF0表示，FCPublish 3 object(Null) String("a")
协议截图如下：
协议方向：客户端 -> 服务器
块头字段：
HeaderType: 1
CSID: 3
时间戳：0
BodySize: 25
TypeID: 0x14
负载格式：AMF0表示，createStream 4 object(Null)
协议截图如下：
协议方向：服务器 -> 客户端
块头字段：
HeaderType: 0
CSID: 3
时间戳：0
BodySize: 29
TypeID: 0x14
Stream ID: 0
负载格式：AMF0表示，_result 4 object(Null) Number(1)
包括以下报文和步骤：
完成推推后，还包括以下报文和步骤：
协议截图如下：
协议方向：客户端 -> 服务器
块头字段：
HeaderType: 0
CSID: 8
时间戳：0
BodySize: 31
TypeID: 0x14
Stream ID: 1
负载格式：AMF0表示，publish 5 Object(Null) String节目ID("a") String("live")
协议截图如下：
协议方向：服务器 -> 客户端
块头字段：
HeaderType: 0
CSID: 5
时间戳：0
BodySize: 105
TypeID: 0x14
Stream ID: 1
负载格式：AMF0表示，onStatus 0 Object1(Null) object2
object2属性列表：
"level": "status"
"code": "NetStreamPublishStart",
"description": "Start publishing",
End Of Object Marker
协议截图如下：
协议方向：客户端 -> 服务器
块头字段：
HeaderType: 0
CSID: 4
时间戳：0
BodySize: 387
TypeID: 0x12
Stream ID: 1
负载格式：AMF0表示，@setDataFrame "onMetaData" ECMAarray
ECMAarray属性列表：
"duration": 0,
"width": 480,
"height": 270,
"videodatarate": 1953125,
"framerate": 16,
"videocodeid": 2,
"audiodatarate": 625,
"audiosamplerate": 44100,
"audiosamplesize": 16,
"stereo": false,
"audiocodeid": 2,
"major_brand": "isom",
"minor_version": "512",
"compatible_brands": "isomiso2avc1mp41",
"encoder": "Lavf598100",
"filesize": 0,
End Of Object Marker
协议截图如下：
协议方向：客户端 -> 服务器
块头字段：
HeaderType: 0
CSID: 4
时间戳：0
BodySize: 209
TypeID: 0x08
Stream ID: 1
负载格式：格式头，媒体数据
协议截图如下：
协议方向：客户端 -> 服务器
块头字段：
HeaderType: 1
CSID: 3
时间戳：0
BodySize: 28
TypeID: 0x14
负载格式：AMF0表示，FCUnpublish 6 object(Null) String("a")
协议截图如下：
协议方向：客户端 -> 服务器
块头字段：
HeaderType: 1
CSID: 3
时间戳：0
BodySize: 34
TypeID: 0x14
负载格式：AMF0表示，deleteStream 7 object(Null) Number(1)
协议截图如下：
协议方向：服务器 -> 客户端
块头字段：
HeaderType: 0
CSID: 5
时间戳：0
BodySize: 108
TypeID: 0x14
Stream ID: 1
负载格式：AMF0表示，onStatus 0 Object1(Null) object2
object2属性列表：
"level": "status"
"code": "NetStreamUnpublishStart",
"description": "Stop publishing",
End Of Object Marker
结合以上分析，总结时序图如下：
另外，关于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(releaseStream) HeaderType: 1 CSID: 3
0x14(FCPublish) HeaderType: 1 CSID: 3
0x14(createStream) HeaderType: 1 CSID: 3
0x14(createStream _result) HeaderType: 0 CSID: 3
0x14(publish) HeaderType: 0 CSID: 8
0x14(publish onStatus) HeaderType: 0 CSID: 5
0x12(onMetaData) HeaderType: 0 CSID: 4
0x08(audioData) HeaderType: 0 CSID: 4
0x09(videoData) HeaderType: 0 CSID: 6
0x14(FCUnpublish) HeaderType: 1 CSID: 3
0x14(deleteStream) HeaderType: 1 CSID: 3
0x14(deleteStream onStatus) HeaderType: 0 CSID: 5
总结：
关于HeaderType的运用，有以下规则：
releaseStream、FCPublish、createStream、FCUnpublish、deleteStream使用1号HeaderType，借用3号CSID之前的StreamID。
audioData和videoData视情况使用0、1、2、3号HeaderType。
关于CSID的运用，有以下规则：
经与拉流对比，发现CSID的使用没有明显的约束规则，如果某类数据需要压缩头部，建议使用相同的CSID。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）