也就是说，使用HTTP协议来流媒体内容。与RTMP相比，HTTP更简单和众所周知，并且不担心被专利绑架。内容延迟也可以实现2到5秒，并且开放速度更快，因为HTTP本身没有复杂的状态相互作用。因此，从延迟的角度来看，HTTP-FLV优于RTMP。

HLS协议：

也就是说，HTTP Live是基于提出的HTTP的流媒体传输协议。 HLS具有很大的优势：可以直接打开和播放；这意味着可以通过微信等转发和共享实时广播链接，并且无需安装任何独立的应用程序，它只是浏览器，因此非常受欢迎。对于社交直播应用程序，可以说HLS是基本需求，因此让我们分析其原理。

基于HLS的Live流URL是一个M3U8文件，它包含一些最近的小型视频TS（视频封装格式，此处未扩展）。如果是实时流链接，则内容如下：

假设列表包含5个TS文件，并且每个TS文件包含5秒的视频内容，则总延迟为25秒。当然，可以缩短列表的长度和单个TS文件的大小以减少延迟。在极端情况下，可以减少列表长度为1或1秒的M3U8文件，但它非常容易受到网络波动的影响并导致滞后。

通过对公共网络的验证，同一城市网络的当前效应可以实现5到7秒的更好效果，这也是全面流利性和内容延迟的结果。那么，是否可以直接以较低的延迟开放直播技术？最后，我们将讨论这个问题。

RTP协议：

也就是说，实时是多媒体数据流的传输层协议。

在实际应用方案中，经常使用RTCP（RTP），可以简单地理解为RTCP传输交互式控制信号，而RTP传输实际媒体数据。

RTP广泛用于视频监视，视频会议和IP手机，因为视频会议和IP电话的重要用户体验：内容非常实时。

与上述三个或两个协议相比，RTP与它们之间存在重要区别，默认情况下，UDP协议用于传输数据，而RTMP和HTTP是基于TCP协议传输的。为什么UDP可以实现此类实时结果？关于TCP和UDP之间的差异有很多文章。我不会在这里详细介绍，我将简要概述：

UDP：单个数据报不需要建立连接。这很简单且不可靠。它将丢失数据包，并且不秩序。

TCP：流媒体，需要建立连接，复杂，可靠且有序。

实时音频和视频流的场景不需要可靠的保证，因此不需要重新启动机制。您可以实时看到图像的声音，在网络摇晃时会失去一些内容，以及模糊的图片和模糊屏幕，这是完全不重要的。 TCP将导致延迟和外同步以重新启动。如果由于重新传播而在1秒后到达某个内容，则整个对话将延迟1秒。随着网络的震动，延迟将增加到2秒和3秒。秒，如果未处理客户播放，它将严重影响实时广播体验。

总结：在选择实时广播协议中，如果您选择RTMP或HTTP-FLV，则意味着内容延迟为2到5秒，但是它已打开并且HTTP-FLV比RTMP更好。 HLS的内容延迟为5到7秒。选择RTP进行实时广播，以在1秒内实现实时广播延迟。但是，众所周知，主要的CDN制造商不支持基于RTP的实时广播，因此主流国内市场仍然是RTMP或HTTP-FLV。

除HLS以外，还有较低延迟的解决方案吗？

HLS的优点很明显：移动终端无需安装应用程序即可使用兼容的浏览器进行观看。所有主流移动浏览器基本上都得到了支持，并且在实时广播的传播和经验中都有巨大的优势。

而且唯一的缺点似乎是：高内容延迟（这里有许多HLS限制，例如H264 AAC编码，也可以被视为“默认值”之一）。如果可以解决，它将是实时广播技术的很大进步。还是换句话说，是否有可以直接通过链接传播的实时广播解决方案？不限于HLS本身。

浏览器的直接视频互动已被提升。目前，已经出现了许多形成的产品。您可以打开浏览器并实时对话，并实时广播它们。但是，让我们看一下以下浏览器叠加层：

令人遗憾的是，直到iOS 9.3才得到支持的人。继续我们的探索，如何支持？

除了旧的和未经审查的Mini外，所有浏览器都支持它。这似乎是个好消息。让我们解决现场广播需要解决的问题：

1。后端兼容性

2。传输

3。解码播放

＃1似乎不是一个大问题，但这是RTMP对HLS和RTP的基本技能。 ＃2是浏览器使用HTTP进行传输的更好选择。对于＃3，建议在此处进行开源JS解码项目：已经有一个用于实时广播的-JS服务器。

从测试结果来看，该项目的代码相对较薄，尚未达到工业成熟度的水平。据估计，它需要自己填补许多陷阱。有兴趣的学生可以学习和研究。

以上是实时广播云：选择实时广播应用程序层协议和传输层协议以及对实时广播体验的影响的分析。有关访问网络优化，内容缓存和传输策略优化以及终端优化，请参阅下一步发布的其他部分。

3。内容缓存和传输策略优化细节的基本知识在传输直播媒体的传输中：I框架，B框架，P框架

