startautomating / obs-powershell Goto Github PK

The generated obs-powershell commands should all be able to -PassThru/-OutputRequest/-OutputInput.

Providing this switch should make the command return the payload it would have used for a request.

This will make the generated commands testable without obs running.

It should be easy to create a color source.

OBS is a great tool.

obs-powershell is a PowerShell module that lets you automate OBS.

If a parameter for an obs function would be named -*Path, we should realize that OBS will expect an absolute path, and should try to resolve the provided path first.

When more than one message is piped to Send-OBS, it will try to send them as a batch.

This currently will not quite work, due to case-sensitivity of the payload.

Which brings up point one of improvements to batch processing:

• Fix case-sensitivity of batched requests

Additionally, Send-OBS should expose parameters that grant control of the batch.

• haltOnFailure should be exposed as a parameter in some form.
• executionType should be exposed as a parameter in some form.

Finally, because batch requests with small sleeps can be used for smooth manipulation, we want to:

• Add a parameter to sleep between each batch (not in PowerShell, in obs)

There are many events sent by the obs-websocket, and, while those can currently be cause by Register-EngineEvent, the average PowerShell user is unlikely to know about Register-EngineEvent without prompting.

Therefore, there should be a Watch- function for every event surfaced within obs.

One should be able to clear all of the items from a given scene.

One should prompt for confirmation before doing this.

This it the standard for most PowerShell commands, and we have already abstracted the parameter name away from the "bound" property, using [ComponentModel.DefaultBindingProperty("realName")].

Given changes in #54 , we can now make specific actions for specific source types.

As such, any color source should be able to change it's color.

To assist #18 , the core logic for watching OBS should be put into a distinct function.

The return currently contains two effectively duplicated columns: inputKind and unversionedInputKind.

It should only display one of these.

In order to provide a better experience around scene items, they should be formatted.

Request counters are more likely to lead to confusion, especially with module reloads.

Various changes can only be made to particular kinds of input. Therefore, whenever Receive-OBS receives a message with an .InputKind property, that .InputKind should be added to the typenames.

This will allow us to make specific script methods and properties for this kind of input.

