~~в getUserData нет status: ESTABLISHED, этот статус возникает только на клиенте. поэтому ws.data: {status:ESTABLISHED} выглядит лишним.~~

статус есть в getUserData, хотя SDK поднимает статус ESTABLISHED наверх, не проверяя это значение, по факту получения и обработки getUserData

о каком другом протоколе речь? как воспроизвести кейс вручную?

Этот функционал вообще работает? Не помню такого метода в WebSDK, автоматической документации на него тоже нет, нужно проверифицировать

Этот функционал еще работает? Не вижу в WebSDK метода для отправки SIP сообщений. Нужно проверифицировать

WebRTC и Flash здесь нет, только SIP

состав параметров не соответствует хуку. RegistrationStatusEvent выглядит так (пример из логов сервера) OBJECT: { "nodeId" : "f02vkq9PbK9A8MrBnKatCK9clLbHbPyR@95.191.130.39", "appKey" : "defaultApp", "sessionId" : "/5.129.23.83:53866/95.191.130.39:8443-caab56ae-481a-484e-8ca6-ff8a47456080", "status" : "REGISTERED" }

о каком другом протоколе речь? как воспроизвести кейс вручную?

здесь должно быть Hook type: notify это работает не только для WebSDK, но и для других, там тоже есть метод sendData

Этот функционал вообще работает? Не вижу на стороне клиента каких-либо методов. Нужно проверифицировать.

ConnectionStatusEvent содержит разный состав полей для различных кейсов: WebRTC, Flash, SIP

и кейса Status там точно нет

рекомендуется протестировать вручную и посмотреть, как это работает

на диаграмме не хватает connect от клиента к серверу

иначе непонятно, откуда взялось SIP REGISTER

не TCP connect, просто connect, т.к. SIP REGISTER мы отправляем не только по факту websocket connect, там еще идет сигналинговое сообщение connection с параметрами регистрации

этот функционал вообще работает?

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

если это легаси, лучше будет его из документации убрать вообще

это не информационное сообщение, это управление потоком (остановка потока на стороне сервера) документация здесь: https://docs.flashphoner.com/static/WCS53/Streaming_video_functions/Captured_stream_management/Stopping_the_video_stream_on_the_server_side/

нужно скорректировать описание и диаграмму

лучше показать пример остановки стрима: 1. верхняя стрелка оставляем только publishing stream 2. бэкенд отвечает 403 Forbidden 3. от клиента к серверу перечеркнутая стрелка publishing stream 4. от сервера к клиенту стрелка Notify stream status (FAILED)

если приходит 200 OK, сервер ничего с потоком не делает, но если приходит что-то иное (в клиентской доке мы рекомендуем 403, т.к. это ближе всего по смыслу), сервер останавливает медиасессию, клиент получает нотификацию StreamStatusEvent с FAILED

диаграмма:

1. Пунктирная стрелка от клиента к серверу Publishing stream
2. Пунктирная стрелка от сервера ко второму клиенту Playing stream
3. Стрелка от паблишера к серверу Mute stream audio
4. Стрелка от сервера к паблишеру audioMuted
5. POST /apps/DefaultApp/StreamEvent к бэкенду и т.д.

Вообще, зеленый квадратик желательно расшифровывать во всех случаях

Стрелка audioMuted должна быть от сервера к зрителю, а не к паблишеру

диаграмма:

Речь идет об отправке данных с одного клиента многим клиентам https://flashphoner.com/docs/api/WCS5/rest_api/latest/v3/#tag/Data/operation/sendData

1. От клиента к серверу POST /data/send
2. Рисуем второго клиента, к нему OnDataEvent
3. Дальше POST /apps/DefaultApp/DataStatusEvent на бэкенд и т.д.

На диаграмме не хватает пунктирной стрелки от клиента к серверу Publishing stream

также Unpublish stream лучше заменить на Stop publishing

Метод WebSDK Session.submitBugReport() принимает на вход JSON объект. Не факт, что упаковка вообще поддерживается. Нужно проверить, как работает функционал, и скорректировать описание.

Здесь на диаграмме не хватает пунктирной стрелки от сервера к клиенту Playing stream

stopStream идет только доя PLAYING сессий, для PUBLISHING есть свой хук unPublishStream

