流媒体协议-概念篇

在这篇文章中，首先将说明什么是 video streaming protocol；其次会讨论流协议（streaming protocl）和编解码器之间的区别；最后，将介绍五种常见的流协议

原则上，RTSP，RTMP，HTTP 都可以做直播和点播，但一般做 直播用 RTSP和RTMP，做点播用 HTTP。我们选用的是RTMP协议。

1. 什么是 video streaming protocol

先看一下什么是流视频协议，大多数数字视频是为了两件事情：存储和播放。要满足这样的需求，视频需要满足小文件和通用播放这两点。

大多数视频文件都不适合流式传输。流式传输需要将音视频分割成小块（chunk），将这些小块按顺序发送，并在接收时播放。如果正在直播则视频源来自于摄像机；否则，来自于文件。

流媒体协议是一种标准化的传递方法，用于将视频分解为多个块，将其发送给视频播放器，播放器重新组合播放。

这是对 streaming protocol 简单的总结，streaming protocl 协议涉及多方面，可以变得非常复杂。大部分流协议是码率自适应（adaptive bitrate）的，这项技术可以在任一时间为用户提供最佳质量视频。不同协议有不同优势，例如，延迟、数字版权管理（Digital rights management，简称DRB），支持平台数量。

1. 流协议和编、解码器区别

编、解码器（codec）指视频压缩技术。不同的编、解码器用于不同的目的。例如，Apple ProRes 一般用于编辑视频。H.264一般用于在线播放视频。即使不需要使用流式协议，视频也需要使用解编码器进行编码、解码。

视频格式（format）也容易引起疑惑。通常，视频格式指视频文件格式（container format）。常见 container format 包括 .mp4、.m4v、.avi、.mov等，container format 只是一个框（box），框中通常包含视频文件、音频文件和元数据。视频文件格式并不是流式的核心概念。

下面的例子有助于理解这些概念。假设你是商人，需要批量运输衣服（衣服就是视频）。编解码器就是将衣服压缩成捆以节省空间的机器。容器格式就是装压缩后衣服的集装箱。流协议就是将其运输到目的地的铁轨、信号灯和驾驶员。

很多 streaming protocol 只支持几种解编码器。

 

3. 六种常见流协议

现在，比较一下常见的视频流协议以及每种协议的适用情景。

3.1 Real-Time Messaging Protocol (RTMP)

RTMP 是一个古老的协议。RMTP 最初由 Macromedia 开发，后被 Adobe 收购，至今仍被使用。

由于 RTMP 播放视频需要依赖 Flash 插件。而 Flash 插件多年来一直受安全问题困扰，正在被迅速淘汰。因此，目前 RTMP 主要用于提取 stream。也就是，当设置解编码器将视频发送到托管平台时，视频将使用 RTMP 协议发送到 CDN，随后使用另一种协议（通常是HLS）传递给播放器。

何时使用 RTMP

RTMP 协议延迟非常低，但由于需要 Flash 插件，不建议使用该协议，但流提取是例外。在流提取方便，RTMP 非常强大，且几乎得到了普遍支持

3.2 Dynamic Adaptive Streaming over HTTP (MPEG-DASH)

MPEG-DASH 是最新的协议之一。尽管未被广泛使用，但该协议有一些很大的优势。

首先，MPEG-DASH 支持码率自适应。这意味着将始终为观众提供他们当前互联网连接速度可以支持的最佳视频质量。网络速度波动时 DASH 可以保持不间断播放。

其次，MPEG-DASH 几乎支持所有编解码器，还支持加密媒体扩展（Encrpted Media Extensions，简写EME）和媒体扩展源（Media Source Extension，简写MSE），这些扩展用于浏览器的数字版权管理标准API。

何时使用 MPEG-DASH

如今只有一些广播公司在使用，将来或许会成为标准技术。但由于兼容性问题，这样的时刻还没有到来。

3.3 Microsoft Smooth Streaming （MSS）

Microsoft smooth streaming 技术于2008年推出。如今，以 Microsoft 为重点的开发人员和在 Xbox 生态系统的开发人员仍在使用，除此之外已逐渐失去用户。

Smooth streaming 支持码率自适应，并且拥有强大的数字版权管理工具。

何时使用 Smooth Streaming

除非目标用户是 Xbox 用户，或计划只开发 Windows 平台的 app，否则，不推荐使用该协议。。

3.4 HTTP Dynamic Streaming (HDS)

Adobe 携带 HDS 再次进入了流协议世界。HDS 是 RTMP 的后继产品，也是依赖 Flash 的协议，但增加了码率自适应，并以高质量著称。

HDS 是延迟最低的流协议之一。但由于分段和加密操作，HDS 延迟并不如 RTMP 那样低。在流媒体体育比赛和其他重要事件中广受欢迎。

何时使用 HDS

通常，不建议使用 HDS。对于任何公司而言，采用基于 flash 的技术无法吸引用户，围绕 flash 搭建播放器不是一个好主意。

3.5 HTTP Live Streaming (HLS)

HTTP Live Streaming 是 Apple 实现的基于 HTTP 的自适应比特率流通信协议，使用 HLS 可以直播（live）和点播（on-demand）音、视频。由于 HLS 采用了 HTTP 协议，使用普通 web 服务器和内容分发网络（Content Delivery Network，简写 CDN）即可。HLS 专为可靠性而设计，可以根据网络状况动态播放当前可播放最佳质量音视频。

• 直播（Live broadcasts）和点播（video on demand，简写 VOD，即预录内容）。
• 具有不同比特率的多个备用流。
• 根据网络变化对流进行智能切换。
• 数据加密和用户身份验证。

