mismatch between encoder and image

[Antoine Martin]

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.

[Antoine Martin]

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.

[Antoine Martin]

Milestone renamed

[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.

[Antoine Martin]

Similar to #1287

[Antoine Martin]

Related:

• r13664: missing csc cleanup
• r13048: race condition

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)

[alas]

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.

[Antoine Martin]

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

[migration script]

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