RTMP协议

RTMP协议介绍

一.概述

RTMP是Real Time Messaging Protocol(实时消息传输协议)的首字母缩写。该协议基于TCP,是一个协议族,包括RTMP基本协议及RTMPT/RTMPS/RTMPE等多种变种。RTMP 是一种设计用来进行实时数据通信的网络协议,主要用来在Flash/AIR平台和支持RTMP协议的流媒体/交互服务器之间进行音视频和数据通信。支持该协议的软件包括Adobe Media Server/Ultrant Media Server/red5等。

RTMP又是Routing Table Maintenance Protocol(路由选择表维护协议)的缩写。在AppleTalk 协议组中,路由选择表维护协议(RTMP,Routing Table Protocol)是一种传输层协议,它在AppleTalk 路由器中建立并维护路由选择表。RTMP 基于路由选择信息协议(RIP)。正如RIP 一样,RTMP 使用跳数作为路由计量标准。一个数据包从源网络发送到目标网络,必须通过的路由器或其它中间介质节点数目的计算结果即为跳数。

RTMP(Real Time Messaging Protocol)实时消息传送协议是Adobe Systems公司为Flash 播放器和服务器之间音频、视频和数据传输开发的开放协议。

它有多种变种:

1)RTMP工作在TCP之上,默认使用端口1935;

2)RTMPE在RTMP的基础上增加了加密功能;

2)RTMPT封装在HTTP请求之上,可穿透防火墙;

3)RTMPS类似RTMPT,增加了TLS/SSL的安全功能;

二.协议介绍

RTMP协议(Real Time Messaging Protocol)是被Flash用于对象,视频,音频的传输.这个协议建立在TCP协议或者轮询HTTP协议之上.

RTMP协议就像一个用来装数据包的容器,这些数据既可以是AMF格式的数据,也可以是FLV中的视/音频数据.

一个单一的连接可以通过不同的通道传输多路网络流.这些通道中的包都是按照固定大小的包传输的.

网络连接(Connection)

一个Actionscript连接并播放一个流的简单代码:

var videoInstance:Video = your_video_instance;

var nc:NetConnection = new NetConnection();

var connected:Boolean = nc.connect("rtmp:/localhost/myapp");

var ns:NetStream = new NetStream(nc);

videoInstance.attachVideo(ns);

ns.play("flvName");

默认端口为1935

三.握手请求及应答

Client →Server :向服务器发出握手请求.这不属于协议包一部分,该握手请求第一个字节为(0×03),其后跟着1536个字节.尽管看上去这部分的内容对于RTMP协议来说并不是至关重要的,但也不可随意对待.

Server →Client :服务器向客户端回应握手请求.这部分的数据仍然不属于RTMP协议的部分.该回应的起始字节仍然为(0x03),但是后边跟着两个长度为1536个字节(一共为3072字节)的包块.第一个1536块看上去似乎可以是任意内容,甚至好像可以是Null都没有关系.第二个1536的代码块,是上一步客户端向服务器端发送的握手请求的内容.

Client→Server:把上一步服务器向客户端回应的第二块1536个字节的数据块.

至此客户端与服务器端的握手结束,下面将发送RTMP协议的包内容.

Client →Server :向服务器发送连接包.

Server →Client :服务器回应.

... .... 等等... ...

RTMP 数据类型

0×01 Chunk Size changes the chunk size for packets

0×02 Unknown anyone know this one?

0×03 Bytes Read send every x bytes read by both sides

0×04 Ping ping is a stream control message, has subtypes

0×05 Server BW the servers downstream bw

0×06 Client BW the clients upstream bw

0×07 Unknown anyone know this one?

0×08 Audio Data packet containing audio

0×09 Video Data packet containing video data

0x0A - 0×11 Unknown anyone know?

0×12 Notify an invoke which does not expect a reply

0×13 Shared Object has subtypes

0×14 Invoke like remoting call, used for stream actions too.

Shared Object 数据类型

0×01 Connect

0×02 Disconnect

0×03 Set Attribute

0×04 Update Data

0×05 Update Attribute

0×06 Send Message

0×07 Status

0×08 Clear Data

0×09 Delete Data

0x0A Delete Attribute

0x0B

Initial Data

RTMP包结构

RTMP包包含一个固定长度的包头和一个最长为128字节的包体.包头可以是下面4种长度的任意一种:12, 8, 4, or 1 byte(s).

第一个字节的前两个Bit很重要,它决定了包头的长度.它可以用掩码0xC0进行"与"计算.下面的表格罗列了可能的包头长度:Bits Header Length

00 12 bytes

01 8 bytes

10 4 bytes

11 1 byte

其实RTMP包结构就是使用了AMF格式.

下面是一个关于客户端向服务器端发送流的流程:

Client→Server :发送一个创建流的请求.

Server→Client :返回一个表示流的索引号.

Client→Server :开始发送.

Client→Server :发送视音频数据包(这些包在同一个频道(channel)并用流的索引号来唯一标识).

四.RTMP协议封包

