The patch below breaks the zero-copy code in the GStreamer video
encoder:
commit c3d237075b994fe67edddd58f2b3164cb579e6f4
Author: Frediano Ziglio <fziglio@xxxxxxxxxx>
Date: Mon Dec 12 17:22:50 2016 +0000
gstreamer: Avoid memory copy if strides are different
If bitmap stride and stream stride are different copy was used.
Using GStreamer 1.0 you can avoid the copy setting correctly
image offset and stride.
Signed-off-by: Frediano Ziglio <fziglio@xxxxxxxxxx>
Acked-by: Christophe Fergeau <cfergeau@xxxxxxxxxx>
The symptom is that each SpiceBitmap chunk gets incrementally shifted 8
pixels to the right. See the attached screenshot. Interestingly the 8
extra pixels don't seem to really be random but they don't seem to be
identical either.
Anyway, commenting out the gst_buffer_add_video_meta_full() line fixes
it (in cases where there is no need for cropping) but of course is
defeats the purpose of the patch.
I did not see anything obviously wrong in the patch. The bug is
unrelated to the codec: it happens with mjpeg, vp8 and h264. So to
reproduce it simply make sure you're using GStreamer for video, grab
big_buck_bunny_480p_h264.mov and play it with either mplayer or totem.
Maybe it's a gstreamer bug? Here I'm using 1.10.2.
--
Francois Gouget <fgouget@xxxxxxxxxxxxxxx>Attachment:
SpiceZeroCopy.png
Description: SpiceZeroCopy.png
_______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/spice-devel