Method

This is running on Sunshine latest master (e1b112c), on a M1 macbook.
All tests are using forced H.264 and only changing resolution and bitrate (Moonlight defaults used).

I benchmarked the method videoBroadcastThread() at different points using:

auto start = high_resolution_clock::now();

// code ...

auto stop     = high_resolution_clock::now();
auto duration = duration_cast<microseconds>(stop - start);
BOOST_LOG(info) << "Total time: " << duration.count();

This method will roughly do the following:

• waits for an encoded frame to come thru, then:
  • do a bunch of preparation operations (measured up until here)
  • for each FEC block of RTP packets (measured up until here)
    • FEC encode it (measured in here)
    • Adjust RTP headers
    • Send it

Results

Here are just the worst reported time for a very short (3 min) video streaming. All times reported are in microseconds.

Stream cfg	Preparation	Block 1 (FEC)	Block 2 (FEC)	Block 3 (FEC)	Total
1080p - 60fps - 20 Mbps	7377	1443 (1206)	1211 (1085)	1031 (921)	11062
2560x1600 - 60fps - 40 Mbps	8167	3053 (2831)	3179 (2924)	2982 (2781)	17381
4K - 60fps - 80 Mbps	21066	25447 (24847)	27608 (27139)	25570 (25119)	99691

These are the absolute worst performances, during a stream the frame size will swing wildly.
This is just to demonstrate that Sunshine code can introduce quite a big latency depending on the size of the encoded frame to be sent.