downgoon / -mpeg2-ts-howto Goto Github PK

互动聊天：WebRTC + WebSocket

To make it easier to explain how WebSockets works together with WebRTC, we can use the following diagram:

1. John calls William. His information is sent along with the request
2. The WebSocket server asks William if he wants to answer John’s call. William receives John’s information
3. William accepts and answers John’s call. His information is sent along with the response
4. John receives William’s information
5. WebRTC establish the peer to peer communication

上图非常重要的一点：连接建立的过程需要借助服务器，但是视频/语音通话就不再需要服务器了，而是浏览器对浏览器的直连。不仅降低了通话时延，提高了实时性；而且给服务器 节省了带宽，降低了企业运营成本。

体验

使用WebRTC功能，开发者只需要用javascript编程，调用浏览器内置的API。现在支持WebRTC的浏览器有Chrome，Firefox和Opera。Safari和IE暂不支持。

WebRTC则实现了浏览器在无需插件的情况下对实时视频通讯的支持。WebRTC包含有三个组件：访问用户摄像头及麦克风的getUserMedia，穿越NAT及防火墙建立视频会话的PeerConnection，以及在浏览器之间建立点对点数据通讯的DataChannels。Google的WebRTC视频聊天演示。

参考资料

• webrtc 国内社区
• how-to-build-a-chat-based-application-with-webrtc-websockets

现在主流的CDN厂商对视频都支持Time Seeking了。Apache Traffic Server（CDN缓存开源方案）也支持MP4 Plugin来实现MP4 Time Seeking。

https://docs.trafficserver.apache.org/en/latest/admin-guide/plugins/mp4.en.html

This module provides streaming media server support for MP4 files. User can send a HTTP request to the server with start argument which is measured in seconds (NOT in binary offset), and the server will respond with the stream such that its start position corresponds to the requested time, for example:

http://v.foo.com/dota2.mp4?start=290.12

This allows performing a random seeking at any time. We can use flash player, vlc, mplayer, firefox or chrome to play the streaming media.

Note

This plugin requires that the moov box in the mp4 file should be ahead of mdat box.

备注：对于moov在mdat后面的，需要改写到前面。也有公开的工具支持，比如qt-faststart。

It is not a good idea to cache a large mp4 file, many video sites will cut a large video file into many small mp4 files, and each small mp4 file will be less than 80M(bytes), it will be a reasonable choice.

另外在nginx上也有插件支持mp4 seeking: http://nginx.org/en/docs/http/ngx_http_mp4_module.html

关于HLS播放器，你需要知道的：

• safari浏览器内核默认支持：HLS是Apple公司发明的，在safari浏览器中直接填写.m3u8的文件地址，就能直接播视频。当然也可以用HTML5的<video>标签播。

• H5的<video>标签直接播放是误传：有人说，H5的<video>标签能直接播放HLS的视频，其实是误传。在safari浏览器中，的确是对的。但是并不是所有支持H5的浏览器都支持，比如chrome和firefox即使支持H5，但默认都无法播放HLS。

• 如何在支持H5的 所有 浏览器中播放HLS呢？safari默认支持，其他（比如：chrome，firefox和IE10以上），需要额外的第三方js库支持。比如： 排名第一的hls.js 和 第二的 videojs/videojs-contrib-hls

• 如何在IE浏览器中播放HLS呢？ IE10及其以上版本，都支持H5了，可以用前一个方法播。但市面上IE8和IE6的份额依然较大，而它们都不支持H5，通常需要借助广泛使用的Flash来播放。比如：sewise-player 等。

• 转码后播放：市面上还有一些在服务端先转码，后在浏览器上以WebSocket + canvas 播放的。

浏览器播/放器矩阵

尽管看上去，sewise-player 所有都支持，但是需依赖Flash，作者并不推荐它。hls.js 和 videojs-contrib-hls 在H5环境，都能播放，但是笔者的使用经验，当视频时长超过4小时时（.m3u8超过4小时，比如24小时监控领域），videojs-contrib-hls 的拖拽seeking定位会错位。所以，三个播放器，笔者更加推崇 hls.js。

其他未实测的播放器

• JWplayer
• THEOplayer: Universal Video Player – Reach your viewers on every device
• chimee: 国产开源，677个star
• CKplayer: 国产播放器，教程丰富
• flashls: Flash HLS

单个轨道结构

以视频为例，我们将视频压缩成的H264码流，可以称作为ES流，它有很多个帧，将其 每帧 打包变为PES流，再将PES流拆分成多个 188字节，称为TS流。

“对应关系” 简单理解：H264视频流 -> m个帧 -> n个ts

• 疑问1：难道每个ts流都是188字节？那为什么有的.ts只有5s，有的可以是2分钟呢？

