Нужны диаграммы

1. HLS, не ABR, Single Node
2. HLS, не ABR, в CDN
3. HLS ABR, Single Node (транскодинг на этой же ноде)
4. HLS ABR, в CDN (транскодинг на Edge)
5. HLS ABR, в CDN (транскодинг на Transcoder)

Добавить 200 OK

Диаграмма.

Добавить участника Client, который играет стрим.

Playing stream

Добавить 200 OK

Диаграмма.

Pushing RTMP

Добавить 200 OK

Добавить 200 OK

Добавить 200 OK

Диаграмма. Добавить 200 ОК.

По новым обозначениям должно быть так:

Publishing stream Pull stream Pulling stream Pull stream Pulling stream

Диаграмма.

1. Client устанавливает соединение с сервером.
2. Сервер /set_log_level
3. НА СЕРВЕРЕ пишется лог для соединения sessionId, поэтому log_level применяется к серверному логу и никак не действует на Client.

Тоже что 1 и 2 HLS. За основу просьба взять WebRTC ABR, где подписаны профили 720p, 360p

Замечания те же, что и к 1 и 2 HLS.

За основу просьба взять WebRTC ABR, показать что транскодинг на Транскодер - ноде, Edge пулит стрим с Транскодер, на Edge происходит конвертация HLS ABR.

Description

Замечания те же что и к диаграммам 1 и 2 HLS.

• Publishing stream
• Pulling stream
• Converting to HLS
• Playing HLS ABR chunks
• etc

Также просьба взять за пример WebRTC ABR, где показано что вначале идет транскодинг по профилям, и далее конвертация в ABR.

Description

HLS Player Publishing stream Remove label "Stream already published" Converting to HLS - процесс Pull stream Pulling stream - Edge никогда не забирает стрим с Origin по HLS. Playing HLS chunks

Конвертация в HLS происходит на Edge

Publishing stream - лэйбл не нужен, везде без лэйблов

Converting stream to HLS - пунктирная стрелка

Вместо участника Client будет HLS Player, потому что наш Client не умеет играть HLS, а подключается в основном по вебсокету.

Вместо Origin - WCS, т.к. эта диаграмма вне контекста CDN.

Варианты:

Playing HLS chunks Playing HLS Playing HLS segments

т. к. playlist для пользователя может путаться с плейлистом плеера, где много записей.

Publishing stream Playing stream Playing stream

Вопрос: файл 1 гигабайт будет загружаться и инжектиться прогрессивно? Если да, то:

Loading file - процесс пунктирной стрелочкой.

Если же ожидается полная загрузка файла перед инжектом, то - это запрос, сплошная стрелка.

Не отображается диаграмма

Не отображается диаграмма

Диаграмма. Последовательность.

1. startup
2. converting
3. 200 OK

Диаграмма

Pull RTMP

Play - т. к. стрим можно играть не только по WebRTC, например по RTSP или HLS

Playing stream - т. к. стрим можно играть не только по WebRTC, например по RTSP или HLS

Transcoding stream

Label: Transcoding width height, gop, etc.

RTMP - это протокол, в него не транскодируют.

ОК

Нужна диаграмма. Запись - это длительный процесс, который можно показать пунктирной стрелкой.

Request MP4 file - потому что Play, а не Plays

Downloading MP4 file - потому что процесс скачивания по HTTP может занять минуты, пунктирная стрелка.

Converting - пунктирная

1. Converting MP4 file to stream т. к. это процесс

2. Playing stream

3. Файл можно загружать с S3 или с HTTP Server Поэтому можно добавить участника:

S3 or HTTP

Диаграмма.

У нас стейт джоба завязан на агента, поэтому 200 OK вернет только тогда, когда агент без ошибок начнет Push.

Поэтому последовательность должна быть такой:

1. /startup
2. Pushing WebRTC
3. 200 OK

В остальном, вопросов нет.

Диаграмма.

Pulling RTSP stream - т. к. может быть audio+video stream.

Converting RTSP to internal stream

Playing stream - т. к, стрим можно играть не только по WebRTC, а например по RTMP или HLS

200 OK

Диаграмма - приввести к согласованному виду

Диаграмма:

Transcoding stream to target parameters - длительное действие

Publishing a stream

Playing stream - НЕ playback, НЕ Play, во всех схемах к одной терминологии

По диаграмме:

1. Publishing a stream

Т. к. стрим может быть любым, например RTMP

