google chrome version 50 breaks video

[totaam]

Issue migrated from trac ticket # 1165

component: core | priority: minor | resolution: invalid

2016-04-14 02:14:51: jiang.qian created the issue

---

I was in xpra heaven, with everything working and fast: even video playback and sound are in sync! Then suddenly after upgrading to google chrome 50, from repository, the video forwarding stop working. Video are shown as black square with no moving images.

Symptom: Forwarding video by e.g. mplayer still works, but google video, whether flash video or youtube (H264 encoding), show up as empty square with sound still playing.

Interestingly, if I just do a forward X11 through ssh, videos also show up as blank square (obviously there's no sound there). Playing video on chrome in the native X11 screen directly attached to the workstation still works. When downgrading to chrome 49, it also works.

It must be chrome's fault!

My system are ubuntu 14.04 64 bit on both server and client. Xpra are downloaded from here http://xpra.org/beta/trusty/main/binary-amd64/ I'm using version 0.17.0-1 released on March 27.

Please let me know how I can help debugging this.

[totaam]

2016-04-14 03:09:55: antoine changed owner from antoine to jiang.qian

[totaam]

2016-04-14 03:09:55: antoine commented

---

You could try to enable Usage OpenGL to see if chrome switches to that for rendering.

[totaam]

2016-04-14 20:27:12: jiang.qian commented

---

My openGL works (there is no error message after I upgraded pythonGL via pip), I think. glxgears give much higher framerate over xpra than over ssh forwarded x11. (Indeed it is higher than glxgears running on client) glxinfo shows

OpenGL vendor string: VMware, Inc.
OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 3.4, 256 bits)

Which is what xpra always show me (forwarded X11 the rendering string is MESA). What other test can I use to see if my openGL over xpra is working or not?

But the google chrome video still shows a blank.

However, what does work is when I uncheck "use hardware acceleration when available" under chrome. So it does seem that the trouble is with graphic acceleration over xpra, at least for old ubuntu 14.04.

However, for now, I could get a workaround by unchecking use hardware acceleration when available under chrome.

[totaam]

2016-04-14 21:26:22: jiang.qian commented

---

OK, I'm writing too fast. I found that despite giving no error message, the openGL may not be working in my case after all. When I select from xpra applet to enable OpenGL (which was not enabled by default somehow), all of my forwarded window become blank. So there must really be some problem with openGL in my set up. The error message is this. I am using rgb raw pixel forwarding. What is the problem? Should I file a new bug report since this is not a chrome problem, but an OpenGL problem?

2016-04-14 16:30:21,021 do_paint_rgb32 error
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/xpra/client/window_backing_base.py", line 314, in do_paint_rgb32
    success = self._do_paint_rgb32(img_data, x, y, width, height, rowstride, options)
  File "/usr/lib/python2.7/dist-packages/xpra/client/gl/gl_window_backing_base.py", line 634, in _do_paint_rgb32
    return self._do_paint_rgb(32, img_data, x, y, width, height, rowstride, options)
  File "/usr/lib/python2.7/dist-packages/xpra/client/gl/gl_window_backing_base.py", line 650, in _do_paint_rgb
    self.gl_init()
  File "/usr/lib/python2.7/dist-packages/xpra/client/gl/gl_window_backing_base.py", line 406, in gl_init
    glTexParameteri(GL_TEXTURE_RECTANGLE_ARB, GL_TEXTURE_MAX_LEVEL, 0)
  File "errorchecker.pyx", line 53, in OpenGL_accelerate.errorchecker._ErrorChecker.glCheckError (src/errorchecker.c:1218)
