Запись манифеста клиента Azure: элементы n и r

Question

Просматривая манифест клиента, предоставляемый службами мультимедиа Azure для HTTP Smooth Stream, я заметил новый элемент (n), который не был найден в предыдущих манифестах IIS и отсутствует в блоге Сэма Чжана.

Согласно предыдущим манифестам (clientManifestVersion 2.2), r означает "повтор" и используется для сжатия - указывает длительность дублированного фрагмента.

Но сравнивая два манифеста Azure из одного и того же потока в разное время, вы можете увидеть:

`<c t="868948936" d="2000" r="1770" n="136" />`  // (@ 8:21 PM)
`<c t="881664896" d="2000" r="1770" n="6494"/>`  // (@ 11:53 PM)

Насколько я понимаю, d = 2000 обозначает длительность фрагмента (2 секунды)

И где:
n1 = 136
n2 = 6494,
t1 = 868948936
t2 = 881664896,

n2 - n1 = 6358 * d = 12716000 + t1 = t2

Even though r is supposed to be a repeat, r remains the same while n increases over time... So what is r if it is unchanging, and what is n?

Answer 1

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" />

Вы можете думать об этом просто как о дублировании элемента XML r количество раз.

Изменить: Основываясь на комментарии, я теперь понимаю источник путаницы - вопрос не в том, что на самом деле эти атрибуты, а почему, с живым потоком, делает только 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 это индекс первого фрагмента! Это не единственный способ представления живого видео, но он, безусловно, наиболее эффективен из-за очевидного небольшого размера данных в манифесте.