На диаграмме выглядит так, что 200 OK в сторону REST клиента уходит (ну или статус задания меняется на DONE) только после срабатывания хука. Необходимо проверить, так это или нет, и, если не так, то скорректировать диграмму

Здесь на диаграмме можно уточнить, что на клиенте вызывается метод Session.startDebug

Этот хук предназначен только для аутентификации https://docs.flashphoner.com/static/WCS53/Streaming_video_functions/Playing_a_video_stream_from_the_server/In_a_player_via_RTSP/#rtsp_playback_authentication_via_rest_hook

URL, имя и другие параметры стрима при этом не меняются. В custom передаются параметры, которые должны проверяться (например, accessKey)

Этот хук предназначен только для аутентификации https://docs.flashphoner.com/static/WCS53/Streaming_video_functions/Playing_a_video_stream_from_the_server/In_a_browser_via_HLS/#hls_playback_authentication_using_rest_hook

URL, имя и другие параметры стрима при этом не меняются. В custom передаются параметры, которые должны проверяться (например, accessKey)

Этот хук работает не только для Websocket (DefaultApp), но и для cdnApp, и для falshStreamingApp. Во всех случаях триггером служит сам факт установки TCP соединения. Поэтому правильнее будет не заостряться именно на Websocket

диаграмма:

1. Open Websoket and sebd connect меняем на TCP connect

Неверно. call - это звонок, инициированный клиентом, а не входящий звонок. См метод WebSDK Call.call()

диаграмма:

1. Стрелка от PBX к серверу SIP INVITE
2. Стрелка от сервера к клиенту Incoming call notification
3. И т.д.

диаграмма:

1. Пунктирная стрелка от клиента к серверу Publishing stream
2. POST и 200 OK остаются
3. Notify stream status (PUBLISHING)

Claude не разобрался, откуда этот хук берется. надо разобраться и поправить формулировку и диаграмму

исходным событием должен быть вызов Session.startDebug() на стороне клиента (WebSDK). возможно, этот функционал уже и не работает, нужно проверифицировать.

диаграмма:

1. От клиента к серверу пунктирная стрелка Publishing stream
2. От клиента к серверу стрелка POST /recorder/startup
3. Далее POST /apps/DefaultApp/RecordingStatusEvent к бэкенду и т.д.

и надо проверифицировать, отправляется ли этот хук, не помню, чтобы видел его в логах сервера

диаграмма:

Send data меняем на POST /data/send

диаграмма: Перед ConnectionStatusEvent нужно показать какое-то событие сессии. Например, перечеркнутая стрелка от клиента к серверу с надписью Disconnect.

не показываем внутренние объекты, это внешняя документация

диаграмма: 1. Показываем от клиента к WCS /v3/call/startup 2. Показываем от WCS к PBX стрелку с подписью Call established 3. Дальше остается POST в сторону бэкенда и т.д.

не показываем внутренние объекты, это внешняя документация

диаграмма: 1. Убрать Create Connection instance. Мы не показываем внутренние процессы сервера. 2. После Apply backend updates пунктирная стрелка в сторону клиента с подписью Connected 3. Убрать Create Stream instance 4. После Apply backend updates пунктирная стрелка от клиента к серверу с подписью Publishing stream

to notify an external system...

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

vod://s3/bucket/sample.mp4 после s3 нет двоеточия

маршруты показываются и для профилей поэтому можно так: The name of the stream published to Origin, or stream name by profile to inspect its delivery route

в мастере примеры для текстовой ватермарки и картинки разделены, лучше, чтобы при мерже это не потерялось

в мастере примеры для текстовой ватермарки и картинки разделены, лучше, чтобы при мерже это не потерялось

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

body area -> mixed stream area

очень мелкая диаграмма

возможно, стрелка Playing stream1 должна быть выше, чем POST /inject2/startup. так нагляднее показывается, что поток заменяется у существующих зрителей, а не у новых

двойные стрелки между нодами на диаграмме можно с одной нодой показать incoming, с другой outgoing

это не сигналинговые каналы, а WebRTC каналы при cdn_agent=rtmp их показывать не будет

здесь решили диаграмму не дублировать?

обычно у нас с одной нодой один коннект: либо incoming, либо outgoing поэтому на диаграмме можно оставить только incoming connection

то же, что для reset_inbound: у нас не может быть двух коннектов с одной нодой для этого случая нужно еще одну ноду на диаграмму добавить