下图显示了 HTTP Live Stream 的组成部分：

 

目前，iOS、macOS、tvOS、PC、Android 等均支持 HLS 协议，HLS 是应用最为广泛的流协议。Apple 提供了几个支持 HTTP Live Streaming 的框架，包括AVKit、AVFoundation、WebKit

 

 

HTTP Live Streaming 由 Apple 开发，旨在能够从 iPhone 中删除 flash，如今已成为使用最广泛的协议。

桌面浏览器、智能电视、Android、iOS 均支持 HLS。HTML5 视频播放器也原生的支持HLS，但不支持 HDS 和 RTMP。这样就可以触达更多的用户。

HLS 支持码率自适应，并且支持最新的 H.265 解编码器，同样大小的文件，H.265 编码的视频质量是 H.264 的二倍。

此前，HLS 缺点一直是高延迟。但 Apple 在 WWDC 2019 发布了新的解决方案，可以将延迟从8秒降低到1至2秒。具体可以查看Introducing Low-Latency HLS。

 

在学习 HLS 之前，需要先了解几个相关概念。

1.1 MPEG

动态图像专家组（Moving Picture Experts Group，简称 MPEG）原本是一个研究视频、音频编码标准的组织，成立于1988年，致力于开发视频、音频压缩编码技术。现在我们所说的MPEG泛指该小组制定的一系列视频编码标准正式审核程序。至今已制定了MPEG-1、MPEG-2、MPEG-3、MPEG-4、MPEG-7、MPEG-21、MPEG-H、MEPG-DASH等标准。

1.2 MPEG-2

MPEG-2 由 ITU 定义，也称为 H.222 / H.262，是运动图像和相关音频信息的通用编码标准，它描述了视频、音频有损压缩的组合方法，该方法允许使用当前可用的存储媒体和传输宽带来存储、传输电影。常用在数字卫星电视、数字有线电视，以及 DVD 视频光盘中。

MPEG-2 标准作为 ISO / IEC 12818 的一部分发布。MPEG-2 包含多个标准，每个部分涵盖整个规范的某个方面。例如，Part 1 系统描述音视频同步和多路复用；Part 7 部分描述了有损数字音频压缩的音频编码标准，称为高级音频编码（Advanced Audio Coding，简称 AAC）。AAC 被设计为 MP3 格式的后继产品，在相同的比特率下，其声音质量通常比 MP3 更好。

1.3 MPEG-4

MPEG-4 定义了音视频数字数据的压缩方法。于1998年推出，并指定了一组音频、视频编码格式的标准和相关技术。MPEG-4 由 ISO/IEC MEPG 组织在 ISO / IEC 14496 标准发布。MPEG-4 标准压缩的数据可用于网络流媒体、CD 分发、电话、可视电话和广播电视。

与 MPEG-2 类似，MPEG-4 也包含多个部分，每个部分涵盖整个规范的某个方面。例如，Part 2 描述了视觉数据的压缩格式；Part 10 描述了视频信号的压缩格式，在技术上与 ITU-T H.264 标准相同。

1.4 H.264

H.264 被称为高级视频编码（Advanced Video Coding，简称 AVC，也称为 H.264、MPEG-4 Part 10、MPEG-4 AVC），是一种面向块、基于运动补偿的视频编码标准。在2004年时 H.264 已成为高精度视频录制、压缩、发布最常用格式之一。第一版标准的最终草案于2003年5月完成。

H.264 / MPEG-4 AVC 项目的目的是为了创建一个更佳的视频压缩标准，在更低的比特率下依然能提供良好视频质量，同时不会大幅度增加设计的复杂性。广泛用于网络流媒体、各种高清晰度电和卫星。

1.5 H.265

H.265 被称为高效率视频编码（High Efficiency Video Coding，简称 HEVC），是 MPEG-H 规范的第二部分。H.265 是一种视频压缩标准，被视为 H.264 标准的继任者。与AVC相比，HEVC 在相同视频质量下数据可以压缩 25% 至 50%，或相同比特率下可显著提高视频质量。HEVC 支持高达 8192*4320 的分辨率，HEVC 的高保真 Main10 配置文件已经集成到几乎所有支持的硬件中。HEVC 正在与 IETF 的 AV1 编码格式竞争。

1.6 AC-3

AC-3 是音频编码（Audio Coding）的缩写，是杜比数字音频编码器（Dolby Digital audio codec）的同义词。除 Dolby TrueHD 外，音频均为有损压缩。通常，AC-3 几乎只用于视频，并且通常需要特殊许可的软件或硬件才能进行编码、解码。除非用于电影、DVD和蓝光项目，否则没有理由使用AC-3。

1.7 AAC

AAC 被称为高级音频编码（Advanced Audio Coding），用于有损数字音频压缩的音频编码标准，被设计为 MP3 格式的继任者。在相同比特率下，AAC 通常比 MP3 可以获得更好的声音质量。AAC 是 iOS、Android 等系统的默认或标准音频格式。

2. HLS 架构

这一部分介绍 HLS 主要组件如何协同工作以传递流媒体。从概念上讲，HTTP Live Streaming 包含三部分：服务器组件、分发组件和客户端软件。

在常见配置中，硬件编码器接受输入的音视频，将其编码为 HEVC 视频、AC-3 音频，输出片段化（fragmented）MPEG-4 文件或 MPEG-2 传输流，分段器（segmenter）软件将 stream 分割成系列短媒体文件，然后将短媒体文件放在 web 服务器上。segmenter 还会创建并维护一个包含媒体文件列表的索引文件（index file）。索引文件的 URL 在 web 服务器上发布，客户端读取索引文件，按顺序读取列出的媒体文件并播放，各片段间没有任何暂停或间隔。

