成熟的媒体应用往往面对这样的需求:
其中一种比较灵活的解决方案是把自定义媒体数据推流为http,而大部分播放器都能很好地支持http(vlc/ffmepg/mediaplayer/ijkplayer/kodi等)。
数据流示意:
本篇文章主要讲解上图的http协议部分。
http协议是应用层协议,使用tcp进行传输。
请求报文是播放器(http客户端)发给http伺服器的内容,由请求方法、请求URI、协议版本、可选的请求首部栏位和内容实体构成,如:
POST /media HTTP/1.1 Host: 127.0.0.1:8000 Content-Type: application/x-www-form-urlencoded Content-Length: 10
path=/tmp/1.mp4
第1行包含了请求方法、请求URI、协议版本,第2~4行是请求首部栏位,最后一行是内容实体。
响应报文由协议版本、状态码、状态码原因短语、可选的响应首部栏位和实体主体构成,如:
HTTP/1.1 200 OK Content-Length: 53 Content-Type: text/html
<html> ...
第一行包含了协议版本、状态码、状态码原因短语,第2~3行是响应首部栏位,最后几行是主体,也就是通常浏览器要渲染的内容
流媒体就是像流水一样把视频数据通过网路传输到终端上播放。
通过http推送流媒体的时候,对应的是http的chunk传输。
chunk传输的典型(响应)报文如下:
HTTP/1.1 200 OK Transfer-Encoding: chunked Content-Type: video/mpeg
400 ...ad....fxa... ... 400 xai.. ... 0
即,通过Transfer-Encoding: chunked告知客户端现在传输的是分块数据,这样客户端就会维持这个连接,直到数据接收完成。
Transfer-Encoding: chunked
数据传输过程中,每个chunk都是以大小 数据 的格式传输,最后以大小0通知客户端数据完成。
大小 数据
流传输在多媒体应用中常用于直播,因为直播的数据长度一般是不定的,这样就可以借助客户端和服务端间的这个长连接持续不断地传输媒体数据。
流媒体的缺点是不能跳进。
不能跳进不仅意味著用户无法seek观看节目,也意味著一些节目的信息无法获取(如时长)。
为了支持跳进,可以借助http的range请求。
range请求常以断点续传闻名,它允许客户端从任何位置开始,向伺服器请求任意长度的数据。
比如:
POST /media HTTP/1.1 Host: 127.0.0.1:8000 Content-Type: application/x-www-form-urlencoded Content-Length: 10 Range: bytes=500-1000
这个请求报文通过Range向伺服器请求了第500~1000位元组的数据(共501位元组,第一个位元组是索引0)
Range
伺服器如果能正确返回这部分数据,就回复:
HTTP/1.1 206 OK Content-Length: 53 Content-Type: video/mpeg Accept-Ranges: bytes Content-Range: bytes 500-1000/1024 Content-Length: 501
....
Accept-Ranges:bytes意思是接收按位元组为单位进行range请求;Content-Range告诉客户端返回的数据对应的是哪个范围的数据,这里回复的是客户端请求的500-1000,其中1024是整个媒体的数据长度;Content-Length表示返回的数据长度(1000-500+1 = 501)
Accept-Ranges:bytes
Content-Range
500-1000
1024
Content-Length
所以,一般播放器在播放http源的时候要进行seek就是通过发起新的http请求,并在请求中加入Range栏位来从seek的目标位置读取数据。
然而,实际情况会复杂一些。
其一,播放器可能会在开始播放的时候就会跳转到尾部读取视频数据,以确定节目时长(比如ts封装就需要读取尾部数据来估算视频时长);
其二,seek可能需要经过多次range请求才能跳转到目标位置(如ffmpeg会用二分查找来查找目标时间点);
其三,http是无状态的,所以每次客户端来的请求所在的处理线程不一定相同,而且同次点播的多个http请求间是无关联的。这对于静态文件资源而言是无关紧要的,但对于动态内存资源(如动态解密的视频)而言就需要谨慎处理多线程问题和session管理了。
上节了解过,seek基于多次range request的实现机制会导致在一次点播期间,服务端与客户端间会有多次的通信,而http的无状态特性导致这几次通信是无关联的,伺服器无从知道这几次通信对应的是同一次点播。
通用的解决方法是利用http的cookie机制,在多次通信中携带id栏位进行session关联。示意图如下:
对应于http报文是:
"第一次通信":
POST /media HTTP/1.1 Host: 127.0.0.1:8000 Content-Type: application/x-www-form-urlencoded Content-Length: 10 Range: bytes=0-
"你的id是123":
HTTP/1.1 206 OK Content-Length: 53 Content-Type: video/mpeg Accept-Ranges: bytes Content-Range: bytes 0-1023/1024 Content-Length: 1024 Set-Cookie: id=123
"我的id是123,Range 500-1000":
POST /media HTTP/1.1 Host: 127.0.0.1:8000 Content-Type: application/x-www-form-urlencoded Content-Length: 10 Range: bytes=500-1000 Cookie: id=123
"你的id是123,你的请求已受理":
HTTP/1.1 206 OK Content-Length: 53 Content-Type: video/mpeg Accept-Ranges: bytes Content-Range: bytes 500-1000/1024 Content-Length: 501 Set-Cookie: id=123
上面通信过程主要依赖Set-Cookie和Cookie两个栏位保证。协议也很简单,服务端通过Set-Cookie给客户端发送id=123,客户端识别如果有Set-Cookie,则在下次请求中把Set-Cookie的内容放到Cookie中通知回服务端。
Set-Cookie
Cookie
id=123
上述基本就是完成http推流所需要的核心协议了。总结下:
我们将在http推流设计与实现一文中介绍xport,详解如何实现http推流。
compilelife/xport?github.com 推荐阅读: