IOS 视频直播/智能家居(一行行敲代码,从零开始)lesson:1整体架构
2015-07-30 10:15
525 查看
前段时间由于工作需要做了一个视频直播/智能家居类的应用。算是对IOS音视频专栏中流媒体处理做了一次小结。这里想把整个开发流程纪录下来,一方面是和大家共同探讨学习,另一方面也可以方便自己以后查漏补缺。
整个开发没有借助任何第三方框架,所有流媒体协议都是一行行敲上去的,为什么呢?呵呵
授之以鱼不如授之以渔!
下面开始先了解下整个软件的架构。
![](http://img.blog.csdn.net/20150730094918739?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQv/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center)
前端我们在IOS audio&video 专栏中已经介绍的非常详细了,包括摄像头、音视频的各种处理都做了详细的分析。后端我们也在IOS audio&video 专栏的FFmpeg中、高级使用中也做了详细的介绍,这里也不再讨论。下面就网络部分做详细的分析。
(1)RTCP
RTCP:RTP Control Protocol,实时传输控制协议,一般和RTP配合使用,主要用于数据传输的监视,控制功能。同时RTCP是基于UDP传输的。RTCP传输的这些信息非常重要,主要包括:时间戳(用于同步)、序列号(用于丢包和重排序检测)、以及负载格式(用于说明数据的编码格式)。简单概括一下,就是用于QoS反馈和同步媒体流。与RTP比较而言,其带宽一半占用只有RTP的5%左右。非常小。
根据不同的使用状态,RTCP分为下面几种情况:
![](http://img.blog.csdn.net/20150730100046170?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQv/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center)
直播、智能家居类项目只要用到发送端报告,这里我们会在后面的代码中详细分析。
(2)RTP
Real-time Transport Protocol,实时传输协议,一般用于多媒体数据的传输。音视频主要通过这个协议传输,它是建立在UDP协议上的,效率更高但允许丢包。所以在媒体重组时需要做不少工作。RTP协议包格式如下:
![](http://img.blog.csdn.net/20150730100434258?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQv/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center)
(3)SDP
我们先来看看抓包的网络请求过程:
服务器响应数据。我们关心的部分:RTSP
response=RTSP/1.0 200 OK
CSeq: 1
Content-base: rtsp://192.168.36.168/
Date: 2015年7月29日 GMT+8下午2:52:00
Content-Type:application/sdp
Content-Length:424
SDP部分:
v=0
o=-1804289383 1804289383 IN IP4 192.168.36.168
s=Livestream from iOS
c=INIP4 0.0.0.0
t=00
a=control:*
m=video0 RTP/***P 96
b=TIAS:85528
a=maxprate:9.0000
a=control:streamid=1
a=rtpmap:96H264/90000
a=mimetype:string;"video/H264"
a=framesize:96720-480
a=Width:integer;720
a=Height:integer;480i
a=fmtp:96packetization-mode=1;profile-level-id=64001e;sprop-parameter-sets=Z2QAHqxWwLQ9pqAgICBA,KO4CPLA=
可以很清晰的看到RTSP协议是包含两部分的,第一部分为rtsp传输协议,另一部分是SDP协议。SDP准确的说其实不能算是传输层协议,而要规划到会话层协议部分。SDP(SessionDescription Protocol)是服务器端生成的描述媒体文件的编码信息以及所在服务器的链接等信息的文件,客户端通过它来设置播放软件的参数。
(4)RTSP
有了以上的分析,我们基本了解了整个结构,那么还剩下最后一部分,RTSP协议。实时流传输协议,是TCP/IP协议体系中的一个应用层协议。和Http协议类似。至于协议的具体结构我们放在后面和代码一起讲。
下面看看一个RTSP流媒体交互的简单过程:这是一个比较典型的请求过程:
1. Client->Server:OPTION request //询问S有哪些方法可用
1. Server->Client:OPTION response //S回应信息中包括提供的所有可用方法
2. Client->Server:DESCRIBE request
//要求得到S提供的媒体初始化描述信息
2. Server->Client:DESCRIBE response
//S回应媒体初始化描述信息,主要是sdp
3. Client->Server:SETUP request //设置会话的属性,以及传输模式,提醒S建立会话
3. Server->Client:SETUP response //S建立会话,返回会话标识符,以及会话相关信息
4. Client->Server:PLAY request //C请求播放
4. Server->Client:PLAY response //S回应该请求的信息
Server->Client:发送流媒体数据
5. Client->Server:TEARDOWN request
//C请求关闭会话
5. Server->Client:TEARDOWN response
//S回应该请求
整个开发没有借助任何第三方框架,所有流媒体协议都是一行行敲上去的,为什么呢?呵呵
授之以鱼不如授之以渔!
下面开始先了解下整个软件的架构。
前端我们在IOS audio&video 专栏中已经介绍的非常详细了,包括摄像头、音视频的各种处理都做了详细的分析。后端我们也在IOS audio&video 专栏的FFmpeg中、高级使用中也做了详细的介绍,这里也不再讨论。下面就网络部分做详细的分析。
(1)RTCP
RTCP:RTP Control Protocol,实时传输控制协议,一般和RTP配合使用,主要用于数据传输的监视,控制功能。同时RTCP是基于UDP传输的。RTCP传输的这些信息非常重要,主要包括:时间戳(用于同步)、序列号(用于丢包和重排序检测)、以及负载格式(用于说明数据的编码格式)。简单概括一下,就是用于QoS反馈和同步媒体流。与RTP比较而言,其带宽一半占用只有RTP的5%左右。非常小。
根据不同的使用状态,RTCP分为下面几种情况:
直播、智能家居类项目只要用到发送端报告,这里我们会在后面的代码中详细分析。
(2)RTP
Real-time Transport Protocol,实时传输协议,一般用于多媒体数据的传输。音视频主要通过这个协议传输,它是建立在UDP协议上的,效率更高但允许丢包。所以在媒体重组时需要做不少工作。RTP协议包格式如下:
(3)SDP
我们先来看看抓包的网络请求过程:
服务器响应数据。我们关心的部分:RTSP
response=RTSP/1.0 200 OK
CSeq: 1
Content-base: rtsp://192.168.36.168/
Date: 2015年7月29日 GMT+8下午2:52:00
Content-Type:application/sdp
Content-Length:424
SDP部分:
v=0
o=-1804289383 1804289383 IN IP4 192.168.36.168
s=Livestream from iOS
c=INIP4 0.0.0.0
t=00
a=control:*
m=video0 RTP/***P 96
b=TIAS:85528
a=maxprate:9.0000
a=control:streamid=1
a=rtpmap:96H264/90000
a=mimetype:string;"video/H264"
a=framesize:96720-480
a=Width:integer;720
a=Height:integer;480i
a=fmtp:96packetization-mode=1;profile-level-id=64001e;sprop-parameter-sets=Z2QAHqxWwLQ9pqAgICBA,KO4CPLA=
可以很清晰的看到RTSP协议是包含两部分的,第一部分为rtsp传输协议,另一部分是SDP协议。SDP准确的说其实不能算是传输层协议,而要规划到会话层协议部分。SDP(SessionDescription Protocol)是服务器端生成的描述媒体文件的编码信息以及所在服务器的链接等信息的文件,客户端通过它来设置播放软件的参数。
(4)RTSP
有了以上的分析,我们基本了解了整个结构,那么还剩下最后一部分,RTSP协议。实时流传输协议,是TCP/IP协议体系中的一个应用层协议。和Http协议类似。至于协议的具体结构我们放在后面和代码一起讲。
下面看看一个RTSP流媒体交互的简单过程:这是一个比较典型的请求过程:
1. Client->Server:OPTION request //询问S有哪些方法可用
1. Server->Client:OPTION response //S回应信息中包括提供的所有可用方法
2. Client->Server:DESCRIBE request
//要求得到S提供的媒体初始化描述信息
2. Server->Client:DESCRIBE response
//S回应媒体初始化描述信息,主要是sdp
3. Client->Server:SETUP request //设置会话的属性,以及传输模式,提醒S建立会话
3. Server->Client:SETUP response //S建立会话,返回会话标识符,以及会话相关信息
4. Client->Server:PLAY request //C请求播放
4. Server->Client:PLAY response //S回应该请求的信息
Server->Client:发送流媒体数据
5. Client->Server:TEARDOWN request
//C请求关闭会话
5. Server->Client:TEARDOWN response
//S回应该请求
相关文章推荐
- HeartBeat+DRBD+NFS 高可用
- 在线CRC32网站
- 如何利用General框架进行三层架构开发
- 盘点国内网站常用的一些CDN公共库加速服务
- 代替谷歌搜索的网站
- VC++.Net CAD编程架构
- 用Kettle的一套流程完成对整个数据库迁移 - - ITeye技术网站
- 使用keepalived搭建高可用的LVS-DR集群
- 网站服务架构
- PHP网站页面静态化
- 基于keepalived双主模型的高可用LVS
- 基于keepalived双主模型的高可用LVS
- Hibernate学习之架构
- 一个初学者对于MVC架构的理解
- Jsoup读取东方财富网站数据实例
- C/C++源代码的网站
- 攻击网站的游戏(连续的三个数字)含有ArrayList的升级版
- 网站ssl加密
- 大型网站架构演化
- 攻击网站的游戏(simple连续的三个数字)