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.
-d encoding,score server output (pasted from terminal)
Initial Incident of BUG - report
a repro with, possibly, different & interesting info
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):
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
xpra info | grep pipeline_option
get_video_pipeline_options with -d score
-d scaling to the debug log
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
xpra info | grep pipeline_option produces nothing at all.
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.
ticket 757, server output with scaling added to the -d list
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).
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?...)
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.
I run into a server-side Traceback and can't connect:...
ValueError?: too many values to unpack
This is unrelated and is fixed in r8202.
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.
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.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/757