嵌入式LINUX应用编程-视频服务器.ppt

嵌入式LINUX应用编程 视频服务器篇 方勇军2009年11月10日 2 嵌入式LINUX编程 视频服务器 V4L2编程RTSP协议RTP协议视频服务器案例 3 V4l2编程 关于视频的基本概念 1 视频分辨率常用的数字图像分辨率格式有 QCIF 176 144 CIF 352 288 1 2D1 352 576 2 3D1 480 576 D1 720 576 QQVGA 160 120 QVGA 320 240 VGA 640 480 2 一些压缩标准MJPEG MotionJPEG2000 MPEG 1 MPEG 2 MPEG 4ASP MPEG 4 AVC H 120 H 261 H 262 H 263 H 264 AMV AVS Bink Dirac Indeo Pixlet RealVideo RTVideo SheerVideo Smacker Snow Theora VC 1 VP6 VP7 VP8 WMV3 一些音频压缩标准MPEG 1LayerIII MP3 MPEG 1LayerII MPEG 1LayerI AAC HE AACG 711 G 718 G 719 G 722 G 722 1 G 722 2 G 723 G 723 1 G 726 G 728 G 729 G 729 1 G 729a AC3 AMR AppleLossless ATRAC FLAC iLBC Monkey sAudio law Musepack Nellymoser OptimFROG RealAudio RTAudio SHN Siren Speex Vorbis WavPack WMA TAK4 一些视频编码格式 文件格式3GP ASF AVI Bink DMF DPX FLV Matroska MP4 MXF NUT Ogg OggMedia QuickTime RealMedia Smacker RIFF VOB 4 V4L2编程 1 打开设备 打开视频设备在V4L2中 视频设备被看做一个文件 使用open函数打开这个设备 用非阻塞模式打开摄像头设备intcameraFd cameraFd open dev video0 O RDWR O NONBLOCK 0 如果用阻塞模式打开摄像头设备 上述代码变为 cameraFd open dev video0 O RDWR 0 应用程序能够使用阻塞模式或非阻塞模式打开视频设备 如果使用非阻塞模式调用视频设备 即使尚未捕获到信息 驱动依旧会把缓存 DQBUFF 里的东西返回给应用程序 5 V4L2编程 2 设定属性及采集方式 设定属性及采集方式打开视频设备后 可以设置该视频设备的属性 例如裁剪 缩放等 这一步是可选的 在Linux编程中 一般使用ioctl函数来对设备的I O通道进行管理 intioctl intfd unsignedlongintrequest args 在进行V4L2开发中 常用的命令如下 VIDIOC REQBUFS 分配内存VIDIOC QUERYBUF 把VIDIOC REQBUFS中分配的数据缓存转换成物理地址VIDIOC QUERYCAP 查询驱动功能VIDIOC ENUM FMT 获取当前驱动支持的视频格式VIDIOC S FMT 设置当前驱动的频捕获格式VIDIOC G FMT 读取当前驱动的频捕获格式VIDIOC TRY FMT 验证当前驱动的显示格式VIDIOC CROPCAP 查询驱动的修剪能力VIDIOC S CROP 设置视频信号的边框VIDIOC G CROP 读取视频信号的边框VIDIOC QBUF 把内存加入缓存队列VIDIOC DQBUF 从缓存队列读取数据VIDIOC STREAMON 开始视频显示函数VIDIOC STREAMOFF 结束视频显示函数VIDIOC QUERYSTD 检查当前视频设备支持的标准 例如PAL或NTSC 6 V4L2编程 设定属性及采集方式 检查当前视频设备支持的标准在亚洲 一般使用PAL 720X576 制式的摄像头 而欧洲一般使用NTSC 720X480 使用VIDIOC QUERYSTD来检测 v4l2 std idstd do ret ioctl fd VIDIOC QUERYSTD 7 V4L2编程 设定属性及采集方式 v4l2 format结构如下 structv4l2 format enumv4l2 buf typetype 数据流类型V4L2 BUF TYPE VIDEO CAPTUREunion structv4l2 pix formatpix structv4l2 windowwin structv4l2 vbi formatvbi u8raw data 200 fmt structv4l2 pix format u32width 宽 必须是16的倍数 u32height 高 必须是16的倍数 u32pixelformat 视频数据存储类型 例如是YUV4 2 2还是RGBenumv4l2 fieldfield u32bytesperline u32sizeimage enumv4l2 colorspacecolorspace u32priv 8 V4L2编程 视频采集方式 内核空间和用户空间操作系统一般把系统使用的内存划分成用户空间和内核空间 分别由应用程序管理和操作系统管理 应用程序可以直接访问内存的地址 而内核空间存放的是供内核访问的代码和数据 用户不能直接访问 v4l2捕获的数据 最初是存放在内核空间的 这意味着用户不能直接访问该段内存 必须通过某些手段来转换地址 一共有三种视频采集方式 使用read write方式 在用户空间和内核空间不断拷贝数据 占用了大量用户内存空间 效率不高 内存映射方式 把设备里的内存映射到应用程序中的内存控件 直接处理设备内存 这是一种有效的方式 用户指针模式 与前种类似 区别在于内存片段由应用程序自己分配 这点需要在v4l2 requestbuffers里将memory字段设置成V4L2 MEMORY USERPTR 9 V4L2编程 内存映射方式采集视频 分配设备缓冲 structv4l2 requestbuffersreqbuf memset V4L2编程 内存映射方式采集视频 v4l2 requestbuffers结构如下 structv4l2 requestbuffers u32count 缓存数量 也就是说在缓存队列里保持多少张照片enumv4l2 buf typetype 数据流类型enumv4l2 memorymemory V4L2 MEMORY MMAP或 V4L2 MEMORY USERPTR u32reserved 2 10 11 V4L2编程 内存映射方式采集视频 获取并记录缓存的物理空间使用VIDIOC REQBUFS 我们获取了req count个缓存 下一步通过调用VIDIOC QUERYBUF命令来获取这些缓存的地址 然后使用mmap函数转换成应用程序中的绝对地址 最后把这段缓存放入缓存队列 typedefstructVideoBuffer void start size tlength VideoBuffer 12 V4L2编程 内存映射方式采集视频 VideoBuffer buffers calloc req count sizeof buffers structv4l2 bufferbuf for numBufs 0 numBufs req count numBufs memset 13 V4L2编程 内存映射方式采集视频 采集一帧视频数据数据缓存采用FIFO 先进先出 的方式 当应用程序调用缓存数据时 缓存队列将最先采集到的视频数据缓存送出 并重新采集一张视频数据 这个过程需要用到两个ioctl命令 VIDIOC DQBUF和VIDIOC QBUF structv4l2 bufferbuf memset 14 V4L2编程 关闭视频设备 若使用内存映射或用户自定义内存映射的方式捕捉视频 则在结束一个视频流前 应先使用VIDIOC STREAMOFF停止视频流显示 enumv4l2 buf type V4L2 BUF TYPE VIDEO CAPTURE if 1 xioctl fd VIDIOC STREAMOFF 使用close函数关闭一个视频设备close cameraFd 详细参考 VideoforLinuxTwoAPISpecification 15 RTSP协议 RTSP简介 什么是RTSP协议RealTimeStreamingProtocol或者RTSP 实时流媒体协议 是在IP网络上传输流媒体数据的应用层协议 控制实时数据的传送 RTSP提供了一个可扩展框架 使实时数据 如音频与视频的受控 点播成为可能 数据源包括现场数据与存储在剪辑中数据 该协议目的在于控制多个数据发送连接 为选择发送通道 如UDP 组播UDP与TCP 提供途径 并为选择基于RTP RFC1889 上传送机制提供方法 RTSP协议详细参考RFC2326 什么是RFCRequestForComments RFC 是一系列以编号排定的文件 文件收集了有关因特网相关资讯 以及UNIX和因特网社群的软件文件 目前RFC文件是由InternetSociety ISOC 所赞助发行 16 RTSP协议 RTSP与HTTP 在RTSP里我们没有连接的概念 而由RTSP会话 session 代替 每次服务由服务器端保持一个带标签的会话 RTSP会话没有绑定到传输层连接 如TCP连接 因为虽然在RTSP会话期间 RTSP客户端可打开或关闭多个对服务器端的可靠传输连接以发出RTSP请求 但此外 也可能使用无连接传输协议 比如用UDP发送RTSP请求 RTSP控制的流可能用到RTP 但RTSP操作并不依赖用于携带连续媒体的传输机制 实时流协议在语法和操作上与HTTP 1 1类似 因此HTTP的扩展机制大都可加入RTSP RTSP在很多方面还是和HTTP有很大的不同 RTSP引入了很多新方法并且有不同的协议标识符 RTSP服务器在大多数默认情况下需要维持一个状态 但HTTP是无状态协议 RTSP客户机和服务器都可以发出请求 数据由另一个协议传送 有一特例除外 RTSP使用ISO10646 UTF 8 而不是ISO8859 1 以配合当前HTML的国际化 RTSP使用URI请求时包含绝对URI 而由于历史原因造成的向后兼容性问题 HTTP 1 1只在请求中包含绝对路径 把主机名放入单独的标题域中 这使得 虚拟主机 实现更为简便 一个单独IP地址的主机可虚拟为几个文件树主机 17 RTSP协议 支持的操作 从媒体服务器上检索媒体 用户可通过HTTP或其它方法请求一个表示描述 如表示是组播 表示描述就包含用于连续媒体的的组播地址和端口 如表示仅通过单播发送给用户 用户为了安全应提供目的地址 媒体服务器邀请进入会议 媒体服务器可被邀请参加正进行的会议 或回放媒体 或记录其中一部分 或全部 这种模式在分布式教育应用上很有用 会议中几方可轮流按远程控制按钮 将媒体加到现成讲座中 如服务器告诉用户可获得附加媒体内容 对现场讲座显得尤其有用 18 RTSP协议 RTSP状态 RTSP控制的流可通过单独协议发送 与控制通道无关 例如 RTSP控制可通过TCP连接 而数据流通过UDP 因此 即使媒体服务器没有收到请求 数据也会继续发送 在会话生命期 单个媒体流可通过不同TCP连接顺序发出请求来控制 所以 服务器需要维持能联系流与RTSP请求的会话状态 RTSP中很多方法与状态无关 但下列方法在定义服务器流资源的分配与应用上起着重要的作用 SETUP 让服务器给流分配资源 启动RTSP会话 PLAY与RECORD 开始由SETUP分配的流的数据传输 PAUSE 临时停止流 而不释放服务器资源 TEARDOWN 释放流的资源 RTSP会话停止 标识状态的RTSP方法使用会话 session 标题域识别RTSP会话 为回应SETUP请求 服务器生成会话标识 19 RTSP协议 RTSP消息 RTSP是基于文本的协议 采用ISO10646字符集 使用UTF 8编码方案 行以CRLF中断 但接收者本身可将CR和LF解释成行终止符 基于文本的协议使以自描述方式增加可选参数更容易 10646字符集避免敏感字符集切换 但对应用来说不可见 RTCP也采用这种编码方案 带有重要意义位的ISO8859 1字符表示如100001x10 xxxxxx RTSP信息可通过任何低层传输协议携带 请求包括方法 方法作用于其上的对象和进一步描述方法的参数 方法也可设计为在服务器端只需要少量或不需要状态维护 当信息体包含在信息中 信息体长度有如下因素决定 不管实体标题域是否出现在信息中 不包括信息体的回应信息总以标题域后第一和空行结束 如出现内容长度标题域 其值以字节计 表示信息体长度 如未出现标题域 其值为零 20 RTSP协议 消息类型 RTSP消息由客户端到服务器的请求和由服务器到客户端的回应组成 RTSP message Request Response RTSP 1 0messages请求 Request 和回应 Response 消息都使用RFC822中实体传输部分规定 作为消息中的有效载荷 的消息格式 两者的消息都可能包括一起始行 一个或多个标题域 headers 一行表示标题域结束的空行 即CRLF前没有内容的行 和一个消息主体 message body 可选 generic message start line message headerCRLF message body start line Request Line Status Line为了健壮性考虑 服务器应该忽略任何在期望收到请求行时收到的空行 换句话说 如果服务器正在读协议流 在一个消息开始时如果首先收到了CRLF 这个CRLF符应被忽略 21 RTSP协议 消息标题 RTSP标题域 包括主标题 General Header 4 3节 请求标题 回应标题 及实体标题 都遵照RFC822 3 1节 7 给出的通用格式定义 每个标题域由后紧跟冒号的名字 单空格 SP 字符及域值组成 域名是大小写敏感的 虽然不提倡 标题域还是可以扩展成多行使用 只要这些行以一个以上的SP或HT开头就行 RTSP header field name field value CRLFfield name tokenfield value field content LWS field content 标题域接收的顺序并不重要 但良好的习惯是 先发送主标题 然后是请求标题或回应标题 最后是实体标题 当且仅当标题域的全部域值都用逗号分隔的列表示时 即 值 多个有相同域名的RTSP标题域才可以表示在一个消息里 而且必须能在不改变消息语法的前提下 将并发的域值加到第一个值后面 之间用逗号分隔 最终能将多个标题域结合成 域名 域值 对 22 RTSP协议 消息主体和长度 RTSP消息的消息主体 如果有 用来携带请求或回应的主体 仅在使用传输编码 Transfer Encoding 时消息主体和实体主体才有所不同 这种情况在传输编码标题域中有详细说明 message body entity body 传输编码必须能解释所有保证传输安全和正确的应用程序的传输编码 传输编码是消息而不是实体的一个属性 因此可以由任一应用程序随着请求 回应链添加或者删除 什么时候允许消息带消息体的规则在请求和回应两种情况下有所不同 在请求中有无消息主体的标志是是否包含内容长度或请求消息标题域中的传输编码标题域 只有当请求方法允许有实体主体的时候才能在请求中包含消息主体 而对于回应消息来说 无论消息中是否存在消息主体都与请求方法和回应状态编码无关 所有回应标题请求方法的消息都不能包含消息主体 尽管有时会因为存在实体标题域而使人产生误解 所有1 信息 204 无内容 304 未修改 回应都不包含消息主体 而其他回应则都包含主体 尽管其长度有可能长度为零 23 消息主体和长度 4 4消息长度当消息包含消息主体时 消息主体的长度由以下规则来决定 按优先级高低顺序排列 1 任何回应消息都不包含消息主体 如1 204和304回应 并且不管消息中是否存在实体标题域都以消息标题域后的第一行空行表示结束 2 如果内容长度标题域存在 它在字节中的值就是消息主体的长度 如果内容标题域不存在 则假设值为零 3 服务器关闭连接时 关闭连接没有用来表明请求主体结束 否则可能导致服务器不能回应 注意 RTSP不支持 至少现在 HTTP 1 1的块传输编码 详见 H3 6 并且要求有内容长度标题域 尽管表示描述长度动态产生 但由于可获得了表示描述返回长度 使得服务器总是能决定表示描述长度而不需使用块传输编码方式 只要有实体主体就必须有内容长度项 这些规则保证了即使没有给出明确长度也能做出合理的操作 24 RTSP协议 应答 状态行 完整回应消息的第一行就是状态行 它依次由协议版本 数字形式的状态代码 及相应的词语文本组成 各元素间以空格 SP 分隔 除了结尾的CRLF外 不允许出现单独的CR或LF符 Status Line HTTP VersionSPStatus CodeSPReason PhraseCRLF状态代码和原因分析 状态代码 Status Code 由3位数字组成 表示请求是否被理解或被满足 原因分析是用简短的文字来描述状态代码产生的原因 状态代码用来支持自动操作 原因分析是为人类用户准备的 客户端不需要检查或显示原因分析 状态代码的第一位数字定义了回应的类别 后面两位数字没有具体分类 首位数字有5种取值可能 o1xx 保留 将来使用 o2xx 成功 操作被接收 理解 接受 received understood accepted o3xx 重定向 Redirection 要完成请求必须进行进一步操作 o4xx 客户端出错 请求有语法错误或无法实现 o5xx 服务器端出错 服务器无法实现合法的请求 25 RTSP协议 回应标题域 回应标题域中包括不能放在状态行中的附加回应信息 该域还可以存放与服务器相关的信息 以及在对请求URI所指定资源进行访问的下一步信息 response header Location Proxy Authenticate Public Retry After Server Vary WWW Authenticate 回应标题域名只有在与协议版本的变化结合起来后 才能进行可靠的扩展 实际上 新的或实验中的标题域只要能被通讯各方识别 其语法就可使用 而无法识别的标题域都将被视为实体域 26 RTSP协议 连接 RTSP请求可以几种不同方式传送 1 持久传输连接 用于多个请求 回应传输 2 每个请求 回应传输一个连接 3 无连接模式 传输连接类型由RTSPURI来定义 对 rtsp 开头的URI请求 需要持续连接 而 rtspu 开头的URI请求 调用RTSP请求发送 而不用建立连接 不象HTTP RTSP允许媒体服务器给媒体用户发送请求 然而 这仅在持久连接时才支持 否则媒体服务器没有可靠途径到达用户 这也是请求通过防火墙从媒体服务器传到用户的唯一途径 流水线操作 支持持久连接或无连接的客户端可能给其请求排队 服务器必须以收到请求的同样顺序发出回应 27 RTSP协议 传输的可靠性及确认 可靠性及确认 如果请求不是发送给组播组 接收者就确认请求 如没有确认信息 发送者可在超过一个来回时间 RTT 后重发同一信息 RTT在TCP中估计 初始值为500ms 应用缓存最后所测量的RTT 作为将来连接的初始值 如使用一个可靠传输协议传输RTSP 请求不允许重发 RTSP应用反过来依赖低层传输提供可靠性 如两个底层可靠传输 如TCP和RTSP 应用重发请求 有可能每个包损失导致两次重传 由于传输栈在第一次尝试到达接收着者前不会发送应用层重传 接收者也不能充分利用应用层重传 如包损失由阻塞引起 不同层的重发将使阻塞进一步恶化 时序标头用来避免重发模糊性问题 避免对圆锥算法的依赖 每个请求在CSeq头中携带一个系列号 每发送一个不同请求 它就加一 如由于没有确认而重发请求 请求必须携带初始系列号 实现RTSP的系统必须支持通过TCP传输RTSP 并支持UDP 对UDP和TCP RTSP服务器的缺省端口都是554 许多目的一致的RTSP包被打包成单个低层PDU或TCP流 RTSP数据可与RTP和RTCP包交叉 不象HTTP RTSP信息必须包含一个内容长度头 无论信息何时包含负载 否则 RTSP包以空行结束 后跟最后一个信息头 28 RTSP协议 方法定义 方法定义表示了对请求统一资源标志符 Request URI 识别的资源所执行的操作 方法名区分大小写 将来可能定义新的方法 方法名可能不以美元符 十进制数24 开头 但必须具有表征意义 下表是对方法的一个小结 方法方向目标是否必需DESCRIBEC SP SrecommendedANNOUNCEC S S CP SoptionalGETPARAMETERC S S CP SoptionalOPTIONSC S S CP Srequired S C optional PAUSEC SP SrecommendedPLAYC SP SrequiredRECORDC SP SoptionalREDIRECTS CP SoptionalSETUPC SSrequiredSETPARAMETERC S S CP SoptionalTEARDOWNC SP Srequired对RTSP方法 和其操作方向及所操作对象 P 表示 S 媒体流 的一个概览注意 PAUSE方法是推荐的 但在构建一个全功能的服务器时可能不支持此方法 这时就不需要它 比如对于livefeeds 如果服务器不支持某个特殊方法 它必将返回 501NotImplemented 并且客户端应该不再向该服务器请求该方法 29 RTSP协议 OPTIONS方法 OPTIONS请求可能在任何时候发出 例如客户端将要发出一个非标准的请求时 它不影响服务器状态 示例 C S OPTIONS RTSP 1 0CSeq 1Require implicit playProxy Require gzipped messagesS C RTSP 1 0200OKCSeq 1Public DESCRIBE SETUP TEARDOWN PLAY PAUSE注意 这些都是必要的构造特征 necessarilyfictionalfeatures 30 RTSP协议 DESCRIBE方法 DESCRIBE方法从服务器检索表示的描述或媒体对象 这些资源通过请求统一资源定位符 therequestURL 识别 此方法可能结合使用Accept首部域来指定客户端理解的描述格式 服务器端用被请求资源的描述对客户端作出响应 DESCRIBE的答复 响应对 reply responsepair 组成了RTSP的媒体初始化阶段 示例 C S DESCRIBErtsp 31 RTSP协议 DESCRIBE方法 u http www cs ucl ac uk staff M Handley sdp 03 pse mjh isi edu MarkHandley c INIP4224 2 17 12 127t 28733974962873404696a recvonlym audio3456RTP AVP0m video2232RTP AVP31m whiteboard32416UDPWBa orient portraitDESCRIBE响应必须包含它所描述资源的所有媒体初始化信息 如果媒体客户端从一个数据源获得表示描述 而非通过DESCRIBE 并且该描述包含了一个媒体初始化参数的全集 那么客户端就应该使用这些参数 而不是再通过RTSP请求相同媒体的描述 再有 服务器不应该 SHOULDNOT 使用DESCRIBE响应作为mediaindirection的方法 32 RTSP协议 DESCRIBE方法 需要建立基本的规则 使得客户端有明确的方法了解何时通过DESCRIBE请求媒体初始化信息 何时不请求 强制DESCRIBE响应包含它所描述媒体流集合的所有初始化信息 不鼓励将DESCRIBE用作mediaindirection的方法 通过这两点避免了使用其他方法可能会引起的循环问题 loopingproblems 媒体初始化是任何基于RTSP系统的必要条件 但RTSP规范并没有规定它必须通过DESCRIBE方法完成 RTSP客户端可以通过3种方法来接收媒体初始化信息 DESCRIBE方法 其它一些协议 HTTP email附件 等 命令行或标准输入 同一个SDP或其它媒体初始化格式的文件一起启动 工作方式类似于浏览器的帮助程序 为了实际协同工作 强烈建议最精简的服务器也支持DESCRIBE方法 最精简的客户端也支持从标准输入 命令行和 或其它对于客户端操作环境合适的方法来接收媒体初始化文件的能力 33 RTSP协议 ANNOUNCE方法 ANNOUNCE方法有两个用途 当客户端向服务器发送时 ANNOUNCE将通过请求URL识别的表示描述或者媒体对象提交给服务器 当服务器向客户端发送时 ANNOUNCE实时更新会话描述 如果有新的媒体流加到表示中 比如在一个现场表示中 整个表示描述应该重发 而不只是增加组件 如果这样做的话 组件也可以被删除了 C S ANNOUNCErtsp 34 RTSP协议 SETUP方法 SETUP请求为URI指定流式媒体的传输机制 客户端能够发出一个SETUP请求为正在播放的媒体流改变传输参数 服务器可能同意这些参数的改变 若是不同意 它必须响应错误 455MethodNotValidInThisState 为了尽量绕开防火墙干涉 即使它不会影响参数 客户端也必须指出传输参数 例如 指出服务器向外发布的固定的广播地址 由于SETUP包括了所有传输初始化信息 防火墙和其他中间的网络设备 它们需要这些信息 分让了解析DESCRIBE响应的繁琐任务 这些任务留给了媒体初始化 Transport首部域指定了客户端数据传输时可接受的传输参数 响应包含了由服务器选出的传输参数 C S SETUPrtsp 35 RTSP协议 PLAY方法 PLAY方法告知服务器通过SETUP中指定的机制开始发送数据 在尚未收到SETUP请求的成功应答之前 客户端不可以发出PLAY请求 PLAY请求将正常播放时间 normalplaytime 定位到指定范围的起始处 并且传输数据流直到播放范围结束 PLAY请求可能被管道化 pipelined 即放入队列中 queued 服务器必须将PLAY请求放到队列中有序执行 也就是说 后一个PLAY请求需要等待前一个PLAY请求完成才能得到执行 比如 在下例中 不管到达的两个PLAY请求之间有多紧凑 服务器首先play第10到15秒 然后立即第20到25秒 最后是第30秒直到结束 C S PLAYrtsp 36 RTSP协议 PLAY方法 结合PAUSE请求的描述 看更深一层的示例 不含Range首部域的PLAY请求也是合法的 它从媒体流开头开始播放 直到媒体流被暂停 如果媒体流通过PAUSE暂停 媒体流传输将在暂停点 thepausepoint 重新开始 如果媒体流正在播放 那么这样一个PLAY请求将不起更多的作用 只是客户端可以用此来测试服务器是否存活 Range首部域可能包含一个时间参数 该参数以UTC格式指定了播放 palayback 开始的时间 如果在这个指定时间后收到消息 那么播放立即开始 时间参数可能用来帮助同步从不同数据源获取的数据流 对于一个点播 On demand 媒体流 服务器用播放 playback 的实际范围答复请求 如果在请求中没有指定范围 当前位置将在答复中返回 答复中播放范围的单位与请求中相同 在播放完被要求的范围后 表示将自动暂停 就好像发出了一个PAUSE请求 37 RTSP协议 PLAY方法 下面的示例在play整个表示时从SMPTE时间0 10 20直到剪辑 clip 结束 播放开始于1997年1月23号 15点36分C S PLAYrtsp 38 RTSP协议 PAUSE方法 PAUSE请求引起媒体流传输的暂时中断 如果请求URL中指定了具体的媒体流 那么只有该媒体流的播放和记录被暂停 halt 比如 指定暂停音频 播放将会无声 如果请求URL指定了一个表示或者媒体流已成组 那么在该表示或组中的所有当前活动流的传输将被暂停 在重启播放或记录后 必须维护不同媒体轨迹 track 的同步 尽管服务器可能在暂停后 在timeout的时间内关闭会话 释放资源 但是任何资源都必须保存 其中timeout参数位于SETUP消息的会话头中 示例 C S PAUSErtsp 39 RTSP协议 PAUSE方法 利用PAUSE请求可忽视所有排队的PLAY请求 但必须维护媒体流中的暂停点 不带Range首部域的后继PLAY请求从暂停点重启播放 比如 如果服务器有两个挂起的播放请求 播放范围 range 分别是10到15和20到29 这时收到一个暂停请求 暂停点是NPT21 那么它将会开始播放第二个范围 并且在NPT21处停止 如果服务器正在服务第一个请求播放到NPT13位置 收到暂停请求 暂停点NPT12 那么它将立即停止 如果请求在NPT16暂停 那么服务器在完成第一个播放请求后停止 放弃了第二个播放请求 再如 服务器收到播放请求 播放范围从10到15和13到20 即之间有重叠 PAUSE暂停点是NPT14 则当服务器播放第一段范围时 PAUSE请求将生效 而第二个PLAY请求会被忽略重叠部分 就好像服务器在开始播放第二段前收到PAUSE请求 不管PAUSE请求何时到达 它总是设置NPT到14 如果服务器已经在Range首部域指定的时间外发送了数据 后继的PLAY仍会在暂停点及时重启 因为它认为客户端会丢弃在暂停点后收到的数据 这就确保了连续 无隙的暂停 播放循环 40 RTSP协议 TEARDOWN方法 TEARDOWN请求终止了给定URI的媒体流传输 并释放了与该媒体流相关的资源 如果该URI是对此表示的表示URI 那么任何与此会话相关的任何RTSP会话标志符将不再有效 除非所有传输参数由会话描述符定义 否则SETUP请求必须在会话能被再次播放之前发出 示例 C S TEARDOWNrtsp 41 RTSP协议 GET PARAMETER方法 GETPARAMETER请求检索URI指定的表示或媒体流的参数值 答复和响应的内容留给了实现 不带实体主体的GETPARAMETER可用来测试客户端或服务器是否存活 Ping 示例 S C GET PARAMETERrtsp 42 RTSP协议 SET PARAMETER方法 此方法给URI指定的表示或媒体流设置参数值 为了客户端能检查某个特定的请求为何失败 请求应该只附带一个参数 当请求附带多个参数时 服务器只有在这些参数全都设置正确时才作出响应 服务器必须允许某个参数被重复设置成相同的值 但可能不允许改变参数值 注意 必须只能使用SETUP命令来给媒体流设置传输参数 限制只有SETUP能设置传输参数有利于防火墙设计 示例 C S SET PARAMETERrtsp 43 RTSP协议 REDIRECT方法 REDIRECT请求告知客户端连接到另一个服务器位置 它包含首部域Location 该域指出了客户端应该发出请求的URL 它可能包含参数Range 在重定向生效时 该域指明了媒体流的范围 如果客户端希望继续发送或接收其URI指定的媒体 它必须发出一个TEARDOWN请求来关闭当前会话 并向委派的主机发送SETUP以建立新的会话 本例中 在给定的播放时间将URI请求重定向到新的服务器 S C REDIRECTrtsp 44 RTSP协议 RECORD方法 此方法根据表示描述开始记录媒体数据 时间戳 timestamp 表现了起始和结束时间 UTC 如果没有给定时间范围 就使用表示描述中提供的开始和结束时间 如果会话已经开启 立即开始记录 由服务器来决定是否存储记录的数据到请求URI下或者其它URI下 如果服务器没有使用请求URI 那么响应代码应该是201 创建 并且包含一个实体 该实体描述了请求的状态 并通过Location首部域指向新资源 允许记录现场表示 livepresentations 的媒体服务器必须支持时钟范围格式 theclockrangeformat smpte格式对此无用 在本示例中 媒体服务器被邀请到指定的会议C S RECORDrtsp 45 RTSP协议 RTSP播放实例 第一步 客户端发送OPTIONS请求OPTIONSrtsp 125 120 11 80 554RTSP 1 0CSeq 1User Agent RealMediaPlayerHelixDNAClient 10 0 1 65 win32 Supported ABD 1 0ClientChallenge a936f4c39265412e46dfd8d2e666908dClientID WinNT 5 1 6 0 14 806 RealPlayer R41CND zh cn 686CompanyID y2HqBFnBtv4dl XFMO3zIQ GUID 00000000 0000 0000 0000 000000000000PlayerStarttime 19 02 2009 17 15 1208 00 Pragma initiate sessionRegionData 98121服务器应答 RTSP 1 0200OKCSeq 1Public OPTIONS DESCRIBE SETUP TEARDOWN PLAY PAUSE 46 RTSP协议 RTSP播放实例 第二步 客户端发送DESCRIBE请求 DESCRIBErtsp 125 120 11 80 554 cam1 sdpRTSP 1 0CSeq 2Accept application sdpUser Agent RealMediaPlayerHelixDNAClient 10 0 1 65 win32 Bandwidth 1544000ClientID WinNT 5 1 6 0 14 806 RealPlayer R41CND zh cn 686GUID 00000000 0000 0000 0000 000000000000Language zh cnRegionData 98121Require com real retain entity for setupSupportsMaximumASMBandwidth 1服务器应答 RTSP 1 0200OKCSeq 2Date ThuFeb1917 53 422009GMTContent Base rtsp 125 120 11 80 554 cam1 sdp Content Type application sdpContent Length 386 47 RTSP协议 RTSP播放实例 v 0o IPCAM11INIP4125 120 11 80s MPEG4videostreamedbyLTIPCAMi realtimevideot 00a range npt now a control m video0RTP AVP96c INIP40 0 0 0b AS 30a rtpmap 96MP4V ES 90000a fmtp 96profile level id 1 config 00000100000001200086C40017305040F14003a range npt now a framerate 5a framesize 96160 120a cliprect 0 0 160 120a control streamid 0 48 RTSP协议 RTSP播放实例 第三步 SETUP请求SETUPrtsp 125 120 11 80 554 cam1 sdp streamid 0RTSP 1 0CSeq 3Transport RTP AVP unicast client port 6970 6971 mode play RTP AVP TCP unicast mode playUser Agent RealMediaPlayerHelixDNAClient 10 0 1 65 win32 服务器应答 RTSP 1 0200OKCSeq 3Date ThuFeb1917 53 422009GMTTransport RTP AVP TCP unicast destination 125 120 166 82 source 125 120 11 80 interleaved 0 1Session 15 49 RTSP协议 RTSP播放实例 第四步 客户端发送PLAY请求PLAYrtsp 125 120 11 80 554 cam1 sdpRTSP 1 0CSeq 4User Agent RealMediaPlayerHelixDNAClient 10 0 1 65 win32 Session 15Range npt 0 Bandwidth 252274000服务器应答 RTSP 1 0200OKCSeq 4Date ThuFeb1917 53 442009GMTSession 15Range npt 0 000 RTP Info url rtsp 125 120 11 80 554 cam1 sdp streamid 0 seq 12345 rtptime 0 50 RTSP协议 RTSP播放实例 第五步 客户端发送TEARDOWN请求 TEARDOWNrtsp 115 192 188 17 554 1 3gpRTSP 1 0CSeq 5User Agent RealMediaPlayerHelixDNAClient 10 0 1 65 win32 Session 15服务器应答 RTSP 1 0200OKServer DSS 5 5 5 Build 489 16 Platform Linux Release Darwin state beta Cseq 5Session 350323148535363110Connection Close 51 RTP协议 RTP介绍 RTP是针对Internet上多媒体数据流的一个传输协议 由IETF Internet工程任务组 作为RFC1889发布 RTP被定义为在一对一或一对多的传输情况下工作 其目的是提供时间信息和实现流同步 RTP的典型应用建立在UDP上 但也可以在TCP或ATM等其他协议之上工作 RTP本身只保证实时数据的传输 并不能为按顺序传送数据包提供可靠的传送机制 也不提供流量控制或拥塞控制 它依靠RTCP提供这些服务 52 RTP协议 RTP工作机制 威胁多媒体数据传输的一个尖锐的问题就是不可预料数据到达时间 但是流媒体的传输是需要数据的适时的到达用以播放和回放 rtp协议就是提供了时间标签 序列号以及其它的结构用于控制适时数据的流放 在流的概念中 时间标签 是最重要的信息 发送端依照即时的采样在数据包里隐蔽的设置了时间标签 在接受端收到数据包后 就依照时间标签按照正确的速率恢复成原始的适时的数据 不同的媒体格式调时属性是不一样的 但是rtp本身并不负责同步 rtp只是传输层协议 为了简化运输层处理 提高该层的效率 将部分运输层协议功能 比如流量控制 上移到应用层完成 同步就是属于应用层协议完成的 它没有运输层协议的完整功能 不提供任何机制来保证实时地传输数据 不支持资源预留 也不保证服务质量 rtp报文甚至不包括长度和报文边界的描述 同时rtp协议的数据报文和控制报文使用相邻的不同端口 这样大大提高了协议的灵活性和处理的简单性 rtp协议和udp二者共同完成运输层协议功能 udp协议只是传输数据包 不管数据包传输的时间顺序 rtp的协议数据单元是用udp分组来承载的 在承载rtp数据包的时候 有时候一帧数据被分割成几个包具有相同的时间标签 则可以知道时间标签并不是必须的 而udp的多路复用让rtp协议利用支持显式的多点投递 可以满足多媒体会话的需求 rtp协议虽然是传输层协议但是它没有作为osi体系结构中单独的一层来实现 rtp协议通常根据一个具体的应用来提供服务 rtp只提供协议框架 开发者可以根据应用的具体要求对协议进行充分的扩展 53 RTP协议 RTP报文格式 54 RTP协议 RTP报文格式 开始12个八进制出现在每个RTP包中 而CSRC标识列表仅出现在混合器插入时 各段含义如下 版本 V 2位 标识RTP版本 填充标识 P 1位 如设置填充位 在包尾将包含附加填充字 它不属于有效载荷 填充的最后一个八进制包含应该忽略的八进制计数 某些加密算法需要固定大小的填充字 或为在底层协议数据单元中携带几个RTP包 扩展 X 1位 如设置扩展位 固定头后跟一个头扩展 CSRC计数 CC 4位 CSRC计数包括紧接在固定头后CSRC标识符个数 标记 M 1位 标记解释由设置定义 目的在于允许重要事件在包流中标记出来 设置可定义其他标示位 或通过改变位数量来指定没有标记位 55 RTP协议 RTP报文格式 载荷类型 PT 7位 记录后面资料使用哪种编码 接收端找出相应的解码库解碼出來 56 RTP报文格式 PT类型续 57 RTP协议 RTP报文格式 序列号16位 序列号随每个RTP数据包而增加1 由接收者用来探测包损失 系列号初值是随机的 使对加密的文本攻击更加困难 时标32位 时标反映RTP数据包中第一个八进制数的采样时刻 采样时刻必须从单调 线性增加的时钟导出 以允许同步与抖动计算 时标可以让receiver端知道在正确的时间将资料播放出来 由上图可知 如果只有系列号 并不能完整按照