我的框架代表关键帧。您可以理解，这张图片框架的完全保留；仅在解码时只能完成此帧的数据。 （因为包括完整的图片）

AP帧表示此帧与先前的密钥帧（或P帧）之间的区别。解码时，您需要使用先前缓存的图片将此框架定义的差异叠加以生成最终图片。 （即，差异框架，P帧没有完整的图片数据，只有与上一个帧的图片不同的数据）

框架B是双向差分框架。框架B记录了此框架与前后框架之间的差异（具体细节非常复杂，有4种情况）。换句话说，要解码B框架，不仅需要先前的缓存图片，而且需要后续图片，并且最终图片是通过将前后图片与此框架的数据相叠加来获得的。

B帧的压缩率很高，但是在编码和解码时它会消耗更多的CPU，并且可能会增加实时广播期间的实时广播延迟，因此B框架通常在移动设备上不使用B框架。

密钥帧缓存策略

典型的视频框架序列是...

对于实时广播，为了减少实时广播的延迟，编码时通常不使用B框架。 P帧B框架对I帧具有直接或间接的依赖关系，因此，如果玩家想要解码视频帧序列并播放它，则必须先解码I帧，然后可以解码后续B帧和P帧。这样，如何在服务器上缓存密钥帧将对实时广播和其他方面的延迟产生重大影响。

一个更好的策略是通过服务器自动判断密钥帧的间隔，根据业务需求缓存帧序列，并确保在缓存中存储至少两个或多个关键帧，以应对低延迟，反研究，智能数据包损失和其他需求。 。

延迟和滞后

实时广播的延迟和滞后是两个指标，这些指标在分析实时广播服务的质量时非常关注。互动现场广播的场景对延迟非常敏感，而新闻和体育的实时广播更加关注播放的平稳性。

但是，这两个指标从理论上讲是矛盾的关系 - 需要较低的延迟，这意味着服务器和播放端的缓冲区都必须较短，并且网络中的异常抖动很容易导致滞后；当服务可以接受更高的延迟时，服务器和播放端都可以具有更长的缓冲区来应对网络的抖动，并提供更流畅的实时广播体验。

当然，对于网络条件非常好的用户，可以同时保证这两个项目。这主要用于没有如此良好的网络条件的用户。如何解决延迟和滞后问题。

通常，这里有两种技术可以平衡和优化这两个指标。

首先，服务器提供灵活的配置策略，对延迟要求更敏感。当服务器确保密钥帧时，它将为每个连接保持一个较小的缓冲区队列；对于具有更高要求的实时广播。 ，缓冲区队列的长度适当增加，以确保播放平稳。

其次，服务器智能检测所有连接的网络条件。当网络条件良好时，服务器将减小连接的缓冲队列的大小并减少延迟；而且，当网络条件较差时，尤其是当检测到抖动时，这是更明显的。当服务器将缓冲区队列长度添加到连接中时，优先考虑确保播放的平滑度。

数据包丢失策略

您什么时候需要丢失包装？

对于具有良好的网络连接并且延迟相对较小的网络连接，数据包丢失策略将永远不会有用。对于网络连接较差的用户，由于下载速度较慢或抖动相对较大，因此该用户的延迟将越来越高。

另一种情况是，如果实时流键帧间隔相对较长，那么当保证第一个数据包是关键帧时，观看该程序的受众延迟可能会达到键帧序列的长度。在上面的两种情况下，都需要启用数据包丢失策略来调整播放延迟。

关于数据包丢失，需要解决两个问题：

首先，正确判断何时需要丢失数据包；

第二是如何丢失数据包，以最大程度地减少对观众播放体验的影响。更好的方法是定期监视所有连接的缓冲区队列的长度，以便队列长度和时间形成离散的功能关系。后端通过自发算法来分析此离散功能，以确定是否需要数据包丢失。

一般的框架下降策略是直接丢弃完整的视频框架序列。该策略似乎很简单，但对用户播放体验有很大的影响。相反，背景应采用逐渐删除帧的策略。每个视频框架序列将失去最后一个或两个帧，以便将用户的感知最小化，并顺利地逐渐收缩延迟的效果。

4。客户优化

分析优化

参见前面介绍的DNS过程，如下图所示：

根据可控性和灾难恢复的需求，移动代码通常不会推动服务器IP地址进行流或播放，而是使用域名。如果发生IP停机时间或网络中断，也可以通过更改DNS来消除问题IP。域名的分辨率时间从数十毫秒到几秒钟。对于新生成的域名较低，平均分辨率延迟通常为。根据上图中的每个链接，只要有一个通道网络会产生波动或具有高设备负载。将增加到几秒钟。数十毫秒的情况是，当ISP NS层非常受欢迎时将缓存域名分辨率。如下图所示：

根据我们上面分析的情况，该省的延迟约为15ms，因此最低域名分辨率至少可以达到15ms。但是，由于实时广播方案的特殊性，很难使用用于按下和播放的域名以满足ISP NS高速缓存标准，因此您通常需要回到root NS的路径进行查询。

