[Spice-devel] [spice v15 01/21] mjpeg: Use src_area as the authoritative source for the frame dimensions

[Christophe Fergeau]

On Thu, May 26, 2016 at 05:15:35PM +0200, Francois Gouget wrote:
> Video frames correspond to QXL_DRAW_COPY operations where the frame area
> is defined by the SpiceCopy.src_area field.
> 
> Signed-off-by: Francois Gouget <fgouget at codeweavers.com>
> ---
>  server/mjpeg-encoder.c | 14 ++++++--------
>  1 file changed, 6 insertions(+), 8 deletions(-)
> 
> diff --git a/server/mjpeg-encoder.c b/server/mjpeg-encoder.c
> index e3646db..7dcea50 100644
> --- a/server/mjpeg-encoder.c
> +++ b/server/mjpeg-encoder.c
> @@ -706,7 +706,7 @@ static void mjpeg_encoder_adjust_fps(MJpegEncoder *encoder, uint64_t now)
>   */
>  static int mjpeg_encoder_start_frame(MJpegEncoder *encoder,
>                                       SpiceBitmapFmt format,
> -                                     int width, int height,
> +                                     const SpiceRect *src,
>                                       uint8_t **dest, size_t *dest_len,
>                                       uint32_t frame_mm_time)
>  {
> @@ -777,10 +777,12 @@ static int mjpeg_encoder_start_frame(MJpegEncoder *encoder,
>          return VIDEO_ENCODER_FRAME_UNSUPPORTED;
>      }
>  
> +    encoder->cinfo.image_width = src->right - src->left;
> +    encoder->cinfo.image_height = src->bottom - src->top;

I don't think this is correct in the !SIZED_STREAM case. dcc-send.c has:

    if (drawable->sized_stream) {
        if (red_channel_client_test_remote_cap(rcc, SPICE_DISPLAY_CAP_SIZED_STREAM)) {
            SpiceRect *src_rect = &drawable->red_drawable->u.copy.src_area;

            width = src_rect->right - src_rect->left;
            height = src_rect->bottom - src_rect->top;
        } else {
            return FALSE;
        }
    } else {
        width = stream->width;
        height = stream->height;
    }

so if the client has SPICE_DISPLAY_CAP_SIZED_STREAM, we can use src_rect.
However, in the !CAP_SIZED_STREAM case, we are not using the size of the current bitmap
during encoding, but rather the initial size of the stream. Ie I'm worried that
with this simplification, the stream we are sending is not of the right resolution in
the !CAP_SIZED_STREAM case.

Christophe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/spice-devel/attachments/20160531/fb5411bb/attachment.sig>