视频编解码（51）
网络传输（15）
在中，我们重点介绍了HLS协议中M3U8文件里面和时间相关的一些字段，以及这些字段在不同平台MAC，Android上的一些应用，本文介绍一下HLS中TS文件里面和时间相关的字段。
一．TS介绍
TS，全称是Transport Stream，最早应用在数字电视系统中。数字电视的标准有三个，美国的ATSC，日本的ISDB和欧洲的DVB，我们国家大概在2001开始引入数字电视，采用的欧洲的DVB标准。在DVB标准中，对于编码后的音视频信息，使用TS格式进行封装，一般情况下，TS的格式的封包大小是188个字节，其中包括了4个字节的头信息和184字节的数据载荷（Payload），我们先简单了解一下TS的封装格式，如下所示：
TS头（4Bytes）
数据（184）
图1 TS格式
TS头4个字节包括了如下内容：
Sync byte(8bits)
Transport error(1bit)
Payload start indicator(1bit)
Transport priority(1bit)
PID(13bits)
Transport scrambling control(2bits)
Adaption field control(2bits)
Continuity counter(4bits)
其它红色部分，需要重点关注，也是我们今天讨论的重点。
Sync byte，同步字节，值为0x47，用来进行数据对齐，当连续5个188字节的首字节都是0x47，则认为数据已经同步，即数据可以进行正常的处理。
Payload start indicator，数据载荷起始指示符，数据载荷有两种，一是编码后的音视频数据，二是用户描述音视频信息的表格（PSI、SI），表格信息不是今天介绍的重点。顾名思义，起始指示符就是当每帧视音频数据或每次表格信息的第一个字节出现时，就把该位置1。
PID，在TS中，不同类型的信息，如视频，音频，不同的表格信息，都通过PID来进行区分，不同PID对应的信息类型在PSI，SI表格中描述。
Adaption field control：调整字段指示符。调整字段，它的作用有两个，一是用来传输PCR时钟（我们本文要讲的一个时间相关的参数），另外当数据载荷的长度不够184时，用来填充一些无效数据。
Continuity counter：连续计数，用来标识TS包的连续性，0x1~0xF循环，依次加1，对于相同PID的TS包，如果相依两个TS包的Continuity counter（Mod 0x10）差值不是1，则表示有丢包。
TS格式的设计的初衷是为了抗网络丢包，在网络传输的过程中，不管因为何种原因导致丢包，只要能够进行数据同步，后面的数据就可以进行正常的处理。
今天的重点是介绍HLS的TS中和时间相关的参数，对TS流其它信息感兴趣的话，可以参考一下ISO 13818-1的标准。
二 TS中时间相关的参数
1.DTS和PTS
编码后的视音频数据称为ES（Elementary Stream），在对ES进行解码显示，会遇到两个问题，一是这些数据什么时候应该解码，什么时候应该显示，对网络流，我们可以说接受到就解码，但因为网络抖动的原因也是出现数据传输不均匀，那就会解码随着网络的抖动时快时慢；二是音视频如何同步。为了解决上面两个问题，在对将ES打包成TS之前，首先在每帧音视频数据前面打个的解码时间（DTS）和显示时间（PTS），来告诉解码器每帧数据的解码时间和显示时间，打上PTS和DTS的ES称为PES。
为了提高时间精度，在TS中，PTS和DTS的时间单位不是毫秒，而是1/90000秒。
对于音频帧而言，正常情况下DTS和PTS相等，即解码后立即显示，因此只存放PTS即可。
对于视频帧而言，如果只有I帧和P帧，和音频相同处理，只存放PTS即可。但当出现B帧时情况就变得复杂起来了。假设有一组图像如下，进入编码器前如下图所示：
P110 P211P312P413P514P615P716
上标表示PTS,带两个B帧的编码情况后，编码后的输出如下：
P41310P21111P31212
P71613P51414P61515
下标表示DTS，红色为I帧，蓝色为P帧，绿色为B帧；图中P2和P3在编码时参考了P4，因此它们要等P4解码后才能解码。在这种情况下，对于I帧和P帧就需要同时存放DTS和PTS。
对于DTS和PTS有两点需要注意（不考虑达到最大值绕头的情况Wrap around）：
?&&DTS是一个单调递增数列。
?&&PTS必须不小于DTS，因为从逻辑上讲，只有解码之后再能显示。
关于DTS和PTS的模型也可以参考一下ISO-13818-1的文档。
上面提到DTS和PTS两个时间，有一个问题没有提到，这个时间参考基准是什么？系统时间吗？貌似也可以，把接收到第一个DTS时的系统时间和DTS做一个差值，然后每次比较时一下这个基准时间（当前系统时间+差值）和DTS或PTS，但是，处理过硬件时钟的同学都知道，每个时钟和每个时钟的晶振都会的差异，运行的时间越长，越偏差就会越大，因此需要进行校正，哪用谁来校正呢？在DVB标准中，把这个校正的时间称为PCR（ProgramClock Reference）,PCR放在了AdaptationField 中，它的精度更高，单位是1/秒。每当TS中出现PCR时，就要用这个PCR去校正一下我们之前的时间基准，从而达到和编码时的时钟一致。
在TS的传输过程中，一般DTS和PCR差值会在一个合适的范围，这个差值就是要设置的视音频Buffer的大小，一般情况下视频DTS和PCR的差值在700ms~1200ms之间，音频差值在200ms-700ms之间。
3.连续计数
Continuity counter ，在前面我们介绍过，是用来标识TS包的连续性，对于相同PID的TS包，它的连续计数值是逐个加1的。
4.TS文件名
在HLS标准中，对于TS命名没有规定，可以是合法的任意字符串，但是在实际的实现中，如果我们合理的对TS进行命名，也可以解决和时间相关的一些问题，推荐TS命名中至少包括毫秒级的系统UTC时间。这样的做的好处于，通过不同TS命名中UTC时间的差值和DTS的差值，我们可以用来判断网络传输是否存在慢速。当UTC的差值大于DTS的差值到一定阀值时，我们就可以认为发生了慢速。当然这个阀值要根据实际的情况进行设置，在这里不再赘述。
通过两篇文章的介绍，我们对HLS协议中和时间相关的一些字段进行了分析，了解这些参数的含意后，在对HLS直播过程的问题进行分析时，我们就可以重点观察一下这些和时间相关的参数的变化。
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：597786次
积分：5893
积分：5893
排名：第3404名
原创：77篇
转载：73篇
评论：150条
(1)(1)(1)(1)(1)(1)(1)(2)(2)(1)(2)(2)(2)(1)(1)(1)(1)(1)(1)(3)(4)(1)(3)(4)(7)(2)(6)(2)(1)(3)(2)(1)(1)(2)(10)(4)(3)(2)(1)(14)(2)(3)(1)(1)(4)(1)(2)(3)(5)(1)(6)(8)(2)(3)(2)(4)(3)1080人阅读
视频（13）
.tw/voice/95294
透過網路串流，讓使用者可即時存取直播或點播多媒體數位內容，是目前相當熱門的應用，其中，HLS協定和CDN的技術，扮演舉足輕重的角色，讓網站能夠負擔直播的功能與規模擴展
按讚加入iThome粉絲團
文/&|&發表
在現今的網路環境，基於CDN（Content& Delivery Network）來提供串流服務已成主流，不論是直播或是「點播（即隨選視訊－Video On Demand）」皆然。
直播指的是和內容來源同步播放，僅維持一定的時間差，像電視頻道或是實況轉播的節目，都是採用直播的形式。在直播的情況下，內容無法快轉或倒轉，只能隨著時間播放。
而點播就不同了，點播的內容，都是早就存在好的檔案，並不像直播內容，都是由直播內容來源即時的產生。也因此，二者運用的技術會有所差異。
在過去，直播不是透過即時的串流協定，就是透過P2P的即時串流來做到，理由之一，便是因為直播內容是即時產生，不方便事先產生一個靜態的檔案來供接收端取用。但目前使用CDN的方式來提供接收端存用，卻都是以靜態檔案的方式，因為，CDN的作用基本上，就是把靜態檔案分布到多個快取伺服器上去，以降低各地客戶端存取的延遲時間及分散流量。
HLS協定為HTTP提供網路內容直播技術
那麼直播要如何基於CDN來做到呢？要回答這個問題，就得從HLS說起了。
HLS（HTTP Live Streaming）通訊協定是由Apple所提出的，現在雖然尚未成為IETF的標準，但是因為主流的平臺，諸如iOS/Android等重要的手持裝置平臺，皆已支援，使得它儼然成為在業界流通的準標準了。
那什麼是HLS呢？簡單的來說，HLS就是一種基於HTTP協定之上的串流協定，而且可適用於即時的直播用途。
HTTP的基本運作原則，就是一個請求可以取得一個檔案。倘若想要取得一個不知道長度有多長的檔案，像即時的串流就是如此，它很有可能不只是不知道有多長，甚至，它不會有結束。過去，有些人會基於HTTP做一些Hacks，例如設一個非常大的檔案長度，來表示一個即時的串流。但是，有些多媒體檔案格式，在串流內容還沒結束時，形同檔案沒有完成，接收端也可能無法正確的剖析及使用。
所以，要怎麼運用HTTP來做直播呢？
HLS的核心想法，是將串流的內容切割成一個個短的片段，例如，如果是影音內容的話，就把內容切割成約十秒左右的片段。不一定要切成十秒，究竟要切成幾秒，還可以考慮其他的因素。通常，這十秒的片段的格式其容器（container）格式為MPEG-TS，所包裝的視訊格式為H.264 ，而音訊格式為AAC。因此，整個影音的內容，就會被切割成許許多多的小片段。
當支援HLS的播放器要播放時，是從一個 .M3U8格式的播放清單開始，在這個播放清單中，會有一連串的MPEG-TS檔案的網址。此時，播放器只需要逐一的取出每個MPEG-TS檔案的網址，並且透過HTTP協定持續取得每一個MPEG-TS檔案，就能夠持續的播放整個串流的內容。
有一點很重要的是，在播放器播放某個MPEG-TS檔案的內容時，它可以取得整個清單中更之後的MPEG-TS檔案，甚至做一定程度的預儲，這使得前一個MPEG-TS播放完成時，下一個MPEG-TS已經準備好了，因此可以達到流暢的播放。若是預儲的份量夠，則可以提供足夠的緩衝效果，來因應時有的網路傳輸速度短暫、不穩定情況。
正因為它是把整個串流的內容切割成多個小檔案，因此，得以實現即時的串流。
但說是即時，也不那麼的完全即時。因為，整個內容來源就算很快的完成格式的轉換、壓縮、及切割，客戶端也要載入起碼一個MPEG-TS，之後才能播放，也就是說，起碼也要再等十秒（若是單一個MPEG-TS切割成十秒的話），才能看到直播的內容。但是，絕大多數的應用情境，都可以接受一定程度的直播延遲，這使得HLS有機會成為網路串流直播的主要選項。
當初HLS選擇基於HTTP是個不錯的決定，怎麼說呢？第一個考量是，HTTP是一個「穿透率」比較好的協定，因為它是瀏覽網站時所需的協定，因此，許多防火牆都會開放HTTP通過。倘若是其他的串流協定，不見得就會出現在防火牆的開放清單中。
CDN技術的應用，協助快速擴展執行規模
此外，還有一個重要的好處，就是有許多擴展規模的技術，都是基於HTTP而做的，這是為了開發能承載高流量、大規模的網站而研發的，如今都可以運用在HLS服務的擴展規模之上，例如CDN就是其中之一。
當串流內容經過如上所描述的一連串程序，產生一個個MPEG-TS檔案之後，即可將它們送至CDN之上，接著再利用CDN的機制，將不同客戶端的來源，分配至不同的快取伺服器。如此一來，客戶端可以更就近、快速取得檔案，而流量也都不需要集中在特定的伺服器或機房，而可以分散掉，而分散化就是得到規模可擴充性的主要手段之一。
此外，同一個內容，還可以被編碼成不同的位元率（bitrate），也就是會提供不同的品質。因為透過網路連接上串流服務的客戶端，可能會有各種不同可能的連線頻寬，針對不同連線頻寬的客戶端，就可以藉此提供不同的品質，使得它們都可以流暢的觀看。
而使用HLS的好處之一，也包括了播放過程中，可因應客戶端連線頻寬變化而執行品質的調整。
當播放時，發現客戶端的頻寬持續不足的情況，便可以將它導向另一組位元率較低的MPEG-TS檔案，以提高它播放的流暢度，而這個轉換的動作，在HLS的設計下，是可以動態的進行。所以，你可以看得出來，這樣的設計，有助於行動裝置在多媒體串流的播放，因為行動裝置的連線品質通常變化動態，會比個人電腦來得還大。
所以，經過這樣的說明，就不難了解HLS和CDN之間的關聯性。倘若只有HLS，最終還是必須面臨傳統集中式架構的問題，即頻寬使用集中、無法分散的缺點。但正如前面所述及的，選擇了HTTP，等於選擇了為HTTP所開發出來的各種擴展規模的技術，包括CDN在內。這使得立足於CDN的HLS，有了優秀的規模可擴充性。
現在，許多雲端平臺都提供CDN的服務，例如Amazon的CloudFront，這更便於串流服務的提供者，因為只需將串流內容直接送往CDN，即可處理掉擴展服務規模的許多技術議題。在這裡，雲端的平臺技術，對即時串流服務，起了很大的作用。
應用HLS+CDN的成本不一定低
此外，即使不是即時的串流，也可以使用HLS+CDN的技術組合。也有不少「點播」的服務者，使用靜態檔案部署於CDN的方式，來提供點播的檔案，例如使用 .MP4 做為容器格式，內含H.264 及AAC格式的視訊及音訊。
這也行的通，但是MP4 的容器格式對播放器來說，需要多花點時間，才能取得相關的一些索引資訊，因此，在載入時間上就不像HLS那樣的短。在播放時，需要更多的時間才能開始收看。此外，這種方式在CDN上，會比HLS成本更高。
但HLS也並非毫無缺點，舉例來說，MPEG-TS格式的額外負擔比較重，因此，會提高整體傳輸時所需的位元率。
總而言之，HLS的設計搭上CDN基礎設施的愈趨完備，使得它成為目前多媒體串流服務的主流選項。以現在服務的品質及規模來看，這個組合會流行好一陣子。
最近支持了两个M3U8的高清点播服务，有些心得需要总结如下
问：为何点播要用M3U8来搞？存成一个文件不更好吗？
答：1. 下载速度：&一般下载对于高清视频总会出现观看不太流畅的问题（P2P除外）
&&&&& 2. 磁盘：高清点播长视频一般都是G级别的，对于大文件下载来说，单盘的IO压力较大。如果能在磁盘上将大文件打散分片存储,单盘IO将会大大缓解
& & & 3. 容错：下载或存储过程中，1G的文件中任一字节出错将导致 可能会导致改视频的失效，而被切成小碎片后，容错将变得相对简单，只需补全出错的切片即可。
& & &4. 分发：大文件分发起来相对小文件比较困难，下载耗时长，特别是在服务初期，源服务器需要承受极高的磁盘IO请求
& & &5. 简单：simple is beautiful~
问：CDN对m3u8点播需要做哪些支持？
答：受限于播放器与源站之间的交互行为的不确定性，给M3U8做缓存&加速服务时，最好先抓包 分析下 在播放器 与源站直接交互时的请求与响应头，这样会加速解决在经过CDN时遇到的故障。
& & &特别是需要注意：
&&&&& 1.源站明确告诉播放器哪些内容不能缓存，明确cache-control：no-cache的，尽量不要与源站配置一致，如可能影响到播放器的xml控制文件及M3U8文件（分析其内容是否会变化）
& & &2.长连接：源站与播放器直接的交互是开启长连接，Connection：keep-alive，如果是长连接的话，在拿wireshark 打开包时，点击follow stream时，将可以看到一个stream流中有多次GET请求及响应，一般的播放及拖拽卡顿，很有可能是长连接没有打开，注意开启&CDN设备到 播放器，及CDN到源站的长连接。这样可以将miss时对用户的体验降到最低。
问: M3U8支持中遇到的一些问题，及优化措施
答：1.提前预加载，获取所有m3u8列表，跑个脚本，先全部预加载到CDN设备上。比较土，但不影响后续观看体验。
& & &2.实时预加载，在CDN设备上首次获取M3U8文件时，在CDN端对M3U8进行解析，自行在CDN内部完成对视频文件的预热。相对更理想，但在CDN端做解析，会让M3U8从源站到客户端加大延迟。相对1来说稍复杂点。
总结：CDN视频加速夹在播放器与服务端，总是要揣摩播放器的一些行为，如果播放器与服务器之间没有啥隐晦的规则还好，反之将在联调之际灰常蛋疼。http://blog.chinaunix.net/uid--id-3804679.html
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：1309298次
积分：15234
积分：15234
排名：第564名
原创：160篇
转载：566篇
评论：103条
(3)(1)(3)(10)(3)(14)(4)(17)(7)(6)(6)(1)(2)(29)(2)(5)(2)(1)(1)(1)(4)(10)(2)(1)(5)(4)(3)(1)(11)(3)(3)(4)(6)(3)(6)(5)(26)(24)(10)(9)(8)(6)(4)(5)(19)(4)(6)(8)(10)(5)(3)(15)(13)(52)(5)(7)(5)(4)(3)(3)(2)(2)(1)(2)(2)(5)(2)(1)(5)(3)(19)(30)(10)(12)(4)(4)(1)(2)(15)(1)(3)(1)(7)(1)(7)(19)(6)(1)(1)(2)(3)(2)(1)(13)(2)(2)(8)(7)(17)(6)(13)(9)(7)(1)(2)(10)(11)(1)(1)仁济医院：如何实现四大院区的信息共享？
作者：HC3i中国数字医疗网
分类 : 比特网
　　“体量“一直是国内各大医院不能回避的话题。如何在体量增大的同时，解决孤岛问题，实现信息共享？上海交通大学医学院附属仁济医院(简称“仁济医院”)作为拥有四个院区、一个研究所的大型医院，与深度合作，利用其成熟可靠的LinuxONE解决，以全新平台完美化解信息系统中的各种不足，提升了医院综合实力。
　　医院历史悠久建设不遵循守旧
　　仁济医院建于1844年，是上海开埠后第一所西医医院。医院目前由东西南北四个院区和上海市肿瘤研究所组成，是一个学科门类齐全，集医疗、教学、科研于一体的综合性三级甲等医院。作为一所有着百年历史的仁济医院，在信息化建设方面，丝毫不显保守，结合相应的移动医疗应用软件，医生和护士通过实现了对患者的诊疗信息管理，不仅方便、效率高，而且降低了手写的出错率。
　　今天的仁济医院，信息化已经成为医疗的辅助和支撑手段，对医院的战略发展起到很大作用。年，仁济医院经历了大跃进式的发展，从东、西两个院区扩展到4个院区。随着医院的院区大面积扩张，信息系统的同步成为了仁济医院的信息化建设重点。
　　四大院区信息系统割裂问题显露
　　随着仁济医院的院区不断扩张、就医患者的增多，如何改变四个院区信息系统割裂、患者跨院区就医信息同步难、就医体验不佳等现状，成为了医院必须面对的问题。对于年门诊量约400万人次的仁济医院来说，系统的成本、性能、技术支持、性、稳定性是最关键的要素。可以说医院的信息化系统是关系到无数患者生命健康的大事，这意味着，必须保障每迅速、可靠、完整的在各个院区及子系统中传递。，对此LinuxONE显示出了成本可控、响应时间一致性、可扩展性、可用性等巨大的优势，成为医院最佳的选择。
　　医院为了避免医院和数量持续膨胀、成本上升等趋势，正基于LinuxONE的解决方案，搭建其多院区一体化基础信息平台架构。该架构将帮助仁济医院实现东西北三个园区一体化，建成一个HIS、电子病历+数据集成平台，改进医生和患者的使用体验。而LinuxONE也使仁济医院在无需改有应用架构的前提下，为未来的系统扩展预留了充足空间。
　　唯前瞻颠覆者 携世界前行
　　近日，以“唯前瞻颠覆者 携世界前行”为主题的IBM z Systems & LinuxONE前瞻者盛典在杭州举行。会上，IBM与上海仁济医院、江西银行等客户一起与在座嘉宾分享了最新的LinuxONE。
　　本次大会始终在强调“颠覆”，即前瞻者以远见颠覆科技，以雄心探索未来。“颠覆”是一种强大的力量，无论对于IT厂商、生态成员或是行业用户都是如此。颠覆是IBM持续升级大型主机和LinuxONE自有能力、交付更强大基础架构的主动力，是IBM与生态成员携手刷新固有合作方式、实现商业模式和技术成果创新的协同力，更是行业客户基于前瞻性转型方案、获得竞争先机的超越力。
　　凭借多重领先特性，IBM大型主机及LinuxONE将为包括医疗行业用户在内的各类行业用户在认知转型的历程中提供强大支持。大型主机及LinuxONE对大量非结构化数据的处理和分析能力能够为提供高速、安全的实时数据，其业界最高级别的安全性能够为企业的敏感数据提供良好保障。LinuxONE对于区块链、Spark等最新开源技术的支持则使企业能够利用性能升级的前沿科技。未来IBM也将多方携手，在挑战与机遇并存的认知时代下，不断颠覆创新。
[ 责任编辑：佚名 ]
比特网 09:26:36
带着朋友和机器人上月亮散步
比食人鱼更恐怖：长着人类牙齿的鱼
软件信息化周刊
比特软件信息化周刊提供以数据库、操作系统和管理软件为重点的全面软件信息化产业热点、应用方案推荐、实用技巧分享等。以最新的软件资讯，最新的软件技巧，最新的软件与服务业内动态来为IT用户找到软捷径。
商务办公周刊
比特商务周刊是一个及行业资讯、深度分析、企业导购等为一体的综合性周刊。其中，与中国计量科学研究院合力打造的比特实验室可以为商业用户提供最权威的采购指南。是企业用户不可缺少的智选周刊！
比特网络周刊向企业网管员以及网络技术和产品使用者提供关于网络产业动态、技术热点、组网、建网、网络管理、网络运维等最新技术和实用技巧，帮助网管答疑解惑，成为网管好帮手。
服务器周刊
比特服务器周刊作为比特网的重点频道之一，主要关注x86服务器，RISC架构服务器以及高性能计算机行业的产品及发展动态。通过最独到的编辑观点和业界动态分析，让您第一时间了解服务器行业的趋势。
比特存储周刊长期以来，为读者提供企业存储领域高质量的原创内容，及时、全面的资讯、技术、方案以及案例文章，力求成为业界领先的存储媒体。比特存储周刊始终致力于用户的企业信息化建设、存储业务、数据保护与容灾构建以及数据管理部署等方面服务。
比特安全周刊通过专业的信息安全内容建设，为企业级用户打造最具商业价值的信息沟通平台，并为安全厂商提供多层面、多维度的媒体宣传手段。与其他同类网站信息安全内容相比，比特安全周刊运作模式更加独立，对信息安全界的动态新闻更新更快。
新闻中心热点推荐
新闻中心以独特视角精选一周内最具影响力的行业重大事件或圈内精彩故事，为企业级用户打造重点突出，可读性强，商业价值高的信息共享平台；同时为互联网、IT业界及通信厂商提供一条精准快捷，渗透力强，覆盖面广的媒体传播途径。
云计算周刊
比特云计算周刊关注云计算产业热点技术应用与趋势发展，全方位报道云计算领域最新动态。为用户与企业架设起沟通交流平台。包括IaaS、PaaS、SaaS各种不同的服务类型以及相关的安全与管理内容介绍。
CIO俱乐部周刊
比特CIO俱乐部周刊以大量高端CIO沙龙或专题研讨会以及对明星CIO的深入采访为依托，汇聚中国500强CIO的集体智慧。旨为中国杰出的CIO提供一个良好的互融互通 、促进交流的平台，并持续提供丰富的资讯和服务，探讨信息化建设，推动中国信息化发展引领CIO未来职业发展。
IT专家新闻邮件长期以来，以定向、分众、整合的商业模式，为企业IT专业人士以及IT系统采购决策者提供高质量的原创内容，包括IT新闻、评论、专家答疑、技巧和白皮书。此外，IT专家网还为读者提供包括咨询、社区、论坛、线下会议、读者沙龙等多种服务。
X周刊是一份IT人的技术娱乐周刊，给用户实时传递I最新T资讯、IT段子、技术技巧、畅销书籍，同时用户还能参与我们推荐的互动游戏，给广大的IT技术人士忙碌工作之余带来轻松休闲一刻。}