jackyhee
diff --git a/‎VideoDevelopment/流媒体协议/DASH.md‎
Lines changed: 12 additions & 74 deletions b/‎VideoDevelopment/流媒体协议/DASH.md‎
Lines changed: 12 additions & 74 deletions
diff --git a/‎VideoDevelopment/流媒体协议/HLS.md‎
Lines changed: 21 additions & 6 deletions b/‎VideoDevelopment/流媒体协议/HLS.md‎
Lines changed: 21 additions & 6 deletions
@@ -2,7 +2,9 @@
 
 除了前面讲的Apple的HLS，还有Adobe HTTP Dynamic Streaming (HDS)、Microsoft Smooth Streaming (MSS)。他们各家的协议原理大致相同，但是格式又不一样，也无法兼容，所以Moving Picture Expert Group (MPEG) 就把大家叫到了一起，呼吁大家一起来制定一个标准的，然后就有了[MPEG-DASH](https://www.encoding.com/mpeg-dash/),它的主要目标是形成IP网络承载单一格式的流媒体并提供高效与高质量服务的统一方案，解决多制式传输方案(HTTP Live  Streaming, Microsoft Smooth Streaming, HTTP Dynamic  Streaming)并存格局下的存储与服务能力浪费、运营高成本与复杂度、系统间互操作弱等问题。
 
-[DASH(MPEG-DASH)](https://mpeg.chiariglione.org/standards/mpeg-dash/)全称为Dynamic Adaptive Streaming over HTTP.是由MPEG和ISO批准的独立于供应商的国际标准，它是一种基于HTTP的使用TCP传输协议的流媒体传输技术。MPEG-DASH是一种自适应比特率流技术，可根据实时网络状况实现动态自适应下载。和HLS, HDS技术类似， 都是把视频分割成一小段一小段，  通过HTTP协议进行传输，客户端得到之后进行播放；不同的是MPEG-DASH支持MPEG-2 TS、MP4(最新的HLS也支持了MP4)等多种格式,  可以将视频按照多种编码切割, 下载下来的媒体格式既可以是ts文件也可以是mp4文件，MPEG—DASH技术与编解码器无关，可使用H.265，H.264，VP9等任何编解码器进行编码。
+[DASH(MPEG-DASH)](https://mpeg.chiariglione.org/standards/mpeg-dash/)全称为Dynamic Adaptive Streaming over HTTP.是由MPEG和ISO批准的独立于供应商的国际标准，它是一种基于HTTP的使用TCP传输协议的流媒体传输技术。它诞生的目的是为了统一标准，因此是兼容SmoothStreaming和HLS的.同时支持TS profile和 ISO  profile，支持节目观看等级控制，支持父母锁. mpeg  dash支持的DRM类型包括PlayReady和Marlin，而HLS支持的是AES128（密钥长度为128位的高级加密标准Advanced  Encryption Standard）加密类型。
+
+MPEG-DASH是一种自适应比特率流技术，可根据实时网络状况实现动态自适应下载。和HLS, HDS技术类似， 都是把视频分割成一小段一小段，  通过HTTP协议进行传输，客户端得到之后进行播放；不同的是MPEG-DASH支持MPEG-2 TS、MP4(最新的HLS也支持了MP4)等多种格式,  可以将视频按照多种编码切割, 下载下来的媒体格式既可以是ts文件也可以是mp4文件，MPEG—DASH技术与编解码器无关，可使用H.265，H.264，VP9等任何编解码器进行编码。
 
 安卓平台上的ExoPlayer支持MPEG-DASH。另外，三星、索尼、飞利浦、松下的一些较新型号的智能电视支持MPEG—DASH。Google的Chromecast、YouTube 和Netflix 也已支持MPEG-DASH。
 
@@ -123,80 +125,28 @@ Segments可以包含任何媒体数据，关于容器，官方提供了两种建
 
 
 
-## fMP4
-
-[MP4和fMP4的详细介绍](https://github.com/CharonChui/AndroidNote/blob/master/VideoDevelopment/MP4%E6%A0%BC%E5%BC%8F%E8%AF%A6%E8%A7%A3.md)
-
-
-
-fMP4（fragmented MP4），可以简单理解为分片化的MP4，是DASH采用的媒体文件格式，文件扩展名通常为（.m4s或直接用.mp4）。     
-
-![fMP4](https://img-blog.csdn.net/20171107114807709?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQveXVlX2h1YW5n/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/SouthEast)
-
-
-
-### fMP4与ts的区别
-
-最主要的就是.ts文件不提供关于时长等信息，你无法在ts文件中去实现音视频的seek操作。fmp4不同于ts，它是提供了时长等信息，可以执行seek到指定位置。
-
-
-
-### 媒体数据与元数据的分离
-
-在mp4格式中，元数据可以和媒体数据很好地分开存储，后者都在mdat box中，而在ts中，诸多es流和header/metadata信息是复用在一起的。
- 元数据的分离允许我们在streaming中先读取各个流的元数据，知道他们的媒体内容的属性（比如不同的视频质量、不同的语言等），从而可以更好地在不同的media data之间做自适应切换。
- 当然，在更实际的应用场景中，比如在dash协议中会直接把这些元数据信息写在mpd中，player可以只读一个mpd就知道各个媒体数据的属性
-
-### 各个Track独立存储
-
-在fmp4中，不仅媒体数据和metadata相互独立的存储，音视频track的数据也可以分开存储，这里的“分开”已经不仅仅局限于box层面的分开，而是真的可以分开存储于不同的目录。在这种情况下，player只需要读一个记录了它们各自存储位置的manifest，即可去对应的位置download它们的分片，只要做好音视频分片之间的同步工作，就可以正常的播放。
- 举个例子，下面是一个dash中常见的mpd：
-
-在这个mpd中我们看到视频的分片都是存储在video/1/这个目录下，而音频分片都存储在audio/und/mp4a/1这个目录下，而player还是可以将它们拼接到一起完成播放。
- 相对地，在streaming TS流时，音视频往往是复用在一起的，以HLS这个应用场景为例的话，server端一定还需要提前将TS切片做好，这样就会带来几个问题：
-
-1. 媒体文件存储成本和媒资管理成本增加
-    假设server端将video track编码为三个质量级别V1, V2, V3，audio track也被编码为三个质量级别A1, A2,  A3，那么如果利用fmp4格式的特性，我们只需要存储这6份媒体文件，player在播放时再自主组合不同质量级别的音视频track即可。而对于TS，则不得不提前将3x3=9种不同的音视频复用情况对应的媒体文件都存储到server端，平白无故多出三份文件的存储成本。实际中，因为要考虑到大屏端、小屏端、移动端、桌面端、不同语言、不同字幕等各种情况，使用TS而造成的冗余成本将更加可观。同时，存储文件的增加也意味着媒资管理成本的增加。这也是包括Netflix在内的一些公司选择使用fmp4做streaming格式的原因。
-2. manifest文件更加复杂
-    fmp4格式的特性可以确保每一个单独的媒体分片都是可解密可解码的（当然player需要先从moov  box中读到它们的编解码等信息），这意味着server端甚至根本不需要真的存储一大堆分片，player可以直接利用byte range  request技术从一个大文件中准确地读出一个分片对应的media data，这也使得对应manifest(mpd)文件可以更加简洁，如下：
 
-针对不同语言的音频，都只需要存一个大文件就够了。
-相对地，在streaming TS流时，不得不在manifest（m3u8）文件中把成百上千个ts分片文件全都老老实实地记录下来。
 
-所以Dash同样可以支持下面的操作: 
 
-- 音频视频分离，在后台播放时可以只拉取音频
-- 支持多音轨，多视频轨，多字幕任意切换
 
-### 服务器的cache效率会降低
- 实际的streaming应用场景中，往往需要cdn的支持，经常会被client请求的媒体分片就会存在距离client最近的edge  server上。对于fmp4 streaming的情况，因为需要的文件更少，cache命中率也就更高，举个例子：可能某一个audio  track会和其他各种video track组合，那么就可以将这个audio track放在edge server上，而不用每次都跟origin server去请求。
- 相对地，在streaming TS流时，因为每一个音视频组合的都需要以复用文件的形式存储，组合数又非常多，相当于分母大了，edge server就会有很大的几率没有缓存需要的组合而要去向orgin server请求。
+### HLS vs DASH
 
-### 对Trick-play的支持
 
-所谓Trick-play，就是快进、快退、直接跳到章节起点、慢动作播放这些“花式”播放功能。支持这些功能往往意味着要快速找到播放流中的关键帧，以快进播放为例，如果利用fmp4格式的特点，可以通过只读取每个媒体分片的moof加上mdat的起始（包含了关键帧图像）部分即可，说白了就是通过只显示关键帧的方法达到“快进”的视觉效果。因为fmp4格式中可以保证每一个分片一定是以IDR帧开始的，这就使得上述的方案实现起来非常方便。
- 相对地，在streaming TS流时，没有办法保证关键帧一定在什么位置，所以你可能需要解析一大堆TS packets才能找到关键帧的位置。
 
-### 无缝码流切换
+- 在标准HTTP服务器上的用法： HLS和DASH均可在常规HTTP服务器（例如Nginx，Apache等）上使用。
+- 多个音频通道: 特别是对于多语言内容，重要的是能够在各个语言的不同音频通道之间进行切换。 DASH和HLS都可以做到这一点。
+- 字幕和标题: 为了给视频添加字幕，通常创建一个单独的文件，例如，文件可以具有WebVTT格式。然后从清单（即.m3u8或.mpd文件）中引用该文件。
+- 插入广告: 通常，可以在HLS和DASH的实时流中插入广告。为此，只需交换单个视频块。 DASH为此提供了一种有效的方法：标准化的界面允许有效地插入广告。
+- 快速频道切换: 您可以在各个通道之间切换的速度取决于最大的子段（块）。块越小，通道更改速度越快。正如引言中已经提到的，HLS块通常长约10秒，而DASH块通常长2至4秒。因此，DASH在这方面领先一步。小块还具有降低代码效率的缺点。具有较小块的播放列表必须比具有较大块的播放列表更频繁地更新。这意味着包含较短视频片段的播放列表必须通过HTTP更频繁地更新。
 
-无缝码流切换实现的关键在于：当第一个码流播放结束时，也就是发生切换的时间，第二个码流一定要以关键帧开始播放。在streaming  TS流时，因为不能保证每一个TS  chunk一定以关键帧开始，做码流切换时就意味着要同时download两个码流的相应分片，同时解析两个码流，然后找到关键帧对应的位置，才能切换。同时下载、解析两个码流的媒体内容对网络带宽以及设备性能都形成了挑战。而且有意思的是，如果当前网络环境不佳，player想要切换到低码率码流，结果还要在本来就不好的网络环境下同时进行两个码流的下载，可谓是雪上加霜。
- 而在fmp4中，除了保证各个分片一定以IDR帧开始外，还能保证不同码流的分片之间在时间线上是对齐的。而且streaming  fmp4流时因为不要求音视频复用存储，也就意味着视频和音频的同步点可以不一样，视频可以全都以GOP边界作为同步点，音频可以都以sync  frame作为同步点，这都使得无缝码流切换更简单。
 
-### 与DRM的集成
-
-所谓DRM即数字版权管理，说白了就是对流进行加密，这东西在国内用的不多，但是在国外可是每一个内容提供商必须要有的东西。和编码标准一样，业界也存在很多DRM方案，为了避免每采用一个新的加密方案就要重新编一个码流，MPEG推出了通用加密（CENC）标准（23001-7 - Common Encryption）。使用这一标准的码流，就可以将一个码流应用于各种不同的DRM方案。在DASH  spec中，也定义了Content Protection字段来对应这种加密方案。
- CENC使用的就是fMP4格式，这是利用了fMP4中音视频可以不复用同时还能提供独立于media data存储的metadata的特点。TS流就享受不了这样的好处了。
-
-DASH和HLS之间的另一个关键区别是它支持DRM。可是，在DASH中不存在一个单一通用的DRM解决方案。例如，Google的Chrome支持Widevine，而Microsoft的Internet  Explorer支持PlayReady。然而，通过使用MPEG-CENC（MPEG通用加密）结合加密媒体扩展（EME），视频流内容可以仅被加密一次。HLS支持AES-128加密，以及苹果自己的DRM，Fairplay。
 
 
 
 ### 测试流
 
 - HEVC HLS with fMP4: [http://bitmovin-a.akamaihd.net/content/dataset/multi-codec/hevc/stream_fmp4.m3u8](https://bitmovin-a.akamaihd.net/content/dataset/multi-codec/hevc/stream_fmp4.m3u8)
 
-    
-
 - HEVC HLS with TS (not supported by Apple): [http://bitmovin-a.akamaihd.net/content/dataset/multi-codec/hevc/stream_ts.m3u8](https://bitmovin-a.akamaihd.net/content/dataset/multi-codec/hevc/stream_ts.m3u8)
 
     [https://bitmovin-a.akamaihd.net/content/playhouse-vr/m3u8s/105560.m3u8](https://bitmovin-a.akamaihd.net/content/playhouse-vr/m3u8s/105560.m3u8)
@@ -213,23 +163,11 @@ DASH和HLS之间的另一个关键区别是它支持DRM。可是，在DASH中不
 
 参考:  
 
-[HLS，MPEG-DASH - What is ABR?](http://telestreamblog.telestream.net/2017/05/what-is-abr/)
-
-[B站我们为什么使用DASH](https://www.bilibili.com/read/cv855111)
-
-
-
-
-
-
-
-
-
-
-
-
+- [HLS，MPEG-DASH - What is ABR?](http://telestreamblog.telestream.net/2017/05/what-is-abr/)
 
+- [B站我们为什么使用DASH](https://www.bilibili.com/read/cv855111)
 
+- [Adaptive HTTP Streaming Technologies: HLS vs. DASH](https://strivecast.io/hls-vs-mpeg-dash/)
 
 
 
 
@@ -11,11 +11,23 @@ HLS协议规定:
 HLS协议由三部分组成:  
 
 - HTTP:传输协议
-- m3u8:索引文件
+- m3u8:索引文件(m3u8 文件本质说其实是采用了编码是 UTF-8 的 m3u 文件。)
 - TS:音视频媒体信息
 
 HLS点播，基本上就是常见的分段HTTP点播，不同在于，它的分段非常小。相对于常见的流媒体直播协议，例如RTMP协议、RTSP协议、MMS协议等，HLS直播最大的不同在于，直播客户端获取到的，并不是一个完整的数据流。HLS协议在服务器端将直播数据流存储为连续的、很短时长的媒体文件（MPEG-TS格式），而客户端则不断的下载并播放这些小文件。因为服务器端总是会将最新的直播数据生成新的小文件，这样客户端只要不停的按顺序播放从服务器获取到的文件，就实现了直播。由此可见，基本上可以认为，HLS是以点播的技术方式来实现直播。由于数据通过HTTP协议传输，所以完全不用考虑防火墙或者代理的问题，而且分段文件的时长很短，客户端可以很快的选择和切换码率，以适应不同带宽条件下的播放。不过HLS的这种技术特点，决定了它的延迟一般总是会高于普通的流媒体直播协议。它也解决了RTMP协议存在的一些问题，例如RTMP协议不使用标准的HTTP接口传输数据(TCP、UDP端口)，所以在一些特殊的网络环境下可能被防火墙屏蔽掉，而HLS使用的是HTTP协议传输数据(80端口)，不会遇到被防火墙屏蔽的情况。
 
+
+
+### HLS架构
+
+HLS的架构分为三部分：Server，CDN，Client 。即服务器、分发组件和客户端。
+
+下面是 HLS 整体架构图：
+
+<img src="https://raw.githubusercontent.com/CharonChui/Pictures/master/transport_stream_2x.png" style="zoom:50%;" />
+
+
+
 ## TS
 
 TS(Transport Stream)，全程为MPEG2-TS。它的特点就是要求从视频流的任一片段开始都是可以独立解码的。DVD节目中的MPEG2格式，确切的说是MPEG2-PS，全程是Program Stream，而TS的全称是Transport Stream。MPEG2-PS主要应用于存储的具有固定市场的节目，如DVD电影，而MPEG2-TS则主要应用于实时传送的节目，比如实时广播的电视节目。这两种格式的主要区别是什么呢？简单地打个比喻说，你将DVD上的[VOB](https://baike.baidu.com/item/VOB)文件的前面一截cut掉（或者干脆就是数据损坏），那么就会导致整个文件无法解码了，而电视节目是你任何时候打开电视机都能解码（收看）的，所以，MPEG2-TS格式的特点就是要求从[视频流](https://baike.baidu.com/item/视频流)的任一片段开始都是可以独立解码的。
@@ -27,7 +39,7 @@ TS(Transport Stream)，全程为MPEG2-TS。它的特点就是要求从视频流
 - 是一个索引地址/播放列表，通过FFmpeg将本地的xxx.mp4进行切片处理，生成m3u8播放列表（索引文件）和N多个  .ts文件，并将其（m3u8、N个ts）放置在本地搭建好的webServer服务器的指定目录下，我就可以得到一个可以实时播放的网址，我们把这个m3u8地址复制到 VLC 上就可以实时观看！ 在 HLS 流下，本地视频被分割成一个一个的小切片，一般10秒一个，这些个小切片被 m3u8管理，并且随着终端的FFmpeg  向本地拉流的命令而实时更新，影片进度随着拉流的进度而更新，播放过的片段不在本地保存，自动删除，直到该文件播放完毕或停止，ts  切片会相应的被删除，流停止，影片不会立即停止，影片播放会滞后于拉流一段时间
 
 
-<img src="https://raw.githubusercontent.com/CharonChui/Pictures/master/transport_stream_2x.png" style="zoom:50%;" />
+
 
 - Media encoder(媒体编码)
 
@@ -138,16 +150,19 @@ cctv1hd-1585920074000.ts
 
 ## HLS 的劣势
 
-- 相比 RTMP 这类长连接协议, 延时较高, 难以用到互动直播场景.HLS 理论延时 = 1 个切片的时长 + 0-1个 td (td 是 EXT-X-TARGETDURATION, 可简单理解为播放器取片的间隔时间) + 0-n 个启动切片(苹果官方建议是请求到 3 个片之后才开始播放) + 播放器最开始请求的片的网络延时(网络连接耗时)。为了追求低延时效果, 可以将切片切的更小, 取片间隔做的更小, 播放器未取到 3 个片就启动播放. 但是, 这些优化方式都会增加 HLS 不稳定和出现错误的风险.
+- 相比 RTMP 这类长连接协议, 延时较高, 难以用到互动直播场景.HLS 理论延时 = 1 个切片的时长 + 0-1个 td (td 是 EXT-X-TARGETDURATION, 可简单理解为播放器取片的间隔时间) + 0-n 个启动切片(苹果官方建议是请求到 3 个片之后才开始播放) + 播放器最开始请求的片的网络延时(网络连接耗时)。为了追求低延时效果, 可以将切片切的更小, 取片间隔做的更小, 播放器未取到 3 个片就启动播放. 但是, 这些优化方式都会增加 HLS 不稳定和出现错误的风险.通常 HLS 直播延时会达到 20-30s，而高延时对于需要实时互动体验的直播来说是不可接受的。
 - 对于点播服务来说, 由于 TS 切片通常较小, 海量碎片在文件分发, 一致性缓存, 存储等方面都有较大挑战.
+- HLS 基于短连接 HTTP，HTTP 是基于 TCP 的，这就意味着 HLS 需要不断地与服务器建立连接，TCP 每次建立连接时的三次握手、慢启动过程、断开连接时的四次挥手都会产生消耗。
 
 
 
 
 
-
-
-
+CCTV1高清：http://ivi.bupt.edu.cn/hls/cctv1hd.m3u8
+CCTV3高清：http://ivi.bupt.edu.cn/hls/cctv3hd.m3u8
+CCTV5高清：http://ivi.bupt.edu.cn/hls/cctv5hd.m3u8
+CCTV5+高清：http://ivi.bupt.edu.cn/hls/cctv5phd.m3u8
+CCTV6高清：http://ivi.bupt.edu.cn/hls/cctv6hd.m3u8