RTMP协议封包由一个包头和一个包体组成,包头可以是4种长度的任意一种:12, 8, 4, 1 byte(s).完整的RTMP包头应该是12bytes,包含了时间戳,AMFSize,AMFType,StreamID信息, 8字节的包头只纪录了时间戳,AMFSize,AMFType,其他字节的包头纪录信息依次类推。包体最大长度默认为128字节,通过chunkSize可改变包体最大长度,通常当一段AFM数据超过128字节后,超过128的部分就放到了其他的RTMP封包中,包头为一个字节.

完整的12字节RTMP包头每个字节的含义:

用途大小(Byte) 含义

Head_Type 1 包头

TIMMER 3 时间戳

AMFSize 3 数据大小

AMFType 1 数据类型

StreamID 4 流ID

1.Head_Type

第一个字节Head_Type的前两个Bit决定了包头的长度.它可以用掩码0xC0进行"与"计算:

Head_Type的前两个Bit和长度对应关系:

Bits Header Length

00 12 bytes

01 8 bytes

10 4 bytes

11 1 byte

Head_Type的后面6个Bit和StreamID决定了ChannelID。StreamID和ChannelID对应关系:StreamID=(ChannelID-4)/5+1 参考red5

ChannelID Use

02 Ping 和ByteRead通道

03 Invoke通道我们的connect() publish()和自字写的NetConnection.Call() 数据都是在这个通道的

04 Audio和Vidio通道

05 06 07 服务器保留,经观察FMS2用这些Channel也用来发送音频或视频数据

例如在rtmp包里面经常看到的0xC2, 就表示一字节的包头,channel=2.

2. TIMMER

TIMMER占3个字节纪录的是时间戳,音视频流的时间戳是统一排的。可分为绝对时间戳和相对时间戳。

fms对于同一个流,发布的时间戳接受的时间戳是有区别的

publish时间戳,采用相对时间戳,时间戳值等于当前媒体包的绝对时间戳与上个媒体包的绝对时间戳之间的差距,也就是说音视频时间戳在一个时间轴上面.单位毫秒。

play时间戳,相对时间戳,时间戳值等于当前媒体包的绝对时间戳与上个同类型媒体包的绝对时间戳之间的差距, 也就是说音视频时间戳分别为单独的时间轴,单位毫秒。

flv格式文件时间戳,绝对时间戳,时间戳长度3个字节。超过0xFFFFFF后时间戳值等于TimeStamp & 0xFFFFFF。

flv格式文件影片总时间长度保存在onMetaData的duration属性里面,长度为8个字节,是一个翻转的double类型。

3. AMFSize

AMFSize占三个字节,这个长度是AMF长度,可超过RTMP包的最大长度128字节。如果超过了128字节,那么由多个后续RTMP封包组合,每个后续RTMP封包的头只占一个字节。一般就是以0xC?开头。

4. AMFType

AMFSize占三个字节,这个长度是AMF长度,可超过RTMP包的最大长度128字节。AMFType是包的类型

0×01 Chunk Size changes the chunk size for packets

0×02 Unknown

0×03 Bytes Read send every x bytes read by both sides

0×04 Ping ping is a stream control message, has subtypes

0×05 Server BW the servers downstream bw

0×06 Client BW the clients upstream bw

0×07 Unknown

0×08 Audio Data packet containing audio

0×09 Video Data packet containing video data

0x0A-0x0E Unknown

0x0F FLEX_STREAM_SEND TYPE_FLEX_STREAM_SEND

0x10 FLEX_SHARED_OBJECT TYPE_FLEX_SHARED_OBJECT

0x11 FLEX_MESSAGE TYPE_FLEX_MESSAGE

0×12 Notify an invoke which does not expect a reply

0×13 Shared Object has subtypes

0×14 Invoke like remoting call, used for stream actions too.

0×16 StreamData 这是FMS3出来后新增的数据类型,这种类型数据中包含AudioData 和VideoData

5. StreamID

StreamID是音视频流的ID,如果AMFType!=0x08 或!=0x09那么StreamID为0。

ChannelID 和StreamID之间的计算公式:StreamID=(ChannelID-4)/5+1 参考red5

例如当ChannelID为2、3、4时StreamID都为1 当ChannelID为9的时候StreamID为2

6. 封包分析

例如有一个RTMP封包的数据03 00 00 00 00 01 02 14 00 00 00 00 02 00 07 63 6F 6E 6E 65 63 74 00 3F F0 00 00 00 00 00 00 08 ,,,

数据依次解析的含义

03表示12字节头,channelid=3

000000表示Timmer=0

000102表示AMFSize=18

14表示AMFType=Invoke 方法调用

00 00 00 00 表示StreamID = 0

//到此,12字节RTMP头结束下面的是AMF数据分析,具体的AMF0数据格式请参考https://www.360docs.net/doc/917583468.html,/fly2700/archive/2008/04/09/281432.html

02表示String

0007表示String长度7

63 6F 6E 6E 65 63 74 是String的Ascall值"connect"

00表示Double

3F F0 00 00 00 00 00 00 表示double的0.0

08表示Map数据开始

rtmp流媒体协议