1. 划分若干个帧

• 一段ES流= N个 帧（就是第2行中的数据）
• 1个帧 = 1 PES_payload
• 1PES = 1PES包头 + 1 PES_payload

2. 每个帧切分成若干ts流

标题说每个帧切分成若干ts流，确切来讲应该是：每个PES包，切分成多个ts块（1PES 切成N段，每段组成一个TS包的负载。）。
就是图中从第3行变到第4行的过程。

3. 三大类五小类ts

• 头部类ts：最开始的TS包由 TS包头(图中有T标志的) + PES 包头(草绿色) + PES_payload（白色） 组成

• 尾部类ts：最末尾的TS包由 TS包头(图中有T标志的) + 自适应字段（橙色）+ PES_payload（白色） 组成

• 中间类ts: 头尾TS包很简单，中间很复杂。经过血的教训，发现其由3种包组成，出现位置随机，每种出现的概率不相同，如下：

  • 第一种 TS包头(图中有T标志的) + 自适应字段（橙色）+ PES_payload（白色），出现概率 1%
  • 第二种 TS包头(图中有T标志的) + 自适应字段（橙色）出现概率 0.1%
  • 第三种 TS包头(图中有T标志的) + PES_payload（白色）出现概率 98.9%

多个轨道描述

一个“节目”通常有：视频轨道，音频轨道和文本轨道组成。

PSI(节目特定信息) 分为PAT(节目相关表)和PMT(节目映射表)
1个PAT表中包含N个PMT表的索引信息
而1个PMT表中又包含 视频PES, 音频PES 等索引信息。

小结： 1个PAT -> N个 PMT -> 视频PES + 音频PES + 文本PES

PAT与PMT

TS Package

参考资料

• mpeg2-ts协议分析
• HLS介绍

http://www.codeweblog.com/tsparser-java-mpeg2-analyzer/

github地址：https://github.com/downgoon/TSParser/wiki/HowToRun

点播样例

版本3的样例：

• 原文

   #EXTM3U
   #EXT-X-TARGETDURATION:10
   #EXT-X-VERSION:3
   #EXTINF:9.009,
   http://media.example.com/first.ts
   #EXTINF:9.009,
   http://media.example.com/second.ts
   #EXTINF:3.003,
   http://media.example.com/third.ts
   #EXT-X-ENDLIST

• 解析

   #EXTM3U
   #EXT-X-TARGETDURATION:10   // 最长ts的时长，表示后续所有ts的时长不会超过10秒。
   #EXT-X-VERSION:3 // 版本3，市面多见版本3和6
   #EXTINF:9.009,   // 具体某个ts的时长声明，末尾的逗号可要可不要，不同播放器容错性不一样
   http://media.example.com/first.ts // 具体某个ts的文件存储地址
   #EXTINF:9.009,
   http://media.example.com/second.ts
   #EXTINF:3.003,
   http://media.example.com/third.ts
   #EXT-X-ENDLIST  // 最后一个结束tag，标识点播文件的末尾。必不可少！！！

直播文件

• 原文

   #EXTM3U
   #EXT-X-VERSION:3
   #EXT-X-TARGETDURATION:8
   #EXT-X-MEDIA-SEQUENCE:2680

   #EXTINF:7.975,
   https://priv.example.com/fileSequence2680.ts
   #EXTINF:7.941,
   https://priv.example.com/fileSequence2681.ts
   #EXTINF:7.975,
   https://priv.example.com/fileSequence2682.ts

• 解析

   #EXTM3U
   #EXT-X-VERSION:3
   #EXT-X-TARGETDURATION:8  // 最大ts的时长（单位：秒），虽说是最大的，但更确切表示服务端按8秒左右来切分。
   #EXT-X-MEDIA-SEQUENCE:2680  // 第一个ts的序号：很重要，在直播时，播放器看到这个就表示是直播（同时末尾没有 #EXT-X-ENDLIST），然后就会每8秒左右轮询本文件（因为所有ts大概是8秒一个）。第二次请求时，比对 #EXT-X-MEDIA-SEQUENCE，如果出现更大的，说明有新的ts流入，需要继续解析；否则，视为服务端没有新流，不继续解析。
       // 中间有个空行，可要可不要，一般播放器都会做兼容处理。
   #EXTINF:7.975,
   https://priv.example.com/fileSequence2680.ts
   #EXTINF:7.941,    // 跟点播比没有什么差别
   https://priv.example.com/fileSequence2681.ts
   #EXTINF:7.975,
   https://priv.example.com/fileSequence2682.ts
   // 点播末尾有 #EXT-X-ENDLIST，但直播没有。

参考资料

• draft-pantos-http-live-streaming-23#section-8: 官方关于m3u8的样例