包含librtmpjava的词条
今天给各位分享librtmpjava的知识，其中也会对进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！
本文目录一览：
如何使用ndk编译ffmpeg静态库
如何使用ndk为ffmpeg编译rtmp+polarssl静态库？这个问题花了我整整一天时间。其中遇到很多小问题，这里记录一下，方便自己也方便其他人。
1、编译polarssl，查看其Readme文件即可，不需要configure，只需要make时带上必要的参数即可，不过要记得在每一次执行make命令时都带上CC的参数（指向你的arm gcc），因为我试过在make install时没有带上CC的参数，虽然能编译出polarssl但是未能正确被rtmp引用到。
2、因为前面我用的polarssl是当前最新（1.3.7）版本，而librtmp使用的好像是polarssl1.0.0以下版本的api，所以需要修改rtmp部分源码，让其调用新版polarssl的api，这里的修改可以参照《Migrating from PolarSSL-1.2 to the PolarSSL 1.3 branch》和《[rtmpdump] branch master updated. a312ac7 Fix compat with PolarSSL = 1.1.0》。
3、出现 undefined reference to `havege_random’错误，这里是因为polarssl默认关闭了havege模块，需要你手动开启，主要就是修改include/polarssl/config.h，去掉POLARSSL_HAVEGE_C前的注释，也就是要定义POLARSSL_HAVEGE_C，如下：
#define POLARSSL_HAVEGE_C
4、在编译出上面两个库之后，可以开始编译ffmpeg（2.1.1版本）了，如果遇到下面的问题 check_pkg_config librtmp librtmp/rtmp.h RTMP_Socket
ERROR: librtmp not found
这里有三种解决方法：
第一种，因为是网络上传播最多的，算是比较简便的方法，就是修改ffmpeg的configure，将以下一行：
enabled librtmp require_pkg_config librtmp librtmp/rtmp.h RTMP_Socket
改为：
enabled librtmp require librtmp librtmp/rtmp.h RTMP_Socket -lrtmp -lpolarssl -lz
或者直接注释掉 ＊＊＊ 部分，然后再自己加上librtmp的库路径也行
第二种，（比较推荐，因为解决了这个会顺带解决大部分找不到库的错误！）因为这里使用了pkg-config工具查找库，而这个工具ndk并没有附带提供，而出现check_pkg_config相关错误的话，只要稍加注意，会发现在使用configure配置ffmpeg的交叉编译时，已经有相应的pkg-config不存在的警告了。我对这个工具不熟悉，所以我只是简单地加上了一个软链接到系统的pkg-config，如下：
ln -s /usr/bin/pkg-config /home/cidy0106/android-ndk-r9d/toolchains/arm-linux-androideabi-4.8/prebuilt/linux-x86_64/bin/arm-linux-androideabi-pkg-config
这个时候重新configure的话可能会出现找不到polarssl库的错误提示，需要修改一下librtmp安装目录里的librtmp.pc,把以下内容：
Libs: -L${libdir} -lrtmp -lz
改为：
Libs: -L${libdir} -lrtmp -lz -lpolarssl
至此，就可以正确编译出ffmpeg了
转载
RTMP协议抓包分析推流过程
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://127.0.0.1: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": "NetConnection.Connect.Success",
"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": "NetStream.Publish.Start",
"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": 195.3125,
"framerate": 16,
"videocodeid": 2,
"audiodatarate": 62.5,
"audiosamplerate": 44100,
"audiosamplesize": 16,
"stereo": false,
"audiocodeid": 2,
"major_brand": "isom",
"minor_version": "512",
"compatible_brands": "isomiso2avc1mp41",
"encoder": "Lavf59.8.100",
"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": "NetStream.Unpublish.Start",
"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。
如何在自己的应用程序直接接收rtmp流
一，目标: 利用开源或者免费工具实现一个直播系统；同时支持在浏览器、播放器和嵌入到 PC 应 用或者移动 APP 中观看直播。 二，技术选型: 视音频源端:： Adobe Flash Media Live Encoder 3.2，可以在 windows 和 mac 安装； 如果你已有一些支持 RTMP 的采集设备，那是最好了； 或许你想在自己的应用中实现，这样你就必须自己开发处理采集，编码和协议传输了(以后 再表)； RTMP Server： FMS -- Adobe 公司出品的服务器，价格昂贵，当然是最正宗的，因为 RTMP 就是 Adobe 公 司的私有协议； Wowza -- 同样需要授权费， 大概是$55 per month/instance，效率和稳定性都还不错； Red5 -- 一个开源实现， 效率和稳定性都稍微差些，由于它是 java 实现的，所以天生支持 跨平台运行； Nignx-rtmp-module - -nginx 的一个第三方模块，如果你熟悉 nginx 那是不错的选择，当然它 也是免费的，不过功能就没有其他几个丰富了； 这里我选择 nginx+nginx-rtmp-module 作为服务器，这是我认为最容易上手的一种方式了(如 果 你 把 windows 作 为 服务 器 那 可 能 麻烦 些 ， 官 方 提供 的 windows 二 进 制版 本 是 没 有 nignx-rtmp-module 的，而且 nginx 在 windows 下的性能比 linux 就差太多了) 客户端： VLC 也可以安装其他支持 rtmp 的播放器； JW Media Player 一个开源的 flash 视音频播放器， 利用它我们可以直接在浏览器观看直播； (移动端的浏览器是不知道 flash 的) ffmpge/librtmp 如果你希望在自己的应用中实现播放器，或者希望在移动端直接接收 RTMP 流，那就要自己开发了(以后再表) 最后选型是： Adobe Flash Media Live Encoder 3.2 + Nignx-rtmp-module + JW Media Player 三，实现 (本文将 nginx 安装到 Centos 6.5 下，IP 为 192.168.0.51) 1，下载安装 Adobe Flash Media Live Encoder 3.2 2，编译安装配置 nginx + nginx-rtmp-module (nginx 1.7 无法编译通过) #wget #tar -zxvf nginx-1.6.2.tar.gz #git clone (如果没有安装 git 则直接下载 zip 包) #cd nginx-1.6.2 #./configure --add-module=../nginx-rtmp-module --with-http_ssl_module #make #make install 配置 ( 详细查看 ), 编辑 nginx/nginx.conf ，增加 rtmp 模块: rtmp { server { Listen 1935; chunk_size 4000; #可以将 mylive 改成你想要的名字 application mylive { live on; } } } 在 http 模块增加： location /stat{ rtmp_stat all; rtmp_stat_stylesheet stat.xsl; } location /stat.xsl{ root html; } 同时需要将 nginx-rtmp-module 源码目录下的 stat.xsl 拷贝到 nginx/html 下，这样就可以通过 网页查看服务器的 RTMP 状态了。
RTMP协议抓包分析拉流过程
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://127.0.0.1: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": "NetConnection.Connect.Success",
"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": "NetStream.Play.Start",
"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的运用，有以下规则：
关于librtmpjava和的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。