通常，观看直播通常更关注视频质量和直播延迟。在某些情况下，对于实时广播延迟，它可能不是那么高，但是互动式实时广播中的实时广播延迟非常重要。这是不可接受的。
上图显示了不同实时广播方案的延迟。我们可以发现最低的延迟是WebRTC，但是WebRTC通常不能支持大型用户同时观看实时广播。这篇文章将在图中介绍低LATENECY HLS LIVE方案，以确保它被延迟了。3秒。
HLS是Apple在2009年提出的基于HTTP的流媒体协议。不了解HLS的学生可以首先看到原始视频网站（例如AI Youteng）使用此文章来播放本文。简单的理解。
一开始，苹果从倒数第二个视频剪辑开始，建议使用HLS视频剪辑10秒（现在建议使用6秒）。如果您遵循此建议配置，则实时广播的延迟将在30秒内使用。这是上图上图中最高的延迟位置。
为了减少延迟，一种非常简单的方法是直接缩短视频片段的长度。例如，将视频片段缩短到3秒。使用此非常短的视频剪辑，实时广播延迟可以减少到大约10秒钟。
当然，延迟在大约10秒内仍然很高，因此有些人提出了一个社区低延迟计划，这称为lhls.lls。下面详细介绍。
LHLS也称为Cl-HLS，这不是标准规范，而是社区驱动的HLS低延迟解决方案。最早的潜望镜团队在2017年发布了一个博客，该博客在2017年发表了该概念，并提出了这一概念。法人与一些流媒体制造商合作，以规范该计划的低latence HLS流媒体。
LHLS如何实现低延迟直播？您可以看到下面的图片，其中之一是8秒。
现在总共生成了3个视频剪辑。第四个视频剪辑已生成3秒钟。因为只有在完全生成视频片段才能下载视频片段。因此，我们有以下不同的方法播放此播放列表。
可以发现上述三个方案的延迟非常高。第三个方案延迟略低，但延迟太高。
LHLS方案是将视频片段分成一个小块。它不需要等待整个视频片段生成。每次生成块时，都会下载到播放器以缓存。
具体而言，LHLS是使用HTTP/1.1的块状传输编码函数。玩家将保持与服务器的连接。每当服务器生成块时，它将直接传递给播放器，直到所有视频片段被传输并在破裂之前被打破。
社区解决方案的主要问题之一是，进行ABR自适应代码速率切换并不容易，因为与服务器的连接是长时间的连接，并且客户端不好估计当前用户的网络带宽。为了解决此问题测试当前的网络速度。
在社区规格中引入了两个自定义标签。与该功能相同，但不能放置在上面，必须将其变成它。
该规范与HLS标准规格完全兼容。对于支持此规范的玩家，他们可以选择使用它们来延迟实时广播。对于不支持玩家，他们会忽略这些标签，并成为延迟的现场广播。
以下是LHLS M3U8文件的示例。
我们可以找到除最后两行以外，这与普通的M3U8文件没有什么不同。ALHLS M3U8至少包含一个，并且不超过两个标签。在标签后面遵循URL，它是尚未生成的一部分。
播放器支持LHLS将直接发送两个HTTP请求，并请求请求。服务器将维护这两个请求并不断发送块。
一些学生可能会问，如果连接没有断开连接，但是如果连接接收数据，该怎么办？此时，玩家必须在内部保留这些数据，直到上一个请求完成。
那么谁在使用LHLS低潜伏期计划？上面提到的最早的潜望镜团队上面提到的计划是由Twitter收购的，然后关闭了。
但是，在国外非常著名的Twitch正在使用此解决方案。它尚未根据社区规格实施，而是添加了一些自定义的东西，例如它代替了它，并且可以直接应用。
那么，Twitch的实时广播延迟是什么？我决定开设一个直播房间并自己尝试。
但是，注册帐户被困在第一步。
输入无数密码后，最终有一个令人满意的系统。
推动OBS，输入我自己的直播房间后，您可以看到我推出的1080p实时广播，延迟约为5秒。
LL-HLS代表了苹果的低估计划，该计划也被称为ALHLS。在2019年WWDC上，苹果介绍了其官方HLS低潜伏期解决方案。Apple发布的低潜伏期方案没有从社区低潜伏期计划的结果中学习，而是重新设计了一组低潜伏期解决方案。Apple的目标是在1到2秒内延迟，以支持大型用户的实时广播，并且可以完全兼容。
在阅读了苹果的解决方案后，每个人都不稳定，因为苹果的解决方案提到HTTP2需要需要的推动功能，但是此功能的大部分也没有实现，并且此功能与传统解决方案有很大不同。最终，Apple最终决定从规格中删除HTTP2推动功能，并添加标签而不是函数。
与LHL相比，LLHLS方案大大改善。LLHLS总共添加了5个修改，即部分段，请求长连接，增量更新，预加载和快速重量切换。以下功能将详细介绍。
此外，由于苹果公司推出了官方的HLS低 - 德莱规格，因此社区立即放弃了社区规范，并删除了相关代码以实现LLHLS规范。
llhls将视频片段细分作为一个小段，视频片段由多个小片段组成。从字面上，您需要等待一个视频剪辑完全生成以便下载。例如，片段为6秒，客户需要等待6秒才能下载它。
现在，服务器将片段分为多个小段。例如，一个小部分为200毫秒。然后，视频片段包含30个小片段。客户只需要等待200毫秒即可下载这些小细分市场。
可以发现该方法与社区解决方案非常相似。社区解决方案是将视频段分成小块，并通过HTTP/1.1块的传输编码功能下载给客户。LLHLS是将视频片段分为小细分市场，并通过普通的HTTP请求下载这些小段。
有两个与小段有关的标签。
Ext-X-Part-Inf提供有关播放列表中小段的信息。如果播放列表中有标签，则必须提供此标签。
该标签只有一个必须 - 超越属性，其值是浮点，并且单元为秒。和标签类型，此属性代表小段的目标持续时间。
Ext-X-PART标签与该标签相似，该标签用于声明一个小段，该段总共具有5个属性。
应该注意的是，如果标签包含属性，则客户端不应请求此资源。客户需要解决如何单独跳过此差距。Apple Player的方法是延长上一帧的播放持续时间。
以下是完整的LLHLS播放列表的示例。
可以发现，LLHLS播放列表中有很多部分。为了防止太多小细分市场，服务器将定期清理旧的小细分市场。
先前的请求HLS播放列表是启动普通HTTP获取请求的客户端，然后服务器返回M3U8文件。
现在允许LLHLS在请求列表时添加查询条件。服务器支持这些功能是通过标签设置它，然后是标签背后的属性列表，以指示服务器支持的哪些条件查询。
目前，LLHLS总共支持3个查询参数，即和谐。通过它们可以实现不同的功能，将在下面详细介绍特定参数含义。
在HLS实时广播中，我们需要经常请求播放列表文件以检查是否添加了新的视频剪辑，这非常浪费时间和资源。在llhls中，服务器可以连续保持此连接，并且请求不是完成直到客户需要。
服务器支持此功能，并需要标签中的属性。
要告诉服务器何时完成请求，您需要使用和两个查询条件。如果服务器只需要生成下一个视频片段，则请求可以发送以下请求。
它用于控制在返回请求之前指定片段或指定片段之后包含片段的服务器播放列表。控制服务器播放列表包含哪些指定片段的小片段返回到请求。视频剪辑为6秒，小段为1秒。然后，该视频片段由总计0到5的一小部分组成。
应该注意的是，它可以单独使用并且必须与之一起使用，否则服务器将返回400个错误。当太多的服务器超过最新一代片段时，将返回400个错误。
如果包含播放列表，则将忽略服务器和两个参数。
在HLS实时广播中，每次我们刷新播放列表时，我们都会包含一些我们已经知道的旧片段信息。，2和3。我们可以发现我们知道1和2米德尔。
LLHLS提供播放列表增量更新功能。我们可以告诉服务器可以跳过哪些剪辑，并且不需要将其包括在播放列表中，从而减少了传输损失。
为了支持增量更新功能，需要标签包含属性。它还可以包括必须一起使用的属性，这意味着它是否可以跳过旧标签。
属性的值是小数浮点，单元为秒。该值至少是目标的6倍。它指示跳跃部分的边框。
要启动播放列表的增量续订请求，您需要包括查询参数。
值为或指示旧段被跳过。指示跳过旧剪辑和旧标签（要求服务器返回）。
应该注意的是，当客户端没有完整的播放列表或当前播放列表太长时，跳过边界就太长了。您应该使用完整的查询而不是增量查询。
当播放列表是增量更新时，播放列表将包含标签。该标签只有两个属性。这意味着视频片段的数量和哪些Datenge ID已跳过。
这是增量更新的示例。
可以发现上面的示例跳过了3个视频剪辑。跳过的视频片段的MSN分别为266、267和268。
LLHLS还具有视频剪辑的预加载函数，这表明尚未创建视频剪辑，但客户端请求它。此功能与社区解决方案非常相似。
与此功能相关的标签是其背后有4个属性，并带有属性列表。
当客户端遇到此标签时，您可以选择是否直接请求此资源。服务器将像上述请求长连接一样维护此请求，并返回资源直到整个资源数据可用。当然，可以直接返回404。
使用HLS的优点之一是可以通过自适应代码速率切换。根据当前的网络速度，屏幕尺寸和其他信息，选择最适合用户的当前环境代码速率。在LLHLS中，Apple提供了一个可以快速切换代码的函数。
通过标签，服务器使用与当前媒体类型播放列表中的主要播放列表中当前流媒体列表相关的流条件。该标签共有3个属性。
每个视频流可能与。该标签提供了此信息。我们不需要要求那些向后流，这可以减少许多不必要的请求。
客户应该在哪里面对播放列表，我应该从哪里开始玩？离锚位置越远，缓冲区越接近锚点的当前位置，这很容易引起口吃。
上面介绍的标签可以解决此问题。该标签有两个属性。这两个属性是服务器推荐的实时广播的起始位置。
当有属性时，客户端应忽略属性。如果播放列表包含标签，则必须具有属性。
CDN通常具有缓存，因此如何获得最新版本的播放列表？Apple提供了解决方案。
当然，您还可以实现自己的算法来获取最新版本的播放列表，例如，计算此列表。
它的最小值在目标长度和响应头和零件目标延迟之间的差之间的最小值为1.5倍，然后计算出目标延迟。然后计算出和两个查询条件的参数。
苹果推荐的视频剪辑的长度为6秒。部分细分期间的建议设置将设置为1秒，并将共和党推荐设置为1到2秒。建议开始至少3个零件目标。
由于LLHLS相对较新，因此我不知道使用了哪个实时广播平台，但是那些流媒体服务制造商已经实施了LLHL。
在WOWZA的低延迟解决方案中，包括Apple低延迟HLS解决方案，并且在其官方网站演示视频中有实时广播延迟。
在演示视频中将零件小段长度设置为0.4秒，并在0.8秒内设置。然后使用支持LLHLS进行实时流的Theoplayer。可以发现只有1.7秒的延迟。
本文介绍了两个HLS实时广播方案，LHLS社区解决方案和LLHLS官方解决方案，它们可以提供良好的低删除现场直播广播。将支持它，官员将继续保持该解决方案的扩展。此外，在设置实时广播延迟时，必须考虑特定的使用情况。延迟越低，越好，但也会导致较低的缓存并容易导致活着。