#2200 closed defect (fixed)
html5 client visual corruption
Reported by: | Antoine Martin | Owned by: | Antoine Martin |
---|---|---|---|
Priority: | blocker | Milestone: | 2.5 |
Component: | html5 | Version: | 2.4.x |
Keywords: | Cc: |
Description (last modified by )
Seen with the win32 shadow server as tested for #2124.
Looks like some screen updates go missing. Likely to be scroll
or video
updates.
Links that may be related:
- ticket:1426#comment:8 - html5 visual corruption
- #2053: web client does not update regions...
- #2060: html5 h264 broadway decoder picture dimension is rounded up
- #2051: nvenc produces invalid stream - unlikely, reproducible without nvenc
- #1992: html5 scroll paint error
- #1637: Scroll paint bug in HTML5 Client
- #1432: html5 client should honour paint flush order
Change History (4)
comment:1 Changed 2 years ago by
Description: | modified (diff) |
---|---|
Status: | new → assigned |
comment:2 Changed 2 years ago by
comment:3 Changed 2 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Using XPRA_SAVE_VIDEO_STREAMS=1 xpra shadow ...
, then using ffmpeg to extract an image from the first frame:
ffmpeg -i window-1-0.1-x264.h264 -frames:v 1 -f image2 frame.png
I can see that the frames in that stream are just fine.
And ffprobe shows:
$ ffprobe window-1-0.1-x264.h264 ffprobe version 4.0.3 Copyright (c) 2007-2018 the FFmpeg developers built with gcc 8 (GCC) libavutil 56. 14.100 / 56. 14.100 libavcodec 58. 18.100 / 58. 18.100 libavformat 58. 12.100 / 58. 12.100 libavdevice 58. 3.100 / 58. 5.100 libavfilter 7. 16.100 / 7. 16.100 libavresample 4. 0. 0 / 4. 0. 0 libswscale 5. 1.100 / 5. 1.100 libswresample 3. 1.100 / 3. 1.100 libpostproc 55. 1.100 / 55. 1.100 [h264 @ 0x56024fdac4c0] decoding for stream 0 failed Input #0, h264, from 'window-1-0.1-x264.h264': Duration: N/A, bitrate: N/A Stream #0:0: Video: h264 (High), yuv420p(progressive), 824x530, 25 tbr, 1200k tbn, 50 tbc
Then with the "same" stream from a python2 server:
$ ffprobe window-1-0.1-x264.h264 ffprobe version 4.0.3 Copyright (c) 2007-2018 the FFmpeg developers built with gcc 8 (GCC) libavutil 56. 14.100 / 56. 14.100 libavcodec 58. 18.100 / 58. 18.100 libavformat 58. 12.100 / 58. 12.100 libavdevice 58. 3.100 / 58. 5.100 libavfilter 7. 16.100 / 7. 16.100 libavresample 4. 0. 0 / 4. 0. 0 libswscale 5. 1.100 / 5. 1.100 libswresample 3. 1.100 / 3. 1.100 libpostproc 55. 1.100 / 55. 1.100 [h264 @ 0x55db912104c0] decoding for stream 0 failed Input #0, h264, from 'window-1-0.1-x264.h264': Duration: N/A, bitrate: N/A Stream #0:0: Video: h264 (Constrained Baseline), yuv420p(progressive), 824x530, 25 tbr, 1200k tbn, 50 tbc
The big difference is in the profile:
- with python3 and
-d x264
:using default profile=high x264: get_tune() TUNE=None, fast_decode=1, content_type=desktop x264 context=0x53cf9e0, YUV420P 824x530 quality=100, speed=80, content_type=desktop x264 params: {'me': {'type': 'DIA', 'me-range': 16, 'mv-range': -1, 'mv-range-thread': -1, 'subpel_refine': 2, 'weighted-pred': 0}, 'rc': {'rc-method': 'CRF', 'qp_constant': -1, 'qp_min': 0, 'qp_max': 2147483647, 'qp_step': 4, 'bitrate': 0, 'vbv_max_bitrate': 0, 'vbv_buffer_size': 0, 'mb-tree': False, 'lookahead': -1}, 'vfr-input': False, 'bframe-adaptive': 'FAST', 'open-gop': True, 'bluray-compat': False, 'cabac': False, 'deblocking-filter': False, 'intra-refresh': False, 'interlaced': False, 'constrained_intra': False, 'threads': 'auto', 'sliced-threads': True} x264 encode YUV420P frame 0 as IDR slice with 4 nals, tune=b'zerolatency', total 221909 bytes, keyframe=True , delayed=0
- with python2
x264: get_tune() TUNE=None, fast_decode=1, content_type=desktop x264 context=0x4573df0, YUV420P 824x530 quality=100, speed=80, content_type=desktop x264 params: {u'vfr-input': False, u'intra-refresh': False, u'deblocking-filter': False, u'cabac': False, u'threads': u'auto', u'bframe-adaptive': u'FAST', u'constrained_intra' : False, u'open-gop': False, u'interlaced': False, u'me': {u'mv-range-thread': -1, u'weighted-pred': 0, u'subpel_refine': 2, u'me-range': 16, u'mv-range': -1, u'type': u'DIA'}, u'sliced-threads': True, u'bluray-compat': False, u'rc': {u'rc-method': u'CRF', u'vbv_buffer_size': 0, u'lookahead': -1, u'qp_min': 0, u'qp_step': 4, u'vbv_max_bitrate': 0, u'qp_max': 2147483647, u'mb-tree': False, u'bitrate': 0, u'qp_constant': -1}} x264 encode YUV420P frame 0 as IDR slice with 4 nals, tune=zerolatency, total 214879 bytes, keyframe=True , delayed=0
That's because the broadway decoder cannot handle the other profiles.
And so it is just the painful strings vs bytes from python3 (which is also a complete waste of CPU cycles):
- we have to use a typedict function to lookup the key without caring if it's a string or bytes
- we have to convert the result to a string so that it passes validation.
With python2, we don't need to worry about any of this nonsense.
Fixed in r22037.
comment:4 Changed 3 months ago by
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/2200
It seems that this only occurs reliably with the python3 version of the server.
-d compress
with html5 client "paint" debug enabled looks like this:Same with python3 server:
So the python3 server never triggers
broadway picture decoded
.