Reduce traffic smoothing window size

This matches WebRTC which uses 5ms as described in:
https://tools.ietf.org/html/draft-ietf-rmcat-gcc-02#section-5

Now instead of sending a large burst and then waiting 100ms before
starting to trickle out packets, we will send a very small burst and
start to trickle packets after 5ms. This may result in medium size
video frames taking longer to send but overall traffic will be smoother
and raising the allowed peak send bandwidth should more than make up
for the smoothing delay on networks that can handle it.

This new behavior seems to perform better in all situations. If you have
a fast connection your peak kbps will be much higher than the video kbps
and only minimal smoothing will be applied. If you are streaming at
close to the speed of your connection then significant smoothing will be
applied to keep within your network's capability. Doing this smoothing
at the application level is preferred with RTP over trusting the user's
router and connection to handle large bursts of packets.

Author: danstiner

libftl/ftl_private.h

@@ -69,7 +69,7 @@
 #define NACK_RTT_AVG_SECONDS 5
 #define MAX_STATUS_MESSAGE_QUEUED 100
 #define MAX_FRAME_SIZE_ELEMENTS 64 //must be a minimum of 3
-#define MAX_XMIT_LEVEL_IN_MS 100 //allows a maximum burst size of 100ms at the target bitrate
+#define MAX_XMIT_LEVEL_IN_MS 5 // allows a maximum burst size of 5ms at the peak bitrate
 #define VIDEO_RTP_TS_CLOCK_HZ 90000
 #define AUDIO_SAMPLE_RATE 48000
 #define AUDIO_PACKET_DURATION_MS 20