RTSP 2.0 | Метод PLAY

Методы RTSP 2.0 — это указание того, что должно быть выполнено на ресурсе, идентифицированном Request-URI на основании синтаксиса строки запроса RTSP, определённой как:

<Method> SP <Request-URI> SP <RTSP-Version> CRLF

Методы RTSP 2.0 перечислены в таблице 2.

В этом разделе описывается использование метода «PLAY» в целом, для агрегированных сеансов и в различных сценариях использования.

Общее использование

Метод «PLAY» указывает серверу начать отправку данных через механизм, указанный в SETUP, и какую часть мультимедиа следует воспроизвести. Запросы PLAY действительны, когда сеанс находится в состоянии готовности (Ready) или воспроизведения (Play). Запрос PLAY ДОЛЖЕН включать заголовок Session (раздел 18.49 из RFC 7826), чтобы указать, к какому сеансу применяется запрос.

После получения запроса PLAY сервер ДОЛЖЕН установить нормальное время воспроизведения на начало диапазона, указанного в принятом заголовке Range, в пределах медиаресурса и в соответствии с заголовком Seek-Style (раздел 18.47 из RFC 7826). Он ДОЛЖЕН доставлять потоковые данные до конца диапазона, если он задан, до получения нового запроса PLAY, до получения запроса PAUSE (раздел 13.5 из RFC 7826) или до достижения конца носителя. Если в запросе PLAY отсутствует заголовок Range, сервер ДОЛЖЕН воспроизводиться с текущей точки паузы до конца мультимедиа. По умолчанию точка паузы при запуске сеанса начинается с начала носителя. Для носителей, у которых время увеличивается и не сохраняется, точка паузы всегда будет установлена равной NPT «now» (сейчас), то есть текущей точкой доставки. Точка паузы также может быть установлена для определенной точки на носителе методом PAUSE; см. раздел 13.6 из RFC 7826. Точка паузы для медиафайлов, которые воспроизводятся в данный момент, равна текущей медиа-позиции. Для носителей с прогрессирующим временем и ограниченным во времени хранением, если точка паузы представляет позицию, которая старше, чем та, которую удерживает сервер, точка паузы будет перемещена в самую старую сохраненную позицию.

Какие значения диапазона допустимы, зависит от типа контента. Для контента, который не прогрессирует во времени, значение диапазона допустимо, если данный диапазон является частью какого-либо носителя в совокупности. Другими словами, допустимым диапазоном мультимедиа для агрегата является объединение всех компонентов мультимедиа в агрегате. Если данное значение диапазона указывает за пределы носителя, ответ ДОЛЖЕН быть кодом ошибки 457 (Недопустимый диапазон) и включать заголовок Media-Range (раздел 18.30 из RFC 7826) с допустимым диапазоном для носителя. За исключением контента с прогрессирующим временем, когда клиент запрашивает начальную точку до того, что сохраняется, начальная точка настраивается на самый старый сохраненный контент. Для начальной точки, которая находится за передним краем носителя, то есть за пределами текущего значения для «now», сервер ДОЛЖЕН настроить начальное значение на текущий передний край. Значение точки остановки заголовка Range может указывать за пределы текущей границы носителя. В этом случае сервер ДОЛЖЕН доставлять носитель из запрошенной (и, возможно, скорректированной) начальной точки до первой из предоставленной конечной точки или конца носителя. Обратите внимание, что если кто-то просто хочет играть с определенной начальной точки до конца носителя, РЕКОМЕНДУЕТСЯ использовать заголовок Range с неявной конечной точкой.

Если клиент запрашивает начало воспроизведения в конце носителя, либо явно с заголовком Range, либо неявно с точкой паузы, находящейся в конце носителя, ДОЛЖНА быть отправлена ошибка 457 (Недопустимый диапазон), которая включает заголовок Media-Range (Раздел 18.30 из RFC 7826). Ниже указывается, что заголовок Range также должен быть включен в ответ и что он будет переносить точку паузы на носителе в случае, когда сеанс находится в состоянии готовности. Обратите внимание, что это также применимо, если точка паузы или запрошенная начальная точка находятся в начале носителя и заголовок Scale (раздел 18.46 из RFC 7826) включен с отрицательным значением (воспроизведение в обратном направлении).

Для носителей со свойствами произвольного доступа клиент может указать, какую политику для выбора начальной точки должен использовать сервер. Это делается путем включения заголовка Seek-Style (раздел 18.47 из RFC 7826) в запрос PLAY. Примененный стиль поиска будет влиять на содержимое заголовка Range, так как он будет скорректирован, чтобы указывать, с какой точки медиа фактически доставляется.