H5视频直播扫盲 1 H5到底能不能做视频直播 当然可以, H5火了这么久,涵盖了各个方面的技术。 对于视频录制,可以使用强大的webRTC(Web Real-Time Communication)是一个支持网页浏览器进行实时语音对话或视频对话的技术,缺点是只在PC的chrome上支持较好,移动端支持不太理想。 对于视频播放,可以使用HLS(HTTP Live Streaming)协议播放直播流,ios和android都天然支持这种协议,配置简单,直接使用video标签即可。 webRTC兼容性: video标签播放hls协议视频:

1 2 3 4

Your browser does not support HTML5 video. 2 到底什么是HLS协议 简单讲就是把整个流分成一个个小的,基于HTTP的文件来下载,每次只下载一些,前面提到了用于H5播放直播视频时引入的一个.m3u8的文件,这个文件就是基于HLS协议,存放视频流元数据的文件。 每一个.m3u8文件,分别对应若干个ts文件,这些ts文件才是真正存放视频的数据,m3u8文件只是存放了一些ts文件的配置信息和相关路径,当视频播放时,.m3u8是动态改变的,video标签会解析这个文件,并找到对应的ts文件来播放,所以一般为了加快速度,.m3u8放在web服务器上,ts文件放在cdn上。 .m3u8文件,其实就是以UTF-8编码的m3u文件,这个文件本身不能播放,只是存放了播放信息的文本文件: 1 2 3 4 5#EXTM3U m3u文件头 #EXT-X-MEDIA-SEQUENCE 第一个TS分片的序列号#EXT-X-TARGETDURATION 每个分片TS的最大的时长#EXT-X-ALLOW-CACHE是否允许cache #EXT-X-ENDLISTm3u8文件结束符

rtmp协议

RTMP:Real Time Messaging Protocol 实时消息传送协议 字节序:大端 Message Format: Timestamp:4 bytes Length:3 bytes Type ID:1 bytes Message Stream ID:4 bytes 小端 Handshake three static_sized chunks client:C0 C1 C2 server:S0 S1 S2 simple handshake: handshake sequence 握手开始于客户端发送C0、C1块 客户端在发送C2块之前必须等待直到S1块被接收 客户端在发送任何其他数据之前必须等待直到S2块被接收 服务器在发送S0、S1之前必须等待直到C0被接收或是C1被接收服务器在发送S2之前必须等待直到C1被接收 服务器在发送任何其他数据之前必须等待直到C2被接收 C0和S0格式 一个字节(8bits) 本版本是3 C1和S1格式 1536个字节

C2和S2格式 1536个字节,是C1和S1的回复响应 time:必须包含对等段发送的时间戳(对C2来说是S1,对S2来说是C1)time2:必须包含先前发送的被对端读取的包(S1或C1)的时间戳 handshake diagram

Complete handshake Chunking Chunk format A header and data +--------------+----------------+--------------------+----------+ | Basic Header | Message Header | Extended Timestamp | Chunk Data| +--------------+----------------+--------------------+----------+ | | |<------------------- Chunk Header ----------------->| Chunk Format Basic header:1-3bytes,chunk stream ID and chunk type(fmt) 长度可变type depend on the format of the encoded message header the length depend on the chunk stream ID ID:3-65599,0\1\2 reserved 0:2bytes,ID range 64-319 (the second byte+64) 1:3bytes,ID range 64-65599(the third byte*256+the second byte+64) 2:low-level protocol 2-63: 64-319:

RTMP协议

RTMP Protocol Connect NetConnect.connect() Flash Play 通过NetConnect.connect连接到RTMP Server时,首先进行握手,再发送connect的参数. 1) 握手过程有三步: Step 1, Flash Player 至RTMP Server : 1个byte(0x03)+1536个byte数据. Step 2, RTMP Server至Flash Player : 1个byte(0x03)+1536个byte数据(Server的握手数据) + 1536个byte数据(通过和随机数hash得出, 详见附录) Step 3, Flash Player 至RTMP Server : 1536个byte数据(RTMP Server计算出来的). 注意:这个数据块没有1个byte的0x03. 2) 接下是connect参数 RTMP Server <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

RTMP Server >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>Flash Player RTMP协议步骤 Step 1 发送一个0x05的包,即ServerBW, (channel 0x02) (0x00 26 25 a0) Step 2 发送一个0x06的包,即ClientBW, (channel 0x02) (0x00 26 25 a0) + (0x02) Step 3 发送一个0x14的包,即Invoke, (channel 0x03) (body超过128的长度就要分包, 用0xc3来) string (“_result”) + number (0x3F F0 00 00 00 00 00 00) + Object string (“capabilities”) ; number (31.0) string (“fmsV er”) ; string (随便填) (“RubyIZUMI/0,1,2,0”) End Of Object (0x00 00 09) //(connect status) + Object string (“code”) ; string (“NetConnection.Connect.Success”) string (“level”) ; string (“status”) string (“description”) ; string (“Connection Succeeded.”) End Of Object (0x00 00 09) RTMP Server <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

课题_nginx搭建rtmp协议流媒体服务器总结

