Skip to content

Commit 546203d

Browse files
CharonChuiCharonChui
committed
add notes
1 parent 5a9fcd1 commit 546203d

File tree

12 files changed

+808
-597
lines changed

12 files changed

+808
-597
lines changed

‎VideoDevelopment/流媒体协议/DASH.md‎

Lines changed: 41 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -10,6 +10,10 @@ MPEG-DASH是一种自适应比特率流技术，可根据实时网络状况实
1010

1111
![dash_compare](https://raw.githubusercontent.com/CharonChui/Pictures/master/dash_compare.png)
1212

13+
HLS在16年支持了fmp4，在17年支持了4K。
14+
15+
16+
1317
## 思想
1418

1519
![dash_main_idea](https://raw.githubusercontent.com/CharonChui/Pictures/master/dash_main_idea.png)
@@ -26,8 +30,6 @@ DASH的整个流程:
2630

2731
![image-20200406164238038](https://raw.githubusercontent.com/CharonChui/Pictures/master/mpd_hierarchical_data.png)
2832

29-
30-
3133
```xml
3234
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
3335
<MPD id="0564e940-122b-42bb-9d56-98f3def67247" profiles="urn:mpeg:dash:profile:isoff-main:2011" type="static" availabilityStartTime="2016-01-14T09:30:35.000Z" publishTime="2016-01-14T09:31:33.000Z" mediaPresentationDuration="P0Y0M0DT0H2M17.000S" minBufferTime="P0Y0M0DT0H0M1.000S" bitmovin:version="1.6.0" xmlns:ns2="http://www.w3.org/1999/xlink" xmlns="urn:mpeg:dash:schema:mpd:2011" xmlns:bitmovin="http://www.bitmovin.net/mpd/2015">
@@ -60,19 +62,19 @@ DASH中的重要概念
6062

6163
### Period
6264

63-
MPD文件包含一个或者多个片段(Period)，它表示时间轴上的一段时间，每个片段都有一个起始时间和结束时间，并且包含了一个或者多个适配集合(Adaptation Set)。每个适配集合提供了一个或者多个媒体组件的信息，并包含了多种不同的码率。每个适配集合又是由多个呈现(Representation)组成，每个呈现就是同一个视频的不同特征的版本，如码率、分辨率等特征。由于每个的视频都要被切成固定长度的切片，因此每个呈现包括多个视频切片(Segment)，每个视频切片都有一个URL地址，这样客户端就可以通过这个地址向服务器发送HTTP GET请求获取该片段。同一个Period内，意味着可用的媒体内容及其各个可用码率（Representation）不会发生变更。直播情况下，“可能”需要周期地去服务器更新MPD文件，服务器可能会移除旧的已经过时的Period,或是添加新的Period。新的Period中可能会添加新的可用码率或去掉上一个Period中存在的某些码率(Representation)。
65+
标注了视频的时长信息，也可以看做是更新mpd文件的最长时长，MPD文件包含一个或者多个片段(Period)，它表示时间轴上的一段时间，每个片段都有一个起始时间和结束时间，并且包含了一个或者多个适配集合(Adaptation Set)。每个适配集合提供了一个或者多个媒体组件的信息，并包含了多种不同的码率。每个适配集合又是由多个呈现(Representation)组成，每个呈现就是同一个视频的不同特征的版本，如码率、分辨率等特征。由于每个的视频都要被切成固定长度的切片，因此每个呈现包括多个视频切片(Segment)，每个视频切片都有一个URL地址，这样客户端就可以通过这个地址向服务器发送HTTP GET请求获取该片段。同一个Period内，意味着可用的媒体内容及其各个可用码率（Representation）不会发生变更。直播情况下，“可能”需要周期地去服务器更新MPD文件，服务器可能会移除旧的已经过时的Period,或是添加新的Period。新的Period中可能会添加新的可用码率或去掉上一个Period中存在的某些码率(Representation)。
6466

6567
### Adaptation Set
6668

67-
一个Period由一个或者多个Adaptationset组成。Adaptationset由一组可供切换的不同码率的码流（Representation)组成，这些码流中可能包含一个（ISO profile)或者多个(TS profile)media content components，因为ISO profile的mp4或者fmp4 segment中通常只含有一个视频或者音频内容，而TS profile中的TS segment同时含有视频和音频内容，当同时含有多个media component content时，每个被复用的media content component将被单独描述
69+
包含了媒体呈现的形式，（视频/音频/字幕）。 一个Period由一个或者多个Adaptationset组成。Adaptationset由一组可供切换的不同码率的码流（Representation)组成，这些码流中可能包含一个（ISO profile)或者多个(TS profile)media content components，因为ISO profile的mp4或者fmp4 segment中通常只含有一个视频或者音频内容，而TS profile中的TS segment同时含有视频和音频内容，当同时含有多个media component content时，每个被复用的media content component将被单独描述
6870

6971
### Representation
7072

71-
每个Adaptationset包含了一个或者多个Representations,一个Representation包含一个或者多个media streams，每个media stream对应一个media content component。为了适应不同的网络带宽，dash客户端可能会从一个Representation切换到另外一个Representation，如果不支持某个Representation的编码格式，在切换时可以忽略之。
73+
包含不同的码率、编码方式、帧率信息等。每个Adaptationset包含了一个或者多个Representations,一个Representation包含一个或者多个media streams，每个media stream对应一个media content component。为了适应不同的网络带宽，实际播放的时候，视频会在一个AdaptationSet中的不同Representaiton 之间切换码率，可能会从一个Representation切换到另外一个Representation，会依次请求该Representaiton下不同Segment序列。
7274

7375
### Segments
7476

75-
Segments可以包含任何媒体数据，关于容器，官方提供了两种建议: ISO base media file format(比如MP4文件格式)和MPEG-2 Transport Stream。
77+
每一个具体的片段。（1,2,4,6,10s …） Segments可以包含任何媒体数据，关于容器，官方提供了两种建议: ISO base media file format(比如MP4文件格式)和MPEG-2 Transport Stream。
7678

7779
每个Representation会划分为多个Segment。Segment分为4类，其中，最重要的是：Initialization Segment（每个Representation都包含1个Init Seg），Media Segment（每个Representation的媒体内容包含若干Media Seg）
7880

@@ -83,6 +85,28 @@ Segments可以包含任何媒体数据，关于容器，官方提供了两种建
8385
- Subsegment
8486

8587
Segment可能进一步划分为subsegment，每个subsegment由数个Acess Unit组成，Segment index提供了subsegment相对于Segment的字节范围和presentation time range 。客户端可以先下载Segment index。
88+
89+
90+
91+
`*_init.mp4`: 初始的mp4文件，相当于视频头，在这个头文件中包含了完整的视频元信息(moov)，具体的可以使用 `MP4Box -info` 查看。
92+
93+
`*.m4s`: 即上面提到的Segments文件，每个m4s仅包含媒体信息 (moof + mdat)，而播放器是不能直接播放这个文件的，需要用支持DASH的播放器从init文件开始播放。
94+
95+
96+
97+
确切的说，当Adaptation set的属性@segmentAlignment为真（true）时，同一个Adaptation set中的多个Representation之中的媒体段是对齐的，因此，当从一个Representation A切换到另一个Representation B时，若Representation A的第N个媒体段已经下载完成，切换时可直接下载Representation B的第N+1个媒体段。
98+
99+
DASH对媒体段定义了三种方式：
100+
101+
BaseURL：单段表示
102+
103+
SegmentList：段列表
104+
105+
SegmentTemplate：段模板
106+
107+
单段表示是最简单的：每个Representation只有一个媒体段。用BaseURL表示。举例如下：
108+
109+
86110

87111
### SAP和无缝切换以及SEEK
88112

@@ -139,7 +163,17 @@ Segments可以包含任何媒体数据，关于容器，官方提供了两种建
139163
- 插入广告: 通常，可以在HLS和DASH的实时流中插入广告。为此，只需交换单个视频块。 DASH为此提供了一种有效的方法：标准化的界面允许有效地插入广告。
140164
- 快速频道切换: 您可以在各个通道之间切换的速度取决于最大的子段（块）。块越小，通道更改速度越快。正如引言中已经提到的，HLS块通常长约10秒，而DASH块通常长2至4秒。因此，DASH在这方面领先一步。小块还具有降低代码效率的缺点。具有较小块的播放列表必须比具有较大块的播放列表更频繁地更新。这意味着包含较短视频片段的播放列表必须通过HTTP更频繁地更新。
141165

166+
# **结构与编码**
167+
168+
MPEG-DASH支持TS和MP4 / ISO BMFF媒体段。HLS只支持MPEG-2 TS。DASH媒体段通常比HLS短，2至4秒比较常见。DASH不需要特定的编解码器。视频可以使用H264编码，也可以用其他编码，VP9和H265也是比较受欢迎的编码。
142169

170+
一般而言，与HLS相比，DASH可以提供实质上更低的端对端延迟。这对于现场直播的工作流程很重要。此外， MPEG-DASH的基于模板的MPD不需要更新，可以在网络边缘服务器进行缓存，HLS则需要周期性地更新传播多次。
171+
172+
DASH支持索引和基于时间的模版，播放器能够基于公开的时钟，如NTPS，进行同步。这对于多相机的情况下，多个播放器之间同步会比较容易。
173+
174+
# **DRM**
175+
176+
DASH和HLS之间的另一个关键区别是它支持DRM。可是，在DASH中不存在一个单一通用的DRM解决方案。例如，Google的Chrome支持Widevine，而Microsoft的Internet Explorer支持PlayReady。然而，通过使用MPEG-CENC（MPEG通用加密）结合加密媒体扩展（EME），视频流内容可以仅被加密一次。HLS支持AES-128加密，以及苹果自己的DRM，Fairplay。
143177

144178

145179

@@ -164,10 +198,9 @@ Segments可以包含任何媒体数据，关于容器，官方提供了两种建
164198
参考:
165199

166200
- [HLS，MPEG-DASH - What is ABR?](http://telestreamblog.telestream.net/2017/05/what-is-abr/)
167-
168201
- [B站我们为什么使用DASH](https://www.bilibili.com/read/cv855111)
169-
170202
- [Adaptive HTTP Streaming Technologies: HLS vs. DASH](https://strivecast.io/hls-vs-mpeg-dash/)
203+
- [自适应流媒体传输](https://blog.csdn.net/nonmarking/article/details/86351147)
171204

172205

173206

‎VideoDevelopment/流媒体协议/HLS.md‎

Lines changed: 54 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -4,7 +4,7 @@
44

55
HLS协议规定:
66

7-
- 视频的封装格式是ts(16年发布也支持了fMP4)
7+
- 视频的封装格式是ts(WWDC2016年发布也支持了fMP4)
88
- 视频的编码格式为H264、H265、VP9(17年支持H265、VP9)，音频编码格式为MP3、AAC或者AC-3
99
- 除了TS视频文件本身，还定义了用来控制播放的m3u8文件(文本文件)
1010

@@ -18,6 +18,18 @@ HLS点播，基本上就是常见的分段HTTP点播，不同在于，它的分
1818

1919

2020

21+
## 使用
22+
23+
- [Google](https://en.wikipedia.org/wiki/Google) added HTTP Live Streaming support in [Android](https://en.wikipedia.org/wiki/Android_(operating_system)) 3.0 (Honeycomb).[[17\]](https://en.wikipedia.org/wiki/HTTP_Live_Streaming#cite_note-17)
24+
- [HP](https://en.wikipedia.org/wiki/Hewlett-Packard) added HTTP Live Streaming support in [webOS](https://en.wikipedia.org/wiki/Webos) 3.0.5.[[18\]](https://en.wikipedia.org/wiki/HTTP_Live_Streaming#cite_note-18)
25+
- Microsoft added support for HTTP Live Streaming in EdgeHTML rendering engine in Windows 10 in 2015.[[19\]](https://en.wikipedia.org/wiki/HTTP_Live_Streaming#cite_note-19)
26+
- Microsoft added support for HTTP Live Streaming in IIS Media Services 4.0.[[20\]](https://en.wikipedia.org/wiki/HTTP_Live_Streaming#cite_note-IISMS4-20)
27+
- [Yospace](https://en.wikipedia.org/wiki/Yospace) added HTTP Live Streaming support in Yospace HLS Player and SDK for flash version 1.0.[*[citation needed](https://en.wikipedia.org/wiki/Wikipedia:Citation_needed)*]
28+
- [Sling Media](https://en.wikipedia.org/wiki/Sling_Media) added HTTP Live Streaming support to its [Slingboxes](https://en.wikipedia.org/wiki/Slingbox) and its SlingPlayer apps.[[21\]](https://en.wikipedia.org/wiki/HTTP_Live_Streaming#cite_note-21)
29+
- In 2014/15, the [BBC](https://en.wikipedia.org/wiki/BBC) introduced HLS-AAC streams for its live internet radio and on-demand audio services, and supports those streams with its [iPlayer Radio](https://en.wikipedia.org/wiki/IPlayer_Radio) clients.[[22\]](https://en.wikipedia.org/wiki/HTTP_Live_Streaming#cite_note-22)
30+
31+
32+
2133
### HLS架构
2234

2335
HLS的架构分为三部分：Server，CDN，Client 。即服务器、分发组件和客户端。
@@ -139,6 +151,36 @@ cctv1hd-1585920074000.ts
139151
140152
141153
154+
#### 直播流
155+
156+
```xml
157+
#EXTM3U
158+
#EXT-X-VERSION:3
159+
#EXT-X-MEDIA-SEQUENCE:396078
160+
#EXT-X-TARGETDURATION:10
161+
#EXTINF:10.000,
162+
cctv1hd-1591683975000.ts
163+
#EXTINF:10.000,
164+
cctv1hd-1591683985000.ts
165+
#EXTINF:10.000,
166+
cctv1hd-1591683995000.ts
167+
#EXTINF:10.000,
168+
cctv1hd-1591684005000.ts
169+
#EXTINF:10.000,
170+
cctv1hd-1591684015000.ts
171+
#EXTINF:10.000,
172+
cctv1hd-1591684025000.ts
173+
```
174+
175+
直播流是没有#EXT-X-ENDLIST标签的，也就是说播放器在播放完一个.ts文件后会向服务器再次发送请求m3u8文件的请求。
176+
177+
live m3u8文件列表需要不断更新，更新规则：
178+
179+
1. 移除一个文件播放列表中靠前的（认为已播放的）文件
180+
2. 不断更新`EXT-X-MEDIA-SEQUENCE`标签，以**步长为1**进行递增
181+
182+
183+
142184

143185

144186
## HLS 的优势
@@ -150,14 +192,16 @@ cctv1hd-1585920074000.ts
150192

151193
## HLS 的劣势
152194

153-
- 相比 RTMP 这类长连接协议, 延时较高, 难以用到互动直播场景.HLS 理论延时 = 1 个切片的时长 + 0-1个 td (td 是 EXT-X-TARGETDURATION, 可简单理解为播放器取片的间隔时间) + 0-n 个启动切片(苹果官方建议是请求到 3 个片之后才开始播放) + 播放器最开始请求的片的网络延时(网络连接耗时)。为了追求低延时效果, 可以将切片切的更小, 取片间隔做的更小, 播放器未取到 3 个片就启动播放. 但是, 这些优化方式都会增加 HLS 不稳定和出现错误的风险.通常 HLS 直播延时会达到 20-30s，而高延时对于需要实时互动体验的直播来说是不可接受的。
195+
- 相比 RTMP 这类长连接协议, 延时较高, 难以用到互动直播场景.HLS 理论延时 = 1 个切片的时长 + 0-1个 td (td 是 EXT-X-TARGETDURATION, 可简单理解为播放器取片的间隔时间) + 0-n 个启动切片(苹果官方建议是请求到 3 个片之后才开始播放) + 播放器最开始请求的片的网络延时(网络连接耗时)。为了追求低延时效果, 可以将切片切的更小, 取片间隔做的更小, 播放器未取到 3 个片就启动播放. 但是, 这些优化方式都会增加 HLS 不稳定和出现错误的风险.通常 HLS 直播延时会达到 20-30s，而高延时对于需要实时互动体验的直播来说是不可接受的。Apple在WWDC2019发布了新的解决方案，可以将延迟从8秒降低到1至2秒。
154196
- 对于点播服务来说, 由于 TS 切片通常较小, 海量碎片在文件分发, 一致性缓存, 存储等方面都有较大挑战.
155197
- HLS 基于短连接 HTTP，HTTP 是基于 TCP 的，这就意味着 HLS 需要不断地与服务器建立连接，TCP 每次建立连接时的三次握手、慢启动过程、断开连接时的四次挥手都会产生消耗。
156198

157199

158200

159201

160202

203+
#### 测试地址:
204+
161205
CCTV1高清：http://ivi.bupt.edu.cn/hls/cctv1hd.m3u8
162206
CCTV3高清：http://ivi.bupt.edu.cn/hls/cctv3hd.m3u8
163207
CCTV5高清：http://ivi.bupt.edu.cn/hls/cctv5hd.m3u8
@@ -166,6 +210,14 @@ CCTV6高清：http://ivi.bupt.edu.cn/hls/cctv6hd.m3u8
166210

167211

168212

213+
#### 参考:
214+
215+
- [HTTP Live Streaming Overview](https://developer.apple.com/library/archive/documentation/NetworkingInternet/Conceptual/StreamingMediaGuide/Introduction/Introduction.html#//apple_ref/doc/uid/TP40008332-CH1-SW1)
216+
217+
218+
219+
220+
169221

170222

171223

‎VideoDevelopment/流媒体协议/HTTP FLV.md‎

Lines changed: 12 additions & 13 deletions
Original file line numberDiff line numberDiff line change
@@ -1,29 +1,21 @@
11
HTTP FLV
22
===
33

4-
先看看HTTP-FLV长成什么样子：http://ip:port/live/livestream.flv，协议头是http,另外”.flv”这个尾巴是它最明显的特征。
5-
6-
HttpFlv 就是 http+flv ，将音视频数据封装成FLV格式，然后通过 HTTP 协议传输给客户端。
7-
8-
9-
10-
下的直播平台中大部分的主线路使用的都是HTTP-FLV协议，备线路多为RTMP。小编随便在Safari中打开几个直播平台房间，一抓包就不难发现使用HTTP-FLV协议的身影：熊猫、斗鱼、虎牙、B站。
4+
在说HTTP-FLV之前，我们有必要对FLV adobe 官方标准有个认识，因为HTTP-FLV协议中封装格式使用的是FLV。FLV文件格式标准是写F4V/FLV fileformat spec v10.1的附录E里面的FLVFile Format。
115

126

137

8+
FLV（Flash Video）是Adobe公司设计开发的一种流行的流媒体格式，其格式相对简单轻量，不需要很大的媒体头部信息。整个FLV由Header和Body以及其他Tag组成。因此加载速度极快。它是基于HTTP/80传输，可以避免被防火墙拦截的问题，除此之外，它可以通过 HTTP 302 跳转灵活调度/负载均衡，支持使用 HTTPS 加密传输，也能够兼容支持 Android，iOS 的移动端。但是由于它的传输特性，会让流媒体资源缓存在本地客户端，在保密性方面不够好，因为网络流量较大，它也不适合做拉流协议。此外，FLV可以使用Flash Player进行播放，而Flash Player插件已经安装在绝大部分浏览器上，这使得通过网页播放FLV视频十分容易。FLV封装格式的文件后缀通常为“.flv”。
149

1510

16-
FLV（Flash Video）是Adobe公司设计开发的一种流行的流媒体格式，由于其视频文件体积轻巧、封装简单等特点，使其很适合在互联网上进行应用。此外，FLV可以使用Flash Player进行播放，而Flash Player插件已经安装在绝大部分浏览器上，这使得通过网页播放FLV视频十分容易。FLV封装格式的文件后缀通常为“.flv”。
17-
18-
在说HTTP-FLV之前，我们有必要对FLV adobe 官方标准有个认识，因为HTTP-FLV协议中封装格式使用的是FLV。
19-
20-
FLV文件格式标准是写F4V/FLV fileformat spec v10.1的附录E里面的FLVFile Format。
2111

12+
先看看HTTP-FLV长成什么样子：http://ip:port/live/livestream.flv，协议头是http,另外”.flv”这个尾巴是它最明显的特征。
2213

14+
HttpFlv 就是 http+flv ，将音视频数据封装成FLV格式，然后通过 HTTP 协议传输给客户端。
2315

24-
Flash Video`:是Adobe公司推出的另一种视频格式，是一种在网络上传输的流媒体数据存储容器格式。其格式相对简单轻量，不需要很大的媒体头部信息。整个FLV由Header和Body以及其他Tag组成。因此加载速度极快。它是基于HTTP/80传输，可以避免被防火墙拦截的问题，除此之外，它可以通过 HTTP 302 跳转灵活调度/负载均衡，支持使用 HTTPS 加密传输，也能够兼容支持 Android，iOS 的移动端。但是由于它的传输特性，会让流媒体资源缓存在本地客户端，在保密性方面不够好，因为网络流量较大，它也不适合做拉流协议。
2516

2617

18+
下的直播平台中大部分的主线路使用的都是HTTP-FLV协议，备线路多为RTMP。小编随便在Safari中打开几个直播平台房间，一抓包就不难发现使用HTTP-FLV协议的身影：熊猫、斗鱼、虎牙、B站。
2719

2820

2921

@@ -37,7 +29,14 @@ HTTP FLV伪流：支持SEEK，可从未下载的部分开始播放。
3729

3830
HTTP-FLV流：拥有和流式协议RTMP一样的特征，长连接，流式数据。
3931

32+
#### 4 优点：
33+
34+
- 服务器兼容性好：基于 HTTP 协议。
35+
- 低延迟：直接传输 FLV 流，而且基于 HTTP 长链接。
36+
37+
#### 5 缺点：
4038

39+
- 播放端兼容性不好：需要 Flash 支持，不支持多音视频流，不便于 Seek。
4140

4241
▣ HTTP-FLV技术实现
4342

0 commit comments

Comments
 (0)