Xpra: Ticket #1237: mismatch between encoder and image

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.



Wed, 22 Jun 2016 13:48:10 GMT - Antoine Martin: status changed

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.


Tue, 12 Jul 2016 16:52:22 GMT - Antoine Martin: milestone changed

Milestone renamed


Wed, 07 Sep 2016 10:23:43 GMT - Antoine Martin:

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.


Tue, 13 Sep 2016 11:46:49 GMT - Antoine Martin:

Similar to #1287


Wed, 21 Sep 2016 12:27:50 GMT - Antoine Martin: status changed; resolution set

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)


Mon, 18 Sep 2017 23:26:59 GMT - alas: status changed; resolution deleted

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.


Wed, 25 Oct 2017 17:34:39 GMT - Antoine Martin: status changed; resolution set

This isn't fatal, I have not seen it, and I don't see how we could hit it... so closing again.


Sat, 23 Jan 2021 05:18:45 GMT - migration script:

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