nginx搭建rtmp协议流媒体服务器总结 最近在ubuntu12.04上搭建了一个rtmp服务器,感觉还挺麻烦的,所以记录下。 大部分都是参考网络上的资料。 前提: 在linux下某个目录中新建一个nginx目录。 然后进入该目录去下载搭建环境所需要的一些资源包。 此处在/root/ 目录下新建一个nginx目录即: /root/nginx/ ==================================== 1、安装依赖包: #yum -y install gcc glibc glibc-devel make nasm pkgconfig lib-devel openssl-devel expat-devel gettext-devel libtool mhash.x86_64 perl-Digest-SHA1.x86_64 2、安装相关工具包 1). git # mkdir soft-source # cd soft-source # wget ://https://www.360docs.net/doc/917583468.html,/projects/git-snapshots/git/git-latest.tar.xz # xz -d git-latest.tar.xz # tar xzvf git-latest.tar # cd git-2014-06-27 # autoconf # ./configure # make && make install # git --version git version 2.0.0.GIT # cd .. 2). zlib # wget ://https://www.360docs.net/doc/917583468.html,/zlib-1.2.8.tar.gz # tar -zxvf zlib-1.2.8.tar.gz cd zlib-1.2.8 # ./configure # make # make install # cd .. 3). pcre # wget ://exim.mirror.fr/pcre/pcre-8.12.tar.gz # tar zxvf pcre-8.12.tar.gz # cd pcre-8.12 # ./configure # make && make install # cd .. 4). yadmi yadmi的作用是为flv文件添加关键帧,才能实现拖动播放 # wget ://https://www.360docs.net/doc/917583468.html,/projects/yamdi/files/yamdi/1.4/yamdi-1.4.tar.gz/download # tar xzvf download # cd yamdi-1.4 # make && make install # cd .. 使用方法: # yamdi -i input.flv -o out.flv 给input.flv文件添加关键帧,输出为out.flv文件 5). OpenSSL # wget ://https://www.360docs.net/doc/917583468.html,/source/openssl-1.0.1c.tar.gz # tar -zxvf openssl-1.0.1c.tar.gz # ./config # make # make install 3、安装ffmpeg及其依赖包: 1). Yasm # wget ://https://www.360docs.net/doc/917583468.html,/projects/yasm/releases/yasm-1.2.0.tar.gz # tar xzvf yasm-1.2.0.tar.gz

实时流煤体协议概述v1.0

实时流煤体协议概述v1.0

实时流煤体协议概述 流媒体传输类型: 流媒体传输分两类:实时流媒体和顺序流媒体 一般来说,如果视频为现场直播,或使用专用的流媒体服务器,或应用如RTSP等专用实时协议,即为实时流媒体传输; 如果使用普通的HTTP服务器,将音视频数据以从头至尾方式发送,则为顺序流媒体传输。 实时流传输既可传输实况直播,也可传输完整的音视频文件(专用协议流式)。 顺序流媒体不可用于实况直播,仅能传输完整的音视频文件(HTTP渐进式)。 主流的流媒体协议 主流的流媒体协议主要有:RTMP,HLS,RTSP等。

附:流媒体播放实现流程 一,h ttp渐进式下载原理(仅支持文件播放)http边下载边播放,严格意义上讲,不是实况直播协议。他的原理是先下载文件的基本信息,音频视频的时间戳,再下载音视频数据,以播放mp4为例,先下载文件头,根据文件头指引下载文件尾,然后再下载文件的音视频数据。 播放方式:1. 浏览器调用系统播放器播放; 2. 使HTML5的Video标签,浏览器内部支持直接播放。

二,苹果支持的hls原理(支持文件播放和实况直播)HLS的文件点播 1.使用“文件分段器”将基于H264和AAC或MP3的MPEG4分段, 生成.ts和.m3u8文件,存储于普通服务器上。 2.苹果应用程序或苹果浏览器可以通过访问.m3u8文件获取到索引, 并下载所需要的数据片段来播放。 HLS的实况直播 1.使用“流分段器”将基于H264、AAC、MP3的MPEG2传输 流分段, 2.可使用其它工具将MPEG4音视频文件加载到MPEG2传输流当中。 3.生成.ts和.m3u8文件,存储于普通服务器上。 4.苹果应用程序或苹果浏览器可以通过访问.m3u8文件获取到索引, 并下载所需要的数据片段来播放。 三,A dobe Flash 支持的RTMP协议(支持文件播放和实况直播) 必须采用Flash服务器FMS(Flash Media Server) 或 RED5. FMS的文件点播 1. 服务器(FMS或RED5)将F4v 或 Flv文件转化为RTMP流或HTTP流 2. 客户端(Flash插件或应用程序)获取RTMP流,提取相应的Flv 或 F4v文件片段进行播放。 FMS的实况直播 1.设备端(摄像头)将数据转化为F4v片段,通过RTMP流上传到服务器 2. 服务器(FMS或RED5)转发RTMP流到客户端 3. 客户端(Flash插件或应用程序)获取RTMP流,提取数据片段播放。 四,R TSP协议 RTSP为纯粹的传输控制协议。 RTSP协议本身不与它负载的媒体数据相关。 RTSP协议需要自定义客户端向服务器发送RTSP命令。

