One standard in HFT is the FAST Protocol[1], an adaptation of the FIX Protocol. One of FIX's newer developments is Simple Binary Encoding[2], which is designed for minimal latency. There's many differences between FIX and "normal" protocols that are really interesting when you realize how much thought went into shaving off as much latency as possible with FIX. Unfortunately, FIX is one of the few solutions in HFT that is publicly available as many firms make money from being the fastest in a particular area.

I doubt many HFT developments could be adapted for use in video streaming, as bandwidth is rarely an issue and hardware can cost much more. However, I would not be surprised if at some point in the future an HFT firm creates a general solution applicable for video.

[1] https://www.fixtrading.org/standards/fast/

[2] https://en.wikipedia.org/wiki/Financial_Information_eXchange...

Edit: Grammar

Gear in this space has to hit sub-frame latency (best in market at the moment is around 0.02 milliseconds), maintain extremely high signal quality (4K60 4:4:4 or 4:2:0) and provide perfect sync across all decode endpoints.

Due to the these constraints it’s a world that lives exclusively in the dedicated hardware space. Some main players that are worth checking out are SDVoE and their associated implementers, Crestron NVX, SVSI, Atlona Omnistream and Lightware UBEX. Dante have also just released their new board that handles all the sync and transmission but let’s inplementers pick there codec of choice too which should be interesting.

Most gear shipping at the moment uses either JPEG2000 or VC-2 based codecs or hand wavey “proprietary” ones that chip vendors refuse to give info on. There some interesting work being done in the form of the JPEG XS codec too. It provides low latency, but also super low quality loss over multiple encode / decode steps too.

Given some of the engineering constraints, it’s a super interesting area to watch.

The MPEG-DASH part 6 spec starts going in this direction, and we tried to run with these ideas in Puffer (https://puffer.stanford.edu). Empirically you can get quick channel changes and better first-chunk quality with this approach; we haven't tried to minimize end-to-end latency below standard levels. And there's probably nothing fundamental that you can do with a WebSocket that you can't do with a sufficiently smart chunked HTTP response.

For really low latency, you want to couple the video codec parameters with the transport's capacity estimate in a way that the WebRTC.org/Chromium codebase is not really capable of doing. See https://snr.stanford.edu/salsify .

It works by repackaging an RTMP stream into GOP chunks and pushes them via Websockets to the browser where they're piped to a video player using MSE (Media Source Extension).

On iPhones, where there is (was) no MSE available it used something like very short, chunked HLS segments. Not sure I fully understood that part but somehow they tricked the m3u8 playlist into loading short segments very very often.

The beauty of it was that it was a drop-in plugin for your existing RTMP-based infrastructure. You just add an instance of their server software and you would use their JS player to your pull your RTMP stream, repackaged on-the-fly.

    let player = new NanoPlayer({
        server: 'wss://nano_server_url', 
        rtmp:   'rtmp://rtmp_server_url/app/stream.mp4'
    });

It's standard to refer to esports as "esports" or "Esports" rather than "eSports".

(see: https://www.dexerto.com/news/esports-esports-associated-pres...)