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

Содержание¶

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

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

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

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

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

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

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

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

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

publish — сессия, когда пользователь публикует видео с веб-камеры или из OBS.
ingest — сессия, когда Flussonic осуществляет захват указанного вами источника, например, IPTV (udp://, tshttp:// и т.д.), IP-камера (rtsp://) или иной (rtmp://, shout:// и т.д.).
push — сессия, когда Flussonic копирует поток на другой сервер или в другой сервис, например, на Youtube, Facebook, или отправляет поток в мультикаст-группу.

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

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

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

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

Сессии во Flussonic могут быть описаны с помощью OpenAPI 3.0 (читайте подробнее здесь). Справочник нашего публичного API с описанием всех его методов доступен здесь.

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

У 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-ух случаях:

для play или push:

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

для 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`

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

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

event_sink example {
  url http://examplehost:5000/events;
  only media=example_stream;
}
stream example_stream {
  input 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.

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