客户端分辨率优化的原理出现了：本机缓存域名分辨率结果并预订域名。每次您需要进行流媒体和播放时，都不再需要执行DNS过程。在这里节省数十万毫秒的开放延迟。

播放优化

实时广播参与者的相关技术点包括：实时广播延迟，第一个屏幕时间（指从播放开始到第一次看到屏幕的时间），音频和视频同步，软解码和硬解码。请参阅以下播放过程：

播放步骤描述：

与服务器建立连接并根据协议类型接收数据（例如RTMP，RTP，RTSP，HTTP等）；

分析二进制数据并从中找到相关的流信息；

根据不同的封装格式（例如flv，ts）取消插图（）；

编码的H.264视频数据和AAC音频数据分别获得；

使用硬解码（对应于系统的API）或软解码（）来解压缩音频和视频数据；

解码后，获得了原始视频数据（YUV）和音频数据（AAC）；

由于音频和视频解码是分开的，因此我们必须同步它们，否则音频和视频将不同步，例如别人的单词与唇部不匹配。

最后，将同步的音频数据发送到耳机或外部播放，并将视频数据发送到屏幕上以显示。

了解玩家的播放过程后，我们可以优化以下几点：

主屏幕时间优化

从步骤2开始，并节省时间通过预设解码器类型来检测文件类型；

从步骤5开始，减少视频数据检测范围，这也意味着减少要下载的数据量。尤其是当网络不好时，减少要下载的数据量可以节省大量时间开始播放。框架后检测到我将立即返回并输入解码过程。

延迟优化

视频缓冲或视频缓存策略。此策略的原则是增加用户的等待时间，而网络被粘得缓存一定数量的视频数据以实现后续平滑查看的效果。该技术可以有效地减少滞后数量，但会带来实时广播。延迟其内容，因此该技术主要用于按需广播。该策略已在实时广播中删除，以尽可能删除或减少内容到屏幕显示的内容的时间； （有利于减少延迟）。

下载数据检测池技术。当用户下载速度不足时，它将切断，网络将突然变得顺利。卡在服务器上的数据将以更快的速度发送。为了减少先前口吃引起的延迟，玩家将加速。播放检测池的视频数据并丢弃当前加速度部分的音频数据，以确保当前查看内容延迟稳定。

推动流优化

流程步骤简介：很容易看出流动和播放实际上是逆转的，因此我不会谈论特定过程。

优化1：适当的QoS（服务质量）策略。

流终端将根据当前的上行链路网络情况控制音频和视频数据的包装和编码。对于网络差，无法发送音频和视频数据，从而导致数据卡在本地。目前，将停止编码器，以防止进一步传输数据。停止，同时，将根据网络情况选择适当的策略，以控制音频和视频传输。

例如，当网络非常差时，流终端将优先发送音频数据，以确保用户可以听到声音并在特定间隔内发送密钥帧数据，以确保用户在一定间隔后可以看到图片中的某些更改。

优化2：合理的密钥帧配置。

合理地控制密钥帧发送间隔（建议使用2秒或1秒），这可以减少后端处理过程并为后端上较小的缓冲区设置创建条件。

软溶液选择

互联网上有许多有关选择软解决方案的分析文章。这里有一些经验，但是基本问题是，没有一般解决方案可以最好地适应所有操作系统和模型。

推动流编码：推荐3（）或以上使用硬编码，以下版本使用软编码； iOS使用完整的硬编码解决方案；

播放解码：iOS播放器使用软解码解决方案。在我们和大量客户的测试和摘要之后，尽管牺牲了功耗，但在某些细节上会表现得更好，并且它将非常可控制并且具有很强的兼容性。错误的错误较少，因此建议使用。

相关硬件和软件编解码器的优势和缺点的比较：

云模型和网络适应

以上分析了视频编码和解码的许多参数，但是在实际条件下的最佳编解码效果需要根据模型进行适应。由于iOS，有针对性的测试和调整的设备较少，但是很难通过模型实现目标调整，而且每年都会生产许多新机器。如果配置或判断逻辑是在代码中写入的，则对维护和迭代非常不利。

因此，我们有一个想法，可以将这些判断逻辑或配置放在云上吗？这创建了将云模型调整为网络的技术。

在推动和播放之前，终端将获得当前的模型配置，网络状态和通过协议报告的IP信息。云将返回最合适的编解码器策略配置：软或硬，各种参数的配置，附近流媒体服务的IP以及附近的播放服务的IP。它只需要一个在终端中获取它，并且在每个流或播放之前就不需要获取一次。

这样，尽管我们继续迭代和改进模型编解码器适应库，但使用此技术的所有实时广播应用程序都将受益。

总结

分析许多优化技术，用于在实时广播后端和终端中的低潜伏期和即时开放，在实时广播云上已经有相关的实践，它们都是更多的“静态”技术。实际上，它提供了稳定，低延迟和平稳的实时广播服务，这是由于日常生活中大量细致的监测，算法和动态操作的结果。这不是要实现一些技术要点，您可以享受稳定的现场直播服务。可以说，这是第一个完成长城的砖头。