Клиент, желающий воспроизвести мультимедиа с начала, ДОЛЖЕН послать запрос PLAY с заголовком Range, указывающим на начало, например, «npt = 0-». Если запрос PLAY получен без заголовка Range, и доставка мультимедиа в конце остановлена, сервер ДОЛЖЕН ответить ошибкой 457 (Invalid Range). В этом ответе текущая точка паузы ДОЛЖНА быть включена в заголовок диапазона.

Все спецификаторы диапазона в этой спецификации допускают диапазоны с неявной начальной точкой (например, «npt = -30»). При использовании в запросе PLAY сервер обрабатывает его как запрос на запуск или возобновление доставки с текущей точки паузы, заканчивающейся в время окончания, указанное в заголовке Range. Если точка паузы находится позже заданного конечного значения, ответ 457 (Недопустимый диапазон) ДОЛЖЕН быть возвращен.

В приведенном ниже примере будут воспроизводиться секунды с 10 по 25. Он также запрашивает у сервера доставку мультимедиа с первой точки произвольного доступа до указанной начальной точки.

C->S: PLAY rtsp://audio.example.com/audio RTSP/2.0 CSeq: 835 Session: ULExwZCXh2pd0xuFgkgZJW Range: npt=10-25 Seek-Style: RAP User-Agent: PhonyClient/1.2

Серверы ДОЛЖНЫ включать заголовок Range в любой ответ с методом PLAY, даже если в запросе отсутствует заголовок Range. Ответ ДОЛЖЕН использовать тот же формат, что и заголовок Range, содержащийся в запросе. Если в запросе не было заголовка Range, формат ДОЛЖЕН использоваться в любом предыдущем запросе PLAY в рамках сеанса. Если в предыдущем запросе формат не указан, сервер МОЖЕТ использовать любой формат времени, поддерживаемый носителем и указанный в заголовке Accept-Ranges в запросе SETUP. РЕКОМЕНДУЕТСЯ, чтобы NPT использовался, если поддерживается средствами массовой информации.

Для любого ответа об ошибке на запрос PLAY ответ сервера зависит от текущего состояния сеанса. Если сеанс находится в состоянии готовности, текущая точка паузы возвращается с использованием заголовка Range с точкой паузы в качестве явной начальной точки и неявной конечной точки. Для контента с прогрессирующим временем, когда точка паузы перемещается в реальном времени из-за ограниченного хранения, возвращается текущая точка паузы. Для сеансов в состоянии Play, текущая точка воспроизведения и остальные части запроса диапазона возвращаются. Для любого носителя с задержкой более 0 секунд действующий в настоящее время заголовок Media-Range ДОЛЖЕН также быть включен в ответ.

Ответ PLAY МОЖЕТ включать заголовок, несущий информацию синхронизации. Поскольку необходимая информация зависит от формата медиатранспорта, необходимы дополнительные правила, определяющие заголовок и его использование. Для RTP указывается заголовок RTP-Info, см. Раздел 18.45 из RFC 7826, и используется в следующем примере.

Вот простой пример для отдельного аудиопотока, где клиент запрашивает мультимедиа, начиная с 3,52 секунды и до конца. Сервер отправляет ответ 200 OK с фактическим временем воспроизведения, которое предшествует 10 мс (3,51), и заголовком RTP-Info, который содержит необходимые параметры для стека RTP.

C->S: PLAY rtsp://example.com/audio RTSP/2.0 CSeq: 836 Session: ULExwZCXh2pd0xuFgkgZJW Range: npt=3.52- User-Agent: PhonyClient/1.2

S->C: RTSP/2.0 200 OK CSeq: 836 Date: Thu, 23 Jan 1997 15:35:06 GMT Server: PhonyServer/1.0 Range: npt=3.51-324.39 Seek-Style: First-Prior Session: ULExwZCXh2pd0xuFgkgZJW RTP-Info:url="rtsp://example.com/audio" ssrc=0D12F123:seq=14783;rtptime=2345962545

S->C: RTP Packet TS=2345962545 => NPT=3.51 Media duration=0.16 seconds

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

В следующем примере клиент получает первый медиапакет, который растягивается до конца и превышает запрошенное время воспроизведения. Таким образом, клиент принимает решение, отображать ли пользователю время между 3,52 и 7,05 или пропустить его. В большинстве случаев, вероятно, наиболее целесообразно не отображать этот период времени.