не грузится лого (в консоли 404 Failed to load resource)

Добавить 200 OK

на диаграмме нет REST запроса

нельзя ли уменьшить размер диаграммы? видимо, оттого, что мало элементов, ее сильно раздувает на экране

Сам ClickHouse ничего не собирает. Поэтому:

• Pushing RELS metrics
• Saving RELS metrics
• Sending RELS metrics

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

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

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

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

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

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

Publishing stream Playing stream Playing stream

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

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

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

Диаграмма.

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

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

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

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

• 202 в 200

и т. д

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

Замечания те же, что и к 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

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

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 для пользователя может путаться с плейлистом плеера, где много записей.

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

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

200 OK

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

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

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

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

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

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

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

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

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

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

Transcoding stream

Label: Transcoding width height, gop, etc.

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

Диаграмма.

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

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

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

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

Диаграмма

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

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

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

Диаграмма

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

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

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

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

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

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

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

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

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

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

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

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

Диаграмма.

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

У диаграммы порезанный RTMP/WebRTC/RTPS

Мне кажется, для акцента можно использовать выделение, как в Markdown с помощью апострофов

~~Тут разве не может быть 404 Not found?~~

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

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. startup
2. converting
3. 200 OK

Диаграмма

Pull RTMP

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

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

ОК

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

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

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

Диаграмма:

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

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

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

Move to the very bottom of the page below the works cited and continuously update based on newly explicit directions/protocol

WAY too long of a parenthesis. Restructure this sentence so that the examples come after the point.

Link to the comment on the site. It should be archived via: Evidence Index

Clumsy unclear phrasing. Revise!

rephrase the end of the sentence to connect with the subsequent verb of treating...

Remove accordion dropdown and instead make these into a logically argumentative paragraph that expands on one question by asking the other

Incorporate Neussanbaum and boyd in this paragraph as well as an important critical counterpoint that builds toward this point on context collapse management

Remove adjective 'temporal' and revise sentence structure with theoretical support from Jonathan Crary's 24/7, particularly his commentary on the ends of sleep amid the late capitalist state of constant socioeconomic hardship and compounding austerity conditions.

Add commentary from Crary's 24/7 here to close out the paragraph

Vacuous string of abstractions

At least 3 paragraphs on this

1. uniquely CUNY
2. growth & fears of doxxing
3. what it means discursively

for - question - sustainable cities - how did the contradiction of sustainability and cities posed by Herbert Girardet in 1999 get resolved?

https://github.com/collectiveidea/delayed_job/issues/1099 had possibly helpful solutions

Duplicate at: https://groups.google.com/g/delayed_job/c/5fsuBCZX1Ak

"Specifically, when one of my classmates stated how he was struggling with the concept and another one of my classmates took the initiative to clarify it, I realized that that individual possibilities vary greatly among students."

I can't figure out where/how to do this.

Yes! I like this.

I got briefly stuck on the first sentence before noticing the second sentence says how. Maybe "Run the CREATE DATABASE command by either clicking on the lightning bolt icon in the upper left, or choosing Query > Execute Current Statement in the menu." Actually, I'm still stuck—the lightning bolt is grayed out/unclickable, as is the menu option. I tried both while the command was highlighted, and while the command was not highlighted. I also saved the file and then tried.

Nice

I know there's a good way to google questions about R that gets search results actually about the R language... but can't remember what it is. Might be nice to mention that someone in the less, maybe in a tips section?

Excellent explanation!

Brief definition of relational database for folks who don't know exactly what a database is (beyond e.g. "stores stuff")

Could you provide a brief definition of NLP here, so that novices understand why you wanted to use it?

I really like how you situate this lesson as a response to a real scholarly problem you ran into! You might consider preceding this with a few skimmable points so that visitors can tell whether the lesson fits their needs or not. E.g. with my lesson, I started with:

1. a single-sentence summary of why you might want to read the lesson (novice-friendly language)
2. what you'll be able to do by the end of the lesson
3. any software/hardware requirements
4. difficulty level of the lesson (do you need any previous knowledge? e.g. knowing what a "finding aid" is or how to make an HTML file like your first index example)

This doesn't read very well. How about "use the search bar to find all annotations with a specific tag"

We should really mention that this works when the content changes. Its one of our key features.

"loaded whenever you return to the document even if the content changes".