2.1 服务器组件

服务器组件负责获取媒体输入流并对其进行数字编码，将其封装成适合传输的格式，并为分发做准备。

对于直播，服务器需要媒体编码器（可以是现有的硬件），以及一种将编码的媒体分割成片段并保存为文件的方法，该方法可以是由 Apple 提供的 media stream segmented，也可以是第三方解决方案。

2.2 分发组件

分发系统是 web 服务器或 web 缓存系统，通过 HTTP 将媒体文件和索引文件传输到客户端。HTTP Live Streaming 协议不需要对服务器模块进行任何自定义即可用于传输内容，且 web 服务器只需要很少的配置。要实际使用 HTTP Live Streaming，需要将 HTML 页面或 app 作为接收器，还需要使用 web 服务器，以及将实时流编码为 HEVC 或 H.264视频、 ACC 或 AC-3 音频的分段 MPEG-4 媒体文件。

2.3 客户端软件

客户端软件负责确定所请求媒体资源类型、下载所需资源、重新组合资源，最后将媒体连续的呈现给用户。目前，Windows 10、macOS 10.6+、iOS 3.0+、Android 4.1+ 等均原生支持 HLS，大部分浏览器也支持HLS。点击这里可以查看各浏览器起始支持 HLS 版本。

客户端软件使用标志流媒体位置的 URL 获取 index file，index file 指定可用媒体文件位置、解密密钥和可选流。选定流后，客户端按顺序下载可用媒体文件，每个文件包含一段连续的 stream。当拥有足够数据后，客户端播放重组的 stream。

客户端负责获取解密密钥、身份认证，根据需要解密媒体文件。

这些过程会一直持续，直到在 index file 遇到 EXT-X-ENDLIST tag。如果没有 EXT-X-ENDLIST tag，则 index file 是直播的一部分。在直播期间，客户端会定期拉去 index file 的新版本，并在新版本的 index file 中查找新的媒体文件和加密密钥，并将这些 URL 添加到队列。

3. 部署基础的 HTTP Live Stream

部署 HTTP Live Stream 需要满足以下三点：

• HTML 网页或客户端作为接收者。
• Web 服务器或 CDN 作为主机。
• 一种将媒体文件或直播流编码为包含 HEVC 或 H.264 视频、 AAC 或 AC-3 音频的 MPEG-4 片段文件的方式。尽管也可以将 MP3 音频或 MPEG-2 用于传输 H.264 视频，但通常不推荐使用这些格式。

3.1 创建 HLS 媒体接收器

分发 HTTP Live Streaming 媒体最简单的方法是使用 M3U8 播放列表文件作为视频源，创建包含 HTML5 标签的网页，对于不支持 HTML5 视频元素的浏览器，或不支持 HTTP Live Streaming 的浏览器，可以在 和 标签之间添加降级代码。例如，可以使用 QuickTime 插件回退到渐进式下载或 RTSP 流。以下示例显示了常见 HTML 网页代码：

<html>

    <head>

        <title>HTTP Live Streaming Example</title>

    </head>

    <body>

        <video controls="controls" autoplay="" src="https://devstreaming-cdn.apple.com/videos/streaming/examples/bipbop_adv_example_hevc/master.m3u8" type="video/x-m4v">

        </video>

    </body

></html>

如果你在开发 iOS app，则可以使用AVKit框架直接播放：

func playHLSVideo() {

        guard let videoURL = URL(string: "https://devstreaming-cdn.apple.com/videos/streaming/examples/bipbop_adv_example_hevc/master.m3u8") else {

            return

        }

        let player = AVPlayer(url: videoURL )

        let playerViewController = AVPlayerViewController()

        playerViewController.player = player

        present(playerViewController,

                animated: true) {

                    playerViewController.player?.play()

        }

    }

3.2 配置服务器

普通的 web 服务器即可提供 HTTP Live Streaming。对服务器进行常规配置，然后将要提供文件的 MIME 类型与文件扩展名相关联。下表显示了 HTTP Live Streaming 的 MIME 类型：

扩展名	MIME 类型
.m3u8	vnd.apple.mpegURL
.ts	video/MP2T
.mp4	video/mp4

如果 web 服务器需要遵守 MIME 类型约束，则可以提供以 .m3u 结尾 MIME 类型为 audio/mpegURL 的文件，以实现兼容性。

索引文件通常很长，经常被重新下载，但由于他们是文本文件，因此可以非常高效地进行压缩。通过启用 M3U8 索引文件的实时 gzip 压缩来减少服务器开销。HTTP Live Streaming 客户端会自动进行解压缩。

对于点播类型视频，索引文件格式如下：

#EXTM3U

#EXT-X-PLAYLIST-TYPE:VOD

#EXT-X-TARGETDURATION:10

#EXT-X-VERSION:4

#EXT-X-MEDIA-SEQUENCE:0

#EXTINF:10.0,

http://example.com/movie1/fileSequenceA.ts

#EXTINF:10.0,

http://example.com/movie1/fileSequenceB.ts

#EXTINF:10.0,

http://example.com/movie1/fileSequenceC.ts

#EXTINF:9.0,

http://example.com/movie1/fileSequenceD.ts

#EXT-X-ENDLIST

各标记用途如下：

EXTM3U：表示此播放列表是扩展为 M3U 的文件列表。通过将第一行标记改为 EXTM3U，可以将这种类型的文件与基本的 M3U 文件区分开。所有 HLS 播放列表都必须以此标签开头。

EXT-X-PLAYLIST-TYPE：提供使用于整个播放列表的文件是否可变信息。此标签内容为 EVENT 或 VOD。如果标签为 EVENT，则服务器不能改变、删除索引文件的任何部分，但可以向尾部拼接。如果标记为 VOD，则播放列表不可更改。