2. Republish stream as WebRtc ABR - не верно, т. к. републикации не происходит.

Converting stream to WebRTC ABR

Стрим конвертируется в WebRTC ABR по профилям, поэтому можно добавить текст - в какие профили стрим конвертируется, например:

profiles: 720p, 360p

4. Play WebRTC ABR stream - лучше обозначать процесс

Playing WebRTC ABR stream

Здесь также можно добавить, что играют те же два профиля:

profiles: 720p, 360p

Предлагаю добавить:

Converting stream to WebRTC ABR

Чтобы показать, что конвертация происходит на Edge, в то время как транскодинг происходит на Transcoder

Добавить 200 OK

Диаграмма.

Приводим к согласованному виду (стрелки, лэйблы).

Нужна диаграмма.

1. Client - соединяется с сервером по вебсокету.

2. В сторону Client передается конкретное вебсокет сообщение, насколько помню OnDataEvent (проверить)

Нужна диаграмма.

1. Client1 Client2 - соединяются с сервером по вебсокету.

2. В сторону Client передается конкретное вебсокет сообщение, насколько помню OnDataEvent (проверить)

Диаграмма.

• Удалить участников Edge/Injected Content, Original Stream

• Переименовать участника Client > REST Client

• Переименовать WCS Server > WCS

• Добавить участников Client, HTTP Server

• 202 в 200

и т. д

Переделать диаграмму под согласованные требования.

Нужна диаграмма

inject3 - инжектит статику inject2 - инжектит стримы

Поэтому у них будут разные диаграммы.

Диаграмма

1. На серевре выполняется Job
2. Приходит запрос на отмену.
3. Job завершается (отменяется).

Нужна диаграмма:

1. Client соединяется с сервером и имеет sessionId
2. Для этого коннекта включается лог.
3. Лог пишется на стороне сервера для этого sessionId

Диаграмма

Publishing stream1

/mixer/startup

Mixer output stream 'mixed_stream' is created

200 OK

/mixer/add

stream1 is added to mixed_stream

200 OK

Playing mixed_stream

Label: The mixed_stream contains stream1 content

Нужна диаграмма. В диаграмме должен быть участник ffmpeg, который публикует MPEG TS стрим на порт выделенный сервером и полученный в 200 OK.

Нужна диаграмма, которая показывает как несколько стримов записываются в один MP4 файл в виде треков (дорожек). В этом случае, оправдано было бы показать MP4 файл как отдельного участника, чтобы подробно расписать как его треки (аудио видео) заполняются стримами. Например, если пишем в MP4 два стрима, в файле бует 4 трека.

Также нужна диаграмма, если изменения применяются в реальном времени и зритель увидит например зеленый квадрат вместо красного.

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

Нужна диаграмма, которая позволяет визуализировать вставку звука.

По-сути это инжект звука в push/rtmp ногу.

Диаграмма.

Тот же вопрос что и push/webrtc

Последовательность должна быть:

1. /startup
2. converting
3. pushing
4. 200 OK

Еще должна быть вторая диаграмма, т.к. если в параметрах будут указаны настройки width, height, то пуш пойдет с Транскодингом, т.е. появится еще один длительный процесс Transcoding перед Converting.

Нужна диаграмма.

RELS метрики записываются в

1. Файловую систему.
2. Базу данных ClickHouse

ClickHouse - участник диаграммы.

Диаграмма. Что такое sfuCallback? Должно быть действительное вебсокет сообщение.

Например: webRtcMetricsUpdate (уточнить)

Диаграмма. Что такое sfuCallback? Должно быть действительное вебсокет сообщение.

Например: webRtcMetricsUpdate (уточнить)

Нужна диаграмма, т.к Event доходит до клиента. Например можно отправить сообщение через stream и его получат все подписчики стрима.

Кроме того, Event может пропагироваться до Edge через CDN, но этот функционал надо уточнить. Если есть то также нужна схема.

На диаграмме должно быть минимум Client 1, Client 2, т. к. диаграмма демонстрирует batch.

Диаграмму к согласованному виду

Здесь возможно два случая

1. Транскодирование для WebRTC ABR на Edge
2. Транскодирование для WebRTC ABR на Transcoder

Соответственно схемы будет две.

1. Publishing a stream
2. Pulling stream
3. Transcoding stream to profiles label: profiles: 720p, 360p
4. Converting stream to WebRTC ABR label: profiles: 720p, 360p
5. Playing WebRTC ABR label: profiles: 720p, 360p