PANABIT支持协议库

Panabit V9.08(战国r3)专业版支持协议列表 (2009.10.16) 类别 应用协议 客户端 发布日期 版本号/注释 HTTP协议 WWW Web音乐 FLASH HTTP代理 HTTP下载 HTTP分块传输 伪IE下载 其他下载主要是“另存为” 土豆网https://www.360docs.net/doc/917583468.html, Web视频 酷6 https://www.360docs.net/doc/917583468.html, 6间房 https://www.360docs.net/doc/917583468.html, 优酷https://www.360docs.net/doc/917583468.html, Youtube https://www.360docs.net/doc/917583468.html, HULU网https://www.360docs.net/doc/917583468.html, 我乐网https://www.360docs.net/doc/917583468.html, Sina视频https://www.360docs.net/doc/917583468.html, Sohu视频 腾讯宽频 波波虎https://www.360docs.net/doc/917583468.html, 其他Web视频 凤凰网https://www.360docs.net/doc/917583468.html, CCTV点播https://www.360docs.net/doc/917583468.html, Viewgood https://www.360docs.net/doc/917583468.html, 常用协议 电子邮件 SMTP POP3 IMAP 终端类 VNC PCAnyWhere SSH Telnet 远程桌面 文件传输 FTP TFTP RSync 缺省端口873 NFS

CVS MSDS Microsoft-DS DNS DHCP NNTP SNMP NTP UPNP NETBIOS DAYTIME 端口为13 SYSLOG 缺省端口514 DECRPC LDAP NAT端口映射 网络管理 ISA控制协议 HTTPS Socks4/5 L2TP PPTP IPSEC GRE 网络安全 OpenVPN 360更新 Nod32更新 Windows更新 软件更新 卡巴斯基更新 流媒体协议 RTSP MMS QuickTime QuickTime 7 Windows MediaPlayer Windows MediaPlayer 11 Real Player Real Player 11 BBSee 1.3 磊客https://www.360docs.net/doc/917583468.html, 新浪奥运视频 网易奥运视频 QQ奥运视频 CCTV央视高清 RTMP P2P下载 BitComet 2009.06.22 1.13 BT BitSpirit 2009.07.27 V 3.6.0.135

RTSP协议转换RTMP直播协议

RTSP协议转换RTMP直播协议 RTSP协议也是广泛使用的直播/点播流媒体协议,最近实现了一个RTSP协议转换RTMP直播协议的程序,为的是可以接收远端设备或服务器的多路RTSP直播数据,实时转换为RTMP直播协议,推送到FMS、Red5、wowza server等RTMP 服务器,以实现flash观看RTSP直播源的需求。程序同时也具备从FLV文件获取输入数据并转换RTMP直播。实现的思路分享如下。 要点分析 首先,程序的主要目的,是从多路RTSP输入源中提取AAC编码的音频和H.264编码视频数据,并生成RTMP数据包,然后组装RTMP推送协议,并发往RTMP 服务器。在发送的过程中,要求可以从RTSP数据源切换到具有相同h.264和aac 编码的FLV文件中,并不影响RTMP直播。因此,本程序的关键点有以下部分: 1.RTSP直播流的读取 2.H.264和AAC编码数据的分析、处理 3.FLV文件数据的提取及与RTSP直接的切换和衔接 4.RTMP数据包封装 5.RTMP推送协议 有了关键点,就可以一项一项的去分析。 设计思路 根据上面分析的要点,首先要选择RTSP直播协议的读取。我们不需要从零做起,网络上有很多和RTSP相关的开源项目可以使用或借鉴,我选择了Live555。 Live555是一个跨平台的流媒体解决方案,主要支持RTSP协议,好像也支持SIP(这个也是我马上研究的重点,之后会写文章研究SIP相关的技术实现)。Live555实现了RTSP包括服务器-客户端的整套结构,是很知名的一个开源项目。网上有很多关于Live555学习和使用的文章,我就不具体介绍了。

flex视频播放器(支持rtmp协议)开发代码

Flex视频播放器(支持rtmp协议)开发代码 开发工具:flash builder4.5 + red5服务器 建议参考之前阶段代码: (1)flex视频播放器开发初级阶段代码:https://www.360docs.net/doc/917583468.html,/detail/ll_jj_yy/ (2)支持rtmp协议,播放red5服务器上的flv视频文件. 直接来代码:

RTSP协议转换RTMP直播协议

RTSP协议转换RTMP直播协议

