[Spice-devel] Gstreamer, RHEL 7, OpenGL and stripes

[Frediano Ziglio]

Hi,
  yesterday/today I attempted to test the gstreamer patches.
My approach was mainly as "user", install and see how does it work.

I installed Francois patches for spice-protocol and spice-server
(not clients so I tested with mjpeg).
The initial test was playing this video:
  https://www.youtube.com/watch?v=IyTv_SR2uUo
under Firefox on a RHEL 7 VM.
The client window is maximized and the physical monitor resolution is 1920x1080.
I started testing with gstreamer enabled or disabled during compile time.
One thing I noted was that with gstreamer enabled the video have some
strange effect where the video seems to go back and forth in different
stripes! This was not happening without gstreamer enabled. Just video
is updated a bit slowly and showing some horizontal stripes.

To try to debug another problem I wrote some code to blend some color
to the different streams inside spice-server (you can have up to 50 streams)
so I moved this debug code on top of Francois gstreamer patches.
You can see code at
https://cgit.freedesktop.org/~fziglio/spice-server/log/?h=stream_bug_francois
(nothing fancy, just some ugly debug code).

What I discover was quite unexpected. The video is split in horizontal stripes
of about (less than) 64K (65536) pixel so for instance the video I was playing
was divided in stripes of 1671x39 pixels (about 23/24 stripes).
Doing similar testing with RHEL 6 and vlc I realized that this behavior is
common to OpenGL (using X11 output with VLC you have a big single stream).

I don't know why Mesa implementation use 64K stripes but the effect on spice
it's actually quite strange. One of the result I can see is that using RHEL 6
to play a single video with VLC (downloaded Sintel video from Blender website,
the 123mb one at https://durian.blender.org/download/) is  much smoother (and
obviously does not present the stripe effects).

Considering the way JPEG (and derivated) encoding work this striping could
have bad impacts on compression (huffman table is computed for every stripe)
and cpu usage (considering that image is split in 8x8 blocks you have additional
empty pixel to take care of).

Could be this a reason for
https://bugzilla.redhat.com/show_bug.cgi?id=1294564 ?

I'm actually trying to reproduce (without much success) the regression
with gstreamer enabled (video going back and forth in striped).

Another thing I noted is that just moving the mouse make the streaming
detection go a bit mad for a while with data sent with and without
streams (with my patch you can see flashing with not blend images from
normal drawing and blended images from streams).

Frediano