GLError: GLError(
        err = 1281,
        description = 'invalid value',
        baseOperation = glTexParameteri,
        cArguments = (
                GL_TEXTURE_RECTANGLE_ARB,
                GL_TEXTURE_MAX_LEVEL,
                0,
        )

[totaam]

2016-04-15 03:54:42: antoine commented

---

However, what does work is when I uncheck "use hardware acceleration when available" under chrome. So it does seem that the trouble is with graphic acceleration over xpra, at least for old ubuntu 14.04. [[BR]] No, see comment:1, what you want is probably vglrun if you have a real graphics card in that system you can use. Xpra does not care about what is used for rendering (opengl or not), it only captures the pixels that get rendered onto the virtual screen, it's likely that the newer google chrome now uses an opengl API that doesn't work properly with your vfb. This may be fixed by using a better / newer version of vfb (ie: newer xdummy), or using vglrun.

[totaam]

2016-04-15 04:30:03: jiang.qian commented

---

Unfortunately, no, it still does not work. I use vglrun. It works over xpra (the glxgears performances tripled and rendering strings in glxinfo shows virtualgl). But when I use vglrun to launch chrome, it still show a blank square for video if I do not uncheck "use acceleration" in chrome. So it is not just an opengl issue, unfortunately.

[totaam]

2016-04-15 04:31:13: antoine commented

---

So it is not just an opengl issue, unfortunately. [[BR]] What makes you think that? I think it clearly is, whatever acceleration chrome uses does not work with the vfb. Little to do with xpra.

[totaam]

2016-04-15 04:43:50: jiang.qian commented

---

But why then doesn't it work with vglrun?

[totaam]

2016-04-15 04:47:04: antoine commented

---

It should, but there's more to it than just vglrun, maybe chrome is probing the display for xv adapters or something. What I am saying is that the vfb is likely to be the problem: chrome tries to use some hardware feature that is not present in the vfb. (and the failure to detect this looks like a real bug in chrome)

I will try it here when I get a chance with a more up to date system than ubuntu 14.04.

[totaam]

2016-04-15 04:54:32: jiang.qian changed priority from blocker to minor

[totaam]

2016-04-15 04:54:32: jiang.qian commented

---

OK, I'll probably upgrade to ubuntu 16.04 when it comes out, though it is my production system so I may not have time to upgrade it for a little while. Thanks for looking into this! I'll change the priority to lower, since there is a workable workaround here (simply disabling hardware acceleration in chrome).

[totaam]

2016-04-15 05:07:15: antoine commented

---

Note: I think xdummy is still horribly broken in 16.04, so this may not help at all.

[totaam]

2016-04-15 05:13:22: jiang.qian commented

---

Ubuntu now have snappy package. Essentially it is a package that contains all its dependencies rather than relying on the package that comes with the OS. Will this help, or is Xdummy and python too much to include in a single package? https://developer.ubuntu.com/en/snappy/build-apps/ I'm sorry ubuntu is such a pain. It is unfortunately too much of a pain to switch to fedora, now that I've been with apt-get system for over a decade---debian is just too out of date.

(I did start out in linux with redhat, from 7.3 to 9.0, until redhat split up into fedora and Redhat Enterprise. Back then there wasn't yum so dependency hell was very real for me back then!)

Thanks for looking into this. It is not too much hassle right now, since I could just disable acceleration on chrome. It's not too much of a penalty.

[totaam]

2016-08-09 16:14:05: antoine commented

---

I have actually fixed the bug from comment:3 in r13237, done as part of the work in #1275: older versions of Ubuntu and Debian will be supported in the next release! These changes should allow you to run with opengl enabled on older systems. (though they may still be greylisted for opengl by default) Note: this fixes the opengl client side, NOT the video forwarding issue with chrome...

[totaam]

2016-09-21 04:19:39: antoine changed status from new to closed

[totaam]

2016-09-21 04:19:39: antoine set resolution to invalid

[totaam]

2016-09-21 04:19:39: antoine commented

---

Tried and things are definitely messed up, not sure how much of it is virtualbox's opengl driver's fault and how much of it is Ubuntu's - but this is not an xpra bug so I am closing as invalid.

There is a workaround: as per comment:1, I can make google-chrome run OK by using virtualgl. You can automate this by using "exec-wrapper = vglrun" in your xpra config. This requires that a "real" X11 display is running on this server system for providing accelerated opengl. (setting up virtualgl is out of scope)

Without vglrun, opengl applications render badly or not at all (black rectangle), the google-chrome window is garbled and half of it is being rendered on the "real" display which it should NOT have access to at all.