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
2 到底什么是HLS协议？
简单讲就是把整个流分成一个个小的，基于HTTP的文件来下载，每次只下载一些，前面提到了用于H5播放直播视频时引入的一个.m3u8的文件，这个文件就是基于HLS协议，存放视频流元数据的文件。
每一个.m3u8文件，分别对应若干个ts文件，这些ts文件才是真正存放视频的数据，m3u8文件只是存放了一些ts文件的配置信息和相关路径，当视频播放时，.m3u8是动态改变的，video标签会解析这个文件，并找到对应的ts文件来播放，所以一般为了加快速度，.m3u8放在web服务器上，ts文件放在cdn上。
.m3u8文件，其实就是以UTF-8编码的m3u文件，这个文件本身不能播放，只是存放了播放信息的文本文件：
1 #EXTM3U m3u文件头
2 3 4 5 6 7 #EXT-X-MEDIA-SEQUENCE 第一个TS 分片的序列号
#EXT-X-TARGETDURATION 每个分片TS 的最大的时长
#EXT-X-ALLOW-CACHE 是否允许cache
#EXT-X-ENDLIST m3u8文件结束符
#EXTINF 指定每个媒体段(ts)的持续时间（秒），仅对其后面的URI 有mystream-12.ts
ts 文件：
HLS 的请求流程是：
1 http 请求m3u8的url 。
2 服务端返回一个m3u8的播放列表，
这个播放列表是实时更新的，一般一次给出5段数据的url
。
3 客户端解析m3u8的播放列表，再按序请求每一段的url，获取ts数据流。
简单流程：
3 HLS直播延时
我们知道hls协议是将直播流分成一段一段的小段视频去下载播放的，所以假设列表里面的包含5个ts文件，每个TS文件包含5秒的视频内容，那么整体的延迟就是25秒。因为当你看到这些视频时，主播已经将视频录制好上传上去了，所以时这样产生的延迟。当然可以缩短列表的长度和单个ts文件的大小来降低延迟，极致来说可以缩减列表长度为1，并且ts的时长为1s，但是这样会造成请求次数增加，增大服务器压力，当网速慢时回造成更多的缓冲，所以苹果官方推荐的ts时长时10s，所以这样就会大改有30s的延迟。参考资料：https://http://biz.doczj.com/doc/e14544465.html,/library/ios/documentation/Net workingInternet/Conceptual/StreamingMediaGuide/Freque ntlyAskedQuestions/FrequentlyAskedQuestions.html
4 视频直播的整个流程是什么？
当视频直播可大致分为：
1 视频录制端：一般是电脑上的音视频输入设备或者手机端的摄像头或者麦克风，目前以移动端的手机视频为主。
2 视频播放端：可以是电脑上的播放器，手机端的native播放器，还有就是h5的video标签等，目前还是已手机端的native播放器为主。
3 视频服务器端：一般是一台nginx服务器，用来接受视频录制端提供的视频源，同时提供给视频播放端流服务。
简单流程：
5 怎样进行音视频采集？当首先明确几个概念：
视频编码：所谓视频编码就是指通过特定的压缩技术，将某个视频格式的文件转换成另一种视频格式文件的方式，我们使用的iphone录制的视频，必须要经过编码，上传，解码，才能真正的在用户端的播放器里播放。
编解码标准：视频流传输中最为重要的编解码标准有国际电联的H.261、H.263、H.264，其中HLS协议支持H.264格式的编码。音频编码：同视频编码类似，将原始的音频流按照一定的标准进行编码，上传，解码，同时在播放器里播放，当然音频也有许多编码标准，例如PCM编码，WMA编码，AAC编码等等，这里我们HLS协议支持的音频编码方式是AAC编码。
下面将利用ios上的摄像头，进行音视频的数据采集，主要分为以下几个步骤：
1 音视频的采集，ios中，利用AVCaptureSession和AVCaptureDevice可以采集到原始的音视频数据流。
2 对视
频进行H264编码，对音频进行AAC编码，在ios中分别有已经封装好的编码库来实现对音视频的编码。3 对编码后的音、视频数据进行组装封包；4 建立RTMP连接并上推到服务端。
ps：由于编码库大多使用c语言编写，需要自己使用时编译，对于ios，可以使用已经编译好的编码库。
x264编码：https://http://biz.doczj.com/doc/e14544465.html,/kewlbear/x264-ios
faac编码：https://http://biz.doczj.com/doc/e14544465.html,/fflydev/faac-ios-build
ffmpeg编码：
https://http://biz.doczj.com/doc/e14544465.html,/kewlbear/FFmpeg-iOS-build-script
关于如果想给视频增加一些特殊效果，例如增加滤镜等，一般在编码前给使用滤镜库，但是这样也会造成一些耗时，导致上传视频数据有一定延时。
简单流程：
6 前面提到的ffmpeg是什么？
和之前的x264一样，ffmpeg其实也是一套编码库，类似的还有Xvid，Xvid是基于MPEG4协议的编解码器，x264是基于H.264协议的编码器，ffmpeg集合了各种音频，视频编解码
协议，通过设置参数可以完成基于MPEG4,H.264等协议的
编解码，demo这里使用的是x264编码库。
7 什么是RTMP？
Real Time Messaging Protocol（简称RTMP）是Macromedia 开发的一套视频直播协议，现在属于Adobe。和HLS一样都可以应用于视频直播，区别是RTMP基于flash 无法在ios的浏览器里播放，但是实时性比HLS要好。所以一般使用这种协议来上传视频流，也就是视频流推送到服务器。这里列举一下hls和rtmp对比：
8 推流
简所谓推流，就是将我们已经编码好的音视频数据发往视频流服务器中，一般常用的是使用rtmp推流，可以使用第三方库librtmp-iOS进行推流，librtmp封装了一些核心的api供使用者调用，如果觉得麻烦，可以使用现成的ios视频推流sdk，也是基于rtmp的，
https://http://biz.doczj.com/doc/e14544465.html,/runner365/LiveVideoCoreSDK
9 推流服务器搭建
简简单的推流服务器搭建，由于我们上传的视频流都是基于rtmp协议的，所以服务器也必须要支持rtmp才行，大概需要以下几个步骤：
1 安装一台nginx服务器。
2 安装nginx的rtmp扩展，目前使用比较多的是
https://http://biz.doczj.com/doc/e14544465.html,/arut/nginx-rtmp-module
3 配置nginx的conf文件：
1 2 3 4 5 6 7 8 9 1 0 1 1 1 2 rtmp {
server {
listen 1935; #监听的端口
chunk_size 4000;
application hls { #rtmp推流请求路径 live on;
hls on;
hls_path /usr/local/var/www/hls; hls_fragment 5s;
}
1 3 1 4 1 5 1 6 1 7 } }
4 重启nginx，将rtmp的推流地址写为
rtmp://ip:1935/hls/mystream，其中hls_path表示生成
的.m3u8和ts文件所存放的地址，hls_fragment表示切片时长，mysteam表示一个实例，即将来要生成的文件名可以先自己
随便设置一个。更多配置可以参考：
https://http://biz.doczj.com/doc/e14544465.html,/arut/nginx-rtmp-module/wiki/
根据以上步骤基本上已经实现了一个支持rtmp的视频服务
器了。
10 在html5页面进行播放直播视频？
简单来说，直接使用video标签即可播放hls协议的直播视频：
1 2 3 4
需要注意的是，给video标签增加webkit-playsinline属性，这个属性是为了让video视频在ios的uiwebview里面可以不全屏播放，默认ios会全屏播放视频，需要给uiwebview设置
allowsInlineMediaPlayback＝YES。业界比较成熟的videojs，可以根据不同平台选择不同的策略，例如ios使用video标签，pc使用flash等。
11 坑点总结
简根据以上步骤，笔者写了一个demo，从实现ios视频录制，采集，上传，nginx服务器下发直播流，h5页面播放直播视
频者一整套流程，总结出以下几点比较坑的地方：
1 在使用AVCaptureSession进行采集视频时，需要实现AVCaptureVideoDataOutputSampleBufferDelegate协议，
同时在- (void)captureOutput:(AVCaptureOutput
*)captureOutput
didOutputSampleBuffer:(CMSampleBufferRef)sampleBuff
er fromConnection:(AVCaptureConnection *)connection捕
获到视频流，要注意的是didOutputSampleBuffer这个方法不是didDropSampleBuffer方法，后者只会触发一次，当时开
始写的是didDropSampleBuffer方法，差了半天才发现方法调用错了。
2 在使用rtmp推流时，rmtp地址要以rtmp://开头，ip地址要写实际ip地址，不要写成localhost，同时要加上端口号，因为手机端上传时是无法识别localhost的。
这里后续会补充上一些坑点，有的需要贴代码，这里先列这么多。
demo地址：
https://http://biz.doczj.com/doc/e14544465.html,/lvming6816077/LMVideoTest/
参考资料：
http://biz.doczj.com/doc/e14544465.html,/index.php/archives/615
结尾打个广告：
移动端日志工具：
https://http://biz.doczj.com/doc/e14544465.html,/lvming6816077/MLogger
ReactNative下拉刷新组件：
https://http://biz.doczj.com/doc/e14544465.html,/lvming6816077/react-native-pullRefresh ScrollView
欢迎使用！
原创文章转载请注明：
转载自AlloyTeam：http://biz.doczj.com/doc/e14544465.html,/2016/05/h5-camera-literacy/
h5---rtmp
nginx -servers
Run port 80:
$ sudo chown root:wheel /usr/local/opt/nginx-full/bin/nginx $ sudo chmod u+s /usr/local/opt/nginx-full/bin/nginx Reload config:
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 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：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 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协议流媒体服务器总结 最近在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 ://http://biz.doczj.com/doc/e14544465.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 ://http://biz.doczj.com/doc/e14544465.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 ://http://biz.doczj.com/doc/e14544465.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 ://http://biz.doczj.com/doc/e14544465.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 ://http://biz.doczj.com/doc/e14544465.html,/projects/yasm/releases/yasm-1.2.0.tar.gz # tar xzvf yasm-1.2.0.tar.gz 实时流煤体协议概述v1.0 实时流煤体协议概述 流媒体传输类型： 流媒体传输分两类：实时流媒体和顺序流媒体 一般来说，如果视频为现场直播，或使用专用的流媒体服务器，或应用如RTSP等专用实时协议，即为实时流媒体传输； 如果使用普通的HTTP服务器，将音视频数据以从头至尾方式发送，则为顺序流媒体传输。 实时流传输既可传输实况直播，也可传输完整的音视频文件（专用协议流式）。 顺序流媒体不可用于实况直播，仅能传输完整的音视频文件（HTTP渐进式）。 主流的流媒体协议 主流的流媒体协议主要有：RTMP，HLS，RTSP等。 附：流媒体播放实现流程 一，h ttp渐进式下载原理（仅支持文件播放）http边下载边播放，严格意义上讲，不是实况直播协议。他的原理是先下载文件的基本信息，音频视频的时间戳，再下载音视频数据，以播放mp4为例，先下载文件头，根据文件头指引下载文件尾，然后再下载文件的音视频数据。 播放方式：1. 浏览器调用系统播放器播放； 2. 使HTML5的Video标签，浏览器内部支持直接播放。 二，苹果支持的hls原理（支持文件播放和实况直播）HLS的文件点播 1.使用“文件分段器”将基于H264和AAC或MP３的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 V9.08（战国r3）专业版支持协议列表 (2009.10.16) 类别 应用协议 客户端 发布日期 版本号/注释 HTTP协议 WWW Web音乐 FLASH HTTP代理 HTTP下载 HTTP分块传输 伪IE下载 其他下载主要是“另存为” 土豆网http://biz.doczj.com/doc/e14544465.html, Web视频 酷6 http://biz.doczj.com/doc/e14544465.html, 6间房 http://biz.doczj.com/doc/e14544465.html, 优酷http://biz.doczj.com/doc/e14544465.html, Youtube http://biz.doczj.com/doc/e14544465.html, HULU网http://biz.doczj.com/doc/e14544465.html, 我乐网http://biz.doczj.com/doc/e14544465.html, Sina视频http://biz.doczj.com/doc/e14544465.html, Sohu视频 腾讯宽频 波波虎http://biz.doczj.com/doc/e14544465.html, 其他Web视频 凤凰网http://biz.doczj.com/doc/e14544465.html, CCTV点播http://biz.doczj.com/doc/e14544465.html, Viewgood http://biz.doczj.com/doc/e14544465.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 磊客http://biz.doczj.com/doc/e14544465.html, 新浪奥运视频 网易奥运视频 QQ奥运视频 CCTV央视高清 RTMP P2P下载 BitComet 2009.06.22 1.13 BT BitSpirit 2009.07.27 V 3.6.0.135 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协议)开发代码 开发工具:flash builder4.5 + red5服务器 建议参考之前阶段代码: (1)flex视频播放器开发初级阶段代码:http://biz.doczj.com/doc/e14544465.html,/detail/ll_jj_yy/ (2)支持rtmp协议,播放red5服务器上的flv视频文件. 直接来代码: 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编码的音视频（http://biz.doczj.com/doc/e14544465.html,/haibindev/archive/2011/12/29/2305712.html），实现摄像头直播”的技术方法，来加以实现。因此，主要需要处理的就是RTSP 直播流数据的获取，以及对其中H.264和AAC编码数据的处理。 于是可以画出大体结构如下： RtmpThread的主要工作就是发送音频数据流的解码信息头和视频数据流的解码信息头，并不断从DataBufferQueue中取出数据，封装为RTMP Packet，发送出去。流程如下列代码所示：（process_buf_queue_，即是上图中的DataBufferQueue） 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是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（real time messaging protocol）协议 1，介绍 这篇文档详细说明了RTMP消息块流，它位高层多媒体流协议提供多路技术和包服务 RTMP消息块流是为RTMP协议设计的，他可以处理任何传送消息流的协议，每一个消息包含时间戳合有效负载类型标示，RTMP消息块流和RTMP一起适用于多样性音视频应用程序，从一对一和一对多向视频点播服务器直接广播到交互式会议应用程序。 当用到实时传输协议就像TCP，RTMP消息块流提供可靠地规则时间戳的端到端全信息传送。穿过多层流，RTMP消息块流不提供任何控制的优先级别和相似形式，但是可以用于高层协议提供这样的优先级，例如：一段实时视频服务会选择丢弃给于缓慢的客户的视频信息确保音频信息可以及时被接收。 RTMP消息块流包含它自己的入队协议控制消息，也提供一个高层协议机制用于嵌入用户的控制消息。 2.定义 有效负载： 包含在包中的数据，就像音频样本或者压缩的视频数据。 包： 一个数据包由固定的包头和有效负载数据组成，一些底层协议或许需要包的封装来被定义。 端口： 在TCP/ＩP协议中定义的用正整数表示的端口号用于在传输中提取以区分目标主机的不同应用，用于OSI传输层的传输选择（TSEL）就是端口。 传输地址： 网络地址和端口的组合识别一个传输层终端端口，例如一个IP地址和TCP端口，数据包从一个源传输层地址传送到目标段的传输层地址。 消息流： 一个通信的逻辑通道，允许消息流通。 消息流ID： 每一个消息拥有一个分配的ID识别跟随的消息流。 消息块： 消息的片段，消息被分成小的部分，在他们在网络中发送之前交叉存储。消息块确保定制时间戳的端到端全消息传送，穿过多层流。 消息块流： 一个通信的逻辑通道，允许消息块在一个特定的方向上流通，消息块流可以从客户端传送到服务器，也可以相反。 消息块流ID： 每一个消息块有一个分配的ID用于识别更随的消息块流。 复合技术： 把分开的音视频数据组合成一条音视频流的过程，使同时传送许多音视频数据成为可能。 逆复合技术： 复合的反向过程，交叉存取组装的音频视频数据，使他们成为最初的音视频数据 3．字节顺序，列队和时间格式 所有的整数字段有被网络字节负载着，字节0是第一个显示出来的，也是一段文字和字段中最重要的。 这种字节顺序一般被认为“大字节“，数字常量在这种文档里是用十进制表示。 所有RTMP消息块流是以用字节列队，例如：一个16字节的字段也许会在字数字节的偏移段。那里要填充被标示，填充字节应该有0值（似乎看不懂）. 在RTMP消息块流中的时间戳用整数表示，单位为毫秒。每一个消息块流以时间戳0开始，但是这不是必须的，只要两个终端在时间点上达成一致，注意那就意味着任何穿过多消息块流异步传输（特 竭诚为您提供优质文档/双击可除 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 协议利用支持显式的多点投递，可以满足多媒体会话的需求。 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协议 (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中，而是通过一个被称为消息块的封装单元进行传输。消息在网络上发送之前往往要分割成多个较少的部分，这些较小的部分就是消息块，属于不同消息流的消息块可以在网络上交叉发送。这样做可以保证各个消息流中的高优先级消息块能够严格按照时间顺序达到通信的对端。比如某个较长消息的实时性要求比较低，如果不进行消息块处理，等长消息都发送完毕后再发送实时性要求高的短消息，则会对流媒体的播放质量造成影响。课题_nginx搭建rtmp协议流媒体服务器总结
实时流煤体协议概述v1.0
PANABIT支持协议库
RTSP协议转换RTMP直播协议
flex视频播放器(支持rtmp协议)开发代码
RTSP协议转换RTMP直播协议
RTMP头RTMP协议封包 参考Red5
RTMP协议
Rtmp协议中文介绍
rtp协议,端口
RTMP协议详解
RTMP协议简介
相关主题