C->S: PLAY rtsp://example.com/audio RTSP/2.0 CSeq: 836 Session: ZGGyCJOs8xaLkdNK2dmxQO Range: npt=7.05- User-Agent: PhonyClient/1.2

S->C: RTSP/2.0 200 OK CSeq: 836 Date: Thu, 23 Jan 1997 15:35:06 GMT Server: PhonyServer/1.0 Session: ZGGyCJOs8xaLkdNK2dmxQO Range: npt=3.52- Seek-Style: First-Prior RTP-Info:url="rtsp://example.com/audio" ssrc=0D12F123:seq=14783;rtptime=2345962545

S->C: RTP Packet TS=2345962545 => NPT=3.52 Duration=4.15 seconds

После воспроизведения желаемого диапазона презентация НЕ переходит в состояние готовности, доставка мультимедиа просто прекращается. Если необходимо перевести поток в состояние готовности, ДОЛЖЕН быть выполнен запрос PAUSE. Запрос PLAY, когда поток все еще находится в состоянии Play, является законным и может быть выдан без промежуточного запроса PAUSE. Такой запрос ДОЛЖЕН заменить текущее действие PLAY новым запрошенным, то есть обрабатываться так же, как если бы запрос был получен в состоянии готовности. В случае, если диапазон в заголовке Range имеет неявное время начала («-endtime»), сервер ДОЛЖЕН продолжать воспроизведение с того места, где он в данный момент находился, до указанной конечной точки. Это полезно для изменения конца в другой точке, чем в предыдущем запросе.

В следующем примере воспроизводится вся презентация, начиная с временного кода SMPTE 0:10:20 и до конца клипа. Примечание: заголовки RTP-Info разбиты на несколько строк, где последующие строки начинаются с пробела, как это разрешено синтаксисом.

C->S: PLAY rtsp://audio.example.com/twister.en RTSP/2.0 CSeq: 833 Session: N465Wvsv0cjUy6tLqINkcf Range: smpte=0:10:20- User-Agent: PhonyClient/1.2

S->C: RTSP/2.0 200 OK CSeq: 833 Date: Thu, 23 Jan 1997 15:35:06 GMT Session: N465Wvsv0cjUy6tLqINkcf Server: PhonyServer/1.0 Range: smpte=0:10:22-0:15:45 Seek-Style: Next RTP-Info:url="rtsp://example.com/twister.en" ssrc=0D12F123:seq=14783;rtptime=2345962545

Для воспроизведения записи живой презентации может быть желательно использовать единицы времени:

C->S: PLAY rtsp://audio.example.com/meeting.en RTSP/2.0 CSeq: 835 Session: N465Wvsv0cjUy6tLqINkcf Range: clock=19961108T142300Z-19961108T143520Z User-Agent: PhonyClient/1.2

S->C: RTSP/2.0 200 OK CSeq: 835 Date: Thu, 23 Jan 1997 15:35:06 GMT Session: N465Wvsv0cjUy6tLqINkcf Server: PhonyServer/1.0 Range: clock=19961108T142300Z-19961108T143520Z Seek-Style: Next RTP-Info:url="rtsp://example.com/meeting.en" ssrc=0D12F123:seq=53745;rtptime=484589019

Агрегированные сессии

Запросы PLAY могут работать в сеансах, управляющих одним медиапотоком, и в агрегированных сеансах, управляющих несколькими медиапотоками.

В агрегированном сеансе запрос PLAY ДОЛЖЕН содержать агрегированный контрольный URI. Сервер ДОЛЖЕН ответить ошибкой 460 (Разрешена только совокупная операция), если клиентский URI запроса PLAY предназначен для одного носителя. Медиа в совокупности ДОЛЖНЫ воспроизводиться синхронно. Если клиенту требуется индивидуальный контроль над мультимедиа, ему необходимо использовать отдельные сеансы RTSP для каждого мультимедиа.

Для агрегированных сеансов, в которых за первоначальным запросом SETUP (созданием сеанса) следует один или несколько дополнительных запросов SETUP, запрос PLAY МОЖЕТ быть передан по конвейеру (раздел 12 из RFC 7826) после этих дополнительных запросов SETUP, не ожидая их ответов. Эта процедура может уменьшить задержку от начала установления сеанса до начала воспроизведения мультимедиа с одним RTT. Однако клиент должен знать, что использование этой процедуры приведет к воспроизведению состояния сервера, установленного во время обработки PLAY, то есть после обработки всех запросов до запроса PLAY в конвейере. Это состояние может не соответствовать предполагаемому из-за сбоя любого из предыдущих запросов. Клиент может легко определить это на основе ответов на эти запросы. В случае сбоя клиент может остановить воспроизведение мультимедиа с помощью PAUSE и попытаться снова установить желаемое состояние, прежде чем отправлять другой запрос PLAY.

