Bug 1030024

Summary: Video playback is not detected as video stream thus not compressed.
Product: Red Hat Enterprise Linux 7 Reporter: Marian Krcmarik <mkrcmari>
Component: mesaAssignee: Dave Airlie <airlied>
Status: CLOSED WONTFIX QA Contact: Desktop QE <desktop-qa-list>
Severity: high Docs Contact:
Priority: unspecified    
Version: 7.0CC: airlied, dinechin, kem, marcandre.lureau, mboisver, otaylor, tpelka, vbenes, victortoso
Target Milestone: rcKeywords: Triaged
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Known Issue
Doc Text:
Video playback on a Red Hat Enterprise Linux 7.0 Beta guest with GNOME Shell is sometimes not detected as a video stream by spice-server. The video stream is therefore not compressed in such a case.
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-12-15 07:28:20 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 910321    
Bug Blocks: 1025505, 1294564    

Description Marian Krcmarik 2013-11-13 18:15:41 UTC
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
qemu-img-1.5.3-19.el7.x86_64
kernel-3.10.0-42.el7.x86_64
qemu-guest-agent-1.5.3-17.el7.x86_64
qemu-kvm-common-1.5.3-19.el7.x86_64
spice-server-0.12.4-3.el7.x86_64
spice-glib-0.20-6.el7.x86_64
qemu-kvm-debuginfo-1.5.3-19.el7.x86_64
spice-debuginfo-0.12.4-3.el7.x86_64
qemu-kvm-1.5.3-19.el7.x86_64
spice-vdagent-0.14.0-5.el7.x86_64
kernel-3.10.0-44.el7.x86_64
spice-gtk3-0.20-6.el7.x86_64

How reproducible:
Always

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).

Actual results:
The video playback is not detected as video stream by spice-server.

Comment 5 Marc-Andre Lureau 2014-07-04 12:31:21 UTC
confirming

Comment 6 Marc-Andre Lureau 2014-07-04 20:48:51 UTC
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?

Comment 7 Dave Airlie 2014-07-06 21:58:05 UTC
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.

Comment 8 Marc-Andre Lureau 2014-07-08 16:40:40 UTC
It seems clutter can handle clipped update region, but the llvm pipe can't

In clutter_stage_cogl_redraw():
(gdb) print can_blit_sub_buffer
$6 = 0
(gdb) print has_buffer_age
$7 = 0

Comment 9 Marc-Andre Lureau 2014-07-08 16:51:09 UTC
In cogl:

      /*
       * "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))
        {
          COGL_FLAGS_SET (context->winsys_features,
                          COGL_WINSYS_FEATURE_SWAP_REGION, FALSE);
        }

Comment 10 Marc-Andre Lureau 2014-07-09 14:11:31 UTC
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?

Comment 11 Marc-Andre Lureau 2015-01-02 14:45:15 UTC
moving to 7.2

Comment 13 Marc-Andre Lureau 2015-05-22 14:54:15 UTC
I am working on improving video detection heuristic and handling in server, however this is unlikely to be ready for 7.2

Comment 14 Marc-Andre Lureau 2015-06-05 17:16:49 UTC
My best attempt to fix this bug resulted in the following mesa patch:
http://lists.freedesktop.org/archives/mesa-dev/2015-June/085860.html

moving component

Comment 18 Frediano Ziglio 2017-03-07 08:36:24 UTC
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?

Comment 19 Christophe de Dinechin 2017-03-22 10:26:53 UTC
Version backported to 11.2.2 here: https://github.com/c3d/mesa/commit/6709e8c3bd8af5df9f748ee3449598aa1787fe51

Does not help solving the tearing issues I saw, unfortunately.

Comment 20 Victor Toso 2018-01-26 16:04:42 UTC
Any news on this?

Comment 21 Dave Airlie 2018-06-08 20:47:36 UTC
The Xshm patches are now in the RHEL7.6 mesa.

Comment 24 RHEL Program Management 2020-12-15 07:28:20 UTC
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.