| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
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 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.
|
|
|
|
|
|
|
| |
changes
If the encoding size seems to get smaller/bigger, re-evaluate the
stream quality and frame rate.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
| |
Fix crashes when there are sized wider frames in the stream, and we are
linked with libjpeg.
Related : rhbz#813826
Resolves: rhbz#820669
|
|
|
|
|
| |
It should have been the allocated size and not the occupied one.
This led to a lot of unnecessary allocations and deallocations.
|
|
|
|
| |
each frame
|
|
|
|
|
|
|
|
|
|
|
|
| |
rhbz #813826
When playing a youtube video on Windows guest, the driver sometimes(**) sends
images which contain the video frames, but also other parts of the
screen (e.g., the youtube process bar). In order to prevent glitches, we send these
images as part of the stream, using SPICE_MSG_DISPLAY_STREAM_DATA_SIZED.
(**) It happens regularly with the you tube html5 player. With flash,
it occurs when moving the cursor in the player area.
|
|
|
|
|
| |
It will abort by default for critical level messages. That behaviour
can be tuned at runtime.
|
|
|
|
|
| |
The free() function allows NULL to be passed in, so any
code which puts a if() before free() is wasting time
|
|
|
|
| |
fix another 64 bit-ism. unsigned long != size_t in general.
|
|
|
|
|
| |
I forgot to handle SPICE_BITMAP_FMT_RGBA when mapping from
spice image formats to libjpeg-turbo colorspaces.
|
|
|
|
|
| |
jpeg_mem_dest is a public symbol in libjpeg8 so using it with
no prefix will cause symbol clashes. Rename it to spice_jpeg_mem_dest.
|
|
|
|
|
|
| |
It's not used when we use jpeg-turbo colorspaces, so it's better
to allocate it when we know we'll need it rather than always
allocating it even if it won't be used.
|
|
|
|
|
|
| |
After the refactoring to optionally use libjpeg-turbo, some
of the functions that mjpeg-encoder used to provide are now no
longer used. This commit removes them.
|
|
|
|
|
|
| |
When libjpeg-turbo is available, we can use the BGR and BGRX
colorspaces that it provides to avoid extra conversions of the
data we want to compress to mjpeg
|
|
|
|
|
| |
Returns the number of bytes per pixel corresponding to the input
data format.
|
|
|
|
|
|
| |
This API is meant to allow us to move the pixel format conversion
into MjpegEncoder. This will allow us to be able to use the
additional pixel formats from libjpeg-turbo when available.
|
|
|
|
|
|
|
|
|
|
| |
When encoding a frame, red_worker passes an allocated buffer to
libjpeg where it should encode the frame. When it fails, a new
bigger buffer is allocated and the encoding is restarted from
scratch. However, it's possible to use libjpeg to realloc this
buffer if it gets too small during the encoding process. Make use
of this feature, especially since it will make it easier to encore
one line at a time instead of a full frame in subsequent commits.
|
| |
|
|
|
|
|
|
|
|
| |
When using config.h, it must be the very first include in all source
files since it contains #define that may change the compilation process
(eg libc structure layout changes when it's used to enable large file
support on 32 bit x86 archs). This commit adds it at the beginning
of all .c and .cpp files
|
| |
|
| |
|
|
|