EXT-X-TARGETDURATION：指定媒体文件最大时长。

EXT-X-VERSION：表示播放列表文件的兼容版本。播放列表媒体和服务器必须符合该版本协议的 IETF Internet-Draft 最新规定。

EXT-X-MEDIA-SEQUENCE：要播放的第一个媒体文件序列号。播放列表中的每个媒体文件 URL 都有一个唯一的整数序列号，URL 的序列号是其前面的 URL 序列号加一，序列号与文件名无关。

EXTINF：记录标记，描述紧随其后的 URL 所标识媒体文件。每个媒体文件 URL 之前都必须有一个 EXTINF 标记。该标记包含一个 duration 属性。duration 属性是一个整数或浮点数，指定媒体段的持续时间（以秒为单位），该值必须小于等于目标持续时间。

始终使用浮点 EXTINF 时长（协议版本 3 中增加的），这将使客户端在流中搜素时减少出现错误。

EXT-X-ENDLIST：标记媒体文件结束，不会再添加新的媒体文件到播放列表。

上面的 VOD 播放列表使用完整路径描述媒体文件。尽管可以使用绝对路径，但更推荐使用相对路径。相对路径是相对于播放列表文件的位置，使用绝对路径会导致更多文本，且相对路径比绝对路径更可移植。下面是使用相对路径的同一播放列表：

#EXTM3U

#EXT-X-PLAYLIST-TYPE:VOD

#EXT-X-TARGETDURATION:10

#EXT-X-VERSION:4

#EXT-X-MEDIA-SEQUENCE:0

#EXTINF:10.0,

fileSequenceA.ts

#EXTINF:10.0,

fileSequenceB.ts

#EXTINF:10.0,

fileSequenceC.ts

#EXTINF:9.0,

fileSequenceD.ts

#EXT-X-ENDLIST

直播和 event session 播放列表会有所不同，具体可以查看：Live Playlist (Sliding Window) Construction 和 Event Playlist Construction。

对于点播来说，整个媒体文件已经存在。因此，索引文件是静态的，只会被下载一次。对于直播来说，索引文件不断更新，当新媒体资源可用时，会替换掉原来媒体资源。对于 event session 来说，新媒体文件可用时会拼接到索引文件结尾，与点播不同的是，不能移除索引文件任何内容，只能向文件尾部拼接新的媒体片段，event session 允许用户跳转到已经播放过片段任一时刻，即等效于点播+直播，常用于演唱会、运动会。

3.3 验证流

Apple 提供的 HTTP Live Streaming Tools 包含 Media Stream Segmenter、Media File Segmenter、Media Subtitle Segmenter、Variant Playlist Creator、Media Stream Validator、 HLS Report、ID3 Tag Generator 几种工具。

Media Stream Validator 工具模拟 HTTP Live Streaming 会话，并验证索引文件和媒体片段是否符合 HTTP Live Streaming 规范。其会执行多次检查以确保流传输可靠，如果发现错误、问题，会在诊断报告中列出。在提供流服务前，请始终运行验证程序。

mediastreamvalidator 命令如下：

$ mediastreamvalidator https://devstreaming-cdn.apple.com/videos/streaming/examples/bipbop_16x9/bipbop_16x9_variant.m3u8

上述命令执行完毕后，会产生一个 validation_data.json 的诊断报告，但其内容并不方便阅读，可以使用下面的 python script 将其转换为 html 格式：

$ hlsreport.py validation_data.json

生成的 validation_data.html 如下图所示：

 

mediastreamvalidator 命令即可以验证 HTTP URLs 的资源，也可以验证本地资源。

使用 mediastreamvalidator 命令时如需帮助，输入mediastreamvalidator -h命令即可查看文档。

此前，HLS 缺点一直是高延迟。但 Apple 在 WWDC 2019 发布了新的解决方案，可以将延迟从8秒降低到1至2秒。具体可以查看Introducing Low-Latency HLS。

 

何时使用 HLS

HLS 是目前使用最广泛的协议，且功能强大。数据显示，如果视频播放过程中遇到故障，只有8%的用户会继续在当前网站观看视频。使用广泛兼容的自适应协议（例如HLS），可以提供最佳的受众体验。

 

 

3.6 RealTime Streaming Protocol (RTSP)就是如下介绍的

 

流媒体协议

简介

流媒体(Streaming Media)技术是指将一连串的媒体数据压缩后，以流的方式在网络中分段传送，实现在网络上实时传输影音以供观赏的一种技术。 

流媒体实际指的是一种新的媒体传送方式，有声音流、视频流、文本流、图像流、动画流等，而非一种新的媒体。 

流媒体文件格式是支持采用流式传输及播放的媒体格式。常用格式有：

RA：实时声音；

RM：实时视频或音频的实时媒体；

RT：实时文本；

RP：实时图像；

SMII.：同步的多重数据类型综合设计文件；

SWF：real flash和shockwavc flash动面文件；

RPM: HTMI。文件的插件；

RAM:流媒体的源文件，是包含RA、RM、SMIIJ文件地址（URL地址）的文本文件；

CSF:一种类似媒体容器的文件格式，可以将非常多的媒体格式包含在其中，而不仅仅限于音、视频。

quicktime，mov，asf，wmv，wma，avi，mpeg，mpg，dat，mts；

aam多媒体教学课件格式，可将authorware生成的文件压缩为aam和aas流式文件播放

 

流媒体特征

(1)内容主要是时间上连续的媒体数据(音频、视频、动画、多媒体等)。

(2)内容可以不经过转换就采用流式传输技术传输