Обновление текущих запросов PLAY

Клиенты могут выдавать запросы PLAY, когда поток находится в состоянии воспроизведения, и, таким образом, обновлять свой запрос.

Важным отличием по сравнению с запросом PLAY в состоянии готовности является обработка текущей точки воспроизведения и способ построения заголовка Range в запросе. Сеанс активно воспроизводит мультимедиа, и точка воспроизведения будет перемещаться, что затрудняет прогнозирование точного времени запроса. В зависимости от того, как выглядит заголовок PLAY, существуют два разных случая: полная замена или продолжение. Полная замена сигнализируется тем, что первая спецификация диапазона имеет явное начальное значение, например, «npt = 45-» или «npt = 45-60», и в этом случае сервер останавливает воспроизведение в текущей точке воспроизведения и затем начинает доставлять медиа в соответствии с заголовком Range. Это эквивалентно тому, что клиент сначала отправляет PAUSE, а затем новый запрос PLAY, который не основан на точке паузы. В случае продолжения первый спецификатор диапазона имеет неявную начальную точку и явное конечное значение (Z), например, «npt = -60», которые указывают, что он ДОЛЖЕН преобразовывать спецификатор диапазона, воспроизводимый до этого запроса PLAY ( От X до Y) в (от X до Z) и продолжайте, как если бы это был первоначально исполненный запрос. Если текущая точка доставки находится за пределами конечной точки, сервер ДОЛЖЕН немедленно приостановить доставку. Поскольку запрос был успешно выполнен, на него должен быть дан ответ 200 OK. PLAY_NOTIFY с концом потока также отправляется для указания фактической точки остановки. Точка паузы установлена на запрошенную точку остановки.

Ниже приведен пример такого поведения: Сервер получил запросы на воспроизведение диапазонов от 10 до 15. Если новый запрос PLAY поступит на сервер через 4 секунды после предыдущего, он вступит в силу, пока сервер все еще воспроизводит первый диапазон (10-15). Сервер изменяет текущее воспроизведение, чтобы оно продолжалось до 25 секунд, то есть эквивалентный одиночный запрос был бы PLAY с «range: npt = 10-25».

C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0 CSeq: 834 Session: apzA8LnjQ5KWTdw0kUkiRh Range: npt=10-15 User-Agent: PhonyClient/1.2

S->C: RTSP/2.0 200 OK CSeq: 834 Date: Thu, 23 Jan 1997 15:35:06 GMT Session: apzA8LnjQ5KWTdw0kUkiRh Server: PhonyServer/1.0 Range: npt=10-15 Seek-Style: Next RTP-Info:url="rtsp://example.com/fizzle/audiotrack" ssrc=0D12F123:seq=5712;rtptime=934207921, url="rtsp://example.com/fizzle/videotrack" ssrc=789DAF12:seq=57654;rtptime=2792482193

C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0 CSeq: 835 Session: apzA8LnjQ5KWTdw0kUkiRh Range: npt=-25 User-Agent: PhonyClient/1.2

S->C: RTSP/2.0 200 OK CSeq: 835 Date: Thu, 23 Jan 1997 15:35:09 GMT Session: apzA8LnjQ5KWTdw0kUkiRh Server: PhonyServer/1.0 Range: npt=14-25 Seek-Style: Next RTP-Info:url="rtsp://example.com/fizzle/audiotrack" ssrc=0D12F123:seq=5712;rtptime=934239921, url="rtsp://example.com/fizzle/videotrack" ssrc=789DAF12:seq=57654;rtptime=2792842193

Обычное использование запроса PLAY в состоянии воспроизведения — это изменение масштаба мультимедиа, т. е. Вход или Выход из режима ускоренной перемотки вперед или назад. Клиент может выдать запрос на обновление PLAY, который является либо продолжением, либо полной заменой, как обсуждалось выше в этом разделе. Ниже приведен пример клиента, который запрашивает ускоренную перемотку вперед (масштаб = 2) без указания точки остановки, а затем переход от ускоренной перемотки вперед к обычному воспроизведению (масштаб = 1). Во втором запросе PLAY время задается явно так, чтобы сервер воспроизводил данные в данный момент (npt = now-), и сервер отвечает фактической точкой воспроизведения, где новый масштаб фактически вступает в силу (npt = 02: 17: 27.144- ).

