+++ This bug was initially created as a clone of Bug #978403 +++

Current state:
All the bitmaps streams that are detected as video, are transferred by spice as an MJPEG stream with static quality of 70.
The frame rate is modified correspondingly to the send-queue congestion.
On the client side, lip sync is implemented by rendering frames when their timestamp correspond to the audio packets being played. Frames with timestamp > current-audio-time, are dropped. The playback latency is determined by the audio latency. The audio latency is not adjusted during playback.

Over limited bandwidth, videos that are played in high resolution, can be unwatchable, with the client dropping more than 70% of the frames that were sent from the server.

Plan:

Dynamically adjust the video bit-rate (by changing quality & frame rate) and the playback latency, using periodic reports from the client about the playback, and evaluating the available bandwidth and latency according to them.
Moreover, the bandwidth and latency estimations of past video playbacks will be used for improving the initial parameters setting of future video playbacks (and can also be used for other spice transfers that can be adjusted for better performance under different network conditions).

Expected Results:

Over limited bandwidth, we should observe a better user experience when watching video playback. While the quality of the frames might be worse, the continuity of the playback should improve (i.e., less occurrences of scenes dropping and pauses).

Over high bandwidth, the user experience shouldn't degrade. However, since it can take a little time to learn the network parameters, the start of the first video playback quality (during a specific connection), might be a bit worse.