(3)具有较强的实时性，交互性。

(4)启动延时大幅度缩短，缩短了用户的等待时间；用户不用等到所有内容都下载到硬盘上才能开始浏览，在经过一段启动延时后就能开始观看。

(5)对系统缓存容量的要求大大降低。

Internet是以包传输为基础进行的异步传输，数据被分解成许多包进行传输，由于每个包可能选择不同的路由，所以到达用户计算机的时间延迟就会不同，而在客户端就需要缓存系统来弥补延迟和抖动的影响以及保证数据包传输的顺序在流媒体文件的播放过程中，由于不再需要把所有的文件都下载到缓存，因此对缓存的要求很低。

 

流式传输方式

流媒体最主要的技术特征就是流式传输，它使得数据可以像流水一样传输。 [3] 

流式传输是指通过网络传送媒体(音频、视频等)技术的总称。实现流式传输主要有两种方式:

顺序流式传输( progressive streaming)

实时流式传输( real time streaming)。

顺序流式传输

顺序流式传输是顺序下载，用户在观看在线媒体的同时下载文件，在这一过程中，用户只能观看下载完的部分，而不能直接观看未下载部分。也就是说，用户总是在一段延时后才能看到服务器传送过来的信息。由于标准的HTTP服务器就可以发送这种形式的文件，它经常被称为HTTP流式传输。

由于顺序流式传输能够较好地保证节目播放的质量，因此比较适合在网站上发布的、可供用户点播的、高质量的视频。 

顺序流式文件是放在标准HTTP或FTP服务器上，易于管理，基本上与防火墙无关。顺序流式传输不适合长片段和有随机访问要求的视频，如:讲座、演说与演示。它也不支持现场广播

实时流式传输realtime streaming protocl

实时流式传输必须保证匹配连接带宽，使媒体可以被实时观看到。在观看过程中用户可以任意观看媒体前面或后面的内容，但在这种传输方式中，如果网络传输状况不理想，则收到的图像质量就会比较差实时流式传输需要特定服务器，如 Quick Time Streaming Server、 Realserver或 Windows Media server。这些服务器允许对媒体发送进行更多级别的控制，因而系统设置、管理比标准HTTP服务器更复杂。实时流式传输还需要特殊网络协议，如:RTSP( realtime streaming protocol)或MMS(microsoft media server)。在有防火墙时，有时会对这些协议进行屏闭，导致用户不能看到一些地点的实时内容，实时流式传输总是实时传送，因此特别适合现场事件

 

 

 

 

 

 

流媒体传输的网络协议

TCP需要较多的开销，故不太适合传输实时数据；

