[Spice-devel] [PATCH spice-protocol 0/2] video streaming enhancements and bandwidth monitoring

[Yonit Halperin]

This patch series includes also patches for spice-common, spice, and spice-gtk.

Till now, the quality of the mjpeg stream was constant (70). However, when spice used ffmpeg's mjpeg,
it had employed its bit rate control, which eventually affected the stream quality.
This patch series introduces:
(1) Support for periodically monitoring the available bit rate of a channel.
The monitoring is based on the time it takes till a "large enough" message, that has been sent from 
the server, is received by the client (actually, till the time it takes the server to receive the ack for it). Thus,
this kind of monitoring suits channels that are used to pass large messages from the server to the client.
(2) Dynamically adjusting the video quality and frame rate, according to the available bit rate and the
current compression ratio for different jpeg qualities (might change significantly when the video scene
properties changes).
(3) Fix for playback glitches with youtube on different browsers in Windows7:
allow stream frames to be bigger and contain the original stream.


TODO:
- Measure latency. The current bandwidth monitoring will classify high-latency + high-bandwidth connection as low-bandwidth ones.
- Remove the initial bandwidth measurement in the main_channel (PING/PONG).
- Remove red_worker.c unused bit-rate setting code, which was used for ffmpeg
- Video tearing in spice-gtk. Sounds like it might happen due to screen
  updates that take place at the same time the canvas is being updated.

I decided not to send it (yet?), but I also worked on monitoring the time it 
takes the client to ack windows of messages (with SPICE_MSGC_ACK), 
when those messages are sent relatively fluently, and when we aggregate several windows
if the total size of the messages is too small.
The time that passes since a window starts till we receive an ack for it includes both the 
preparation time of the messages in the server, and the time it takes to the client to process the messages.
Thus, comparing this time to the QOS_QUERY time, could have given us some sort of estimation for the
cpu state of the client and server. 

Yonit Halperin (2):
  video streaming: add support for frames of different sizes
  Add qos related messages

 spice/enums.h    |    3 +++
 spice/protocol.h |    5 +++++
 2 files changed, 8 insertions(+), 0 deletions(-)

-- 
1.7.7.6