#1237 closed defect (worksforme)
mismatch between encoder and image
Reported by: | Antoine Martin | Owned by: | Antoine Martin |
---|---|---|---|
Priority: | critical | Milestone: | 1.0 |
Component: | encodings | Version: | trunk |
Keywords: | av-sync | Cc: |
Description
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.
Change History (8)
comment:1 Changed 6 years ago by
Status: | new → assigned |
---|
comment:3 Changed 6 years ago by
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.
comment:5 Changed 6 years ago by
Resolution: | → worksforme |
---|---|
Status: | assigned → closed |
comment:6 Changed 5 years ago by
Resolution: | worksforme |
---|---|
Status: | closed → reopened |
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.
comment:7 Changed 5 years ago by
Resolution: | → worksforme |
---|---|
Status: | reopened → closed |
This isn't fatal, I have not seen it, and I don't see how we could hit it... so closing again.
comment:8 Changed 16 months ago by
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1237
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.