このn属性は、フラグメントの 0 から始まるインデックスであり、新しいフラグメントごとに 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" />
rXML 要素を何度も複製しているだけと考えることができます。
編集：コメントに基づいて、混乱の原因を理解しました-問題は実際にこれらの属性が何であるかではなく、なぜライブストリームでは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、 は最初のフラグメントのインデックスです。これはライブ ビデオを表現する唯一の方法ではありませんが、マニフェスト内のデータのサイズが明らかに小さいため、最も効率的であることは間違いありません。