Description of problem:
Video playback on RHEL7 guest with Gnome3 (gnomeshell) is not detected as video stream by spice-server - according to spice debug log output, The interesting thing is that plymouth or moving of any application window may trigger video stream detection and the screen is being streamed as video.
I tried Flash or HMTL5 videos, as well as ogg video played in totem player, in all cases no video stream was detected by spice server.
Version-Release number of selected component (if applicable):
All (client/host/guest) RHEL7 PreBeta with Gnome3
# rpm -qa | egrep "qemu|kernel|spice"libvirt-daemon-driver-qemu-1.1.1-11.el7.x86_64
Steps to Reproduce:
1. Start a RHEL7 guest with Gonme 3 session on RHEL7 host with enabled Spice debug logging.
2. Start video playback on the RHEL7 guest (ogg video in totem, youtube flash/hmtl5 video).
The video playback is not detected as video stream by spice-server.
The drawing updates do not match with the video region. Furthermore, they are consecutive horizontal stripes of the whole display width and of variable height (depending on width of the video, the height can vary).
We can't reasonably have a heuristics based on those drawing updates. The width of updates is just wrong, it would result in higher bandwidth and noise or a lot of complexity to discover updated regions. Since we don't get atomic updates, it would result in a some tearing (and the server would have to somehow recompose the frame which would be more complexity). And the heuristic would have to be changed to deal with those consecutive stripes somehow
I suppose this is something that should be improved at the guest/compositor/renderer level. Any help welcome. Dave, any idea?
I've no good ideas, the problem is the compositor damages the full screen in most cases, maybe there could be some work done to improve things, but it requires a lot of investigation work, probably need to talk to Owen Taylor about it as well.
It seems clutter can handle clipped update region, but the llvm pipe can't
(gdb) print can_blit_sub_buffer
$6 = 0
(gdb) print has_buffer_age
$7 = 0
* "The "drisw" binding in Mesa for loading sofware renderers is
* broken, and neither glBlitFramebuffer nor glXCopySubBuffer
* work correctly."
* - ajax
* - https://bugzilla.gnome.org/show_bug.cgi?id=674208
* This is broken in software Mesa at least as of 7.10 and got
* fixed in Mesa 10.1
if (info->driver_package == COGL_GPU_INFO_DRIVER_PACKAGE_MESA &&
info->driver_package_version < COGL_VERSION_ENCODE (10, 1, 0) &&
(arch == COGL_GPU_INFO_ARCHITECTURE_LLVMPIPE ||
arch == COGL_GPU_INFO_ARCHITECTURE_SOFTPIPE ||
arch == COGL_GPU_INFO_ARCHITECTURE_SWRAST))
The version of cogl in dist-git 0:1.14.0-5.2.el7 doesn't have this issue.
Furthermore, the video is better detected with the patch from bug 910321 "PutImage BIG-REQUEST support"
Dave, do you think we could get those 2 updates?
moving to 7.2
I am working on improving video detection heuristic and handling in server, however this is unlikely to be ready for 7.2
My best attempt to fix this bug resulted in the following mesa patch:
No, this patch was never integrated (just checked on Mesa repository, just to make it sure, I also checked low level "putImage" code is is not using XSHM but still normal XPutImage).
Any way we could have this in 7.4 or at least prepare to be merged in a 7.5 release? Kind of porting and testing and trying to upstream again?
Version backported to 11.2.2 here: https://github.com/c3d/mesa/commit/6709e8c3bd8af5df9f748ee3449598aa1787fe51
Does not help solving the tearing issues I saw, unfortunately.
Any news on this?
The Xshm patches are now in the RHEL7.6 mesa.
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release. Therefore, it is being closed. If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.