#757 closed defect (needinfo)
Getting "BUG: failed to setup video pipeline..." Server output
Reported by: | alas | Owned by: | alas |
---|---|---|---|
Priority: | major | Milestone: | |
Component: | android | Version: | trunk |
Keywords: | Cc: |
Description
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.
Attachments (4)
Change History (11)
Changed 7 years ago by
Attachment: | ticket757-BUG-d-EncodingScore-server-log-output-clipped.txt added |
---|
Changed 7 years ago by
Attachment: | ticket757-BUG-h264-pipline-report-report.zip added |
---|
Initial Incident of BUG - report
Changed 7 years ago by
Attachment: | ticket757-RepeatOfVideoBug.zip added |
---|
a repro with, possibly, different & interesting info
comment:1 Changed 7 years ago by
Owner: | changed from Antoine Martin to alas |
---|
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
comment:2 Changed 7 years ago by
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 matchingget_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.
Changed 7 years ago by
Attachment: | ticket757-d-EncodingScoreScaling_server-output-clipping.txt added |
---|
ticket 757, server output with scaling added to the -d list
comment:3 Changed 7 years ago by
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 r8135 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 thexpra 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.
comment:4 Changed 7 years ago by
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.
comment:5 Changed 7 years ago by
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.
comment:6 Changed 7 years ago by
Resolution: | → needinfo |
---|---|
Status: | new → closed |
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.
comment:7 Changed 16 months ago by
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/757
-d encoding,score server output (pasted from terminal)