RTSP协议
1.概念
- RTSP是一个基于文本的多媒体播放控制协议，属于应用层。
- 对应的协议标准是RFC2326
- 主要用来控制具有实时特性的数据的发送，但是其本身并不用于传送流媒体数据，而必须依赖下层传输协议(RTCP/RTP)所提供的服务来完成流媒体数据的发送。
关键词：基于文本、应用层、RFC2326、实时、依赖下层传输协议
2.作用
- 控制信息
- 操作方法
- 状态码
- 描述与RTP之间的交互操作
- 流程：internet-->IP-->(UDP/TCP)--(RTP/RTCP/RTSP)-->Video/Audio
3.交互过程
+ C->S(OPTION request):Client询问Server有哪些方法可用
+ S->C(OPTION response):Server回应信息中包含的所有方法
+ C->S(DESCRIBE request):Client请求得到Server提供的媒体初始化描述信息
+ S->C(DESCRIBE response):Server回应媒体初始化信息主要是SDP(会话描述协议)
+ C->S(SETUP request):设置会话属性及传输模式，建立会话
+ S->C(SETUP response):Server建立会话，返回会话标识符以及会话相关信息
+ C->S(PLAY request):Client请求播放
+ S->(PLAY response):Server回应播放请求信息
+ S->C(Media Data Transfer):发送流媒体数据
+ C->S(TEARDOWN request):Client请求关闭会话
+ S->C(TEARDOWN response):Server回应关闭请求会话
4.RTSP报文
- OPTIONS请求：客户端向服务器询问可用的方法
- DESCRIBE请求：客户端向服务器请求媒体资源描述，服务器端通过SDP(Session Description Protocol)格式回应客户端的请求。资源描述中会列出所请求媒体的媒体流及其相关信息
- SETUP请求：确定了具体的媒体流如何传输，该请求必须在PLAY请求之前发送。SETUP请求包含媒体流的URL和客户端用于接收RTP数据(audio or video)的端口以及接收RTCP数据(meta information)的端口。服务器端的回复通常包含客户端请求参数的确认，并会补充缺失的部分，比如服务器选择的发送端口
- PLAY请求：播放一个或全部媒体流，PLAY请求中可指定播放的range，若未指定，则从媒体流的开始播放到结束
- PAUSE请求：暂停一个或所有媒体流，后续可通过PLAY请求恢复播放。若参数range存在，则指明在何处暂停，若该参数不存在，则暂停立即生效
- TEARDOWN请求：结束会话
- GET_PARAMETER / SET_PARAMETER请求: 检索/设置媒体流的参数值，不携带消息体的GET_PARAMETER可用来测试服务器端或客户端是否可通(类似ping的功能)。
5.RTSP认证
- RTSP认证主要分两种：基本认证（basic authentication）和摘要认证（digest authentication）
- 基本认证是http 1.0提出的认证方案，其消息传输不经过加密转换因此存在严重的安全隐患（base64编码）
- 摘要认证是http 1.1提出的基本认证的替代方案，其消息经过MD5哈希转换因此具有更高的安全性。
6.RTSP基本认证
- 客户端发送DESCRIBE请求到服务端，RTSP服务端认为没有通过认证，发出WWW-Authenticate认证响应
- 客户端携带Authorization串再次发出DESCRIBE请求
7.RTSP摘要认证
- 客户端发送DESCRIBE请求，服务器端返回401错误，提示未认证并以nonce质询
- 客户端以用户名，密码，nonce，HTTP方法，请求的URI等信息为基础产生response信息进行反馈
- 服务器对客户端反馈的response进行校验
RTMP协议
- RTMP协议是Real Time Message Protocol(实时信息传输协议)的缩写，它是由Adobe公司提出的一种应用层的协议
- RTMP一般采用TCP作为传输层，在基于传输层协议的链接建立完成后，RTMP协议也要客户端和服务器通过“握手”来建立基于传输层链接之上的RTMP Connection链接
- RTMP协议中基本的数据单元称为消息。消息被拆分成更小的消息块进行传输，接收端再进行组合并解封装后得到媒体数据
- 速度快，误码率低，延迟低RTMP 是专为流媒体服务而生，协议在制定的时候就考虑到很多底层的优化消息块的传输能够提供更加稳定的直播环境
- RTMP视频的封装格式是基于flv，支持flash播放，低延时，常常用于互联网直播应用，但在HTML5中需要使用插件才能支持，一般不支持IOS设备
HLS协议
1.概述
- HTTP Live Streaming，是Apple的开放标准，基于HTTP流，它最初是苹果公司针对iPhone、iPod、iTouch和iPad等移动设备而开发的流，现在见到在桌面也有很多应用了，由于是基于HTTP的，因此很多HTTP的优点都得到了继承。
2.特点
- 将流媒体切分为若干 TS 片段（比如每10秒一段），然后通过一个扩展的 m3u 列表文件将这些 TS 片段集中起来供客户端播放器接收。
3.流程功能块
- 视频输入或者采集设备给Media encoder
- Media encoder：负责将视频源转码成H264的视频数据给stream segmenter模块
- stream segmenter：模块将视频切片，得到index file（m3u8）和ts文件给Distribution
- Distribution：一个普通的HTTP文件服务器传输给使用 者client
- client
4.视频文件索引(.m3u8文件)？
- EXTM3U：每个m3u文件第一行必须是这个tag
- EXT-X-TARGETDURATION：指定最大的媒体段时间长（秒）
- EXT-X-MEDIA-SEQUENCE：第一个媒体段的序列号，默认为0
- EXTINF：指出媒体段的时间长度，紧接着指定媒体段的URL
- EXT-X-ENDLIST：媒体列表结束
5.优缺点
- HLS协议一旦切分TS片段完成，之后的分发过程完全不需要额外使用任何专门软件，普通的网络服务器即可，大大降低了 CDN 边缘服务器的配置要求。
- 分发使用的协议是最常见 HTTP，代理服务器对这个协议的缓存优化相当成熟，而很少有代理服务器对 RTSP 的进行缓存优化。这对播放（软）实时视频有相当大的优势，因为这样分发后，对源服务器的负载压力小得多。
- HLS支持自适应码率流播（adaptive streaming）。效果就是客户端会根据网络状况自动选择不同码率的视频流，并且自动在二者间随意切换。实现方法是服务器端提供多码率视频流，并且在列表文件中注明
- HLS协议用 TS 而不是 MP4，因为两个 TS 片段可以无缝拼接，播放器能连续播放，而 MP4 文件由于编码方式的原因，两段 MP4 不能无缝拼接
- IOS、Android、HTML5原生支持。
- 缺点：直播应用中，相比于RTMP延时长，基本在10秒以上。
由于目前待在做人部分脸识别技术的公司，所以对视频流这块需要有一定的了解。以上协议内容概述源于以前看过的一份PPT文档，然后记录下来了，已经不记得原PPT作者具体是谁。望见谅，侵删。
网友评论