C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0 CSeq: 2034 Session: apzA8LnjQ5KWTdw0kUkiRh Range: npt=now- Scale: 2.0 User-Agent: PhonyClient/1.2

S->C: RTSP/2.0 200 OK CSeq: 2034 Date: Thu, 23 Jan 1997 15:35:06 GMT Session: apzA8LnjQ5KWTdw0kUkiRh Server: PhonyServer/1.0 Range: npt=02:17:21.394- Seek-Style: Next Scale: 2.0 RTP-Info:url="rtsp://example.com/fizzle/audiotrack" ssrc=0D12F123:seq=5712;rtptime=934207921, url="rtsp://example.com/fizzle/videotrack" ssrc=789DAF12:seq=57654;rtptime=2792482193

[перемотка вперед и возврат к масштабу = 1]

C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0 CSeq: 2035 Session: apzA8LnjQ5KWTdw0kUkiRh Range: npt=now- Scale: 1.0 User-Agent: PhonyClient/1.2

S->C: RTSP/2.0 200 OK CSeq: 2035 Date: Thu, 23 Jan 1997 15:35:09 GMT Session: apzA8LnjQ5KWTdw0kUkiRh Server: PhonyServer/1.0 Range: npt=02:17:27.144- Seek-Style: Next Scale: 1.0 RTP-Info:url="rtsp://example.com/fizzle/audiotrack" ssrc=0D12F123:seq=5712;rtptime=934239921, url="rtsp://example.com/fizzle/videotrack" ssrc=789DAF12:seq=57654;rtptime=2792842193

Воспроизведение медиа по запросу

Носитель по требованию указывается содержимым заголовка «Media-Properties» в ответе SETUP, когда (см. Также раздел 18.29 из RFC 7826):

для свойства Random Access (Произвольный доступ) установлено значение «Random-Access»;
для свойства Content Modifications (Модификации содержимого) установлено значение «Immutable» (Неизменный);
для свойства Retention (Удержание) установлено значение «Unlimited» (Неограниченный) или «Time-Limited» (Ограниченный).

Воспроизведение мультимедиа по требованию следует общему использованию, как описано в разделе Общее использование.

Воспроизведение динамических медиа по запросу

Динамический носитель по требованию указывается содержимым заголовка «Media-Properties» в ответе SETUP, когда (см. Также раздел 18.29 из RFC 7826):

для свойства Random Access (Произвольный доступ) установлено значение «Random-Access»;
для свойства Content Modifications (Модификации содержимого) установлено значение «Dynamic» (Динамический);
для свойства Retention (Удержание) установлено значение «Unlimited» (Неограниченный) или «Time-Limited» (Ограниченный).

Воспроизведение носителей по требованию следует общему использованию, как описано в разделе Общее использование, если носитель не был изменен.

Клиент может быть информирован об изменениях медиаресурсов в состоянии Play двумя способами. Во-первых, клиент получит запрос PLAY_NOTIFY с заголовком Notify-Reason, установленным в media-properties-update (см. Раздел 13.5.2 из RFC 7826). Клиент может использовать значение заголовка Media-Range для решения дальнейших действий, если заголовок Media-Range присутствует в запросе PLAY_NOTIFY. Второй способ заключается в том, что клиент выдает запрос GET_PARAMETER без тела, но включает заголовок Media-Range. Ответ 200 OK ДОЛЖЕН включать текущий заголовок Media-Range (см. Раздел 18.30 из RFC 7826).

Воспроизведение медиа вживую

Живое мультимедиа указывается содержимым заголовка Media-Properties в ответе SETUP, когда (см. Также раздел 18.29 из RFC 7826):

Для свойства Random Access (Произвольный доступ) установлено значение «No-Seeking»;
Для свойства Content Modifications (Модификации содержимого) установлено значение «Time-Progressing» (Прогрессирование по времени);
Длительность свойства Retention (Удержание) «Time-Duration» установлена равной 0,0.

Для живого мультимедиа ответ SETUP 200 OK ДОЛЖЕН включать заголовок Media-Range (см. Раздел 18.30 из RFC 7826).

