Paper: OpenSight v1.0.0 and H.264 Whitepaper

We are proud to introduce our double-release of OpenSight v1.0.0 and our H.264 Whitepaper.

H.264 Whitepaper

In order to make H.264 streaming (which you can read more about here) a reality, we had to do a lot of research and testing. Fortunately, if you want to implement it yourself, we’ve done all the hard work! Since the release of the Post-Kickoff update, we have worked to bring to the FIRST Community a whitepaper describing how and why we implemented H.264, how it functions, and the difficulties we faced.

Click here to read about our endeavors in H.264! (201.4 KB)

OpenSight v1.0.0

OpenSight’s final major update for this build season, v1.0.0, packed full of stability fixes and quality of life changes. There are too many things to list here, so you can see the full changelog on the GitHub releases page. Already have a working OpenSight image? You can download the latest upgrade directly from the packages page. Just getting started? Check out the installation guide.

Need help of any kind, or curious about H.264? Click here to join our Discord server!


> tfw you realize something didn’t make it into the paper 13 hours after the fact

True to form, the FMS does get in the way of H.264 being streamed over RTSP. Not getting that into the whitepaper is my fault, and I apologize for the confusion.
The TL;DR is that the FMS does not do what you would expect by the manual… or the manual is poorly worded, one of the two. While in the pits, you can connect to rusty-engine (or potential-engine or anything based on gst-rtsp-server, or maybe any RTSP server) with no issues using the “naive” way of viewing RTSP for your program of choice.

Then you arrive on the field.

On the FMS, for some reason, you can only stream RTSP if the “lower transport” is TCP instead of UDP. (UDP is used by default because latency.) You have to force the use of TCP. Thankfully, in practice, this does not seem to noticeably increase latency. I have an entire competition season of “practical demonstration” to back that.

With that all said, here’s how to force TCP for various common stream viewing methods:

  • FFmpeg: -rtsp_transport tcp, see
  • GStreamer, with playbin: Change the URI from rtsp://blah to rtspt://blah. Source
  • GStreamer, using rtspsrc: Set protocols=tcp on your rtspsrc element.
  • Shuffleboard: Wait for an update that fixes it… or write a PR!

This is amazing work. Super great progress bringing H.264 to the larger community. I’ve wanted a future where tacking on a camera with Limelight-like usability will be as simple as buying a few parts, flashing an image, and pointing your dashboard to an H.264 stream. It looks like we’re pretty much there now. Today was a good day to stalk Chief Delphi :grin:.


Have you tried running the radio with the firewall enabled to simulate the FMS firewall? Have you verified using Wireshark or another tool that when using UDP it only uses allowed ports?

I have verified with wireshark that it doesn’t start using random ports under UDP. I haven’t tested how it behaves with the radio firewall enabled, but that should be easy to test if someone wants to try that