More docs-related commits will follow, but this needs to be merged in order to continue with other development.
* Docs: Overhaul docs generator (beginning)
* docs: Rename comments file
* docs: Move comments gitignore
* docs: Initial request documentation
* docs: Improvements to comment processing
* docs: More improvements
* docs: Add enum functionality for protocol.json
* WebSocketServer: Document enums
* RequestHandler: Document RequestStatus enum
* Base: Move ObsWebSocketRequestBatchExecutionType to its own file
Moves it to its own file, renaming it to `RequestBatchExecutionType`.
Changes the RPC to use integer values for selecting execution type
instead of strings.
* docs: Update introduction header
Removes the enum section, and documents RequestBatchExecutionType.
* WebSocketCloseCode: Shuffle a bit
* Base: Use `field` instead of `key` or `parameter` in most places
* RequestStatus: Mild shuffle
It was really bothering me that OutputPaused and OutputNotPaused
had to be separated, so we're breaking it while we're breaking
other stuff.
* docs: Delete old files
They may be added back in some form, but for now I'm getting them
out of the way.
* docs: Add enum identifier value
Forgot to add this before, oops
* docs: Document more enums
* docs: Add basic protocol.md generator
* docs: More work on MD generator
* docs: MD generator should be finished now
* docs: More fixes
* docs: More fixes
* docs: More tweaks + add readme
* docs: Update readme and add inputs docs
* docs: More documentation
This is probably one of the most requested features for obs-websocket.
This currently works by firing an event to all explicit subscribers
with an array of all active audio sources every **60 milliseconds.**
The `inputLevelsMul` field follows this data format:
Base: [Channel, Channel]
Channel: [magnitude (mul), peak (mul), input_peak (mul)]
*Not Muted* *Muted*
Example: [[0.3, 0.5, 0.9], [0.0, 0.0, 0.0]]
(input_peak is the actual peak value, before volume adjustment.)
You may notice that the values are only in mul. This is because we are
trying to cut down on bandwidth. dB values can be calculated using this
formula:
`dB = 20.0 * log10(mul)`
- Implements a WIP ObsWebSocketApi, for obs-websocket-api.h. Events are
finished, but requests are not.
- Some logging improvements
- A bit of code cleanup around the plugin
A new `executionType` field has been added to the `RequestBatch` Op
Types added:
- `OBS_WEBSOCKET_REQUEST_BATCH_EXECUTION_TYPE_SERIAL_REALTIME`(default)
- `OBS_WEBSOCKET_REQUEST_BATCH_EXECUTION_TYPE_SERIAL_FRAME`
- `OBS_WEBSOCKET_REQUEST_BATCH_EXECUTION_TYPE_PARALLEL`
`OBS_WEBSOCKET_REQUEST_BATCH_EXECUTION_TYPE_SERIAL_REALTIME`:
- Same as how request batches have always worked.
- Requests are processed in-order
- Requests are processed as soon as possible by one worker thread
- The `Sleep` request blocks execution for a specified amount of real
world time
`OBS_WEBSOCKET_REQUEST_BATCH_EXECUTION_TYPE_SERIAL_FRAME`:
- New!
- Requests are processed in-order
- Requests are processed on the graphics thread. BE VERY CAREFUL NOT
TO OVERLOAD THE GRAPHICS THREAD WITH LARGE REQUESTS. A general rule
of thumb is for your request batches to take a maximum of 2ms per
frame of processing.
- Requests processing starts right before the next frame is composited.
This functionality is perfect for things like `SetSceneItemTransform`
- The `Sleep` request will halt processing of the request batch for
a specified number of frames (ticks)
- To be clear: If you do not have any sleep requests, all requests in
the batch will be processed in the span of a single frame
- For developers: The execution of requests gets profiled by the OBS
profiler under the `obs-websocket-request-batch-frame-tick` name.
This value (shown in the OBS log after OBS shutdown) represents the
amount of time that the graphics thread spent actively processing
requests per frame. This tool can be used to determine the amount of
load that your request batches are placing on the graphics thread.
`OBS_WEBSOCKET_REQUEST_BATCH_EXECUTION_TYPE_PARALLEL`:
- New!
- Requests are processed asynchronously at the soonest possible time.
- Requests are processed by the core obs-websocket thread pool, where
the number of workers == the number of threads on your machine.
- If you have 12 threads on your machine, obs-websocket will be able
to process 12 requests at any given moment.
- The `results` array is populated by order of request completion.
Consider the order to be random.
- The `Sleep` request will return an error if attempted to be used in
this mode.
- Note: This feature is experimental and can increase the chances of
causing race conditions (crashes). While the implementation is fully
thread-safe, OBS itself is not. Usage of this is only recommended if
you are processing very large batches and need the performance benefit.
- Example use case: Performing `SaveSourceScreenshot` on 8 sources
at once.
- Merge WebSocketProtocol into WebSocketServer
- Having them separated was not doing anything productive
- Request: Move SessionPtr to RequestHandler
- Less copying to do for batch requests
- Fully modularize EventHandler
- Make BroadcastEvent a stored callback that WebSocketServer sets
- Return early on high volume events to avoid unnecessary compute
- These events will only generate a json object when it is actually
needed
Among lots of stuff:
- Generate a random password on first load
- Add `ConnectInfo` dialog including QR code display
- Add `Generate Password` button to generate a new random
password
- Delete `Copy Password to Clipboard` button
- Delete `GetConnectString` or whatever from WebSocketServer
(reimplemented the functionality directly into ConnectInfo)
- Added `GeneratePassword()` to Utils
Todo: Show warning when users specify their own passwords
Will be used to handle incoming websocket messages. Initially I was
going to handle messages within WebSocketServer, but the file is
starting to get very large and so it's only fair to split it up.
I decided to go with nlohmann::json because it supports both JSON and
msgpack. I'm likely going to have to write some conversion utils to
convert between obs_data_t and json, but the advantages of what
nlohmann::json brings to the table are just too attractive.
