http-live-streaming 协议分析

http-live-streaming 协议分析:
不受限制的多媒体数据流的传输。协议支持媒体数据加密与流切换(例如不同码率)。
媒体数据创建后立即传输,播放接近实时。媒体数据通常采用HTTP进行传输。
播放列表由一个有序的媒体URI列表和信息标签组成,每个媒体URI指向一个媒体文件,这个媒体文件是单个连续媒体流上的一个片断。
为了播放媒体流,客户端首先获取播放列表文件,然后获取并播放播放列表中的每个媒体流文件。客户端依据下文定义方式重复加载播放列表文件以获取追加片断。
播放列表必须是扩展的M3U播放列表文件,后缀是.m3u8,Content-Type是"application/vnd.apple.mpegurl"
#EXTM3U:扩展标记 
#EXTINF:#EXTINF:<duration>,<title> 媒体文件的时长(单位s)和标题(可选)
#EXT-X-MEDIA-SEQUENCE:<number>标识播放列表第一个URI的序列号,后面URL的序列号顺序递增
#EXT-X-KEY:METHOD=<method>[,URI="<URI>"][,IV=<IV>]媒体加密方法(NONE,AES-128)和key获取路径以及key的初始化向量,IV=<IV>字段为version2新增
#EXT-X-PROGRAM-DATE-TIME:<YYYY-MM-DDThh:mm:ssZ>标识下一个媒体文件的开始时间
#EXT-X-ALLOW-CACHE:<YES|NO>
客户端是否允许缓存下载文件
#EXT-X-ENDLIST
标识播放列表不再追加媒体文件
#EXT-X-STREAM-INF:[attribute=value][,attribute=value]*
<URI>
标识下一个URI是一个播放列表
Attribute包括:
BANDWIDTH=<n>:码率上限估计值
PROGRAM-ID=<i>:整个播放列表中单个presentation的唯一标识符
CODECS="[format][,format]*":媒体采样类型,符合RFC 4281规定
RESOLUTION=<N>x<M>:N:水平像素,M:垂直像素

#EXT-X-DISCONTINUITY 
标明前后媒体文件编码特性的变化,包括:
file format
number and type of tracks
encoding parameters
encoding sequence
timestamp sequence

播放列表中每个URI标识一个媒体文件,它是媒体展示的一个片断。媒体文件必须是MPEG-2TS流或者MPEG-2 Audio基本流。
MPEG-2传输流只能包含一个MPEG-2 Program,每个文件开头必须有PAT和PMT,含视频的片断文件至少包含一个关键帧和能够让解码器完全初始化的足够信息。
除非第一个或者前置EXT-X-DISCONTINUITY标签的媒体文件,播放列表的媒体文件必须是前后连续的。
客户端必须具备处理音频类型或视频类型存在多个轨的情况,没有特别偏好的客户端选择所能支持的、PID号最低的一个进行播放。
客户端必须忽略TS中无法识别的私有流。
一个媒体文件中采样的编码参数,以及多个每个文件中对应媒体流的编码参数,必须保持一致。客户端应该具备处理编码参数变化的能力,比如调整视频内容尺寸适应分辨率的变化。
1、服务器必须把MPEG-2流切分为长度几乎相等的单个媒体文件,切分点必须支持对单个媒体文件的有效解码,比如按照包和关键帧边界来切分。单个媒体文件长度通常为10s。
2、服务器需要给每个单独媒体文件创建一个可访问的URI。
3、服务器必须创建播放列表文件,格式按照3节要求,URI按播放顺序排列,播放列表中每个URI的媒体文件必须是可被客户端完整访问的。
4、播放列表文件必须包含EXT-X-TARGETDURATION,指明播放列表中所有媒体文件的maximum EXTINF,并且其值在整个展示过程中保持不变,典型是10s。
5、服务器需要给播放列表文件创建一个可访问的URI。
6、播放列表文件的更新对客户端而言必须是原子的。
7、播放列表应该包含EXT-X-VERSION协议版本号。
8、播放列表通过HTTP分发时,服务器应该支持客户端的"gzip" Content-Encoding
9、服务器不能更改EXT-X-ALLOW-CACHE标签值
10、每个媒体文件URI前必须有EXTINF标签
11、服务器可以在媒体文件URI前放置EXT-X-PROGRAM-DATE-TIME标签,建立绝对日期时间与媒体文件的关联。日期和时间值提供媒体时间线与wall-clock时间的映射信息,可用于播放过程中的seek等目的。如果服务器提供这种映射,应该在每个EXT-X-DISCONTINUITY后放置EXT-X-PROGRAM-DATE-TIME。
12、如果播放列表包含展示的最后一个媒体文件,应放置EXT-X-ENDLIST。
13、如果播放列表没有EXT-X-ENDLIST,服务器必须更新播放列表文件,其中至少包含一个新的媒体文件URI。更新时间相对上次更新时间间隔应该在[0.5,1.5]倍的#EXT-X-TARGETDURATION时间范围内(通常为[5,15]s)。
14、如果服务器打算删除整个展示,令播放列表对客户端不可见,但播放列表中媒体文件对客户端仍然可见,至少保留播放列表间隔时长。

文章源地址:http://blog.csdn.net/yangzhiloveyou/article/details/8922341

时间: 11-15

http-live-streaming 协议分析的相关文章

RTP协议分析

