[Spice-devel] [spice v13 03/29] server: Add a GStreamer 1.0 MJPEG video encoder and use it by default

Francois Gouget fgouget at codeweavers.com
Thu May 26 14:49:56 UTC 2016


On Tue, 3 May 2016, Christophe Fergeau wrote:
[...]
> > > > +         /* Copy the line */
> > > > +         uint8_t *src = chunks->chunk[chunk_index].data + chunk_offset;
> > > > +         memcpy(dst, src, stream_stride);
> > > 
> > > Are we guaranteed that we'll have at least 'stream_stride' bytes in the
> > > chunk?
> > 
> > Yes, the is_chunk_padded() check guarantees it. I could rename it to 
> > is_chunk_stride_aligned() to make it clearer.
> 
> Hmm, this guarantees we have at least bitmap->stride bytes, which
> is (assumed to be?) bigger than stream_stride. Is there an explicit
> check/reason that bitmap->stride is bigger than stream_stride?

The red-parse-qxl patch addresses this concern which applied 
equally to all video encoders.
https://lists.freedesktop.org/archives/spice-devel/2016-May/029563.html


> Also, is there anything preventing chunks->chunk[index].len to be 0 in
> is_chunk_padded()?

It is ok for chunks->chunk[index].len to be 0. All it means is that we 
will skip that chunk (since necessarily chunk_offset >= len) and go to 
the next one. See:

         while (chunk_offset >= chunks->chunk[chunk_index].len) {
             if (is_chunk_stride_aligned(bitmap, chunk_index)) {
                 return FALSE;
             }
             chunk_offset -= chunks->chunk[chunk_index].len;
             chunk_index++;
         }

In zero_copy() it means we create a 0-byte GstMemory object which seems 
to be fine, and in chunk_copy() it means we copy 0 bytes which is fine.

-- 
Francois Gouget <fgouget at codeweavers.com>


More information about the Spice-devel mailing list