The idea
First of all, kudos to everyone who has produced live streams from Ultimate events. Watching those broadcasts is what sparked the idea behind this project. One thing I kept wishing for was a reliable live score shown directly in the stream.
I have built and tested this setup myself, but the point is not that it should stay as my own private system. Quite the opposite. Anyone should be able to borrow the whole setup, copy parts of it, or adapt only the pieces that make sense for their own production. If someone only needs a camera and encoder workflow, that part can be used on its own. If someone only wants the score overlay idea, that can also stand independently.
At the moment, my own example kit includes a Sony a5100 camera, a Blackmagic Web Presenter HD, and the necessary cables. For connectivity, internet access is still required on-site, either through ethernet or by connecting a phone to the Blackmagic box via USB-C tethering.
This page is meant as one example framework rather than a final answer. The real point is to share practical experiences, document what works, and welcome others to share their own experiences too so that together we can build something genuinely useful for community streaming.
What problem this setup solves
Community streams often fail for very practical reasons rather than because the technology itself is impossible.
Too much for one person
One person tries to film, monitor audio, handle overlays, update the score, and troubleshoot the network at the same time.
Missing graphics
The stream may work technically, but viewers still do not know the score, the teams, or what is happening.
Remote commentary is awkward
Even when someone is available to commentate, getting them cleanly into the stream can be harder than it should be.
This setup addresses those pain points by splitting the workflow into smaller parts. Video is sent from the field to a remote OBS instance. Score data is handled separately and shown as a browser overlay. Commentary can be added either on-site or remotely. The final output is then sent from one central production point to YouTube or another platform.
OBS stream production setup
The production environment is built around a Linux virtual server running OBS Studio remotely. In my own tests this has been a Hetzner-hosted VPS, but the same idea should work on other providers as well. The on-site device sends video to the server, OBS builds the final program feed, and that feed is forwarded to YouTube or another streaming platform.
High-level architecture
- Score overlay via Browser Source
- Commentary audio via VDO Ninja
- Scenes, logos, graphics
This approach also makes the setup more reusable from event to event. Once the server-side OBS project exists, you only need to reconnect the incoming sources and update the event-specific graphics.
Video capture and SRT transport
Video can be sent to OBS in several ways, but SRT is one of the most useful transport options for this type of setup. A practical chain is to connect a camera to a hardware encoder such as a Blackmagic Web Presenter HD, and then send that signal over the internet into OBS running on the VPS.
In my own example setup, the camera is a Sony a5100 connected to a Blackmagic Web Presenter HD with the necessary cabling. Internet access is required for the encoder to do its job, either through ethernet or by tethering a phone to the Blackmagic box over USB-C.
Typical field-side chain
Other viable input options
The Blackmagic workflow is only one option. Depending on the event and available gear, VDO Ninja and Larix can also be practical ways to bring video into the production chain.
- Blackmagic Web Presenter HD: a good fit when you want a dedicated hardware encoder between the camera and the network.
- Larix: useful when a phone is acting as the encoder or camera source and you want a lightweight app-based workflow.
- VDO Ninja: useful for browser-based contributions, quick remote sources, or flexible ad hoc video and audio inputs into OBS.
Commentary with VDO Ninja
Commentary should not require the commentator to sit next to the production machine. A practical option is to bring commentary into OBS with VDO Ninja. That allows a commentator to join from a laptop or phone while the OBS operator keeps the final mix under control remotely.
This is especially useful for volunteer-driven events because it lowers the barrier to participate. Someone can commentate from home, from another part of the venue, or even from another city, as long as they have a microphone, headphones, and a decent internet connection.
Scoring and browser overlays
One of the most useful ideas in this setup is that scorekeeping is completely separate from video production. Instead of updating the score manually inside OBS, the score lives in its own system and OBS only displays the result.
How it works
The scoring workflow has three parts: the score input, the backend, and the overlay shown in OBS.
- Single source of truth for match state
- Write protected with a claim code
- Read openly by overlays and viewers
1. Score input with Upsi
One person updates the match using the Upsi mobile app. Goals, points, and other match-state changes are entered there in real time. This is useful because the scorekeeper does not need access to OBS at all and does not need to touch the production machine.
In practice, this lets roles stay simple: the camera operator focuses on video, the scorekeeper focuses on the match, and the OBS operator focuses on the broadcast.
2. PointTracker as the backend
The backend acts as the single source of truth for the match state. Upsi sends updates to the server, and the current live state can then be read through an API endpoint.
- Writing data: requires a claim code
- Reading data: open for overlays and viewers
That separation is important. It means score updates stay protected, while the overlay and any public-facing tools can still read the data freely.
3. Browser-based overlay
The overlay itself is just a web page that reads the live match data from the API and renders it visually. OBS does not manage the score directly. It simply loads the overlay page and shows whatever the page displays.
There is already a ready-made overlay example that can be used directly in OBS:
https://pointtracker-service-ultimate.onrender.com/overlay.html
How to use the overlay in OBS
- Add a Browser Source.
- Set the URL to the overlay page above.
- Use a scene size such as 1920 × 1080.
- Position or crop the overlay as needed.
Why this approach works well
- No need to edit scenes during the game every time the score changes.
- The score can update automatically without touching OBS.
- Different overlays can reuse the same match data.
- The scorekeeper can work from a separate phone instead of the production machine.
- The whole setup is easier to reuse across events.
Example end-to-end workflow
A realistic event setup does not need a large crew. Even a small volunteer team can divide the work in a way that makes the stream much easier to manage.
On-site
- Camera operator
- Sony a5100 or another camera
- Blackmagic Web Presenter HD or another encoder
- Internet via ethernet or phone USB-C tethering
- One volunteer updating the score in Upsi
Remote
- OBS operator on VPS
- Browser source for the score overlay
- PointTracker backend providing live match state
- Commentator joining through VDO Ninja
- Final output sent to YouTube
Step by step
- 1Camera feed goes into the Blackmagic Web Presenter HD
- 2The encoder sends the video stream over the internet to remote OBS via SRT
- 3A scorekeeper updates the match live in the Upsi app
- 4Upsi sends the match state to the PointTracker backend
- 5The browser overlay reads that live data from the API
- 6OBS shows the overlay on top of the incoming video
- 7A remote commentator joins through VDO Ninja
- 8OBS sends the final program feed to YouTube
This division of labour is the core strength of the whole concept. The camera operator focuses on framing. The scorekeeper focuses on the match. The commentator focuses on telling the game story. The OBS operator focuses on the actual broadcast.
Community
My hope is that this does not remain just a personal experiment. I may have put this example setup together and tested it in practice, but the point is to make it useful for others too. Anyone should be able to borrow the whole package or just the specific parts they need for their own workflow.
This is not meant to present one final perfect model. It is meant to share one workable framework, collect real experiences, and invite others to build on top of it. If you have tried something similar, found a better method, or solved the same problem differently, those experiences are just as valuable.
Open source
Both the backend and the Upsi app are available as open source. If you want to run your own instance, adapt the overlay system, or contribute improvements, the code is there for you to use.
- PointTracker backend: github.com/jarmoasu/pointtracker-service-ultimate
- Upsi app: github.com/jarmoasu/pointtracker-app-ultimate