Skip to content

Сессии (сеансы) проигрывания потоков во Flussonic

Содержание

  1. Понятие стриминговой сессии
  2. Жизненный цикл сессии
  3. Пример
  4. Cостояния сессии и события
  5. Данные о сессии
  6. Как использовать новые события
  7. Cобытия подключения к источнику
  8. Событие начала проигрывания

Понятие стриминговой сессии

Стриминговая сессия во Flussonic – это интерактивный обмен данными между Flussonic Media Server и внешней системой. Под внешней системой понимаются:

  • головная станция,
  • плеер,
  • другой сервер (Flussonic и не только) и т.п.

Сессия определяется продолжительностью, т.е. она устанавливается в определённый момент времени и позже завершается. Во время сессии по крайней мере одна из сторон сохраняет информацию о текущем состоянии и истории сессии, чтобы сообщение было возможным.

Сессия также характеризуется типом и состояниями. Тип сессии определяет направление потока и его иннициатора, а сама сессия от начала до завершения проходит через несколько состояний. Начинает (открывает) сессию инициатор, а завершение (закрытие) сессии может быть осуществлено любой из сторон: инициатором или приёмником.

Ниже мы расскажем, какие сессии существуют во Flussonic и что о них нужно знать.

Давайте рассмотрим следующий пример. Когда пользователь начинает смотреть телеканал, он начинает cессию play. Когда же он переключается на другой канал, это будет уже начало новой сессии. Проще говоря, один зритель и один телеканал — одна сессия.

До версии 21.02 сессии play были единственным видом сессий, которые были учтены в системе событий. Если Вы уже работали с системой авторизации, то этот тип сессий должен быть Вам знаком.

В версии Flussonic 21.03 появились новые типы сессий:

Мы объединили эти 4 типа сеансов передачи видео (ingest, publish, play, и push) в следующую таблицу:

Инициатор Во Flussonic Из Flussonic
Пользователь publish (приём публикации) play (проигрывание)
Flussonic ingest (захват) push (отправка)

Это можно представить в виде следующей схемы:

Типы передачи потока

Подробнее см. Виды передачи видео с участием Flussonic Media Server.

Жизненный цикл сессии

У Flussonic есть единый жизненный цикл всех типов сессий, перечисленных выше. У каждой сессии есть состояния, которые перетекают из одного в другое, вызывая связанные с ними события. Иными словами, сессия — последовательность состояний и вызываемых их сменой событий.

Название события сессии состоит из 2-ух частей (тип_сессии и тип_события), разделённых символом нижнего подчёркивания (_).
Например: play_opened (тип сессии: play, тип события: opened).

Для удобства сеансы ingest и publish генерируют события под одним и тем же именем: source.

Пример

Рассмотрим пример на основе play:

  • Пользователь делает первый запрос на HLS-поток. Событие play_opened генерируется при открытии нового сеанса play (событие opened).
  • Бэкэнд авторизации разрешает этот сеанс, вызывая событие play_authorized.
  • Плеер начинает приём сегментов. Как только количество принятых сегментов превышает пороговое значение, вызывается событие play_started.
  • Пока пользователь смотрит видео, периодически генерируется событие play_updated, которое можно использовать для сохранения информации о сеансе в Middleware.
  • По истечении некоторого времени ожидания после последнего запроса сессия считается закрытой, вызывая событие play_closed.

Этот процесс можно представить в виде следующей схемы:

Теперь мы можем перейти к общему случаю.

Cостояния сессии и события

Схема ниже представляет состояния во Flussonic, которые могут изменяться в течение сессии, а также события, которые могут генерироваться в связи с этим.

Note

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

Как происходит переход из одного состояния в другое?

Когда сессия открывается, т.е. переходит из состояния None в Establishing, то генерируется событие opened.
Состояние Establishing означает, что сессия ещё только подключается (событие connected), готовится, проверяет авторизацию (событие authorized), т.е. передачи потока ещё не происходит.

Сессия может завершаться, переходя в состояние Finished, с вызовом события closed.

Сессии вида publish и play в состоянии Establishing и Running могут вызывать событие authorized.

В состоянии Establishing сессия:

  • ожидает первый кадр или первый ключевой кадр от источника, если это сессия типа source(т.е. ingest/publish);
  • ожидает достаточного количества байтов, если это сессия типа play/push.

Затем сессия переходит в состояние Running, вызывая событие started.

В состоянии Running сессия периодически обновляется (updated), что позволяет отслеживать сессию. Используйте событие updated, чтобы обновить запись в базе данных для этой сессии, поскольку в таком случае предыдущая информация об этой сессии перезаписывается.

При смене входного или выходного битрейта или media_info в состоянии Running вызывается событие altered.

В состоянии Running событие overflowed может быть сгенерировано в 2-ух случаях:

  1. для play или push:
    Если не получается передавать данные с требуемой скоростью.

  2. для source (ingest/publish):
    Если протокол передачи видео сообщит об этом, как это делают RTSP/RTCP и SRT.

