StreamShark has announced an OBS dock for managing live events, but the official announcement found for this guide still described it as “coming soon”. It does not provide a verified download, installation procedure, supported OBS versions or authentication instructions, so this is not a step-by-step plugin installation guide.
You can use the announcement to assess whether its intended controls suit your event, then check StreamShark’s current official channels before attempting to install anything. If you need to broadcast now, StreamShark documents manual OBS workflows for RTMP and SRT; those are fallbacks, not instructions for the announced plugin.
What the announced OBS plugin is meant to do
StreamShark’s announcement describes a native dock panel inside OBS Studio. The intended idea is to handle selected StreamShark event controls from the OBS workspace rather than switch between OBS and the StreamShark portal for each action. StreamShark says an operator would be able to switch accounts, select a live event, and have the plugin choose RTMP or SRT according to that event’s type.
The announcement presents this as a way to avoid manually copying stream keys and changing OBS output settings for different events. That is a description of planned behaviour, not a claim that the plugin is available or that the controls have been independently tested. In particular, the protocol selection described for the plugin should not be confused with the manual configuration procedures StreamShark documents today.
The announcement also describes separate start and stop controls for primary and backup streams, real-time bitrate monitoring, a Pre/Main/Post phase switcher, and controls to activate configured live calls-to-action and polls. StreamShark says the dual-stream workflow could avoid running two OBS instances. These functions may matter if you manage event transitions, redundancy or audience prompts from one production computer, but the announcement does not establish how they work in a released build.
Think about your event before judging the feature list. A local news loop with a single continuous feed may care most about reconnect behaviour and the ability to monitor the incoming stream. A scheduled business event with an opening segment, a main presentation and a closing prompt may find phase controls and calls-to-action more relevant. A devotional broadcast that runs the same programme for long periods may have little use for polling controls. The fit depends on your workflow, not on how many controls appear in a product announcement.
If you are still deciding between a live event workflow and a file-based continuous channel, our guide to streaming a pre-recorded playlist on YouTube around the clock covers a different operating model. It is not a substitute for setting up a StreamShark event, but it can help you decide whether event controls inside OBS solve the problem you actually have.
Check release status before looking for an installer
StreamShark’s announcement is dated 16 April 2026 and says the plugin is “coming soon” for macOS and Windows. That wording records the state described when the announcement was published; it does not prove the plugin’s status now. The research for this article did not locate a later official release notice or installation guide. Check the original StreamShark announcement alongside StreamShark’s current release and support channels before downloading a file or following third-party instructions.
A useful release check is more than finding a page that repeats the announcement. Look for current, official download and setup documentation that names the relevant operating system, explains the supported OBS versions, tells you how sign-in or account selection works, and describes any event or plan prerequisites. The announcement does not settle those details. Until current documentation does, do not infer them from the fact that a dock is intended to run inside OBS.
The OBS Project’s plugins guide is useful background on OBS plugins generally, but it is not StreamShark installation documentation. A general guide cannot confirm that a particular plugin has shipped, whether a download is genuine, or which version of OBS it supports. If you cannot find a current StreamShark download and matching instructions, treat that as a reason to pause rather than as an invitation to guess.
That caution matters when a broadcast is scheduled. Installing an unverified add-on shortly before an event can introduce a new dependency into a setup you have not tested. For an important event, keep the established workflow available, confirm that it can still connect, and try a newly documented plugin in a separate rehearsal before relying on it. This is ordinary change control, not evidence that the plugin causes problems.
Read the dock workflow as an event-control proposal
The announced workflow starts with account and event selection inside OBS. StreamShark says the operator would choose an account, select an event and let the plugin determine whether that event uses RTMP or SRT. That could reduce context switching if you produce several events or move between event configurations. It could also make the selected account and event especially important to verify before going live: a convenient control panel does not remove the need to confirm where the programme is being sent.
The announcement’s separate primary and backup start/stop controls are aimed at events where redundant ingest is configured. StreamShark says the plugin would allow the operator to manage both without opening two OBS instances. That is a proposed operational convenience, not a guarantee of failover, uninterrupted delivery or a particular redundancy design. Before an event, clarify what the backup stream does in the event’s workflow and how you would know whether the intended primary and backup feeds are actually arriving.
The phase switcher is described in terms of Pre, Main and Post event stages. The likely practical question is whether your crew already uses those stages in the StreamShark event workflow and whether having a phase control in OBS would reduce missed transitions. Do not assume the plugin creates a production schedule or changes the programme automatically: the announcement says it offers a switcher, not that it automates your show.
The calls-to-action and polls controls similarly depend on those features being configured for the event. StreamShark’s pricing page currently places Live CTA and Live Polling among Business and Enterprise capabilities, while the announcement does not state a separate plan requirement for plugin controls. Because plan terms can change, confirm the current feature and eligibility details with StreamShark rather than treating a plugin announcement as proof that a control is available on your account.
A compact control surface is most useful when it matches the way you already operate. Before you need it live, write down who selects the event, who starts each feed, who changes phase, and who checks the workflow. Then identify which of those duties the dock is intended to simplify. That rehearsal will expose whether the missing piece is really an OBS control, or instead event configuration, clear role assignment or a dependable manual fallback.
Confirm current requirements with StreamShark
The most important unresolved items are specific, not technical trivia. Ask StreamShark for the official release location, current operating system and OBS compatibility, installation instructions, account authentication method, plan or event prerequisites, and a support route for a live event. Ask whether the plugin handles both RTMP and SRT for your intended event type, and whether its primary/backup controls require backup ingest to be enabled on the event or plan.
StreamShark’s existing OBS setup guide documents manual setup. It says to create a live stream event in the StreamShark portal first, then use the event’s Server URL and Stream Name in OBS. The guide’s configuration details are specific to its documented workflow; they should not be silently presented as the plugin’s own setup requirements.
For SRT, StreamShark documents a separate SRT ingest guide. It describes creating an SRT Ingest event, completing its event settings, waiting for provisioning to finish and the event to show Ready, then copying a publishing URL from Event Details. In OBS, its documented manual flow uses Custom as the service, the publishing URL in Server and a blank Stream Key. The guide then directs you to start streaming and inspect the event’s Workflow tab to confirm the stream is pushing.
Those details give you a practical set of questions for support: does your event use the standard RTMP arrangement or SRT ingest; which event-side settings must be ready; and where should you verify that the input is arriving? They do not establish that the announced plugin requires the same fields or that it exposes the same checks. Keep manual and plugin documentation distinct until StreamShark publishes instructions tying them together.
If you run a small channel from a home connection, you may also need to distinguish a plugin issue from an upload problem. Our Indian broadband upload-drop guide discusses how changing upstream conditions affect a continuous stream. For event-day planning, the useful lesson is to test the complete path you intend to use rather than assume that a simpler control panel changes the quality of the connection feeding it.
Use the documented manual fallback carefully
If the plugin is not available, StreamShark’s standard manual OBS guide offers a documented route for an RTMP event. First create the event in the portal and locate its Server URL and Stream Name. In OBS, the guide uses the Stream tab with Custom Streaming Server, placing the Server URL in the URL field and the Stream Name in the stream key field. It then asks you to match OBS output bitrate and video resolution to the transcode resolution selected for the event.
The values below are examples published in StreamShark’s guide, not universal encoding recommendations. Your available upload capacity, source material, event settings and audience playback conditions can all affect what is appropriate. Use the current event configuration and vendor documentation rather than copying a row merely because it is a familiar resolution.
| Event transcode resolution in StreamShark’s guide | Video bitrate | Audio bitrate |
|---|---|---|
| 2160p (3840×2160) | 15,000 Kbps | 128 Kbps |
| 1440p (2560×1440) | 8,000 Kbps | 128 Kbps |
| 1080p (1920×1080) | 5,000 Kbps | 128 Kbps |
| 720p (1280×720) | 3,000 Kbps | 128 Kbps |
| 480p (854×480) | 1,000 Kbps | 128 Kbps |
| 360p (640×360) | 600 Kbps | 96 Kbps |
| 240p (426×240) | 300 Kbps | 96 Kbps |
The same guide says the OBS Base (Canvas) Resolution should match the StreamShark transcode resolution, and Output (Scaled) Resolution should match the Base (Canvas) Resolution. This is a documented matching rule for that guide, not a claim that every event or encoder should use those values. After setting up, follow the event workflow to check that a feed is arriving before treating the broadcast as ready.
For an SRT event, use the SRT-specific instructions rather than transplanting RTMP fields. StreamShark’s guide calls for an SRT Ingest event, completed event settings, a Ready state after provisioning, and a publishing URL copied from Event Details. It puts that URL in OBS’s Server field with Stream Key left empty. After starting, inspect Workflow for evidence that the stream is pushing. The announced plugin’s automatic protocol choice is a separate proposed feature, not a shortcut to these manual SRT steps.
A manual setup is less convenient when you frequently change events or protocols, but its fields are visible and documented. A plugin could reduce repeated copying if its released instructions confirm that behaviour. For either route, record the event type, destination values, resolution choice and the check that confirms ingest, then rehearse from the same machine and network you will use live. If your existing setup uses an OBS loop, our non-stop YouTube loop encoder settings guide may help you think through encoder choices, while StreamShark’s event guide remains the authority for its own ingest configuration.
Check plan fit without assuming plugin eligibility
Some of the announced controls rely on StreamShark event capabilities beyond sending a single feed. The pricing page lists backup stream ingest on Team and above, and Live CTA and Live Polling on Business and Enterprise. This is the pricing page’s current feature presentation, not a plugin-specific eligibility statement. The plugin announcement does not say which plan, if any, is required for each dock control, so do not infer a minimum plan from the feature list alone.
If you are evaluating a plan, compare what your event actually needs: a primary feed only, backup ingest, audience prompts, polling, or a particular resolution and transfer allowance. Ask StreamShark to confirm the current plan terms and whether each intended control is available to your account. Plan features and prices are time-sensitive; do not make a budget decision from an old announcement or an undated summary.
A backup feed is not automatically useful just because an interface offers a second start button. It needs to be part of an event design that you understand, and your operator needs a way to tell whether it is connected and what action to take if the primary feed stops. Likewise, a poll control has little value if your audience is not participating in a format that uses polls. Tie every proposed control to an event requirement and a rehearsal task.
StreamNeo addresses a different problem for channels that need a file to run continuously without keeping a production computer switched on: it turns an uploaded video into a YouTube live stream and monitors and restarts the broadcast if it drops. That may remove the need to keep an OBS machine running for a simple file-based loop, but it is YouTube-only and is not a StreamShark event plugin or a replacement for its event controls. If your need is to produce a live event from OBS, assess the StreamShark release and your event requirements directly.
For a live event, plan a decision point before the event date: if official plugin documentation is available and matches your setup, rehearse it; if it is not, use the documented manual flow you already know how to operate. Avoid adding unverified software or changing ingest configuration during the event itself. Keep a contact route for StreamShark support and know where the event’s workflow status is shown.
Before committing, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.
FAQ
Is the StreamShark OBS plugin available to install?
The official announcement dated 16 April 2026 described the plugin as “coming soon”. The research for this guide did not confirm a later release or find official installation instructions, so check StreamShark’s current release and support channels before attempting to install it.
Does the plugin support RTMP and SRT?
The announcement says it is intended to select RTMP or SRT based on the event type. That describes planned behaviour, not verified support in a released version; confirm the current documentation for your event before relying on it.
What can I do while I wait for plugin documentation?
StreamShark documents manual OBS setup for standard RTMP events and a separate manual SRT ingest flow. Follow the relevant current support guide for the event type, and verify the feed in the event workflow before going live.
Does my StreamShark plan include every announced control?
The pricing page lists backup stream ingest on Team and above, and Live CTA and Live Polling on Business and Enterprise, but the plugin announcement does not set out plugin eligibility. Confirm current plan terms and control availability with StreamShark for your account.