# UltraGrid: uncompressed video over commodity network hardware > UltraGrid is a C implementation of high quality, low latency video and audio transmission that runs on Linux, Windows and macOS, driven by a single uv binary and a capture device, a display device and a compression choice. It reaches 1080p to 8K at up to 60 frames per second with roughly 100 ms end to end latency, and it needs a 10GbE card for uncompressed 1.5 Gbps streams. **CESNET/UltraGrid** — UltraGrid low-latency audio and video network transmission system - Repository: https://github.com/CESNET/UltraGrid - Website: http://www.ultragrid.cz - Stars: 605 · Forks: 78 - Language: C - License: NOASSERTION - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/cesnet-ultragrid ## What UltraGrid is for and who runs it UltraGrid is a software implementation of high quality, low latency video and audio transmissions using commodity hardware. It is brought by CESNET's Laboratory of Advanced Networking Technologies, Sitola, and it runs on stations with Linux, Windows or macOS. The signal characteristics are the point. Supported resolutions range through HD at 1920x1080 up to 8K at 7680x2160, with up to 60 frames per second. Quality comes from either uncompressed streams or streams with a very low compression ratio, and end to end transmission latency, from camera to display, is about 100 ms, though that figure varies depending on the camera and capture cards in use. The application areas the project names are collaborative environments, medical settings, cinematography and broadcasting, plus educational activities. Those are all situations where a dropped frame or a recompressed video is a visible defect rather than a rounding error. The origin story explains the engineering. UltraGrid began as a research project to demonstrate the possibilities of 10Gbps networks and to study multi point data distribution in such environments. Recent advances in GPU accelerated low latency codecs extend its usability to Gigabit networks, and high compression ratio modes allow use of any commodity network connection including a shared internet connection. The current code is a fork of the original UltraGrid developed by Colin Perkins, Ladan Gharai and others. ## How the latency and the bandwidth trade works The design axis is a straight trade between quality, bandwidth and latency, and the project is explicit about how each mode sits on it. Uncompressed streams give the highest quality and cost the most bandwidth. The recommended hardware notes put a number on it: for uncompressed 1.5 Gbps streams, either sending or receiving, a 10GbE network interface card is needed, and the project says it tests with a PCIe Myrinet 10GbE card. A Gigabit link cannot carry that stream. Streams with a very low compression ratio are the middle ground, and still leave plenty of headroom above typical video bitrates, which is why they exist for the local network case. High compression ratio modes are the third point, and they are what make the tool usable over ordinary connections, including a shared internet link. The trade there is recompression, so the quality advantage over a normal conferencing codec narrows considerably. On latency, the documented figure of about 100 ms from camera to display is not a constant of the software. The documentation says it varies based on the camera and capture cards being used, which points at the capture path rather than the network as the main source of variation. Anyone quoting a latency number should quote it with the hardware attached to it. ## The hardware the project expects you to have The recommended setup is specific, and the documentation is blunt about the parts that are not optional. A 64-bit CPU with at least 2 cores is the baseline, with an OpenGL compatible graphics card recommended. The OpenGL requirement is tied to DXT compression on the GPU, which is tested with OpenGL 3.3. GPUJPEG compression requires an Nvidia card. Various hardware accelerated compressions are supported with recent GPUs through NVENC and NVDEC, QuickSync, VA-API, VideoToolbox and VDPAU, so the codec path depends on which vendor card you have rather than on a generic GPU flag. For capture and output of SDI signals, one of AJA, Bluefish444, Blackmagic, DELTACAST or Magewell cards is required. For uncompressed 1.5 Gbps streams the network side needs 10GbE. One layout detail is easy to miss and worth repeating: the video capture card should be located on a separate PCI bus from the network card if possible. Both cards are moving large amounts of data at once, and sharing a bus is the kind of contention that shows up as jitter rather than as a clean failure. On the software side, AMD and Nvidia proprietary drivers are listed for optimal performance, and AJA, Blackmagic and DELTACAST drivers are needed for those capture paths. Proprietary vendor drivers as a documented prerequisite is a fair signal about the class of machine this software expects. ## Driving it with the uv binary Once the system is built, the working binary is uv. The usage pattern is short, with one command on the sender and one on the receiver: ```bash uv -t -c hostname (on the sender) uv -d hostname (on the receiver) ``` The sender names a capture device with -t, a compression with -c and the destination host. The receiver names a display device with -d and the source host. Every option has built in help rather than a separate manual page. The display device is one of the list shown with -d help, and the capture device is one of the list shown with -t help. The name of a capture device usually carries the video mode and input configuration with it, and options can be shown interactively, for example -t decklink:help. The compression list is likewise available with -c help. If compression is not specified, video is transmitted uncompressed. That last default is worth internalising. A missing -c flag is not a mild quality reduction, it is the maximum bandwidth mode, which is why the hardware notes talk about 10GbE cards at all. The build itself is handled by an autotools style setup, with autogen.sh, configure.ac and Makefile.in at the root, and the INSTALL file carries the build instructions. ## Repository layout and the packet reflector The top level directory listing is informative in a way that goes beyond a table of contents. The src/ directory holds the source code for the UltraGrid system, gui/ holds the sources for the UltraGrid graphical interface, and data/ holds assets that are not source code. The doc/ directory holds documentation and test/ holds source code and binaries for the test routines. ext-deps/ holds external dependencies that UltraGrid requires, and tools/ holds small standalone helper tools. package_specs/ holds specifications for OBS, which tells you OBS is one of the streaming targets the project supports. Two entries stand out for anyone who wants to use the pieces separately. The hd-rum-multi/ directory is described as a simple standalone packet reflector, which makes sense for testing a path under load without running the whole video stack. And three subdirectories, cuda_dxt, dxt_compress and ldgm, contain libraries that are parts of UltraGrid but are relatively standalone and self contained, so the DXT compression code and the lossy distributed coding library can be reused without pulling in the transmission system. There is also a nat-helper/ directory in the tree, which the documentation does not describe in detail, so its role in the NAT traversal path has to be inferred rather than read off a page. ## Licence terms, copyright holders and CI The licence deserves a careful read because it is not a standard permissive file that GitHub can classify automatically. The documentation states that the software is open source and distributed under the BSD license, and that the project is interested in both research, academic and commercial applications. The full terms and conditions are in the COPYRIGHT file at the repository root, and that file is the authoritative source rather than a short SPDX identifier. Read it yourself before you build a redistribution plan, since the GitHub licence metadata classifies it as a custom licence that the platform cannot categorise, and the per-file copyright notices are part of what you are accepting. The copyright holders are listed directly in the documentation. They are the University of Southern California for 2001 to 2004, the University of Glasgow for 2003 to 2004, Fundacio i2CAT, Internet I Innovacio Digital a Catalunya for 2013 to 2014, and CESNET, zajmove sdruzeni pravnickych osob, for 2005 to 2026. The mixture of academic and institutional holders across two decades is a reminder that this code carries history from several organisations. On the engineering side, the project runs a C and C++ continuous integration workflow and a Coverity Scan build status, both surfaced as badges. The repository also carries CONTRIBUTING.md, a Doxygen configuration in Doxyfile, and a NEWS file described as the change log and modification history. ## Where UltraGrid is the wrong tool There are clear situations where this is not the answer. The first is bandwidth. Uncompressed and lightly compressed streams are sized for a local network with a 10GbE interface, and even the compressed modes still assume a link you control. The documentation is straightforward that high compression modes make use of any commodity connection including a shared internet connection, so remote collaboration over the public internet is possible but is not where the quality advantage lives. If your requirement is a low bandwidth call between offices, an ordinary conferencing codec does the job with less hardware. The second is hardware dependency. This is not a software only project. Capture and output cards from a short list of vendors, GPU vendor drivers, an OpenGL 3.3 capable card, and a fast NIC are all part of the design. An organisation without a machine room and a video engineering skill set will spend its time on hardware rather than on transmission. The third is the build. The project is compiled from source with autotools, with external dependencies vendored under ext-deps/, and the wiki page on compiling from source is the current reference for dependencies. There is no package in the documentation for a supported distribution, and the release stream includes a continuous builds tag alongside versioned releases such as v1.10.7 on 2026-07-21 and v1.10.8 on 2026-08-24. A fourth limitation is the documentation depth. The wiki carries the operational detail, including the feature list and the compile instructions, and the README itself is a summary that points there. Someone evaluating the project offline will find the tree informative but the manual thin. ## Conclusion UltraGrid fits a studio, lecture room, medical or broadcast setup that needs uncompressed quality and predictable latency on a local network, and where the operator will sit in front of the machine to wire capture hardware and tune GPU compression. It does not fit remote collaboration over a public internet link, where the bandwidth of uncompressed 1080p60 is the deciding factor, nor does it fit teams who want a supported commercial product instead of a research code base with a BSD style licence and a public wiki. Before adopting it, confirm your capture and display cards are among the supported ones, check that your network interface can carry the bitrate your chosen compression mode produces, and read the COPYRIGHT file yourself, since the full licence terms live there rather than in a standard SPDX file. ## FAQ ### What latency does UltraGrid achieve? The documentation states that end to end transmission latency, from camera to display, is about 100 ms. It also notes that the figure varies depending on the camera and capture cards being used. ### How do I send video with the UltraGrid uv binary? On the sender, run uv with a capture device, a compression and the destination hostname, and on the receiver run uv with a display device and the source hostname. Available capture devices, display devices and compressions are listed with the -t help, -d help and -c help options. ### What network hardware does UltraGrid need for uncompressed video? For uncompressed 1.5 Gbps streams, either sending or receiving, the documentation says a 10GbE network interface card is needed, and that the project tests with a PCIe Myrinet 10GbE card. ### Which operating systems does UltraGrid support? The project states that UltraGrid is supported on stations with Linux, Windows or macOS. It is written in C and is compiled from source with an autotools style build. ### What licence applies to UltraGrid? The documentation describes the software as open source and BSD licensed, with the full terms and conditions in the COPYRIGHT file at the repository root. Copyright is held across several institutions from 2001 through 2026. ## Sources - [CESNET/UltraGrid on GitHub](https://github.com/CESNET/UltraGrid) - [Issues](https://github.com/CESNET/UltraGrid/issues) - [Project website](http://www.ultragrid.cz) - [README](https://github.com/CESNET/UltraGrid/blob/master/README.md) - [Releases](https://github.com/CESNET/UltraGrid/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/cesnet-ultragrid