mjpeg: fix libjpeg assertion

After the changes to add libjpeg-turbo support to spice-server mjpeg
compression code, it's relatively easy to hit an assertion from
libjpeg in spice-server about "too few scanlines transferred" when
the mjpeg streaming code triggers. This assertion brings down qemu,
which is bad :)

This is because when we first initialize the mjpeg encoder, we do:

stream_width = SPICE_ALIGN(src_rect->right - src_rect->left, 2);
stream_height = SPICE_ALIGN(src_rect->bottom - src_rect->top, 2);

stream->mjpeg_encoder = mjpeg_encoder_new(stream_width, stream_height);

and then when we iterate over the image scanlines to feed them to
libjpeg, we do:

const int image_height = src->bottom - src->top;
const int image_width = src->right - src->left;

for (i = 0; i < image_height; i++) {
    mjpeg_encoder_encode_scanline(...);
}
mjpeg_encoder_end_frame(...);

When stream_height is odd, the mjpeg_encoder will be created with
an height that is 1 more than the number of lines we encode. Then
libjpeg asserts when we tell it we're done with the compression
while it's still waiting for one more scanline.

Looking through git history, this rounding seems to be an artifact
from when we were using ffmpeg for the mjpeg encoding. Since
spicec and spicy (the latter needs a few fixes) can handle streams
with odd height/width, the best way to solve this issue is to stop
rounding up the height and width of the streams we create. This
even saves some bandwidth :)

0 files changed, 0 insertions, 0 deletions