Клиент МОЖЕТ отправлять запросы PLAY без заголовка Range. Если запрос включает заголовок Range, он ДОЛЖЕН использовать символическое значение, представляющее «now» (сейчас). Для NPT эта спецификация диапазона — «npt = now-». Сервер ДОЛЖЕН включать заголовок Range в ответ, и он ДОЛЖЕН указывать явное значение времени, а не символическое значение. Другими словами, «npt = now-» не может использоваться в ответе. Вместо этого рекомендуется время с начала сеанса, выраженное в виде открытого интервала, например, «npt = 96,23-». МОЖЕТ быть дано абсолютное значение времени (часы) для соответствующего времени, то есть «часы = 20030213T143205Z-». Формат Абсолютного Времени можно использовать только в том случае, если клиент показал его поддержку с помощью заголовка Accept-Ranges.

Воспроизведение вживую с записью

Некоторые медиа-серверы могут предлагать своим клиентам услуги записи живых сеансов. Эта запись обычно происходит с начала медиа-сессии. Клиенты могут осуществлять произвольный доступ к мультимедиа с настоящего момента до начала мультимедийного сеанса. Этот живой носитель с записью указывается содержимым заголовка Media-Properties в ответе SETUP, когда (см. Также раздел 18.29 из RFC 7826):

для свойства Random Access (Произвольный доступ) установлено значение «Random-Access»;
для свойства Content Modifications (Модификации содержимого) установлено значение «Time-Progressing» (Прогрессирование по времени);
для свойства Retention (Удержание) задано значение Time-Limited или Unlimited.

Ответ SETUP 200 OK ДОЛЖЕН включать заголовок Media-Range (см. Раздел 18.30 из RFC 7826) для этого типа медиа. Для живых носителей с записью заголовок Range указывает текущую точку доставки на носителе, а заголовок Media-Range указывает текущее доступное окно мультимедиа около текущего времени. Это окно может охватывать записанный контент в прошлом (если смотреть с текущего времени на носителе) или записанный контент в будущем (если смотреть с текущего времени на носителе). Сервер настраивает точку доставки в соответствии с запрошенной границей окна. Если клиент запрашивает точку доставки, которая находится за пределами окна записи, например, если запрошенная точка находится слишком далеко в прошлом, сервер выбирает самую старую точку в записи. Соображения в разделе 13.5.3 из RFC 7826 применяются, если клиент запрашивает доставку со значениями масштаба Scale (раздел 18.46 из RFC 7826), отличными от 1,0 (нормальная скорость воспроизведения), во время доставки живого мультимедиа с записью.

Воспроизведение вживую со сдвигом времени

Некоторые медиасерверы могут предлагать услуги смены времени своим клиентам. Этот сдвиг по времени записывает фиксированный интервал в прошлом, то есть механизм записи скользящего окна, но не пропускает этот интервал. Клиенты могут получить произвольный доступ к мультимедиа между моментом и интервалом. Этот живой носитель с записью указывается содержимым заголовка Media-Properties в ответе SETUP, когда (см. Также раздел 18.29 из RFC 7826):

для свойства Random Access (Произвольный доступ) установлено значение «Random-Access»;
для свойства Content Modifications (Модификации содержимого) установлено значение «Time-Progressing» (Прогрессирование по времени);
для свойства Retention (Удержание) задано значение Time-Duration и значение, указывающее интервал записи (> 0).

Ответ SETUP 200 OK ДОЛЖЕН включать заголовок Media-Range (см. Раздел 18.30 из RFC 7826) для этого типа медиа. Для живых носителей с записью заголовок Range указывает текущее время на носителе, а заголовок Media-Range указывает окно вокруг текущего времени. Это окно может охватывать записанный контент в прошлом (если смотреть с текущего времени на носителе) или записанный контент в будущем (если смотреть с текущего времени на носителе). Сервер устанавливает точку воспроизведения в соответствии с запрошенной границей окна, если клиент запрашивает точку воспроизведения, которая находится за пределами окон записи, например, если запрошен слишком далеко в прошлом, сервер выбирает самый старый диапазон в записи. Соображения в разделе 13.5.3 из RFC 7826 применяются, если клиент запрашивает доставку с использованием значения шкалы Scale (раздел 18.46 из RFC 7826), отличного от 1,0 (нормальная скорость воспроизведения), при доставке живого мультимедиа со сдвигом по времени.

Ссылки на документы

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

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

Общее использование
Агрегированные сессии
Обновление текущих запросов PLAY
Воспроизведение медиа по запросу
Воспроизведение динамических медиа по запросу
Воспроизведение медиа вживую
Воспроизведение вживую с записью
Воспроизведение вживую со сдвигом времени