Getting "BUG: failed to setup video pipeline..." Server output

[totaam]

Issue migrated from trac ticket # 757

component: android | priority: major | resolution: needinfo

2014-12-04 20:57:40: afarr created the issue

---

Running with a client & server version that's slightly customized (dubbed locally as 0.14.13) r8192 - Windows 8.1 client against a fedora 20 server: When playing video and scrolling on a webpage with both text and video (youtube.com, huffingtonpost.com, presumably others) ... after some variable period of time I'm seeing the following error in server-side output: BUG: failed to setup a video pipeline for h264 encoding with source format BGRA, will fallback to: set(['png/L', 'rgb24', 'jpeg', 'webp', 'rgb32', 'png/P', 'png'])

I am able to reproduce the bug, though not always easily. I'll attach a couple of zipped bug reports with xpra info and such.

I was also able to reproduce with -d encoding,score running server-side, which I'll also attach.

[totaam]

2014-12-04 21:09:33: afarr uploaded file ticket757-BUG-d-EncodingScore-server-log-output-clipped.txt (120.9 KiB)

-d encoding,score server output (pasted from terminal)

[totaam]

2014-12-04 21:10:51: afarr uploaded file ticket757-BUG-h264-pipline-report-report.zip (24.8 KiB)

Initial Incident of BUG - report

[totaam]

2014-12-04 21:11:30: afarr uploaded file ticket757-RepeatOfVideoBug.zip (3615.9 KiB)

a repro with, possibly, different & interesting info

[totaam]

2014-12-04 23:58:22: antoine changed owner from antoine to afarr

[totaam]

2014-12-04 23:58:22: antoine commented

---

This is caused by scaling. It should be easier to trigger by lowering the quality and increasing the speed (which causes scaling to kick in earlier), making the dimensions bigger, or using the --scaling=100 command line option with 0.15

TILs:

scaling ((2, 3)) not supported by codec_spec(... 'codec_type': 'x264', 'encoding': 'h264', ..)
get_video_pipeline_options('h264', 1653, 2081, 'BGRA') scores=[]

So we end up with downscaling by 2:3 and without a csc step, x264 cannot do the scaling for us.

The real question is why we don't have a csc step (which would take care of the scaling):

• are all the csc modules installed? xpra info | grep csc to confirm - all seem to be there in the server info txt file - maybe try to run this when the bug occurs, just in case
• can we capture the list of pipeline options when the problem occurs:

xpra info | grep pipeline_option

• can you post the lines matching get_video_pipeline_options with -d score
• add -d scaling to the debug log

[totaam]

2014-12-05 02:06:04: afarr commented

---

Sure enough, those options not only sped up the repro process for the BUG, but also sped up the process of crashing some plugin or other.

• xpra info | grep csc produces the following:

 xpra info :13 | grep csc