RTSP协议转换RTMP直播协议 RTSP协议也是广泛使用的直播/点播流媒体协议,最近实现了一个RTSP协议转换RTMP直播协议的程序,为的是可以接收远端设备或服务器的多路RTSP 直播数据,实时转换为RTMP直播协议,推送到FMS、Red5、wowza server等RTMP 服务器,以实现flash观看RTSP直播源的需求。程序同时也具备从FLV文件获取输入数据并转换RTMP直播。实现的思路分享如下。 要点分析 首先,程序的主要目的,是从多路RTSP输入源中提取AAC编码的音频和H.264编码视频数据,并生成RTMP数据包,然后组装RTMP推送协议,并发往RTMP服务器。在发送的过程中,要求可以从RTSP数据源切换到具有相同h.264和aac 编码的FLV文件中,并不影响RTMP直播。因此,本程序的关键点有以下部分: 1.RTSP直播流的读取 2.H.264和AAC编码数据的分析、处理 3.FLV文件数据的提取及与RTSP直接的切换和衔接 4.RTMP数据包封装 5.RTMP推送协议 有了关键点,就可以一项一项的去分析。 设计思路 根据上面分析的要点,首先要选择RTSP直播协议的读取。我们不需要从零做起,网络上有很多和RTSP相关的开源项目可以使用或借鉴,我选择了Live555。 Live555是一个跨平台的流媒体解决方案,主要支持RTSP协议,好像也支持SIP(这个也是我马上研究的重点,之后会写文章研究SIP相关的技术实现)。Live555实现了RTSP包括服务器-客户端的整套结构,是很知名的一个开源项目。

网上有很多关于Live555学习和使用的文章,我就不具体介绍了。 H.264和AAC数据的分析处理,这个对于从没做过相关项目开发的人来说,应该是一个难点,主要是相关概念的理解。好在我一直在做这块,也比较好弄。 第4和第5点,可以参照文章“RTMP协议发送H.264编码及AAC编码的音视频(https://www.360docs.net/doc/917583468.html,/haibindev/archive/2011/12/29/2305712.html),实现摄像头直播”的技术方法,来加以实现。因此,主要需要处理的就是RTSP 直播流数据的获取,以及对其中H.264和AAC编码数据的处理。 于是可以画出大体结构如下: RtmpThread的主要工作就是发送音频数据流的解码信息头和视频数据流的解码信息头,并不断从DataBufferQueue中取出数据,封装为RTMP Packet,发送出去。流程如下列代码所示:(process_buf_queue_,即是上图中的DataBufferQueue)

RTMP头RTMP协议封包 参考Red5

RTMP头RTMP协议封包参考Red5 RTMP协议封包由一个包头和一个包体组成,包头可以是4种长度的任意一种:12, 8, 4, 1 byte(s).完整的RTMP包头应该是12bytes,包含了时间 戳,AMFSize,AMFType,StreamID信息, 8字节的包头只纪录了时间 戳,AMFSize,AMFType,其他字节的包头纪录信息依次类推。包体最大长度默认为128字节,通过chunkSize可改变包体最大长度,通常当一段AFM数据超过128字节后,超过128的部分就放到了其他的RTMP封包中,包头为一个字节. 完整的12字节RTMP包头每个字节的含义: 用途大小(Byte)含义 Head_Type1包头 TiMMER3时间戳 AMFSize3数据大小 AMFType1数据类型 StreamID4流ID 一、Head_Type 第一个字节Head_Type的前两个Bit决定了包头的长度.它可以用掩码0xC0进行"与"计算: Head_Type的前两个Bit和长度对应关系: Bits Header Length 0012 bytes 018 bytes 10 4 bytes 11 1 byte Head_Type的后面6个Bit和StreamID决定了ChannelID。 StreamID和ChannelID对应关系:StreamID=(ChannelID-4)/5+1 参考red5 ChannelID Use 02Ping 和ByteRead通道 03Invoke通道我们的connect() publish()和自字写的NetConnection.Call() 数据都

RTMP协议

RTMP协议介绍 一.概述 RTMP是Real Time Messaging Protocol(实时消息传输协议)的首字母缩写。该协议基于TCP,是一个协议族,包括RTMP基本协议及RTMPT/RTMPS/RTMPE等多种变种。RTMP 是一种设计用来进行实时数据通信的网络协议,主要用来在Flash/AIR平台和支持RTMP协议的流媒体/交互服务器之间进行音视频和数据通信。支持该协议的软件包括Adobe Media Server/Ultrant Media Server/red5等。 RTMP又是Routing Table Maintenance Protocol(路由选择表维护协议)的缩写。在AppleTalk 协议组中,路由选择表维护协议(RTMP,Routing Table Protocol)是一种传输层协议,它在AppleTalk 路由器中建立并维护路由选择表。RTMP 基于路由选择信息协议(RIP)。正如RIP 一样,RTMP 使用跳数作为路由计量标准。一个数据包从源网络发送到目标网络,必须通过的路由器或其它中间介质节点数目的计算结果即为跳数。 RTMP(Real Time Messaging Protocol)实时消息传送协议是Adobe Systems公司为Flash 播放器和服务器之间音频、视频和数据传输开发的开放协议。 它有多种变种: 1)RTMP工作在TCP之上,默认使用端口1935; 2)RTMPE在RTMP的基础上增加了加密功能; 2)RTMPT封装在HTTP请求之上,可穿透防火墙; 3)RTMPS类似RTMPT,增加了TLS/SSL的安全功能; 二.协议介绍 RTMP协议(Real Time Messaging Protocol)是被Flash用于对象,视频,音频的传输.这个协议建立在TCP协议或者轮询HTTP协议之上. RTMP协议就像一个用来装数据包的容器,这些数据既可以是AMF格式的数据,也可以是FLV中的视/音频数据. 一个单一的连接可以通过不同的通道传输多路网络流.这些通道中的包都是按照固定大小的包传输的. 网络连接(Connection)

