Use peak kbps for video traffic smoothing

Keyframes cause a burst of traffic that may exceed the streamer's connection
speed and thus cause excessive buffering by their router or another hop
along the path to their streaming service.

To counteract this FTL does traffic shaping/smoothing for video packets.

However the implementation is a bit broken. It allows a peak kbps rate
to be set but entirely ignores it and limits outgoing bandwidth to
exactly the video bitrate, calculated over a running 100ms window.

This has very poor behavior on mostly static streams with large
keyframes. For example take a 5000kbps stream that has 200KB keyframes
every two seconds. Because the send rate is limited to 63.5KB every
100ms window it will take 320ms to send the keyframe. But because the
stream is mostly static, non-keyframes will be very small and send
without being delayed.

That is a huge amount of jitter for the low-latency streaming FTL is
trying to support, and it happens even if the user's connections can
support sending at a faster rate. Using the measured speed solves this.

Looking the speedtest and peak bandwidth calculation code, I can only
conclude using the peak kbps value is what the FTL dev's meant to do.

libftl/media.c

@@ -1223,11 +1223,11 @@ OS_THREAD_ROUTINE video_send_thread(void *data)
   while (1) {
 
     if (initial_peak_kbps != video->peak_kbps) {
+      bytes_per_ms = video->peak_kbps * 1000 / 8 / 1000;
       initial_peak_kbps = video->kbps = video->peak_kbps;
     }
 
     if (video->kbps != video_kbps) {
-      bytes_per_ms = video->kbps * 1000 / 8 / 1000;
       video_kbps = video->kbps;
 
       disable_flow_control = 0;