client.encoding.csc_atoms=1
client.encoding.csc_modes=('YUV422P', 'BGRX', 'GBRP', 'RGB', 'YUV420P', 'BGRA', 'ARGB', 'XRGB', 'YUV444P')
client.encoding.full_csc_modes={'h264': ('ARGB', 'BGRA', 'BGRX', 'GBRP', 'RGB', 'XRGB', 'YUV420P', 'YUV422P', 'YUV444P'), 'h265': ('BGRX', 'GBRP', 'RGB', 'XRGB', 'YUV420P', 'YUV422P', 'YUV444P'), 'vp9': ('YUV420P', 'YUV422P', 'YUV444P'), 'vp8': ('YUV420P',)}
csc.BGRX_to_BGR=('swscale',)
csc.BGRX_to_GBRP=('swscale',)
csc.BGRX_to_RGB=('swscale',)
csc.BGRX_to_XRGB=('swscale',)
csc.BGRX_to_YUV420P=('swscale', 'cython')
csc.BGRX_to_YUV422P=('swscale',)
csc.BGRX_to_YUV444P=('swscale',)
csc.BGR_to_BGRX=('swscale',)
csc.BGR_to_GBRP=('swscale',)
csc.BGR_to_RGB=('swscale',)
csc.BGR_to_XRGB=('swscale',)
csc.BGR_to_YUV420P=('swscale',)
csc.BGR_to_YUV422P=('swscale',)
csc.BGR_to_YUV444P=('swscale',)
csc.GBRP_to_BGR=('swscale',)
csc.GBRP_to_BGRX=('swscale', 'cython')
csc.GBRP_to_RGB=('swscale',)
csc.GBRP_to_RGBX=('cython',)
csc.GBRP_to_XRGB=('swscale',)
csc.GBRP_to_YUV420P=('swscale',)
csc.GBRP_to_YUV422P=('swscale',)
csc.GBRP_to_YUV444P=('swscale',)
csc.RGB_to_BGR=('swscale',)
csc.RGB_to_BGRX=('swscale',)
csc.RGB_to_GBRP=('swscale',)
csc.RGB_to_XRGB=('swscale',)
csc.RGB_to_YUV420P=('swscale',)
csc.RGB_to_YUV422P=('swscale',)
csc.RGB_to_YUV444P=('swscale',)
csc.XRGB_to_BGR=('swscale',)
csc.XRGB_to_BGRX=('swscale',)
csc.XRGB_to_GBRP=('swscale',)
csc.XRGB_to_RGB=('swscale',)
csc.XRGB_to_YUV420P=('swscale',)
csc.XRGB_to_YUV422P=('swscale',)
csc.XRGB_to_YUV444P=('swscale',)
csc.YUV420P_to_BGR=('swscale',)
csc.YUV420P_to_BGRX=('swscale', 'cython')
csc.YUV420P_to_GBRP=('swscale',)
csc.YUV420P_to_RGB=('swscale',)
csc.YUV420P_to_RGBX=('cython',)
csc.YUV420P_to_XRGB=('swscale',)
csc.YUV420P_to_YUV422P=('swscale',)
csc.YUV420P_to_YUV444P=('swscale',)
csc.YUV422P_to_BGR=('swscale',)
csc.YUV422P_to_BGRX=('swscale',)
csc.YUV422P_to_GBRP=('swscale',)
csc.YUV422P_to_RGB=('swscale',)
csc.YUV422P_to_XRGB=('swscale',)
csc.YUV422P_to_YUV420P=('swscale',)
csc.YUV422P_to_YUV444P=('swscale',)
csc.YUV444P_to_BGR=('swscale',)
csc.YUV444P_to_BGRX=('swscale',)
csc.YUV444P_to_GBRP=('swscale',)
csc.YUV444P_to_RGB=('swscale',)
csc.YUV444P_to_XRGB=('swscale',)
csc.YUV444P_to_YUV420P=('swscale',)
csc.YUV444P_to_YUV422P=('swscale',)
encoding.csc-module.cython=active
encoding.csc-module.swscale=active

---

• Oddly, xpra info | grep pipeline_option produces nothing at all.

---

• Starting the server with the following: dbus-launch xpra --no-daemon --bind-tcp=0.0.0.0:1204 --start-child=xterm --start-child=epiphany start :13 -d encoding,score,scaling, when I try to search through my log excerpts, I find not a single line matching get_video_pipeline_options.

---

I'll attach another section of output excerpt (the majority of the test), with the scaling added to the list of -d.

[totaam]

2014-12-05 02:07:06: afarr uploaded file ticket757-d-EncodingScoreScaling_server-output-clipping.txt (49.8 KiB)

ticket 757, server output with scaling added to the -d list

[totaam]

2014-12-06 01:39:54: afarr commented

---