流式传输一般采用HTTP/TCP(RTCP来传输控制信息，而用RTP/UDP(RTP)来传输实时声音数据

总结如下：

控制信息，流量控制，拥塞控制：HTTP/TCP->RTCP

实时数据传输：UDP传输数据->RTP

实时传输协议RTP

实时传输协议RTP被定义为在一对一或一对多的传输情况下工作，其目的是提供时间信息和实现流同步；RTP通常使用UDP来传送数据；当应用程序开始一个RTP会话时将使用2个端口:一个给RTP，一个给RTCP。RTP本身并不能为按顺序传送数据包提供可靠的传送制，也不提供流量控制或拥塞控制，它依靠RTCP提供这些服务；通常RTP算法并不作为一个独立的网络层来实现，而是作为应用程序代码的一部分

实时传输控制协议RTCP

实时传输控制协议RTCP和RTP一起提供流量控制和拥塞控制服务；

在RTP会话期间各参与者周期性地传送RTCP包；

RTCP包中含有已发送的数据包的数量、丢失的数据包数量等统计资料，因此，服务器可以利用这些信息动态地改变传输速率，甚至改变有效载荷类型。

RTP和RTCP配合使用，它们能以有效的反馈和最小的开销使传输效率最佳化，因而特适合传送网上的实时数据。

实时流协议RTSP

实时流协议RTSP定义了一对多应用程序如何有效地通过IP网络传送多媒体数据；

RTSP在体系结构上位于RTP和RTCP之上，它使用TCP或RTP(UDP)完成数据传输；HTTP与RTSP相比，HTTP传送HTML超链接文档，而RTSP传送的是多媒体数据；

HTTP时，请求由客户机发出，服务器做出响应；单全功

RTSP时，客户机和服务器都可以发出请求，即RTSP可以是双向的。点对点的手机可视通话，必须在手机终端实现RTSP。双全工

 

 

 

 

 

文件格式

不同的文件格式需要不通的播放器播放

1、微软的ASF，扩展名为.asf  .wmv对应的播放器Media Player，用户可以将图形、声音和动画数据组合成一个ASF格式的文件，也可以将其他格式的视频和音频转换为ASF格式，而且用户还可以通过声卡和视频捕获卡将诸如麦克风、录像机等外设的数据保存为ASF格式。

2、RealNetworks公司的ReaIMedia。它包括RealAudio、RealVideo和RealFlash三类文件，其中RealAudio用来传输接近CD音质的音频数据，RealVideo用来传输不间断的视频数据，RealFlash则是ReaINetworks公司与Macromedia公司联合推出的一种高压缩比的动画格式，这类文件的扩展名是.rm、.ra、.rmvb，文件对应的播放器是ReaIPlayer

 

3、苹果公司的QuickTime。这类文件扩展名通常是.mov，它所对应的播放器是QuickTime。

此外，MPEG、AVI、DVI、SWF等都是适用于流媒体技术的文件格式

 

 

 

系统组成

流媒体系统包括以下5个方面的内容: [

(1)编码工具:用于创建、捕捉和编辑多媒体数据，形成流媒体格式。

(2)流媒体数据。

(3)服务器:存放和控制流媒体的数据。

(4)网络:适合多媒体传输协议甚至是实时传输协议的网络

(5)播放器:供客户端浏览流媒体文件

这5个部分有些是服务器端需要的，有些是客户端需要的，而且不同的流媒体标准和不同公司的解决方案会在某些方面有所不同。

 

 

区别于联系

1、RTP over UDP和RTP over RTSP有什么区别？
RTP over UDP 是RTP下层使用udp传输，
RTP over RTSP 是指的用rtsp协议建立会话，然后使用RTP协议传输数据；

2、RTP over RTSP是不是就是RTP over TCP？
不是：RTP over RTSP 是指的用用rtsp协议建立会话，然后使用RTP协议传输数据；
至于下面用udp 还是tcp是不确定的

3、rtp和rtsp协议是应用层的，tcp和udp是传输层的，所以只能说rtp over tcp/udp。
而且一般情况下一个点播需要rtsp+rtp+rtcp三个协议共同来实现。

RTP，RTCP数据和RTSP数据共享TCP数据通道，所以必须有一个标识来区别三种数据

RTSP、RTCP、RTP区别
1：RTSP实时流协议
作为一个应用层协议，RTSP提供了一个可供扩展的框架，它的意义在于使得实时流媒体数据的受控和点播变得可能。总的说来，RTSP是一个流媒体表示协议，主要用来控制具有实时特性的数据发送，但它本身并不传输数据，而是必须依赖于下层传输协议所提供的某些服务。RTSP可以对流媒体提供诸如播放、暂停、快进等操作，它负责定义具体的控制消息、操作方法、状态码等，此外还描述了与RTP间的交互操作（RFC2326）。

2：RTCP控制协议
RTCP控制协议需要与RTP数据协议一起配合使用，当应用程序启动一个RTP会话时将同时占用两个端口，分别供RTP和RTCP使用。RTP本身并不能为按序传输数据包提供可靠的保证，也不提供流量控制和拥塞控制，这些都由RTCP来负责完成。通常RTCP会采用与RTP相同的分发机制，向会话中的所有成员周期性地发送控制信息，应用程序通过接收这些数据，从中获取会话参与者的相关资料，以及网络状况、分组丢失概率等反馈信息，从而能够对服务质量进行控制或者对网络状况进行诊断。

RTCP协议的功能是通过不同的RTCP数据报来实现的，主要有如下几种类型：
SR：发送端报告，所谓发送端是指发出RTP数据报的应用程序或者终端，发送端同时也可以是接收端。(SERVER定时间发送给CLIENT)。
RR：接收端报告，所谓接收端是指仅接收但不发送RTP数据报的应用程序或者终端。(SERVER接收CLIENT端发送过来的响应)。
SDES：源描述，主要功能是作为会话成员有关标识信息的载体，如用户名、邮件地址、电话号码等，此外还具有向会话成员传达会话控制信息的功能。
BYE：通知离开，主要功能是指示某一个或者几个源不再有效，即通知会话中的其他成员自己将退出会话。
APP：由应用程序自己定义，解决了RTCP的扩展性问题，并且为协议的实现者提供了很大的灵活性。

3：RTP数据协议
RTP数据协议负责对流媒体数据进行封包并实现媒体流的实时传输，每一个RTP数据报都由头部（Header）和负载（Payload）两个部分组成，其中头部前12个字节的含义是固定的，而负载则可以是音频或者视频数据。

RTP用到的地方就是 PLAY ，服务器往客户端传输数据用UDP协议，RTP是在传输数据的前面加了个12字节的头(描述信息)。

RTP载荷封装设计本文的网络传输是基于IP协议，所以最大传输单元(MTU)最大为1500字节，在使用IP／UDP／RTP的协议层次结构的时候，这其中包括至少20字节的IP头，8字节的UDP头，以及12字节的RTP头。这样，头信息至少要占用40个字节，那么RTP载荷的最大尺寸为1460字节。以H264 为例，如果一帧数据大于1460，则需要分片打包，然后到接收端再拆包，组合成一帧数据，进行解码播放

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

RTP

          参考文档 RFC3550/RFC3551

         Real-time Transport Protocol)是用于Internet上针对多媒体数据流的一种传输层协议。RTP协议详细说明了在互联网上传递音频和视频的标准数据包格式。RTP协议常用于流媒体系统（配合RTCP协议），视频会议和一键通（Push to Talk）系统（配合H.323或SIP），使它成为IP电话产业的技术基础。RTP协议和RTP控制协议RTCP一起使用，而且它是建立在UDP协议上的。 

         RTP 本身并没有提供按时发送机制或其它服务质量（QoS）保证，它依赖于低层服务去实现这一过程。 RTP 并不保证传送或防止无序传送，也不确定底层网络的可靠性。 RTP 实行有序传送， RTP 中的序列号允许接收方重组发送方的包序列，同时序列号也能用于决定适当的包位置，例如：在视频解码中，就不需要顺序解码。

      RTP 由两个紧密链接部分组成： RTP ― 传送具有实时属性的数据；RTP 控制协议（RTCP） ― 监控服务质量并传送正在进行的会话参与者的相关信息。

RTCP

        实时传输控制协议（Real-time Transport Control Protocol或RTP Control Protocol或简写RTCP）是实时传输协议（RTP）的一个姐妹协议。RTCP为RTP媒体流提供信道外（out-of-band）控制。RTCP本身并不传输数据，但和RTP一起协作将多媒体数据打包和发送。RTCP定期在流多媒体会话参加者之间传输控制数据。RTCP的主要功能是为RTP所提供的服务质量（Quality of Service）提供反馈。

        RTCP收集相关媒体连接的统计信息，例如：传输字节数，传输分组数，丢失分组数，jitter，单向和双向网络延迟等等。网络应用程序可以利用RTCP所提供的信息试图提高服务质量，比如限制信息流量或改用压缩比较小的编解码器。RTCP本身不提供数据加密或身份认证。SRTCP可以用于此类用途。

SRTP & SRTCP

        参考文档 RFC3711

        安全实时传输协议（Secure Real-time Transport Protocol或SRTP）是在实时传输协议（Real-time Transport Protocol或RTP）基础上所定义的一个协议，旨在为单播和多播应用程序中的实时传输协议的数据提供加密、消息认证、完整性保证和重放保护。它是由David Oran（思科）和Rolf Blom（爱立信）开发的，并最早由IETF于2004年3月作为RFC3711发布。

        由于实时传输协议和可以被用来控制实时传输协议的会话的实时传输控制协议（RTP Control Protocol或RTCP）有着紧密的联系，安全实时传输协议同样也有一个伴生协议，它被称为安全实时传输控制协议（Secure RTCP或SRTCP）；安全实时传输控制协议为实时传输控制协议提供类似的与安全有关的特性，就像安全实时传输协议为实时传输协议提供的那些一样。

        在使用实时传输协议或实时传输控制协议时，使不使用安全实时传输协议或安全实时传输控制协议是可选的；但即使使用了安全实时传输协议或安全实时传输控制协议，所有它们提供的特性（如加密和认证）也都是可选的，这些特性可以被独立地使用或禁用。唯一的例外是在使用安全实时传输控制协议时，必须要用到其消息认证特性。

RTSP

       参考文档 RFC2326

        是由Real Networks和Netscape共同提出的。该协议定义了一对多应用程序如何有效地通过IP网络传送多媒体数据。RTSP提供了一个可扩展框架，使实时数据，如音频与视频的受控、点播成为可能。数据源包括现场数据与存储在剪辑中的数据。该协议目的在于控制多个数据发送连接，为选择发送通道，如UDP、多播UDP与TCP提供途径，并为选择基于RTP上发送机制提供方法。

        RTSP（Real Time Streaming Protocol）是用来控制声音或影像的多媒体串流协议，并允许同时多个串流需求控制，传输时所用的网络通讯协定并不在其定义的范围内，服务器端可以自行选择使用TCP或UDP来传送串流内容，它的语法和运作跟HTTP 1.1类似，但并不特别强调时间同步，所以比较能容忍网络延迟。而前面提到的允许同时多个串流需求控制（Multicast），除了可以降低服务器端的网络用量，更进而支持多方视讯会议（Video Conference）。 因为与HTTP1.1的运作方式相似，所以代理服务器《Proxy》的快取功能《Cache》也同样适用于RTSP，并因RTSP具有重新导向功能，可视实际负载情况来转换提供服务的服务器，以避免过大的负载集中于同一服务器而造成延迟。

RTSP 和RTP的关系

       RTP不象http和ftp可完整的下载整个影视文件，它是以固定的数据率在网络上发送数据，客户端也是按照这种速度观看影视文件，当影视画面播放过后，就不可以再重复播放，除非重新向服务器端要求数据。

      RTSP与RTP最大的区别在于：RTSP是一种双向实时数据传输协议，它允许客户端向服务器端发送请求，如回放、快进、倒退等操作。当然，RTSP可基于RTP来传送数据，还可以选择TCP、UDP、组播UDP等通道来发送数据，具有很好的扩展性。它时一种类似与http协议的网络应用层协议。目前碰到的一个应用：服务器端实时采集、编码并发送两路视频，客户端接收并显示两路视频。由于客户端不必对视频数据做任何回放、倒退等操作，可直接采用UDP+RTP+组播实现。

RTP：实时传输协议（Real-time Transport Protocol） 

RTP/RTCP是实际传输数据的协议 

RTP传输音频/视频数据，如果是PLAY，Server发送到Client端，如果是RECORD，可以由Client发送到Server 

整个RTP协议由两个密切相关的部分组成：RTP数据协议和RTP控制协议（即RTCP） 

RTSP：实时流协议（Real Time Streaming Protocol，RTSP） 

RTSP的请求主要有DESCRIBE,SETUP,PLAY,PAUSE,TEARDOWN,OPTIONS等，顾名思义可以知道起对话和控制作用 

RTSP的对话过程中SETUP可以确定RTP/RTCP使用的端口，PLAY/PAUSE/TEARDOWN可以开始或者停止RTP的发送，等等 

RTCP： 

RTP/RTCP是实际传输数据的协议 

RTCP包括Sender Report和Receiver Report，用来进行音频/视频的同步以及其他用途，是一种控制协议

SDP

        会话描述协议（SDP）为会话通知、会话邀请和其它形式的多媒体会话初始化等目的提供了多媒体会话描述。

       会话目录用于协助多媒体会议的通告，并为会话参与者传送相关设置信息。SDP 即用于将这种信息传输到接收端。SDP 完全是一种会话描述格式 ― 它不属于传输协议 ― 它只使用不同的适当的传输协议，包括会话通知协议（SAP）、会话初始协议（SIP）、实时流协议（RTSP）、MIME 扩展协议的电子邮件以及超文本传输协议（HTTP）。

 

        SDP 的设计宗旨是通用性，它可以应用于大范围的网络环境和应用程序，而不仅仅局限于组播会话目录，但 SDP 不支持会话内容或媒体编码的协商。

        在因特网组播骨干网（Mbone）中，会话目录工具被用于通告多媒体会议，并为参与者传送会议地址和参与者所需的会议特定工具信息，这由 SDP 完成。SDP 连接好会话后，传送足够的信息给会话参与者。SDP 信息发送利用了会话通知协议（SAP），它周期性地组播通知数据包到已知组播地址和端口处。这些信息是 UDP 数据包，其中包含 SAP 协议头和文本有效载荷（text payload）。这里文本有效载荷指的是 SDP 会话描述。此外信息也可以通过电子邮件或 WWW （World Wide Web） 进行发送。

 

SDP 文本信息包括：

 

会话名称和意图；

会话持续时间；

构成会话的媒体；

有关接收媒体的信息（地址等）。

协议结构

SDP 信息是文本信息，采用 UTF-8 编 码中的 ISO 10646 字符集。SDP 会话描述如下：（标注 * 符号的表示可选字段）：

v = （协议版本）

o = （所有者/创建者和会话标识符）

s = （会话名称）

i = * （会话信息）

u = * （URI 描述）

e = * （Email 地址）

p = * （电话号码）

c = * （连接信息 ― 如果包含在所有媒体中，则不需要该字段）

b = * （带宽信息）

 

一个或更多时间描述（如下所示）：

z = * （时间区域调整）

k = * （加密密钥）

a = * （0 个或多个会话属性行）

0个或多个媒体描述（如下所示）

 

时间描述

t = （会话活动时间）

r = * （0或多次重复次数）

 

媒体描述

m = （媒体名称和传输地址）

i = * （媒体标题）

c = * （连接信息 — 如果包含在会话层则该字段可选）

b = * （带宽信息）

k = * （加密密钥）

a = * （0 个或多个会话属性行）

 

RTMP/RTMPS

RTMP(Real Time Messaging Protocol)实时消息传送协议是Adobe Systems公司为Flash播放器和服务器之间音频、视频和数据传输 开发的开放协议。

它有三种变种：

1)工作在TCP之上的明文协议，使用端口1935；

