RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1030024 - Video playback is not detected as video stream thus not compressed.
Summary: Video playback is not detected as video stream thus not compressed.
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: mesa
Version: 7.0
Hardware: Unspecified
OS: Unspecified
Target Milestone: rc
: ---
Assignee: Dave Airlie
QA Contact: Desktop QE
Depends On: 910321
Blocks: 1025505 1294564
TreeView+ depends on / blocked
Reported: 2013-11-13 18:15 UTC by Marian Krcmarik
Modified: 2020-12-15 07:28 UTC (History)
9 users (show)

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.
Clone Of:
Last Closed: 2020-12-15 07:28:20 UTC
Target Upstream Version:

Attachments (Terms of Use)

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

How reproducible:

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

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) &&
          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:

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.

Note You need to log in before you can comment on or make changes to this bug.