Well, if I weren't confused enough already, trying to swap clients and servers has done the trick. Here's a summary attempt that might make some sense of things (if I'm lucky).

• Testing with xpra.org/dists/... 0.14.12 8135 both server and client side, I am not able to reproduce the "BUG".

• Testing with our 0.14.13 server & client (both of which list as r8192) - I am able to reproduce the "BUG" more or less consistently/easily.

• Testing with the xpra.org 0.14.12 client build against our 0.14.13 server build, I AM also able to reproduce the "BUG".

• Testing with our 0.14.13 client build against an xpra.org TRUNK server build (r8205) I AM also able to reproduce the "BUG".

• Testing xpra.org TRUNK client build (r8217) against xpra.org TRUNK server build (r8205) I am also NOT able to reproduce the "BUG".

• Testing the xpra.org TRUNK client build (r8217) against our TRUNK server build (r8195) ... I run into a server-side Traceback and can't connect:

server-side relevant (looking) output:

2014-12-05 16:55:20,840 failed to parse screen size information: too many values to unpack
2014-12-05 16:55:20,994 server error processing new connection from Protocol(SocketConnection(('10.0.32.53', 1201) - ('10.0.11.129', 65143))): too many values to unpack
Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/xpra/server/server_base.py", line 609, in parse_hello_ui
    self.do_parse_hello_ui(ss, c, auth_caps, send_ui, share_count)
  File "/usr/lib64/python2.7/site-packages/xpra/server/server_base.py", line 637, in do_parse_hello_ui
    root_w, root_h = self.do_parse_screen_info(ss)
  File "/usr/lib64/python2.7/site-packages/xpra/server/server_base.py", line 629, in do_parse_screen_info
    root_w, root_h = self.set_best_screen_size()
  File "/usr/lib64/python2.7/site-packages/xpra/x11/x11_server_base.py", line 282, in set_best_screen_size
    return self.set_screen_size(max_w, max_h)
  File "/usr/lib64/python2.7/site-packages/xpra/x11/x11_server_base.py", line 335, in set_screen_size
    xinerama_changed = self.save_fakexinerama_config()
  File "/usr/lib64/python2.7/site-packages/xpra/x11/x11_server_base.py", line 439, in save_fakexinerama_config
    plug_name, x, y, width, height, wmm, hmm = m[:8]
ValueError: too many values to unpack
2014-12-05 16:55:20,998 Disconnecting client Protocol(SocketConnection(('10.0.32.53', 1201) - ('10.0.11.129', 65143))): server error (error accepting new connection)
2014-12-05 16:55:20,999 xpra client disconnected.

client-side output:

Xpra>xpra_cmd.exe attach tcp:10.0.32.53:1201
2014-12-05 16:55:18,487 xpra client version 0.15.0
2014-12-05 16:55:19,095 OpenGL_accelerate module loaded
2014-12-05 16:55:19,095 Using accelerated ArrayDatatype
2014-12-05 16:55:19,204 detected keyboard: layout=us
2014-12-05 16:55:19,204 desktop size is 3840x2160 with 1 screen(s):
2014-12-05 16:55:19,204   '1\WinSta-Default' (1016x571 mm - DPI: 96x96) workarea: 3840x2120
2014-12-05 16:55:19,204     DISPLAY1 (621x341 mm - DPI: 157x160) workarea: 3840x2120
2014-12-05 16:55:19,417 server failure: disconnected before the session could be established
2014-12-05 16:55:19,418 server requested disconnect: server error (error accepting new connection)
2014-12-05 16:55:19,632 Connection lost

(Is this a smoking gun?...)

• Trying to repeat with OSX, using the xpra.org TRUNK client (r8192) I am able to connect to our TRUNK server build (r8195). (I don't have a big enough monitor on my osx client, at the moment, to try to trigger the scaling and see if the BUG is reproducible, though I should be able to test if this seems likely to be useful.)

• Testing with our TRUNK client build (r8192) against our TRUNK server build (r8195) I am able to connect... and I am NOT able to reproduce the "BUG".

• In any case, I am able to find values for pipeline when grepping xpra info up until I see the "BUG", and afterward I am no longer getting any output from the xpra info query.

I have logs for all the permutations in which I was able to reproduce the BUG... let me know if any would be useful. If you can make sense of all the above permutations and have a guess at what to try next, let me know.

[totaam]

2014-12-06 07:50:18: totaam commented

---

I run into a server-side Traceback and can't connect:...
ValueError: too many values to unpack
[[BR]]

This is unrelated and is fixed in r8202.

[totaam]

2014-12-08 20:47:27: antoine commented

---

Judging from comment:3, it is only when using one of your builds that you hit the problem. I see no combination of pure-xpra builds exhibiting the problem, right? That's unexpected, I would have thought only one end should be affected (usually the server).

Can you post the -d all log of when you reproduce the bug, preferably using latest trunk if possible. If it's too big, only include 10K lines before the very first occurrence of the "BUG" line.

[totaam]

2015-02-04 00:30:06: afarr changed status from new to closed

[totaam]

2015-02-04 00:30:06: afarr set resolution to needinfo

[totaam]

2015-02-04 00:30:06: afarr commented

---

I can't even reproduce this with our builds anymore...

I'll close for now and re-open only if I can manage to reproduce in the future.