2)RTMPT封装在HTTP请求之中，可穿越防火墙；

3)RTMPS类似RTMPT，但使用的是HTTPS连接；

 

RTMP协议(Real Time Messaging Protocol)是被Flash用于对象,视频,音频的传输.这个协议建立在TCP协议或者轮询HTTP协议之上.

      RTMP协议就像一个用来装数据包的容器,这些数据既可以是AMF格式的数据,也可以是FLV中的视/音频数据.一个单一的连接可以通过不同的通道传输多路网络流.这些通道中的包都是按照固定大小的包传输的.

 

mms

        MMS (Microsoft Media Server Protocol)，中文“微软媒体服务器协议”，用来访问并流式接收 Windows Media 服务器中 .asf 文件的一种协议。MMS 协议用于访问 Windows Media 发布点上的单播内容。MMS 是连接 Windows Media 单播服务的默认方法。若观众在 Windows Media Player 中键入一个 URL 以连接内容，而不是通过超级链接访问内容，则他们必须使用MMS 协议引用该流。MMS的预设埠（端口）是1755

 

        当使用 MMS 协议连接到发布点时，使用协议翻转以获得最佳连接。“协议翻转”始于试图通过 MMSU 连接客户端。 MMSU 是 MMS 协议结合 UDP 数据传送。如果 MMSU 连接不成功，则服务器试图使用 MMST。MMST 是 MMS 协议结合 TCP 数据传送。