Если произошла остановка передачи данных, то осуществляется переход из состояния Running в состояние Stalling, который сопровождается вызовом события stalled. Это состояние возникает в том случае, если обратный переход в состояние Running потенциально возможен (такой переход сопровождается событием recovered).

Сессии, инициированные извне Flussonic (play и publish), должны проходить авторизацию во внешней системе. Эта внешняя система должна давать ответ на периодические запросы от каждой сессии и уметь останавливать сессию (с вызовом события denied).

Мы собрали все состояния и события в следующую таблицу:

Смена состояний Тип сессии Вызываемые события
None -> Establishing source (ingest/publish), play, push opened
[Establishing, Running] -> Finished source (ingest/publish), play, push closed
Establishing -> Establishing source (ingest/publish), play, push authorized (publish и play), connected
Establishing -> Running source (ingest/publish), play, push started
Running -> Running source (ingest/publish), play, push selected, updated, authorized, altered, overflowed
Running -> Stalling source (ingest/publish), play, push stalled
Stalling -> Running source (ingest/publish), play, push recovered

Данные о сессии

Данные сессий любого типа вы можете получить через API системы событий в виде JSON-объектов, отправленных по HTTP.

Приведём список параметров сессии.

Note

Этот список может быть изменен в будущем. Flussonic может передавать дополнительные недокументированные поля. Мы не рекомендуем их использовать, потому что они могут быть изменены или удалены в любой момент.

Имя поля Тип Описание
opened_at целое число, миллисекунды время создания сессии
id строковый uuid уникальный ID сессии
ip строковый ip peer IP (IP клиента, источника, push назначения, и т.д.)
proto строковый протокол протокол доставки видео
media строковое значение имя потока или файла
bytes целое число переданное число байт
duration целое число, миллисекунды длительность сессии (не меняется после события closed)
user_id строковый user_id сессии, переданный из auth backend (аутентификация бэкенда)
token строковый auth token, переданный пользователем

Как использовать новые события

Добавьте директиву notify в файл конфигурации (/etc/flussonic/flussonic.conf), например:

notify example {
  sink http://examplehost:5000/events;
  only media=example_stream;
}
stream example_stream {
  url fake://fake;
}

При такой конфигурации будут отправляться HTTP POST запросы с телом JSON, содержащим сеансы, описанные на странице выше.

Подробнее о настройке логирования событий см. Настройка логирования событий.

Cобытия подключения к источнику

В примере вы можете видеть ряд событий при подключении Flussonic к источнику:

  • source_connected — старт HTTP соединения ("status":"http_connect");

  • source_started — создание source_id=7ad153b1-68a5-4304-bbfd-b136603baebd;

  • stream_updated — обновление значений bytes, bytes_out для source_id=7ad153b1-68a5-4304-bbfd-b136603baebd.

[{
  "event":"source_connected",
  "event_id":1023,
  "id":"4f3c7cec-5c36-4670-921b-a0dcd4a6f0c8",
  "loglevel":"info",
  "media":"example",
  "priority":1,
  "proto":"tshttp",
  "server":"mk1.e",
  "status":{"status":"http_connect"},
  "url":"tshttp://127.0.0.1/fake/mpegts",
  "utc_ms":1614524093408
 },{
  "dts":93606612.44444445,
  "event":"source_started",
  "event_id":1027,
  "id":"4f3c7cec-5c36-4670-921b-a0dcd4a6f0c8",
  "loglevel":"info",
  "media":"example",
  "priority":1,
  "proto":"tshttp",
  "server":"mk1.e",
  "source_id":"7ad153b1-68a5-4304-bbfd-b136603baebd",
  "url":"tshttp://127.0.0.1/fake/mpegts",
  "utc_ms":1614524093414
 },{
  "bytes":0,
  "bytes_out":0,
  "event":"stream_updated",
  "event_id":1028,
  "id":"82c59180-e64e-42fc-8f11-2dec111ca5f7",
  "loglevel":"debug",
  "media":"example",
  "opened_at":1614524093399,
  "server":"mk1.e",
  "source_id":"4f3c7cec-5c36-4670-921b-a0dcd4a6f0c8",
  "utc_ms":1614524093415
  }]

Событие начала проигрывания

Когда клиент подключается к потоку по протоколу HLS, происходит вывод события play_opened:

[{
    "bytes":0,
    "country":null,
    "event":"play_opened",
    "event_id":1064,
    "id":"24b79b95-7400-4da2-bf9c-a855603baed1",
    "ip":"192.168.100.7",
    "loglevel":"debug",
    "media":"example",
    "opened_at":1614524113129,
    "proto":"hls",
    "query_string":"token=test",
    "referer":null,
    "server":"mk1.e",
    "source_id":"82c59180-e64e-42fc-8f11-2dec111ca5f7",
    "token":"test","user_agent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.192 Safari/537.36",
    "user_id":null,
    "user_name":"example",
    "utc_ms":1614524113129
   }]

Обратим внимание, что "source_id":"82c59180-e64e-42fc-8f11-2dec111ca5f7" — это тот же ID, что и в предыдущем примере. Все события связаны посредством этого самого параметра source_id.

Все события, связанные с сессиями, перечислены на странице Events API.