Found by scrolling around a lot for testing #1232:
2016-06-20 11:21:36,076 error processing encode queue at index 0 2016-06-20 11:21:36,076 item=(1466396496.034009, 596, 482, 1466396496.047771, XShmImageWrapper(BGRX: 0, 142, 596, 482), 'h264', 279, {'av-sync': True}, 0) Traceback (most recent call last): File "/usr/lib64/python2.7/site-packages/xpra/server/window/window_source.py", line 1441, in encode_from_queue self.make_data_packet_cb(*item) File "/usr/lib64/python2.7/site-packages/xpra/server/window/window_source.py", line 1471, in make_data_packet_cb packet = self.make_data_packet(damage_time, process_damage_time, image, coding, sequence, options, flush) File "/usr/lib64/python2.7/site-packages/xpra/server/window/window_source.py", line 1816, in make_data_packet ret = encoder(coding, image, options) File "/usr/lib64/python2.7/site-packages/xpra/server/window/window_video_source.py", line 1410, in video_encode ret = ve.compress_image(csc_image, quality, speed, options) File "xpra/codecs/enc_x264/encoder.pyx", line 619, in xpra.codecs.enc_x264.encoder.Encoder.compress_image (xpra/codecs/enc_x264/encoder.c:6701) assert len(pixels)==3, "image pixels does not have 3 planes! (found %s)" % len(pixels) AssertionError: image pixels does not have 3 planes! (found 1149088)
The video encoder expects a planar image (ie: YUV420P) but gets raw rgb data... Looks like we switched to RGB input but that the image in the queue is still in YUV format.. I think this is caused by av-sync (#835) and that we need to do the CSC step during the delayed encode, not before.
Nope, the whole video_encode method runs from the encode thread, as one unit. We do check that the pipeline is valid, and do_check_pipeline will ensure that the csc output format matches the video encoder's input format.
Will need to reproduce to track down.
Milestone renamed
Cannot reproduce this one any more...
Though I've seen this one instead, which may be a different symptom of the same underlying bug:
* during glxgears resizing: Traceback (most recent call last): File "/usr/lib64/python2.7/site-packages/xpra/server/window/window_source.py", line 1139, in expire_delayed_region self.may_send_delayed() File "/usr/lib64/python2.7/site-packages/xpra/server/window/window_source.py", line 1239, in may_send_delayed self.do_send_delayed() File "/usr/lib64/python2.7/site-packages/xpra/server/window/window_source.py", line 1251, in do_send_delayed self.send_delayed_regions(*delayed) File "/usr/lib64/python2.7/site-packages/xpra/server/window/window_source.py", line 1267, in send_delayed_regions self.do_send_delayed_regions(damage_time, regions, coding, options) File "/usr/lib64/python2.7/site-packages/xpra/server/window/window_video_source.py", line 658, in do_send_delayed_regions self.process_damage_region(damage_time, actual_vr.x, actual_vr.y, actual_vr.width, actual_vr.height, coding, video_options, 0) File "/usr/lib64/python2.7/site-packages/xpra/server/window/window_video_source.py", line 761, in process_damage_region sub = image.get_sub_image(w-dw, 0, dw, h) File "xpra/x11/bindings/ximage.pyx", line 304, in xpra.x11.bindings.ximage.XImageWrapper.get_sub_image (xpra/x11/bindings/ximage.c:3398) raise Exception("invalid sub-image width: %i+%i greater than image width %i" % (x, w, self.width))
happened whilst resizing a glxgears window.
Similar to #1287
Related:
I've not seen this bug since, so closing this ticket for now. (the stacktrace from comment:3 is the one already tracked in #1287)
Was just testing with a 2.2 r16911 fedora 25 server and a 2.2. r16869 win64 client, seeing some sound issues... and while disconnecting/reconnecting the client to check on sound initialization, I came upon a fail to encode x264 frame error traceback (showed server-side in logs).
2017-09-18 15:59:58,441 Error: failed to encode x264 video frame: 2017-09-18 15:59:58,442 image pixels does not have 3 planes! (found 921600) 2017-09-18 15:59:58,442 source: XShmImageWrapper(BGRX: 0, 151, 640, 360) 2017-09-18 15:59:58,443 options: 2017-09-18 15:59:58,443 * scroll : True 2017-09-18 15:59:58,443 encoder: 2017-09-18 15:59:58,444 * b-frames : 0 2017-09-18 15:59:58,444 * delayed : 0 2017-09-18 15:59:58,444 * formats : BGRX, YUV422P, YUV420P, BGRA, YUV444P 2017-09-18 15:59:58,444 * frame-types 2017-09-18 15:59:58,445 * frames : 0 2017-09-18 15:59:58,445 * generation : 91 2017-09-18 15:59:58,445 * height : 360 2017-09-18 15:59:58,445 * lossless : False 2017-09-18 15:59:58,445 * max-size : 8192, 4096 2017-09-18 15:59:58,446 * preset : superfast 2017-09-18 15:59:58,446 * profile : high10 2017-09-18 15:59:58,446 * quality : 49 2017-09-18 15:59:58,446 * source : unknown 2017-09-18 15:59:58,446 * speed : 96 2017-09-18 15:59:58,446 * src_format : YUV420P 2017-09-18 15:59:58,447 * tune : zerolatency 2017-09-18 15:59:58,447 * version : 148 2017-09-18 15:59:58,447 * width : 640
A few quick attempts to repro failed, so might have been a fluke - but leaving a server with a firefox window playing some random stuff off youtube, then disconnecting/reconnecting the client (triggered it before remembering to turn on the -d sound for the issue I was testing)... might be a start?
I'll let you know if I come up with a concrete repro, but thought you'd like to know this might be surfacing again.
This isn't fatal, I have not seen it, and I don't see how we could hit it... so closing again.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1237