5 ms·

I’m very impressed by the video quality and the bitrate. The DJI FPV systems sending HD video use either 25 or 50 mbit/s, while this is getting comparable quali

I’m very impressed by the video quality and the bitrate. The DJI FPV systems sending HD video use either 25 or 50 mbit/s, while this is getting comparable quality with an order of magnitude less throughout. It has me wondering if the 25mbit/s is a large amount of error correction bits sent in order to improve latency. Two questions I have - what is the video latency for this system versus a DJI FPV system? And how many devices can be supported concurrently from a single access point? It would be exciting if this tech could evolve to support “crowded fields” for FPV races.

danboarder 5y ago
Regarding fpv racing and low latency - OpenHD is more of a two-way network connection + HD video so the latency is around 135ms with a lot of optimization and OpenGL overlay graphics, while the shark byte HD FPV system is more optimized for very low latency (5 to 30ms) digital broadcast (I think sharkbyte is open hardware but not software): https://www.fatshark.com/product/shark-byte-module/ https://www.fatshark.com/product/shark-byte-module/ Open.HD latency testing thread: https://www.rcgroups.com/forums/showthread.php?3154184-Open-HD-DIY-135ms-Latency-DIY-DIGITAL-HD-FPV-Discussion/page39 https://www.rcgroups.com/forums/showthread.php?3154184-Open-...
baybal2 5y ago
The problem is the video codec not being degradation tolerant, this way you need a quite an overkill amount of FEC. If a codec can tolerate just a few percents of arbitrary bit errors without completely garbling the image, you can slash the bandwidth many times even with a youtube level HD quality.
- lazide 5y ago
  The issue is that video compression (to produce good compression) creates anti-redundancy - it puts more information into fewer bits by adding dependencies for more areas onto a few bits, and merging many duplicate (redundant) bits into one spot. It also makes later frames more dependent on earlier frames and the side effects of decompressing, to avoid transferring the information again (and adding more anti-redundancy). With a real-time feed used for command and control of something like a fast moving aircraft in close proximity to objects, you have the opposite situation - you want maximum reliability, clear and predictable degradation, and fastest recovery, even if it comes at the cost of clarity or bandwidth. They’re literally working to opposite goals.

danboarder 5y ago

Regarding fpv racing and low latency - OpenHD is more of a two-way network connection + HD video so the latency is around 135ms with a lot of optimization and OpenGL overlay graphics, while the shark byte HD FPV system is more optimized for very low latency (5 to 30ms) digital broadcast (I think sharkbyte is open hardware but not software): https://www.fatshark.com/product/shark-byte-module/ https://www.fatshark.com/product/shark-byte-module/ Open.HD latency testing thread: https://www.rcgroups.com/forums/showthread.php?3154184-Open-HD-DIY-135ms-Latency-DIY-DIGITAL-HD-FPV-Discussion/page39 https://www.rcgroups.com/forums/showthread.php?3154184-Open-...

baybal2 5y ago

The problem is the video codec not being degradation tolerant, this way you need a quite an overkill amount of FEC. If a codec can tolerate just a few percents of arbitrary bit errors without completely garbling the image, you can slash the bandwidth many times even with a youtube level HD quality.

lazide 5y ago
The issue is that video compression (to produce good compression) creates anti-redundancy - it puts more information into fewer bits by adding dependencies for more areas onto a few bits, and merging many duplicate (redundant) bits into one spot. It also makes later frames more dependent on earlier frames and the side effects of decompressing, to avoid transferring the information again (and adding more anti-redundancy). With a real-time feed used for command and control of something like a fast moving aircraft in close proximity to objects, you have the opposite situation - you want maximum reliability, clear and predictable degradation, and fastest recovery, even if it comes at the cost of clarity or bandwidth. They’re literally working to opposite goals.