> On 24 Feb 2017, at 11:58, Francois Gouget <fgou...@codeweavers.com> wrote: > > > The patch below breaks the zero-copy code in the GStreamer video > encoder: > > commit c3d237075b994fe67edddd58f2b3164cb579e6f4 > Author: Frediano Ziglio <fzig...@redhat.com> > 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 <fzig...@redhat.com> > Acked-by: Christophe Fergeau <cferg...@redhat.com> > > > 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.
Looking at the patch, I wonder why we pass an offset and a stride from different sources (offset is from the source, but stride is from the bitmap)? Shouldn’t we use the stream stride? I’m not very familiar with that code yet, but that struck me as odd. > 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 > <fgou...@codeweavers.com><SpiceZeroCopy.png>_______________________________________________ > Spice-devel mailing list > Spice-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/spice-devel _______________________________________________ Spice-devel mailing list Spice-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/spice-devel