如果连接到编入索引的 .asf 文件，想要快进、后退、暂停、开始和停止流，则必须使用 MMS。不能用 UNC 路径快进或后退。若您从独立的 Windows Media Player 连接到发布点，则必须指定单播内容的 URL。若内容在主发布点点播发布，则 URL 由服务器名和 .asf 文件名组成。例如：mms://windows_media_server/sample.asf。其中 windows_media_server 是 Windows Media 服务器名，sample.asf 是您想要使之转化为流的 .asf 文件名。

若您有实时内容要通过广播单播发布，则该 URL 由服务器名和发布点别名组成。例如：mms://windows_media_server/LiveEvents。这里 windows_media_server 是 Windows Media 服务器名，而 LiveEvents 是发布点名

 

HLS

      HTTP Live Streaming（HLS）是苹果公司(Apple Inc.)实现的基于HTTP的流媒体传输协议，可实现流媒体的直播和点播，主要应用在iOS系统，为iOS设备（如iPhone、iPad）提供音视频直播和点播方案。HLS点播，基本上就是常见的分段HTTP点播，不同在于，它的分段非常小。

 

       相对于常见的流媒体直播协议，例如RTMP协议、RTSP协议、MMS协议等，HLS直播最大的不同在于，直播客户端获取到的，并不是一个完整的数据流。HLS协议在服务器端将直播数据流存储为连续的、很短时长的媒体文件（MPEG-TS格式），而客户端则不断的下载并播放这些小文件，因为服务器端总是会将最新的直播数据生成新的小文件，这样客户端只要不停的按顺序播放从服务器获取到的文件，就实现了直播。由此可见，基本上可以认为，HLS是以点播的技术方式来实现直播。由于数据通过HTTP协议传输，所以完全不用考虑防火墙或者代理的问题，而且分段文件的时长很短，客户端可以很快的选择和切换码率，以适应不同带宽条件下的播放。不过HLS的这种技术特点，决定了它的延迟一般总是会高于普通的流媒体直播协议。　

 

     根据以上的了解要实现HTTP Live Streaming直播，需要研究并实现以下技术关键点

 

采集视频源和音频源的数据

对原始数据进行H264编码和AAC编码

视频和音频数据封装为MPEG-TS包

HLS分段生成策略及m3u8索引文件

HTTP传输协议