summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* server/red_parse_qxl: two coding convention pointer cast fixAlon Levy2013-05-171-2/+2
|
* server/dispatchers: initialize stack to 0 for valgrindAlon Levy2013-05-172-5/+5
|
* server/red_dispatcher: close pa hole in RedWorkerMessageDisplayConnect for ↵Alon Levy2013-05-171-2/+2
| | | | valgrind
* server/tests: test_display_width_strideAlon Levy2013-05-174-7/+154
|
* server/red_worker: simplify monitors_config updateAlon Levy2013-05-171-7/+6
|
* server/tests/test_display_base: add missing set_client_capabilities, fix ↵Alon Levy2013-05-171-1/+11
| | | | client_monitors_config signature
* server/red_worker: turn critical (assert) non error into warningAlon Levy2013-05-171-1/+4
| | | | | The situation causing this assert is unknown but it doesn't cause correctness issues with later rendering, and it is causing an abort.
* server/red_worker: s/driver_has_monitors_config/driver_cap_monitors_config/ ↵Alon Levy2013-05-171-5/+7
| | | | (plus small comment)
* red_worker: don't get bit_rate from main_channel_client, if it wasn't ↵Yonit Halperin2013-05-091-12/+30
| | | | | | | | | | | | initialized When setting an initial video stream bit rate, if the bit rate wasn't calculated by main_channel_client, and we don't have estimation from previos streams, use some default values. The patch also removes updating dcc->streams_max_bit_rate when the bit_rate held by the main_channel is larger than it. It is not necessary since we compare those 2 values each time we set the initial bit rate for a stream.
* reds: fix memory leak when core->base.minor_version < 3Yonit Halperin2013-05-081-3/+2
|
* reds: move handle_channel_event logic from main_dispatcher to redsYonit Halperin2013-05-083-9/+19
| | | | | main_dispactcher role is to pass events to the main thread. The logic that handles the event better not be inside main_dispatcher.
* red_worker: fail handle_migrate_data instead of aborting when there is an ↵Yonit Halperin2013-05-081-11/+25
| | | | error during restoration of surfaces
* red_channel: notify and shutdown a channel client when its ↵Yonit Halperin2013-05-081-2/+5
| | | | handle_migrate_data fails
* red_channel: add spice_channel_client_errorYonit Halperin2013-05-081-0/+11
| | | | | | | | spice_channel_client_error prints warning and shutdowns the channel_client that hit the error. This macro is useful for errors that are specific for one session and that are unrecoverable only with respect to this session. Prefer disconnecting a client over aborting when possible.
* red_worker: fix incorrect is_low_bandwidth after migrating a low bandwidth ↵Yonit Halperin2013-05-081-0/+3
| | | | | | | | | | | | | | | connection rhbz#956345 After a spice session has been migrated, we don't retest the network (user experience considerations). Instead, we obtain the is_low_bandwidth flag from the src-server, via the migration data. Before this patch, if we migrated from server s1 to s2 and then to s3, and if the connection to s1 was a low bandwidth one, we erroneously passed is_low_bandwidth=FALSE from s2 to s3. Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
* red_worker: cleanup: add is_low_bandwidth flag to CommonChannelClientYonit Halperin2013-05-081-14/+15
| | | | | | Replace the mixed calls to display_channel_client_is_low_bandwidth and to main_channel_client_is_low_bandwidth, with one flag in CommonChannelClient that is set upon channel creation.
* main_channel: add routine for checking if a network test had been conducted ↵Yonit Halperin2013-05-082-1/+15
| | | | and completed
* red_worker: remove wrong TODOAlon Levy2013-05-051-2/+0
| | | | | | red_create_stream is called even without any client but there is no encoding since the mjpeg encoder is now associated with StreamAgent which is only created when we have a client.
* red_channel: on migration target, start sending ping messages only after the ↵Yonit Halperin2013-05-011-1/+15
| | | | | | | | | | client's migration has completed The connection to the target server is established before migration starts. However, the client reads and replies to messages from the server only after migration completes. Thus, we better not send ping msgs from the target before migration completes (because the observed roundtrip duration will be bigger than the real one).
* red_channel: stop sending ping messages after migration has completedYonit Halperin2013-05-011-0/+5
| | | | | We mustn't send any msg to the client, besides MSG_MIGRATE_DATA, after we send MSG_MIGRATE.
* reds: fix not sending the mm-time after migration when there is no audio ↵Yonit Halperin2013-05-011-4/+14
| | | | | | | | | | | | playback This bug results in the client dropping all the video frames after migration in case that (1) the hosts involved in migration have different mm-time; and that (2) there is no audio playback. This is relvant only for the client that was connected during the migration. rhbz#958276
* red_channel: fix not handling self pipe items in red_channel_client_release_itemYonit Halperin2013-04-301-0/+3
| | | | | | | When a client disconnects, red_channel_client_pipe_clear is called. Releasing pipe items of type == MIGRATE||EMPTY_MSG||PING wasn't handled, and was passed to channel_cbs.release_item. There, an error occured since the pipe items were not recognized.
* server: Add public spice_qxl_driver_unload methodHans de Goede2013-04-246-1/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | With a SPICE_DISPLAY_CAP_MONITORS_CONFIG capable client, the client needs to know what part of the primary to use for each monitor. If the guest driver does not support this, the server sends messages to the client for a single monitor spanning the entire primary. As soon as the guest calls spice_qxl_monitors_config_async once, we set the red_worker driver_has_monitors_config flag and stop doing this. This is a problem when the driver gets unloaded, for example after a reboot or when switching to a text vc with usermode mode-setting under Linux. To reproduce this start a multi-mon capable Linux guest which uses usermode mode-setting and then once X has started switch to a text vc. Note how the client window does not only not resize, if you try to resize it manually you always keep blackborders since the aspect is wrong. This patch is the spice-server side of fixing this, it adds a new spice_qxl_driver_unload method which clears the driver_has_monitors_config flag. The other patch needed to fix this is in qemu, and will calls this new method from qxl_enter_vga_mode. Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* red_worker: assign mm_time to vga framesYonit Halperin2013-04-221-4/+9
|
* red_worker: increase the interval limit for stream framesYonit Halperin2013-04-221-1/+1
|
* collect and print video stream statisticsYonit Halperin2013-04-222-1/+77
|
* server/red_worker: add an option to supply the bandwidth via env varYonit Halperin2013-04-221-5/+24
| | | | | SPICE_BIT_RATE can be set for supplying red_worker the available bandwidth (in Mbps).
* server/red_worker.c: use the bit rate of old streams as a start point for ↵Yonit Halperin2013-04-223-1/+22
| | | | | | | | new streams mjpeg_encoder modify the initial bit we supply it, according to the client feedback. If it reaches a bit rate which is higher than the initial one, we use the higher bit rate as the new bit rate estimation.
* red_worker: video streams - adjust client playback latencyYonit Halperin2013-04-221-5/+54
|
* reds: support mm_time latency adjustmentsYonit Halperin2013-04-225-1/+64
| | | | | | | | When there is no audio playback, we set the mm_time in the client to be older than the one in the server by at least the requested latency (the delta is actually bigger, due to the network latency). When there is an audio playback, we adjust the mm_time in the client by adjusting the playback buffer using SPICE_MSG_PLAYBACK_LATENCY.
* snd_worker: support sending SPICE_MSG_PLAYBACK_LATENCYYonit Halperin2013-04-223-0/+46
| | | | also update spice-common submodule
* dispatcher.h: fix - s/#define MAIN_DISPATCHER_H/#define DISPATCHER_HYonit Halperin2013-04-222-3/+4
|
* red_worker: ignoring video frame drops that are not due to pipe congestionYonit Halperin2013-04-221-3/+13
| | | | | | A frame can be dropped if a new frame was added during the same call to red_process_command (we didn't attempt to send the older frame). Such drops are ignored.
* red_worker: notify mjpeg_encoder on server frame dropsYonit Halperin2013-04-221-4/+13
|
* red_worker: support SPICE_MSGC_DISPLAY_STREAM_REPORTYonit Halperin2013-04-223-2/+85
| | | | | | update mjpeg_encoder with reports from the client about the playback quality. The patch also updates the spice-common submodule.
* red_worker: start using mjpeg_encoder rate control capabilitiesYonit Halperin2013-04-223-59/+68
| | | | | | | | | | This patch only employs setting the stream parameters based on the initial given bit-rate, the latency, and the encoding size. Later patches will also employ mjpeg_encoder response to client reports, and its control over frame drops. The patch also removes old stream bit rate calculations that weren't used.
* server/red_worker: enable latency monitoring in the display channelYonit Halperin2013-04-221-1/+4
|
* red_worker: stream - update periodically the input frame rateYonit Halperin2013-04-221-1/+35
| | | | | Periodically calculate the rate of frames arriving from the guest to the server.
* red_channel: monitor connection latency using MSG_PINGYonit Halperin2013-04-227-2/+251
|
* server/red_worker: assign timer callbacks to worker_core, using ↵Yonit Halperin2013-04-221-0/+14
| | | | | | | spice_timer_queue display channel - supplying timeouts interface to red_channel, in order to allow periodic latency monitoring (see next patch).
* server: spice_timer_queueYonit Halperin2013-04-223-0/+313
| | | | | Each thread can create a spice_timer_queue, for managing its own timers.
* mjpeg_encoder: add stream warmup time, in which we avoid server and client dropsYonit Halperin2013-04-221-0/+27
| | | | | | | | The stream starts after lossless frames were sent to the client, and without rate control (except for pipe congestion). Thus, on the beginning of the stream, we might observe frame drops on the client and server side which are not necessarily related to mis-estimation of the bit rate, and we would like to wait till the stream stabilizes.
* mjpeg_encoder: keep the average observed fps similar to the defined fpsYonit Halperin2013-04-221-2/+73
| | | | | | | | | | | The actual frames distribution does not necessarily fit the condition "at least one frame every (1000/rate_contorl->fps) milliseconds". For keeping the average frame rate close to the defined fps, we periodically measure the current average fps, and modify rate_control->adjusted_fps accordingly. Then, we use (1000/rate_control->adjusted_fps) as the interval between the frames.
* mjpeg_encoder: move the control over frame drops to mjpeg_encoderYonit Halperin2013-04-223-23/+40
|
* mjpeg_encoder: update the client with estimations for the required playback ↵Yonit Halperin2013-04-222-14/+39
| | | | | | | | | | latency The required client playback latency is assessed based on the current estimation of the bit rate, the network latency, and the encoding size of the frames. When the playback delay that is reported by the client seems too small, or when the stream parameters change, we send the client an updated playback latency estimation.
* mjpeg_encoder: modify stream bit rate based on server side pipe congestionYonit Halperin2013-04-222-22/+91
| | | | | | Downgrading stream bit rate when the input frame rate in the server exceeds the output frame rate, and frames are being dropped from the output pipe.
* mjpeg_encoder: adjust the stream bit rate based on periodic client feedbackYonit Halperin2013-04-223-10/+401
| | | | | | | | mjpeg_encoder can receive periodic reports about the playback status on the client side. Then, mjpeg_encoder analyses the report and can increase or decrease the stream bit rate, depending on the report. When the bit rate is changed, the quality and frame rate of the stream are re-evaluated.
* mjpeg_encoder: re-configure stream parameters when the frame's encoding size ↵Yonit Halperin2013-04-221-8/+139
| | | | | | | changes If the encoding size seems to get smaller/bigger, re-evaluate the stream quality and frame rate.
* mjpeg_encoder: configure mjpeg quality and frame rate according to a given ↵Yonit Halperin2013-04-223-7/+312
| | | | | | | | | | | | | | | bit rate Previously, the mjpeg quality was always 70. The frame rate was tuned according to the frames' congestion in the pipe. This patch sets the quality and frame rate according to a given bit rate and the size of the first encoded frames. The following patches will introduce an adaptive video streaming, in which the bit rate, the quality, and the frame rate, change in response to different parameters. Patches that make red_worker adopt this feature will also follow.
* server/red_worker: streams: moving mjpeg_encoder from Stream to StreamAgentYonit Halperin2013-04-221-16/+22
| | | | | | | | | | | | | | The mjpeg_encoder should be client specific, and not shared between different clients**, for the following reasons: (1) Since we use abbreviated jpeg datastream for mjpeg, employing the same mjpeg_encoder for different clients might cause errors when the clients decode the jpeg data. (2) The next patch introduces bit rate control to the mjpeg_encoder. This feature depends on the bandwidth available, which is client specific. ** at least till we change multi-clients not to re-encode the same streams.
generated by cgit (git 2.34.1) at 2024-05-21 01:42:15 +0000