整理记录 版本号 时间 内容 整理人 V1.0 2008-03-31 RTP协议分析初稿 彭令鹏 RTP协议分析 第1章.     RTP概述 1.1.  RTP是什么 RTP全名是Real-time Transport Protocol(实时传输协议).它是IETF提出的一个标准,相应的RFC文档为RFC3550(RFC1889为其过期版本号).RFC3550不仅定义了RTP,并且定义了配套的相关协议RTCP(Real-time Transport Control Protocol,即实时传输

RTP协议分析(转自:http://blog.csdn.net/bripengandre/article/details/2238818)

RTP协议分析 第1章.     RTP概述 1.1.  RTP是什么 RTP全名是Real-time Transport Protocol(实时传输协议).它是IETF提出的一个标准,对应的RFC文档为RFC3550(RFC1889为其过期版本).RFC3550不仅定义了RTP,而且定义了配套的相关协议RTCP(Real-time Transport Control Protocol,即实时传输控制协议).RTP用来为IP网上的语音.图像.传真等多种需要实时传输的多媒体数据提供端到端的实时传输

RTSP 协议分析——看完这篇直接毕业

http://blog.csdn.net/bytxl/article/details/50407413 版权声明:本文为博主原创文章,未经博主允许不得转载. 目录(?)[+] 1.概述: RTSP(Real Time Streaming Protocol),实时流传输协议,是TCP/IP协议体系中的一个应用层协议,由哥伦比亚大学.网景和RealNetworks公司提交的IETF RFC标准.该协议定义了一对多应用程序如何有效地通过IP网络传送多媒体数据.类似HTTP协议的流控制协议.它们都使用纯

蓝牙协议分析(3)_BLE协议栈介绍

1. 前言 通过"蓝牙协议分析(2)_协议架构"的介绍,大家对蓝牙协议栈应该有了简单的了解,但是,肯定还有"似懂非懂.欲说还休"的感觉.有这种感觉太正常了,毕竟蓝牙协议是一个历史悠久又比较庞大的协议,没那么容易理解. 因此,本文将换个视角,从协议栈设计者的角度,思考如下问题: 为什么会有蓝牙协议栈(Why)? 怎样实现蓝牙协议栈(How)? 蓝牙协议栈的最终样子是什么(What)? 另外,我们知道,当前的蓝牙协议包含BR/EDR.AMP.LE三种技术,为了降低复杂度

蓝牙协议分析(7)_BLE连接有关的技术分析

转自:http://www.wowotech.net/bluetooth/ble_connection.html#comments 1. 前言 了解蓝牙的人都知道,在经典蓝牙中,保持连接(Connection)是一个相当消耗资源(power和带宽)的过程.特别是当没有数据传输的时候,所消耗的资源完全被浪费了.因而,对很多蓝牙设备来说(特别是功耗敏感的设备),希望在无数可传的时候,能够断开连接.但是,由于跳频(hopping)以及物理通道(Physical Channel)划分的缘故,经典蓝牙连接

BT协议分析(1)&mdash;1.0协议

简述 BT下载是采用P2P的下载方式,下载的大致形式采用如下图所示,处于图示中心的称为Tracker服务器,其余称为Peer.   缺点 1.资源的安全性 2.资源的实效性(没有上传者则BT也将失效) 3.版权 协议分析 对BT协议(1.0)的分析主要包含4个部分: 1.种子文件的分析 2.同Tracker服务器的通讯(采用HTTP协议) 3.同其他peer(配合/协同者)的通讯(采用TCP协议) 4.总结 分析前的了解 在这些分析之前,需要先了解两点BT协议采用的基础: 1.BT协议中采用的单

物联网MQTT协议分析和开源Mosquitto部署验证

在<物联网核心协议—消息推送技术演进>一文中已向读者介绍了多种消息推送技术的情况,包括HTTP单向通信.Ajax轮询.Websocket.MQTT.CoAP等,其中MQTT协议为IBM制定并力推,其具有开放.简单.轻量级以及易于实现的特点使得其即便在资源受限的环境中也能得到很好的使用,比如运行在资源紧缺型的嵌入式系统中或网络带宽非常昂贵的环境中,除此之外,它也被广泛用于遥感勘测.智能家居.能源监测和医疗应用程序等各个领域,是物联网的重要组成部分,将来可能会成为物联网的事实标准. 本篇文章将帮助

协议分析 - DHCP协议解码详解

协议分析 - DHCP协议解码详解 [DHCP协议简介] DHCP,全称是 Dynamic Host Configuration Protocol﹐中文名为动态主机配置协议,它的前身是 BOOTP,它工作在OSI的应用层,是一种帮助计算机从指定的DHCP服务器获取它们的配置信息的自举协议. DHCP使用客户端/服务器模式,请求配置信息的计算机叫做DHCP客户端,而提供信息的叫做DHCP的服务器.DHCP为客户端分配地址的方法有三种:手工配置.自动配置.动态配置. DHCP最重要的功能就是动态分配

linux 网络协议分析---3

本章节主要介绍linxu网络模型.以及常用的网络协议分析以太网协议.IP协议.TCP协议.UDP协议 一.网络模型 TCP/IP分层模型的四个协议层分别完成以下的功能: 第一层 网络接口层 网络接口层包括用于协作IP数据在已有网络介质上传输的协议.实际上TCP/IP标准并不定义与ISO数据链路层和物理层相对应的功能.相反,它定义像 地址解析协议(Address Resolution Protocol,ARP)这样的协议,提供TCP/IP协议的数据结构和实际物理硬件之间的接口. 第二层 网间层 网

网络协议分析

1. 网络模型 2. 协议分析 2.1协议架构 2. 2 以太网协议格式 2. 3 IP协议格式 2. 4 TCP协议格式 2. 5 UDP协议格式