This will require some post-processing of the response (see #49).

To communicate with obs we use the obs-websocket plugin (which is built into OBS).

The obs-websocket project has a nicely documented protocol.

The protocol is also documented within a .json file, which means we can use it to build the bulk of the commands in obs-powershell.

Aside from Connect-OBS and Disconnect-OBS, the majority of commands in obs-powershell are automatically generated with this technique.

To simplify each generated command, Receive-OBS should exist.

Receive-OBS should inspect a message payload and receive results

SVG is an amazing graphics format and a great web standard.

Unfortunately, it's also a standard that's not fully implemented by many imaging tools.

If, for instance, you want to rasterize an SVG with ImageMagik, go ahead and kiss your symbols goodbye and forget even using CSS classes. Many imaging apps can't handle large chunks of the SVG standard, which leads to omitted text and elements.

And don't even get me started on animated SVGs.

Luckily, OBS has a browser source, and lets us easily capture an SVG as an image or a video exactly as it would render in Chrome.

Let's cover images first.

Because SVGs are scalable, and raster images are not, step one is to get our dimensions right.

SVGs have a Viewbox, which contains the width and height they'll want to render at.

Create a browser source of that width / height, then pipe it to Save-OBSScreen.

Add-OBSBrowserSource -Uri https://4bitcss.com/Batman.svg -Width 640 -Height 240 |
    Save-OBSSourceScreenshot -ImageFormat png -ImageFilePath (Join-Path $pwd "Batman.png")

Because of the Object Pipeline in PowerShell, we don't even need to pass along the -ImageHeight and -ImageWidth to Save-OBSSourceScreenshot (the browser source has an .ImageHeight and .ImageWidth property).

It gets even better.

The file that Save-OBSSourceScreenshot returns packs a little bit of extra info:

• What source generated it
• What scene it was in

Which means we can actually just take a snapshot and remove it:

Add-OBSBrowserSource -Uri https://4bitcss.com/Batman.svg -Width 640 -Height 240 |
    Save-OBSSourceScreenshot -ImageFormat png -ImageFilePath (Join-Path $pwd "Batman.png") |
    Remove-OBSSceneItem

Hope this Helps!

Before getting too far ahead of ourselves, we need to be able to connect to the OBS websocket.

Connect-OBS is the core command responsible for connecting to an OBS websocket.

These should be script properties that return the width and height of a transform.

This should enable easier mapping to, say, Save-OBSScreenShot

In order to make scene sources a smidgeon easier, we should be able to Add-OBSSceneSource.

This can be accomplished via aliasing Add-OBSSceneItem.

In order to make screen capture a bit easier, Add-OBSDisplaySource should exist.

This should:

• Inherit from Add-OBSInput (hiding inputKind, inputName, and sceneName)
• Always use -inputKind monitor_source.
• Allow -Name (alias 'InputName') to name the input
• Default -Name to the -Monitor number
• Allow -Scene (alias 'SceneName') to set the scene
• Default -Scene to the CurrentProgramSceneName

Module makes us of ThreadJob cmdlets -> The module should be required in the module manifest

A Scene item can be rotated by adjusting its transforms.

This should be exposed as a ScriptMethod on a scene item.

Rotation may need to be anchored.

This should:

• Inherit from Add-OBSInput (hiding inputKind, inputName, and sceneName)
• Always use -inputKind ffmpeg_source.
• New Parameters
  • -FilePath/-Fullname/-LocalFile/-Local_file
  • -CloseWhenInactive
  • -Loop
  • -UseHardwareDecoding
  • -ClearOnMediaEnd
  • -FFMpegOption/-FFMpegOptions/-FFMpeg_Options
• Allow -Name (alias 'InputName') to name the input
• Default -Name to the -FilePath's name
• Allow -Scene (alias 'SceneName') to set the scene
• Default -Scene to the CurrentProgramSceneName

If obs can be invoked within a GitHub action, this opens a lot of doors for automated video processing and streaming within a build.

In order to make browser sources easier to create, there should be Add-OBSBrowserSource.

This should:

• Inherit from Add-OBSInput (hiding inputKind, inputName, and sceneName)
• New Parameters
  • -URI/-URL/-FilePath/-FullName
  • -Width
  • -Height
  • -CSS
  • -ShutdownWhenHidden
  • -RerouteAudio
  • -RestartWhenActive
  • -FramesPerSecond/-FPS
• Default -Width/-Height to video outputWidth/outputHeight
• Set .url / .filepath / .is_local_file based off of -Uri's contents
• Always use -inputKind browser_source.
• Allow -Name (alias 'InputName') to name the input
• Default -Name to the last segment of the URI
• Allow -Scene (alias 'SceneName') to set the scene
• Default -Scene to the CurrentProgramSceneName

The obs-websocket returns errors slightly differently than it does normal responses see their specification for more details.

As such, obs-powershell 0.1 did not yet handle the display of errors.

There are two parts to fixing this:

1. Connect-OBS and the obs watcher job it creates should forward comments field when requestStatus.result -eq $false
2. Each command's expecting response code should slightly differ, and Write-Error with the response message.

If there is a $home directory, Connect-OBS should cache connection information within it (inside of an .obs-powershell) subdirectory.

We want to be able to cleanly disconnect from OBS when the module unloads (or whenever we decide to).

Therefore, we need Disconnect-OBS.

Due to a variable rename during preparation for publishing, the generated commands in obs-powershell are not properly incrementing requests.

obs-powershell should be chock full of examples, especially ones good for everyday use.

Though this should do this slightly differently than in the UI.

In the UI, when things are fit to the screen, they are still transformed from the upper left. We should transform from Center.

Since the output of certain web socket events responses leaves something to be desired.

Because we are going to generate commands and some markdown documentation, we want to use PipeScript to build obs-powershell.

When a relative path is passed into a browser source, it does not get resolved, and thus does not work.

In order to simplify the implementation of each autogenerated command, and to make it easier to work with the OBS WebSocket, there should be a high-level function, Send-OBS.

Send-OBS should accept any object from the pipeline.

• If only one object was provided, it should be sent to OBS
• If the object lacks an opcode, it should be treated as a broadcast event
• If the object has authentication, it should be made
• If a single object has requestData, it should be made into the correct payload for an obs request
• If multiple objects were passed and each had request data, they should be made into a batch request
• If multiple objects were passed and did not each have a request data, it should be sent as a series of single objects

While there may be no shortage of built-in controls for obs for StreamDeck and LoupeDeck, these are often limited, and the fine grain control of scripting is always good to surface at the click of a button.

This will improve the output from Get-Member.

It should conform to the general color schema of most of StartAutomating's repos, and should not utilize the obs logo directly.