Rtmp协议中文介绍

RTMP(real time messaging protocol)协议 1,介绍 这篇文档详细说明了RTMP消息块流,它位高层多媒体流协议提供多路技术和包服务 RTMP消息块流是为RTMP协议设计的,他可以处理任何传送消息流的协议,每一个消息包含时间戳合有效负载类型标示,RTMP消息块流和RTMP一起适用于多样性音视频应用程序,从一对一和一对多向视频点播服务器直接广播到交互式会议应用程序。 当用到实时传输协议就像TCP,RTMP消息块流提供可靠地规则时间戳的端到端全信息传送。穿过多层流,RTMP消息块流不提供任何控制的优先级别和相似形式,但是可以用于高层协议提供这样的优先级,例如:一段实时视频服务会选择丢弃给于缓慢的客户的视频信息确保音频信息可以及时被接收。 RTMP消息块流包含它自己的入队协议控制消息,也提供一个高层协议机制用于嵌入用户的控制消息。 2.定义 有效负载: 包含在包中的数据,就像音频样本或者压缩的视频数据。 包: 一个数据包由固定的包头和有效负载数据组成,一些底层协议或许需要包的封装来被定义。 端口: 在TCP/IP协议中定义的用正整数表示的端口号用于在传输中提取以区分目标主机的不同应用,用于OSI传输层的传输选择(TSEL)就是端口。 传输地址: 网络地址和端口的组合识别一个传输层终端端口,例如一个IP地址和TCP端口,数据包从一个源传输层地址传送到目标段的传输层地址。 消息流: 一个通信的逻辑通道,允许消息流通。 消息流ID: 每一个消息拥有一个分配的ID识别跟随的消息流。 消息块: 消息的片段,消息被分成小的部分,在他们在网络中发送之前交叉存储。消息块确保定制时间戳的端到端全消息传送,穿过多层流。 消息块流: 一个通信的逻辑通道,允许消息块在一个特定的方向上流通,消息块流可以从客户端传送到服务器,也可以相反。 消息块流ID: 每一个消息块有一个分配的ID用于识别更随的消息块流。 复合技术: 把分开的音视频数据组合成一条音视频流的过程,使同时传送许多音视频数据成为可能。 逆复合技术: 复合的反向过程,交叉存取组装的音频视频数据,使他们成为最初的音视频数据 3.字节顺序,列队和时间格式 所有的整数字段有被网络字节负载着,字节0是第一个显示出来的,也是一段文字和字段中最重要的。 这种字节顺序一般被认为“大字节“,数字常量在这种文档里是用十进制表示。 所有RTMP消息块流是以用字节列队,例如:一个16字节的字段也许会在字数字节的偏移段。那里要填充被标示,填充字节应该有0值(似乎看不懂). 在RTMP消息块流中的时间戳用整数表示,单位为毫秒。每一个消息块流以时间戳0开始,但是这不是必须的,只要两个终端在时间点上达成一致,注意那就意味着任何穿过多消息块流异步传输(特

rtp协议,端口

竭诚为您提供优质文档/双击可除 rtp协议,端口 篇一:实时传输协议Rtp 实时传输协议Rtp 1.Rtp协议: Rtp(Real-timetransportprotocol)协议最初是在70 年代为了尝试传输声音文件,把包分成几部分用来传输语音,时间标志和队列号。经过一系列发展,Rtp第一版本在1991年8月由美国的一个实验室发布了。到本世纪1996年形成 了标准的的版本。很多著名的公司如netscape,就宣称“netscapelivemedia”是基于Rtp协议的。microsoft也宣称他们的“netmeeting”也是支持Rtp协议. Rtp被定义为传输音频、视频、模拟数据等实时数据的 传输协议。最初设计是为了数据传输的多播,但是它也用于单播的。与传统的注重的高可靠的数据传输的运输层协议相比,它更加侧重的数据传输的实时性。此协议提供的服务包括时间载量标识、数据序列、时戳、传输控制等。Rtp与辅 助控制协议Rtcp一起得到数据传输的一些相关的控制信息。 2.Rtp协议的工作原理:

如上所说明的,影响多媒体数据传输的一个尖锐的问题就是不可预料数据到达时间。但是流媒体的传输是需要数据的适时的到达用以播放和回放。Rtp协议就是提供了时间标签,序列号以及其它的结构用于控制适时数据的流放。 在流的概念中‘时间标签’是最重要的信息。发送端依照即时的采样在数据包里隐蔽的设置了时间标签。在接受端收到数据包后,就依照时间标签按照正确的速率恢复成原始 的适时的数据。不同的媒体格式调时属性是不一样的。但是Rtp本身并不负责同步,Rtp只是传输层协议,为了简化了 运输层处理,提高该层的效率。将部分运输层协议功能(比如流量控制)上移到应用层完成。同步就是属于应用层协议完成的。它没有运输层协议的完整功能,不提供任何机制来保证实时地传输数据,不支持资源预留,也不保证服务质量。Rtp报文甚至不包括长度和报文边界的描述。同时Rtp协议 的数据报文和控制报文的使用相邻的不同端口,这样大大提高了协议的灵活性和处理的简单性。 Rtp协议和udp二者共同完成运输层协议功能。udp协 议只是传输数据包,是不管数据包传输的时间顺序。Rtp的 协议数据单元是用udp分组来承载的。在承载Rtp数据包的时候,有时候一帧数据被分割成几个包具有相同的时间标签,则可以知道时间标签并不是必须的。而udp的多路复用让Rtp 协议利用支持显式的多点投递,可以满足多媒体会话的需求。

RTMP协议详解

Real Time Messaging Protocol(实时消息传送协议协议)是Adobe Systems 公司为Flash播放器和服务器之间音频、视频和数据传输开发的私有协议。 具体使用RTMP的AS代码大概如下: var videoInstance:Video = your_video_instance; var nc:NetConnection = new NetConnection(); var connected:Boolean = nc.connect("rtmp://localhost/myapp"); var ns:NetStream = new NetStream(nc); videoInstance.attachVideo(ns); ns.play("flvName"); Adobe也在官方网站已经提供了RTMP协议的官方文档说明,为什么要写这个系列文章最大的原因只是对前一段工作的一个总结和回顾,最近两个月,实现了一个RTMP Server的c++版本,把公司的流媒体服务和flash无缝对接起来。希望我的文字能给后来研究这个协议的同学有一定的帮助。 RTMP协议是一个基于TCP的高层协议族,当然这个玩意据说还有UDP协议版本的,不过现在还没有出来,好像Adobe下一版本的FMS会提供支持。下文将要描述的是TCP协议版本的协议。 RTMP协议的概要理解: RTMP协议是为了和flash之间交换信令以及媒体数据。为了提高使用效率信令和媒体数据都是使用相同的机制。因为是相同的机制Adobe就整出来了一些比较搞人的概念,当然每个协议第一次接触都是比较难理解的。 在RTMP协议中信令和媒体数据都称之为Message,在网络中传输这些Message,为了区分它们肯定是要加一个Message head的,所以RTMP协议也有一个Message head,还有一个问题因为RTMP协议是基于TCP的,由于TCP的包长度是有限制的(一般来说不超过1500个字节),而RTMP的Message长度是有可能很大的,像一个视频帧的包可能会有几十甚至几千K,这个问题就必然有一

RTMP协议简介

专题报告:RTMP 协议

目录 专题报告:RTMP协议 (1) 一:什么是rtmp (3) 二:RTMP消息格式 (5) 三:RTMP握手过程 (10) 三.协议控制消息 (21) 四:消息交换的例子 (25)

写在前面红色字体是重点必读,蓝色字体是分点便于区分,绿色字体是次分点便于区分一:什么是rtmp

RTMP协议 Real Time Messaging Protocol(实时消息传送协议协议)实时消息传送协议是Adobe Systems公司为Flash播放器和服务器之间音频、视频和数据传输开发的私有协议。它有三种变种: 1)工作在TCP之上的明文协议,使用端口1935; 2)RTMPT封装在HTTP请求之中,可穿越防火墙; 3)RTMPS类似RTMPT,但使用的是HTTPS连接; 介绍: RTMP协议是被Flash用于对象,视频,音频的传输.该协议建立在TCP协议或者轮询HTTP协议之上. RTMP协议就像一个用来装数据包的容器,这些数据可以是AMF格式的数据,也可以是FLV中的视/音频数据. 一个单一的连接可以通过不同的通道传输多路网络流.这些通道中的包都是按照固定大小的包传输的. RTMP中定义了两种通信单元:消息(message)和消息块(chunk).RTMP消息是协议中实现各种流媒体控制和应用的基本逻辑信息单元,消息从种类上可以分为协议控制消息、用于发送音频数据的音频消息、用于发送视频数据的视频消息、发送用户数据的数据消息、共享对象消息以及命令消息,属于相同逻辑通道的消息组成一个消息流,这个逻辑通道通过消息格式中的“消息流ID”字段来标识。 作为应用层协议,RTMP协议架构在TCP层之上,但RTMP消息并不是直接封装在TCP中,而是通过一个被称为消息块的封装单元进行传输。消息在网络上发送之前往往要分割成多个较少的部分,这些较小的部分就是消息块,属于不同消息流的消息块可以在网络上交叉发送。这样做可以保证各个消息流中的高优先级消息块能够严格按照时间顺序达到通信的对端。比如某个较长消息的实时性要求比较低,如果不进行消息块处理,等长消息都发送完毕后再发送实时性要求高的短消息,则会对流媒体的播放质量造成影响。

相关主题
相关文档
最新文档