Xpra: Ticket #757: Getting "BUG: failed to setup video pipeline..." Server output

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.



Thu, 04 Dec 2014 21:09:32 GMT - alas: attachment set

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


Thu, 04 Dec 2014 21:10:51 GMT - alas: attachment set

Initial Incident of BUG - report


Thu, 04 Dec 2014 21:11:29 GMT - alas: attachment set

a repro with, possibly, different & interesting info


Thu, 04 Dec 2014 23:58:21 GMT - Antoine Martin: owner changed

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


Fri, 05 Dec 2014 02:06:04 GMT - alas:

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.




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


Fri, 05 Dec 2014 02:07:06 GMT - alas: attachment set

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


Sat, 06 Dec 2014 01:39:54 GMT - alas:

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

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.


Sat, 06 Dec 2014 07:50:17 GMT - Antoine Martin:

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.


Mon, 08 Dec 2014 20:47:26 GMT - Antoine Martin:

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.


Wed, 04 Feb 2015 00:30:06 GMT - alas: status changed; resolution set

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.


Sat, 23 Jan 2021 05:05:04 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/757