该n属性是片段的从零开始的索引，每个新片段增加 1。只是一个无意义的计数器：0、1、2、3、4，...
该r属性表示r在当前分片之后有更多具有相同持续时间的分片。它允许您替换它：
<c t="1000" d="1000" />
<c t="2000" d="1000" />
<c t="3000" d="1000" />
<c t="4000" d="1000" />
有了这个更紧凑的表示：
<c t="1000" d="1000" r="3" />
您可以将其视为只是r多次复制 XML 元素。
编辑：根据评论，我现在了解了混乱的根源——问题实际上不在于这些属性是什么，而是为什么直播流只会n随着时间的推移而改变。
要理解这一点，您必须了解实况视频在概念上的表示方式以及这与点播视频有何不同。后者有明确的开始和结束，中间有固定数量的片段：
(start)123456789(end)
而根据定义，实时视频是一个没有结尾的视频 - 可能有一个“最后一个片段”，但新的片段会不断添加到结尾，而当前的“最后一个片段”会随着时间的推移而改变：
(start)1234
(start)12345
(start)123456
现在这一切都很好而且超级好，但你可能会注意到这里有一个问题。自适应流媒体技术允许您播放视频的任何片段。如果您的视频基本上永远持续播放，那么源服务器必须有效地存储无限数量的片段！这是不允许的。
为了解决这个问题，自适应流媒体技术引入了DVR 窗口的概念- 视频上的滑动窗口，其中包含玩家可以查看的所有数据。任何超出此窗口范围的数据都可以丢弃。
(start)[1]
(start)[12]
(start)[123]
(start)1[234]
(start)12[345]
(start)123[456]
(start)1234[567]
(start)12345[678]
(start)123456[789]
让我们丢弃我们不需要的片段，看看它的样子。如果您的滑动窗口大小为 3，那么玩家可见的片段将按如下方式进行：
1
12
123
234
345
456
您注意到滑动窗口的大小保持不变（一旦有足够的片段可以填充它）并且第一个片段的索引加上滑动窗口大小足以表示整个滑动窗口。
你有它：r是滑动窗口中的片段数，n是第一个片段的索引！这不是表示实时视频的唯一方法，但它肯定是最有效的，因为清单中的数据明显较小。