RTSP 2.0 | Поле общего заголовка Seek-Style

RTSP 2.0 | Поле общего заголовка Seek-Style

Общие заголовки RTSP 2.0 — это заголовки, которые могут использоваться как в запросах, так и в ответах. Общие заголовки RTSP 2.0 перечислены в таблице 1

Когда клиент отправляет запрос PLAY с заголовком Range для выполнения произвольного доступа к мультимедиа, клиент не знает, выберет ли сервер первые выборки мультимедиа или первую точку произвольного доступа до диапазона запроса. В зависимости от варианта использования клиент может иметь сильные предпочтения. Чтобы выразить это предпочтение и предоставить клиенту информацию о том, как сервер действовал на этом предпочтении, определяется общий заголовок Seek-Style.

 

Seek-Style — это общий заголовок, который МОЖЕТ быть включен в любой запрос PLAY, чтобы указать предпочтение клиента для любого медиапотока, который имеет свойства произвольного доступа. Сервер ДОЛЖЕН всегда включать заголовок в любой ответ PLAY для мультимедиа со свойствами произвольного доступа, чтобы указать, какая политика была применена. Сервер, который получает неизвестную политику стиля поиска, ДОЛЖЕН игнорировать ее и выбрать политику по умолчанию для сервера. Клиент, получающий неизвестную политику, ДОЛЖЕН игнорировать ее и использовать заголовок Range и любую информацию о синхронизации мультимедиа в качестве основы для определения того, что сделал сервер.

Эта спецификация определяет следующие политики поиска, которые могут быть запрошены (см. Также Раздел 4.7.1 из RFC 7826):

Политика поиска «RAP»

Точка произвольного доступа (RAP — Random Access Point) — это запрос сервера найти ближайшую предыдущую точку произвольного доступа, которая существует в совокупности мультимедиа, и доставить из нее. При запросе RAP качество мультимедиа будет наилучшим из возможных, поскольку все мультимедиа будут доставлены из точки, в которой в мультимедийном декодере может быть установлено полное состояние мультимедиа.

 

Политика поиска «CoRAP»

Условная точка произвольного доступа (CoRAP) является вариантом вышеуказанного поведения RAP. Эта политика в первую очередь предназначена для случаев, когда существует большее расстояние между точками произвольного доступа в среде. CoRAP использует политику RAP, если выполняется условие, что точка произвольного доступа находится ближе к запрошенной начальной точке, чем к текущей точке паузы. В противном случае поиск не будет выполнен, и воспроизведение продолжится с текущей точки паузы. Эта политика предполагает, что состояние носителя, существующее до паузы, можно использовать, если доставка продолжается. Если клиент или сервер знают, что это не так, следует использовать политику RAP. Другими словами, в большинстве случаев, когда клиент запрашивает начальную точку до текущей точки паузы, действительная цепочка зависимостей декодирования от носителя, доставленного до паузы, и к запрошенному элементу мультимедиа не будет существовать. Если сервер выполнил поиск в точке произвольного доступа, сервер ДОЛЖЕН вернуть политику CoRAP в заголовок Seek-Style и отрегулировать заголовок Range, чтобы отразить положение выбранного RAP. В случае, если точка произвольного доступа находится дальше и сервер выбирает продолжение с текущей точки паузы, он ДОЛЖЕН включить политику Next (Далее) в заголовок стиля поиска и настроить начальную точку заголовка диапазона в соответствии с текущей точкой паузы.

 

Политика поиска «First-Prior»

Политика первого приоритета (First-Prior) начнет доставку с медиа-блока, у которого есть время воспроизведения, предшествующее запрошенному времени. Для дискретных носителей это будет включать только те носители, которые будут отображаться во время запроса. Для непрерывных носителей это носители, которые будут отображаться в течение запрошенного времени начала диапазона.

 

Политика поиска «Next»

Следующие медиа-единицы после предоставленного времени начала диапазона: для медиа с непрерывным кадром это будет означать первый следующий кадр после предоставленного времени, а для дискретных медиа — первый блок, который должен быть воспроизведен после предоставленного времени. Основное использование в этом случае — когда клиент знает, что у него есть все мультимедиа до определенной точки, и хотел бы продолжить доставку, чтобы можно было добиться полного непрерывного воспроизведения мультимедиа. Примером такого сценария может быть переключение с широковещательной / многоадресной доставки на одноадресную доставку. Эта политика ДОЛЖНА использоваться только по явному запросу клиента.


Обратите внимание, что эти выраженные предпочтения существуют для оптимизации времени запуска или качества носителя. Политика Next нарушает обычное определение заголовка Range, чтобы позволить клиенту запрашивать мультимедийные данные с минимальным перекрытием, хотя некоторые могут все еще происходить для агрегированных сеансов. RAP и First-Prior выполняют требование предоставления медиа из запрошенного диапазона и вперед. Однако, если не используется RAP, качество мультимедиа для многих медиакодеков, использующих методы прогнозирования, может быть серьезно ухудшено, если не будут доступны дополнительные данные, например, уже буферизованные или через другие побочные каналы.

 

Синтаксис поля общего заголовка Seek-Style в RTSP 2.0

Seek-Style = "Seek-Style" HCOLON Seek-S-values
Seek-S-values = "RAP" / "CoRAP" / "First-Prior" / "Next" / Seek-S-value-ext
Seek-S-value-ext = token

Ссылки

Скачать оригинальный документ на английском языке RFC 7826 — Real-Time Streaming Protocol Version 2.0

Читать полную версию документа на русском языке RFC 7826 — Потоковый протокол в реальном времени (RTSP), версия 2.0

Ссылка на синтаксис