Compression help
| Algorithm | Lossiness | Color formats | Alpha channel | CPU usage | Bandwidth usage | Needs external library? |
|---|---|---|---|---|---|---|
| None (raw) | Lossless | All (including HDR) | Yes | Low | Very high (see table below) | No |
| QOI* | Lossless | BGRA | Yes | High | High | No |
| QOIR | Lossless | BGRA | Yes | Medium | High | Yes (more info) |
| QOY | Lossless | NV12 | No | Medium | Medium | No |
| LZ4* | Lossless | All (including HDR) | Yes | Medium | High | No |
| Density | Lossless | All (including HDR) | Yes | Low | High | Yes (more info) |
| JPEG | Lossy | NV12, I420, I444, BGRA | No | Medium | Low | Yes (more info) |
*LZ4 is very similar to Density, but has a higher CPU usage with roughly the same bandwidth demand, therefore it is hidden when the better Density algorithm is available on the system.
*QOI is very similar to QOIR, but has a higher CPU usage with a bit higher bandwidth demand, therefore it is hidden when the better QOIR algorithm is available on the system.
Only feeds with BGRA color format would be truly lossless, because YUV formats like NV12 (the default in OBS), I420 or I444 already lose some color information of the original data before any compression is even applied, but they also drastically reduce the bandwidth demand without extra CPU or GPU usage, so using them is usually a good deal. BGRA on the other hand will make you lose GPU hardware acceleration and therefore increase CPU usage from OBS even before Beam comes into play.
How much bandwidth is still needed for each compression algorithm depends heavily on the content of the video feed, a general prediction cannot be made. As a reference, here is the raw net bandwidth usage of some common resolutions and framerates:
| Resolution | FPS | NV12/I420 bandwidth | I444/P010/I010 bandwidth | BGRA bandwidth |
|---|---|---|---|---|
| 720p | 30 | 312 Mpbs | 632 Mpbs | 840 Mbps |
| 720p | 60 | 632 Mpbs | 1264 Mpbs | 1680 Mbps |
| 900p | 30 | 488 Mpbs | 984 Mpbs | 1312 Mbps |
| 900p | 60 | 984 Mpbs | 1976 Mpbs | 2632 Mbps |
| 1080p (FHD) | 30 | 704 Mpbs | 1416 Mpbs | 1896 Mbps |
| 1080p (FHD) | 60 | 1416 Mpbs | 2840 Mpbs | 3792 Mbps |
| 1440p (2K) | 30 | 1264 Mpbs | 2528 Mpbs | 3368 Mbps |
| 1440p (2K) | 60 | 2528 Mpbs | 5056 Mpbs | 6744 Mbps |
| 2160p (4K) | 30 | 2840 Mpbs | 5688 Mpbs | 7592 Mbps |
| 2160p (4K) | 60 | 5688 Mpbs | 11384 Mpbs | 15184 Mpbs |
- If you want to transmit between OBS instances on the same computer or have a network that is faster than the most widespread 1G setup you should check first whether the resolution, FPS and color format you want to transmit could be sent raw without compression, since this has the lowest CPU usage impact. Otherwise you want to look at the compression options.
- QOI(R) should only be used when you want to transmit BGRA color format anyway for other reasons, using BGRA in OBS only for the sake of using QOI(R) doesn't make sense, since switching to BGRA alone already comes with a CPU usage and bandwidth hit of its own.
- If your network can almost handle the bandwidth of the raw feed but not quite, Density might give you just the little bit of bandwidth usage reduction that you need for almost no CPU usage impact at strength 1, or an even more reduced bandwidth usage at strength 2 with a bit higher CPU usage comparable to that of NDI. By this you are not limited to any color format and can retain the original quality of your feed.
- If Density compressed bandwidth usage is still too high, going with NV12 and the QOY algorithm is an option to get a bit more bandwidth reduction at the cost of only slightly higher CPU usage, while still staying lossless (except for the quality loss NV12 already has by itself), the CPU usage should be similar to Density at strength 2, and therefore comparable to NDI.
- If your network isn't sufficient for any of the other options (usually standard 1G networks), nothing will beat the very low bandwidth usage of JPEG compression, even at the high default quality level of 90. Just like NDI it's a lossy algorithm, but at the default quality level 90 a human will hardly be able to really tell the difference. CPU usage is the highest of all algorithms (and a bit higher than NDI), but still manageable for most systems.
- If you only have a standard 1G network but want to try reducing the CPU usage a bit further, there often is headroom for lowering the level (not the quality) setting, which increases bandwidth demand but very often within what is still possible with 1G networks. However, note that this means that some frames are compressed and some are sent raw. The human eye most probably can't see this constant alternation between lossy and lossless, but it might have a negative effect on video codecs further down the line (when the feed eventually is recorded or streamed) - that's just theory though, there is no data on that, you will just need to try for yourself.
During beta phase of this plugin several algorithms have been implemented and tested and removed after they didn't seem to be useful in any scenario:
- WebP: extremely high CPU usage with mediocre compression at best
- PNG: extremely high CPU usage (even with the fast FPNGE implementation) with mediocre compression at best
- JPEG lossless: good compression, but extremely high CPU usage
- QOIR lossy: worse than JPEG in every single aspect (CPU usage, compression ratio, visual quality)
These were not implemented or tested but ruled out based on their characteristics:
- AV1: API complex to use, looking at video implementations of it, it's supposed to be still slower than all other options that Beam offers
- JPEG-XL: According to these benchmarks all variants are very slow