Xpra: Ticket #1135: degrading video quality more than the rest

Similar and related to #1130 and #967: we want to ensure that when we need to make sacrifices to cope with the amount of pixels that need to be encoded we sacrifice the video area picture quality (if there is video), before we degrade the rest of the window. And also make sure that we only use a video encoder when it is the right choice for the content.

We already have hooks for this: WindowVideoSource get_speed / get_quality: the non-video areas get a huge speed and quality boost.

Other things we could / should be doing:



Wed, 24 Feb 2016 09:35:15 GMT - Antoine Martin: owner, description changed


You can see the server quality settings getting updated with -d stats by looking for update_quality in the output, or with:

xpra info | grep "encoding.quality"

The "backlog_factor" is new and takes the form: backlog_factor=(PACKETS, PIXELS, TARGET_QUALITY). When the recent compression ratio is better than average, the delta should increase the target quality. (and conversely, it should show a negative delta value to lower the quality when the recent is worse than average)

There are some new environment variables which can be used to tune the video region detection code (maybe this can be tuned better so as to exclude problematic cases like #967):


@afarr: do you have reliable test cases to verify that this improves the corner cases we want to deal with?


Wed, 20 Jul 2016 19:39:59 GMT - Antoine Martin:

See also: ticket:1257#comment:3 and ticket:1257#comment:4.


Fri, 02 Sep 2016 22:51:42 GMT - alas:

Testing with 1.0 r13520, both win32 client and fedora 23 server, I'm almost never seeing any change in the backlog_factor (I saw one instance where it was different, but otherwise the only value I've seen is 'backlog_factor': (0, 0, 100) with -d stats running).

I was so fixated on the backlog_factor (thinking this was an indicator of the compression ration you mentioned) that I almost missed that there is another value "two doors over" called - 'compression-ratio'. Nearly oops.

Using the awful site from #967 (http://www.msn.com/en-us/money) I'm finding that the quality, even when I am just looking at a static page, seems to be in the 30s regularly, even when the compression-ratio values are (0, 0, 0) (I am tempted to presume it also uses an (AVERAGE, RECENT, DELTA) format, but in that case the DELTA would often be 0... which I would think would indicate a likelihood that the successive frames are identical, in which case I would presume the quality would want to increase drastically, rather than remain in the 30s?).

Since I'm not entirely sure what to make of the compression-ratio values, I'll add some logs gathered with stats debugging enabled (I set up the pages, started the logging, behaved as the logs are named, then turned off the logging), but a couple quick excerpts for glancing at:

In every case, the video region detection is very often off (as indicated by opengl paint boxes), which I'll investigate further with both the environment variables in this ticket and #1060 and comment further in one of those, or #967...

I am also, in many cases, seeing that mousing around pages like cnn while video is playing will trigger jpeg encoding, often over most of the rest of the window, which will also degrade quality visibly (not sure how to tell whether the quality value listed in the stats logs corresponds to video regions vs. non-video regions that might be getting painted with jpeg).


Fri, 02 Sep 2016 22:52:19 GMT - alas: attachment set

msn-money stats without any interaction


Fri, 02 Sep 2016 22:53:00 GMT - alas: attachment set

msn-money with a lot of mousing over regions & widgets


Fri, 02 Sep 2016 22:53:29 GMT - alas: attachment set

msn-money with both mousing and scrolling


Tue, 06 Sep 2016 15:51:08 GMT - Antoine Martin:

Based on the data above, and some quick tests, I have tweaked the heuristics a bit:

This ticket is being hampered by the issues with video region detection (#967), hopefully r13587 fixes some of those problematic cases.

The value for the quality setting shown in this ticket is the baseline, video encoders should lower the quality and non-video encoders should increase it. You can see the quality actually used for each screen update with "-d compress". And just as important is the CSC mode: video areas should be using "YUV420P" and "film" tuning (#1257).


Tue, 27 Sep 2016 09:51:18 GMT - Antoine Martin: priority, milestone changed


Wed, 05 Oct 2016 01:22:24 GMT - alas: owner changed

Testing some more with 1.0 r13977 osx client against 1.0 r13979 fedora 23 server... after checking on the x264 logging expected from #1257, and looking at that last comment... I'm now running the server with -d stats,x264,compress.

Playing around with a number of sites with and without video, with or without scrolling, I think I might have a bit of a handle on this.

Here's sample (from watching a youtube video) of the correlation I'm seeing between the "compression-ratio" delta and the quality settings after update_quality() calls... which seems to also be affected by 'latency' (which I assume is really just a factor in the heuristics which happens to be noticeably related to the changes seen).

2016-10-03 18:17:28,197 update_quality() info={'batch-delay-ratio': 159, 'backlog_factor': (0, 0, 100), 'latency': 4457, 'compression-ratio': (130, 119, 2), 'min_quality': 30, 'min_speed': 30}, quality=99
…
2016-10-03 18:17:29,198 update_quality() info={'batch-delay-ratio': 42, 'backlog_factor': (0, 0, 100), 'latency': 3271, 'compression-ratio': (163, 156, 1), 'min_quality': 30, 'min_speed': 30}, quality=49
…
2016-10-03 18:17:30,195 update_quality() info={'batch-delay-ratio': 42, 'backlog_factor': (0, 0, 100), 'latency': 3859, 'compression-ratio': (163, 161, 0), 'min_quality': 30, 'min_speed': 30}, quality=45
…
2016-10-03 18:17:31,198 update_quality() info={'batch-delay-ratio': 46, 'backlog_factor': (0, 0, 100), 'latency': 9654, 'compression-ratio': (104, 36, 24), 'min_quality': 30, 'min_speed': 30}, quality=62
…
2016-10-03 18:17:32,200 update_quality() info={'batch-delay-ratio': 47, 'backlog_factor': (0, 0, 100), 'latency': 17305, 'compression-ratio': (52, 13, 16), 'min_quality': 30, 'min_speed': 30}, quality=57
…
2016-10-03 18:17:33,200 update_quality() info={'batch-delay-ratio': 42, 'backlog_factor': (0, 0, 100), 'latency': 21425, 'compression-ratio': (55, 26, 11), 'min_quality': 30, 'min_speed': 30}, quality=50
…
2016-10-03 18:17:34,200 update_quality() info={'batch-delay-ratio': 52, 'backlog_factor': (0, 0, 100), 'latency': 3523, 'compression-ratio': (83, 132, -25), 'min_quality': 30, 'min_speed': 30}, quality=38
2016-10-03 18:17:34,264 x264 context=0x7fa9453e4e20,    BGRX  854x480  quality=38, speed=83, source=unknown
2016-10-03 18:17:34,265  preset=veryfast, profile=high444, tune=zerolatency
2016-10-03 18:17:34,265  me=DIA, me_range=16, mv_range=-1, b-frames=0, max delayed frames=0
2016-10-03 18:17:34,265  vfr-input=0, lookahead=-1, sync-lookahead=0, mb-tree=0, bframe-adaptive=FAST
2016-10-03 18:17:34,265  threads=auto, sliced-threads=True
2016-10-03 18:17:34,266 x264 close context 0x0
2016-10-03 18:17:34,272 x264 encode frame     0 as  IDR slice with 7 nals, total   11846 bytes, keyframe=True , delayed=0
2016-10-03 18:17:34,272 compress:  15.1ms for  854x480  pixels at  195,150  for wid=2     using  h264 with ratio   0.7% ( 1601KB to    11KB), client_options={'pts': 0, 'frame': 0L, 'flush': 0, 'csc': 'YUV444P', 'type': 'IDR', 'quality': 38, 'speed': 83}
2016-10-03 18:17:34,284 packet decoding sequence 79 for window 2: 854x480 took 9.0ms
2016-10-03 18:17:34,284 record_latency: took   10.6 ms round trip,   10.5 for echo,    9.0 for decoding of   409920 pixels,    11944 bytes sent over the network in    1.6 ms,    1.5 ms for echo
2016-10-03 18:17:34,332 x264 encode frame     1 as    P slice with 4 nals, total     139 bytes, keyframe=False, delayed=0
2016-10-03 18:17:34,332 compress:   9.0ms for  854x480  pixels at  195,150  for wid=2     using  h264 with ratio   0.0% ( 1601KB to     0KB), client_options={'pts': 67, 'frame': 1L, 'flush': 0, 'csc': 'YUV444P', 'type': 'P', 'quality': 38, 'speed': 83}
2016-10-03 18:17:34,340 packet decoding sequence 80 for window 2: 854x480 took 3.2ms
2016-10-03 18:17:34,341 record_latency: took    7.3 ms round trip,    7.2 for echo,    3.0 for decoding of   409920 pixels,      236 bytes sent over the network in    4.1 ms,    4.1 ms for echo
2016-10-03 18:17:34,342 rgb_encode using level=1, lz4 compressed 855x3 in rgb24/BGRX: 10260 bytes down to 58
2016-10-03 18:17:34,342 compress:   0.4ms for  855x3    pixels at  194,630  for wid=2     using rgb24 with ratio   0.6% (   10KB to     0KB), client_options={'flush': 1, 'bucket': 3, 'lz4': 1, 'store': 161, 'rgb_format': 'BGRX'}
2016-10-03 18:17:34,343 rgb_encode using level=1, lz4 compressed 1x480 in rgb24/BGRX: 1920 bytes down to 25
2016-10-03 18:17:34,344 compress:   0.5ms for    1x480  pixels at  194,150  for wid=2     using rgb24 with ratio   1.3% (    1KB to     0KB), client_options={'flush': 0, 'lz4': 1, 'rgb_format': 'BGRX'}
2016-10-03 18:17:34,347 packet decoding sequence 81 for window 2: 855x3 took 0.8ms
2016-10-03 18:17:34,347 record_latency: took    2.8 ms round trip,    2.7 for echo,    0.0 for decoding of     2565 pixels,      137 bytes sent over the network in    2.0 ms,    2.0 ms for echo
2016-10-03 18:17:34,348 packet decoding sequence 82 for window 2: 1x480 took 1.4ms
2016-10-03 18:17:34,349 record_latency: took    3.9 ms round trip,    3.8 for echo,    1.0 for decoding of      480 pixels,       85 bytes sent over the network in    2.5 ms,    2.5 ms for echo
2016-10-03 18:17:34,391 x264 encode frame     2 as    P slice with 4 nals, total    2045 bytes, keyframe=False, delayed=0
2016-10-03 18:17:34,391 compress:  10.2ms for  854x480  pixels at  195,150  for wid=2     using  h264 with ratio   0.1% ( 1601KB to     1KB), client_options={'pts': 126, 'frame': 2L, 'flush': 0, 'csc': 'YUV444P', 'type': 'P', 'quality': 38, 'speed': 83}
2016-10-03 18:17:34,398 packet decoding sequence 83 for window 2: 854x480 took 3.4ms
2016-10-03 18:17:34,398 record_latency: took    5.9 ms round trip,    5.8 for echo,    3.0 for decoding of   409920 pixels,     2142 bytes sent over the network in    2.5 ms,    2.4 ms for echo
2016-10-03 18:17:34,408 compress:   4.8ms for 1684x162  pixels at    0,630  for wid=2     using  jpeg with ratio   2.6% ( 1065KB to    27KB), client_options={'quality': 78, 'flush': 3}
2016-10-03 18:17:34,418 compress:   9.2ms for  635x480  pixels at 1049,150  for wid=2     using  jpeg with ratio   3.3% ( 1190KB to    39KB), client_options={'quality': 78, 'flush': 2}
2016-10-03 18:17:34,421 packet decoding sequence 84 for window 2: 1684x162 took 5.1ms
2016-10-03 18:17:34,423 rgb_encode using level=1, lz4 compressed 195x480 in rgb24/BGRX: 374400 bytes down to 1486
2016-10-03 18:17:34,423 record_latency: took   12.3 ms round trip,   12.2 for echo,    5.0 for decoding of   272808 pixels,    28395 bytes sent over the network in    7.2 ms,    7.1 ms for echo
2016-10-03 18:17:34,424 compress:   1.6ms for  195x480  pixels at    0,150  for wid=2     using rgb24 with ratio   0.4% (  365KB to     1KB), client_options={'flush': 1, 'lz4': 1, 'rgb_format': 'BGRX'}
2016-10-03 18:17:34,428 compress:   3.4ms for 1684x150  pixels at    0,0    for wid=2     using  jpeg with ratio   3.3% (  986KB to    32KB), client_options={'quality': 78, 'flush': 0}
2016-10-03 18:17:34,433 packet decoding sequence 85 for window 2: 635x480 took 8.7ms
2016-10-03 18:17:34,434 record_latency: took   10.6 ms round trip,   10.3 for echo,    8.0 for decoding of   304800 pixels,    40785 bytes sent over the network in    1.9 ms,    1.5 ms for echo
2016-10-03 18:17:34,435 packet decoding sequence 86 for window 2: 195x480 took 4.5ms
2016-10-03 18:17:34,436 record_latency: took   10.5 ms round trip,   10.4 for echo,    4.0 for decoding of    93600 pixels,     1552 bytes sent over the network in    5.9 ms,    5.8 ms for echo
2016-10-03 18:17:34,450 x264 encode frame     3 as    P slice with 4 nals, total    3050 bytes, keyframe=False, delayed=0
2016-10-03 18:17:34,450 compress:   8.5ms for  854x480  pixels at  195,150  for wid=2     using  h264 with ratio   0.2% ( 1601KB to     2KB), client_options={'pts': 186, 'frame': 3L, 'flush': 0, 'csc': 'YUV444P', 'type': 'P', 'quality': 38, 'speed': 83}
2016-10-03 18:17:34,452 packet decoding sequence 87 for window 2: 1684x150 took 15.6ms
2016-10-03 18:17:34,452 record_latency: took   23.6 ms round trip,   23.5 for echo,   15.0 for decoding of   252600 pixels,    33590 bytes sent over the network in    8.1 ms,    7.9 ms for echo
2016-10-04 14:30:41,115 x264 context=0x7f4ce0007dc0, YUV420P 1122x528  quality=36, speed=94, source=unknown
2016-10-04 14:30:41,115  preset=superfast, profile=high10, tune=zerolatency
2016-10-04 14:30:41,115  me=DIA, me_range=16, mv_range=-1, b-frames=0, max delayed frames=0
2016-10-04 14:30:41,117  vfr-input=0, lookahead=-1, sync-lookahead=0, mb-tree=0, bframe-adaptive=FAST
2016-10-04 14:30:41,117  threads=auto, sliced-threads=True
2016-10-04 14:30:41,118 x264 close context 0x0
2016-10-04 14:30:41,138 x264 encode frame     0 as  IDR slice with 7 nals, total   28899 bytes, keyframe=True , delayed=0
2016-10-04 14:30:41,139 compress:  41.2ms for 1684x792  pixels at    0,0    for wid=2     using  h264 with ratio   0.5% ( 5209KB to    28KB), client_options={'pts': 0, 'frame': 0L, 'flush': 0, 'csc': 'YUV420P', 'scaled_size': (1122, 528), 'type': 'IDR', 'quality': 36, 'speed': 94}
2016-10-04 14:30:41,150 packet decoding sequence 135 for window 2: 1684x792 took 8.8ms
2016-10-04 14:30:41,150 record_latency: took   10.7 ms round trip,   10.5 for echo,    8.0 for decoding of  1333728 pixels,    29013 bytes sent over the network in    1.9 ms,    1.7 ms for echo
2016-10-04 14:30:41,249 x264 close context 0x7f4ce0007dc0

... of course, I'm not sure if the "YUV420P" and "zerolatency" combo should be moved (or duplicated) to #1257.

In any case, I'll pass this back to you to decide - I feel like this ticket is working as hoped/expected, but perhaps #1257 needs more work(?).


Thu, 06 Oct 2016 09:24:54 GMT - Antoine Martin: owner changed

It looks like the "compression-ratio" deltas are informing adjustments for quality in the right direction, though not nearly as directly as "-10 means drop quality by 10 points"... and poring over some logs until my eyes begin to cross, it looks like growth/shrinkage of 'latency' seems to influence the magnitude of the quality adjustments that seem to be informed by the "compression-ratio"


That's some very good observation right there: the latency value gives us a cap on the calculated quality, if the latency is too high (at least 3 times higher than our target value), then we always discount the quality value calculated using the other heuristics.


Here's a nice "brief" log sample from a youtube video


The quality used in this sample is exactly what we want to see (~40 for h264 and ~80 for jpeg). (the value of 80 may even be high enough that we'll often use RGB or PNG for the non-video region, which saves us doing an auto-refresh later)


However, it looks like I'm getting all "YUV444P" & "zerolatency" x264 encoding - whether I'm looking at a youtube page with video, or if I've scrolled the video region off-frame and I'm just looking at the list of comments on the video Likewise, even when the "YUV420P" csc mode is being selected, I'm still seeing "zerolatency" tuning.


Hmm. Looks like a bug. Scrolling is bursty by nature, so it may not have time to trigger "real video" (YUV420P, b-frames and "film" tuning). Youtube on the other hand... should be using it.

Relevant comments (including information on what we need for debugging these kinds of problems):

r14015 adjusts the scoring a little bit, keeping it as simple as I can this late in the release cycle.. it should now select YUV420P more often when the quality is low. (even when close to or lower than the min-quality)


Sat, 12 Nov 2016 00:52:08 GMT - alas: owner changed

Testing some more with 1.0 r14404 fedora 23 server and 1.0 r14397 win client (without forcing opengl on, after running into the errors noted in #1111).

Looks like scrolling is leading to "zerolatency" tuning, whether it is using "YUV420P" or "BGRX"... but I'm seeing the "film" tuning when I leave a video playing without going crazy and also scrolling the page.

In a short while of testing I didn't see any more examples of jpeg and h264 occurring within close proximity, to compare the relative qualities... but I am often seeing the h264 interspersed with rgb and png (which sounds like what we were hoping for in order to avoid the lossless auto-refreshes).

I did run into a patch of odd heuristics though when I left the client connected after a video had stopped on a page, while poring over the logs. I noticed, with an essentially static page... other than clicking to give it focus and a moment of mousing across... that the page went blurry.

Looking at the server logs, I see that there is indeed still h264 interspersed with rgb and png... and the h264 quality is low - but it looks like it has remained low and there has been no auto-refresh.

Pasting in another patch of logs... but these are the latest logs of a static youtube page that has blurry text around the video frame (which is not playing anything at present)... I'll try to also get a screenshot.

2016-11-11 16:31:50,248 x264 close context 0x0
2016-11-11 16:31:50,256 x264 encode YUV420P frame     0 as  IDR slice with 5 nals, tune=zerolatency, total    6876 bytes, keyframe=True , delayed=0
2016-11-11 16:31:50,256 compress:  13.7ms for 1870x138  pixels at    0,908  for wid=2     using  h264 with ratio   0.7% ( 1015KB to     6KB), sequence   263, client_options={'pts': 0, 'frame': 0, 'csc': 'YUV420P', 'type': 'IDR', 'quality': 30, 'speed': 93}
2016-11-11 16:31:50,290 packet decoding sequence 262 for window 2: 1870x1046 took 47.0ms
2016-11-11 16:31:50,290 record_latency: took   75.9 ms round trip,   75.8 for echo,   47.0 for decoding of  1956020 pixels,    34993 bytes sent over the network in   28.9 ms,   28.8 ms for echo
2016-11-11 16:31:50,301 packet decoding sequence 263 for window 2: 1870x138 took 15.0ms
2016-11-11 16:31:50,302 record_latency: took   45.1 ms round trip,   45.1 for echo,   15.0 for decoding of   258060 pixels,     6966 bytes sent over the network in   30.1 ms,   30.1 ms for echo
2016-11-11 16:31:50,890 compress: 167.5ms for 1871x1047 pixels at    0,0    for wid=2     using   png with ratio  10.9% ( 7652KB to   834KB), sequence   264, client_options={'compress_level': 3}
2016-11-11 16:31:51,011 packet decoding sequence 264 for window 2: 1871x1047 took 109.0ms
2016-11-11 16:31:51,012 record_latency: took  120.9 ms round trip,  120.4 for echo,  109.0 for decoding of  1958937 pixels,   854205 bytes sent over the network in   11.9 ms,   11.4 ms for echo
2016-11-11 16:31:51,057 calculate_batch_delay for wid=2 current batch delay=58, last update 0 seconds ago
2016-11-11 16:31:51,057 calculate_batch_delay for wid=2, skipping - only 4 events since the last update
2016-11-11 16:31:51,058 update_quality() suspended=False, mmap=None, encoding=auto
2016-11-11 16:31:51,058 update_quality() info={'batch-delay-ratio': 35, 'backlog_factor': (0, 0, 100), 'latency': 1419, 'compression-ratio': (244, 377, -37), 'min_quality': 30, 'min_speed': 30}, quality=30
2016-11-11 16:31:51,058 update_speed() info={'frame_delay': 64, 'mpixels': 1, 'low_limit': 1958937, 'min_speed': 30, 'damage_latency': {'abs_factor': 24, 'rel_factor': 143, 'avg': 99, 'ref': 50, 'target': 64}, 'decoding_latency': {'target': 8000000, 'factor': 26}}, speed=97
2016-11-11 16:31:58,964 rgb_encode reformatting because BGRX not in ['RGB', 'RGBX']
2016-11-11 16:31:58,966 rgb_reformat: converting XShmImageWrapper(BGRX: 254, 852, 256, 195) from BGRX to RGB using PIL
2016-11-11 16:31:58,967 rgb_reformat(XShmImageWrapper(RGB: 254, 852, 256, 195), ['RGB', 'RGBX'], False) converted from BGRX (1459380 bytes) to RGB (149760 bytes) in 1.0ms, rowstride=768
2016-11-11 16:31:58,967 rgb_encode using level=0, not compressed 256x195 in rgb24/RGB: 149760 bytes down to 149760
2016-11-11 16:31:58,968 compress:   3.4ms for  256x195  pixels at  254,852  for wid=2     using rgb24 with ratio  75.0% (  195KB to   146KB), sequence   265, client_options={'rgb_format': 'RGB'}
2016-11-11 16:31:58,979 packet decoding sequence 265 for window 2: 256x195 took 0.0ms
2016-11-11 16:31:58,979 may_recalculate(2, 49920) total 49920 pixels, scheduling recalculate work item
2016-11-11 16:31:58,980 calculate_batch_delay for wid=2 current batch delay=58, last update 8 seconds ago
2016-11-11 16:31:58,980 calculate_batch_delay for wid=2, skipping - only 5 events since the last update
2016-11-11 16:31:58,980 update_quality() suspended=False, mmap=None, encoding=auto
2016-11-11 16:31:58,981 update_quality() info={'batch-delay-ratio': 35, 'backlog_factor': (0, 0, 100), 'latency': 1001, 'compression-ratio': (153, 747, -172), 'min_quality': 30, 'min_speed': 30}, quality=30
2016-11-11 16:31:58,981 update_speed() info={'frame_delay': 58, 'mpixels': 0, 'low_limit': 1958937, 'min_speed': 30, 'damage_latency': {'abs_factor': 15, 'rel_factor': 132, 'avg': 81, 'ref': 50, 'target': 58}, 'decoding_latency': {'target': 8000000, 'factor': 17}}, speed=98
2016-11-11 16:32:15,915 x264 close context 0x7f4d1000abe0
2016-11-11 16:32:15,924 x264 context=0x7f4d1000abe0, YUV420P 1246x696  quality=30, speed=98, source=unknown
2016-11-11 16:32:15,924  preset=superfast, profile=high10, tune=zerolatency
2016-11-11 16:32:15,925  me=DIA, me_range=16, mv_range=-1, b-frames=0, max delayed frames=0
2016-11-11 16:32:15,925  vfr-input=0, lookahead=-1, sync-lookahead=0, mb-tree=0, bframe-adaptive=FAST
2016-11-11 16:32:15,925  threads=auto, sliced-threads=True
2016-11-11 16:32:15,925 x264 close context 0x0
2016-11-11 16:32:15,944 x264 encode YUV420P frame     0 as  IDR slice with 7 nals, tune=zerolatency, total   34880 bytes, keyframe=True , delayed=0
2016-11-11 16:32:15,944 compress:  30.1ms for 1870x1046 pixels at    0,0    for wid=2     using  h264 with ratio   0.4% ( 7652KB to    34KB), sequence   266, client_options={'pts': 0, 'frame': 0, 'csc': 'YUV420P', 'scaled_size': (1246, 696), 'type': 'IDR', 'quality': 30, 'speed': 98}
2016-11-11 16:32:16,006 packet decoding sequence 266 for window 2: 1870x1046 took 47.0ms
2016-11-11 16:32:16,006 record_latency: took   60.9 ms round trip,   60.8 for echo,   47.0 for decoding of  1956020 pixels,    34987 bytes sent over the network in   13.9 ms,   13.8 ms for echo
2016-11-11 16:32:16,006 may_recalculate(2, 1956020) total 1956020 pixels, scheduling recalculate work item
2016-11-11 16:32:16,008 calculate_batch_delay for wid=2 current batch delay=58, last update 25 seconds ago
2016-11-11 16:32:16,008 calculate_batch_delay for wid=2, 6189360 pixels updated since the last update
2016-11-11 16:32:16,008 calculate_batch_delay for wid=2, 1082024 bytes sent since the last update
2016-11-11 16:32:16,011 update_batch_delay: damage-network-delay         : 0.99,0.51  {'avg': 41, 'recent': 40}
2016-11-11 16:32:16,011 update_batch_delay: network-send-speed           : 1.35,0.11  {'avg': 1, 'recent': 2}
2016-11-11 16:32:16,011 update_batch_delay: client-decode-speed          : 1.04,0.00  {'avg': 23, 'recent': 25}
2016-11-11 16:32:16,011 update_batch_delay: damage-rate                  : 1.00,0.00  {'max_latency': 100, 'elapsed': 167}
2016-11-11 16:32:16,011 update_batch_delay: client-latency               : 0.92,0.09  {'target': 4, 'weight_multiplier': 321, 'smoothing': 'sqrt', 'aim': 800, 'aimed_avg': 837, 'div': 1000, 'avg': 14, 'recent': 13}
2016-11-11 16:32:16,011 update_batch_delay: client-ping-latency          : 0.51,0.12  {'target': 6, 'weight_multiplier': 170, 'smoothing': 'sqrt', 'aim': 949, 'aimed_avg': 257, 'div': 1000, 'avg': 2, 'recent': 1}
2016-11-11 16:32:16,012 update_batch_delay: server-ping-latency          : 0.04,0.13  {'target': 4, 'weight_multiplier': 137, 'smoothing': 'sqrt', 'aim': 949, 'aimed_avg': 1, 'div': 1000, 'avg': 0, 'recent': 0}
2016-11-11 16:32:16,012 update_batch_delay: packet-queue-size            : 0.00,0.00  {'target': 1000, 'weight_multiplier': 0, 'smoothing': 'sqrt', 'aim': 250, 'aimed_avg': 0, 'div': 1000, 'avg': 0, 'recent': 0}
2016-11-11 16:32:16,012 update_batch_delay: packet-queue-pixels          : 0.00,0.00  {'target': 1000, 'weight_multiplier': 0, 'smoothing': 'sqrt', 'aim': 250, 'aimed_avg': 0, 'div': 1958937000, 'avg': 0, 'recent': 0}
2016-11-11 16:32:16,012 update_batch_delay: compression-work-queue       : 0.00,1.23  {'target': 1000, 'weight_multiplier': 1233, 'smoothing': 'logp', 'aim': 250, 'aimed_avg': 0, 'div': 1000, 'avg': 1520, 'recent': 0}
2016-11-11 16:32:16,012 update_batch_delay: damage-packet-queue-pixels   : 0.00,0.00  {'target': 1000, 'weight_multiplier': 0, 'smoothing': 'sqrt', 'aim': 250, 'aimed_avg': 0, 'div': 1958937000, 'avg': 0, 'recent': 0}
2016-11-11 16:32:16,013 update_batch_delay: focus                        : 0.00,1.00  {'has_focus': True}
2016-11-11 16:32:16,013 update_batch_delay: override-redirect            : 1.00,0.00  {'is_OR': False}
2016-11-11 16:32:16,013 update_batch_delay: fullscreen                   : 0.00,0.00  {'other_is_fullscreen': False}
2016-11-11 16:32:16,013 update_batch_delay: maximized                    : 0.00,0.00  {'other_is_maximized': False}
2016-11-11 16:32:16,013 update_batch_delay: soft-expired                 : 0.00,0.00  {'count': 0}
2016-11-11 16:32:16,014 update_batch_delay: delay=36
2016-11-11 16:32:16,014 update_quality() suspended=False, mmap=None, encoding=auto
2016-11-11 16:32:16,014 update_quality() info={'batch-delay-ratio': 56, 'backlog_factor': (0, 0, 100), 'latency': 1243, 'compression-ratio': (31, 13, 7), 'min_quality': 30, 'min_speed': 30}, quality=56
2016-11-11 16:32:16,015 update_speed() info={'frame_delay': 47, 'mpixels': 1, 'low_limit': 1958937, 'min_speed': 30, 'damage_latency': {'abs_factor': 24, 'rel_factor': 189, 'avg': 99, 'ref': 50, 'target': 50}, 'decoding_latency': {'target': 8000000, 'factor': 18}}, speed=98
2016-11-11 16:32:16,633 compress: 166.6ms for 1871x1047 pixels at    0,0    for wid=2     using   png with ratio  10.9% ( 7652KB to   834KB), sequence   267, client_options={'compress_level': 3}
2016-11-11 16:32:16,748 packet decoding sequence 267 for window 2: 1871x1047 took 93.0ms
2016-11-11 16:32:16,748 record_latency: took  115.0 ms round trip,  114.4 for echo,   93.0 for decoding of  1958937 pixels,   854186 bytes sent over the network in   22.0 ms,   21.4 ms for echo
2016-11-11 16:32:16,748 may_recalculate(2, 1958937) total 1958937 pixels, scheduling recalculate work item
2016-11-11 16:32:17,009 calculate_batch_delay for wid=2 current batch delay=36, last update 1 seconds ago
2016-11-11 16:32:17,010 calculate_batch_delay for wid=2, skipping - only 1 events since the last update
2016-11-11 16:32:17,011 update_quality() suspended=False, mmap=None, encoding=auto
2016-11-11 16:32:17,011 update_quality() info={'batch-delay-ratio': 56, 'backlog_factor': (0, 0, 100), 'latency': 823, 'compression-ratio': (239, 366, -35), 'min_quality': 30, 'min_speed': 30}, quality=34
2016-11-11 16:32:17,012 update_speed() info={'frame_delay': 47, 'mpixels': 0, 'low_limit': 1958937, 'min_speed': 30, 'damage_latency': {'abs_factor': 49, 'rel_factor': 292, 'avg': 151, 'ref': 50, 'target': 50}, 'decoding_latency': {'target': 8000000, 'factor': 24}}, speed=98
2016-11-11 16:32:20,461 x264 encode YUV420P frame     1 as    P slice with 4 nals, tune=zerolatency, total     443 bytes, keyframe=False, delayed=0
2016-11-11 16:32:20,462 compress:  19.8ms for 1870x1046 pixels at    0,0    for wid=2     using  h264 with ratio   0.0% ( 7652KB to     0KB), sequence   268, client_options={'pts': 4517, 'frame': 1, 'csc': 'YUV420P', 'scaled_size': (1246, 696), 'type': 'P', 'quality': 34, 'speed': 98}
2016-11-11 16:32:20,495 packet decoding sequence 268 for window 2: 1870x1046 took 31.0ms
2016-11-11 16:32:20,496 record_latency: took   32.5 ms round trip,   32.5 for echo,   31.0 for decoding of  1956020 pixels,      550 bytes sent over the network in    1.5 ms,    1.5 ms for echo
2016-11-11 16:32:20,496 may_recalculate(2, 1956020) total 1956020 pixels, scheduling recalculate work item
2016-11-11 16:32:20,497 calculate_batch_delay for wid=2 current batch delay=36, last update 4 seconds ago
2016-11-11 16:32:20,497 calculate_batch_delay for wid=2, skipping - only 2 events since the last update
2016-11-11 16:32:20,498 update_quality() suspended=False, mmap=None, encoding=auto
2016-11-11 16:32:20,498 update_quality() info={'batch-delay-ratio': 56, 'backlog_factor': (0, 0, 100), 'latency': 9911, 'compression-ratio': (72, 3, 29), 'min_quality': 30, 'min_speed': 30}, quality=78
2016-11-11 16:32:20,499 update_speed() info={'frame_delay': 36, 'mpixels': 1, 'low_limit': 1958937, 'min_speed': 30, 'damage_latency': {'abs_factor': 23, 'rel_factor': 189, 'avg': 98, 'ref': 50, 'target': 50}, 'decoding_latency': {'target': 8000000, 'factor': 14}}, speed=98

Sat, 12 Nov 2016 00:53:54 GMT - alas: attachment set

page static for a number of minutes & still blurry, despite apparent mix of rgb and png with h264 encodings...


Sat, 12 Nov 2016 00:57:37 GMT - alas:

Oddly, the clip of the logs top-ish left indicates the final encoding for this completely static page... h264 P slice with "zerolatency" tuning... at quality "34" ... and there has been no auto-refresh in the entire time of my composing these comments... leaving it blurry (don't usually catch corner cases so perfectly!).

page static for a number of minutes & still blurry, despite apparent mix of rgb and png with h264 encodings...


Sun, 13 Nov 2016 14:05:29 GMT - Antoine Martin: owner changed

Fixes and tweaks:

we should end up using level=1 or higher to actually compress things now


As for the lack for auto-refresh, we need "-d refresh" (or even "-d refresh,regionrefresh" if a video region was active). I hope you can trigger it again with the same concise logging.


Fri, 18 Nov 2016 02:04:33 GMT - alas: owner changed

Tested a little more with a 1.0 r14430 fedora 23 server and a 1.0 r14416 win32 client.

Not seeing any more of the rgb_encode using level=0 (all at level=1).

Also not stumbling across the lack of auto-refresh... not sure if it was a fluke or something to do with the change to raise quality quickly when there aren't many screen updates... but my attempts to repro are now regularly auto-refreshing with rgb (and someteims also some png) after an initial x264 paint when mousing over a recently ended video region.

I'll test a bit more to be sure, but passing this back to you as looking ready to be closed for now.


Fri, 18 Nov 2016 05:41:51 GMT - Antoine Martin: owner changed

Note: we probably should not be refreshing very large areas with rgb. If it does refresh something bigger than ~720p with rgb, can you please include the "quality", "speed" and "rgb_threshold" from xpra info, as well as the corresponding compress log message. (if not, please just close the ticket)


Fri, 18 Nov 2016 18:23:24 GMT - alas: owner changed

It looks to me, doing a little more testing, like it is doing some of the updates with rgb (probably corresponding to me mousing over the window after a video has stopped, trying to induce another auto-refresh failure) and is then following that up with a png paint, which I presume is a more full auto-refresh.

Here's a clip of some of some sample logs that I'm seeing now while trying to repro, for you to confirm my interpretation.

2016-11-18 09:48:42,952 x264 encode    BGRX frame     0 as  IDR slice with 7 nals, tune=zerolatency, total  232695 bytes, keyframe=True , delayed=0
2016-11-18 09:48:42,954 compress:  66.6ms for 1182x682  pixels at    0,0    for wid=2     using  h264 with ratio   7.2% ( 3148KB to   227KB), sequence 21460, client_options={'pts': 0, 'frame': 0, 'csc': 'YUV444P', 'type': 'IDR', 'quality': 60, 'speed': 55}
2016-11-18 09:48:43,380 compress:  79.1ms for 1182x682  pixels at    0,0    for wid=2     using   png with ratio  14.7% ( 3148KB to   463KB), sequence 21465, client_options={'compress_level': 3}
2016-11-18 09:48:48,526 compress:   4.0ms for  405x84   pixels at  762,598  for wid=2     using   png with ratio  14.2% (  132KB to    18KB), sequence 21466, client_options={'compress_level': 1}
2016-11-18 09:48:48,668 compress:   9.0ms for  382x128  pixels at   83,175  for wid=2     using   png with ratio  46.3% (  191KB to    88KB), sequence 21469, client_options={'compress_level': 1}
2016-11-18 09:48:51,441 rgb_encode using level=1 for 97280 pixels at  63 speed, lz4 compressed  190x128  in rgb24/BGRX: 97280 bytes down to 80655
2016-11-18 09:48:51,442 compress:   1.1ms for  190x128  pixels at  469,175  for wid=2     using rgb24 with ratio  82.9% (   95KB to    78KB), sequence 21587, client_options={'bucket': 2, 'lz4': 1, 'store': 38117, 'rgb_format': 'BGRX'}
2016-11-18 09:48:52,094 compress:  13.3ms for  405x338  pixels at  762,344  for wid=2     using   png with ratio  16.8% (  534KB to    89KB), sequence 21608, client_options={'compress_level': 1}
2016-11-18 09:48:52,249 x264 close context 0x7f8330bc2320
2016-11-18 09:48:52,279 x264 close context 0x0
2016-11-18 09:48:52,283 using default profile=high444
2016-11-18 09:48:52,299 x264 context=0x7f833003ac60,    BGRX 1166x592  quality=35, speed=72, source=unknown
2016-11-18 09:48:52,299  preset=faster, profile=high444, tune=zerolatency
2016-11-18 09:48:52,300  me=DIA, me_range=16, mv_range=-1, weighted-pred=1
2016-11-18 09:48:52,301  b-frames=0, max delayed frames=0
2016-11-18 09:48:52,304  vfr-input=False, lookahead=-1, sync-lookahead=0, mb-tree=False, bframe-adaptive=FAST
2016-11-18 09:48:52,305  open-gop=True, bluray-compat=False, cabac=True, deblocking-filter=True
2016-11-18 09:48:52,308  intra-refresh=False, interlaced=False, constrained_intra=False
2016-11-18 09:48:52,309  threads=auto, sliced-threads=True
2016-11-18 09:48:52,347 x264 encode    BGRX frame     0 as  IDR slice with 7 nals, tune=zerolatency, total   93950 bytes, keyframe=True , delayed=0
2016-11-18 09:48:52,347 compress:  66.4ms for 1166x592  pixels at    0,90   for wid=2     using  h264 with ratio   3.4% ( 2698KB to    91KB), sequence 21613, client_options={'pts': 0, 'frame': 0, 'csc': 'YUV444P', 'type': 'IDR', 'quality': 35, 'speed': 72}
2016-11-18 09:48:52,565 rgb_encode using level=1 for 36156 pixels at  72 speed, lz4 compressed  393x23   in rgb24/BGRX: 36156 bytes down to  4534
2016-11-18 09:48:52,566 compress:   0.7ms for  393x23   pixels at    0,659  for wid=2     using rgb24 with ratio  12.5% (   35KB to     4KB), sequence 21619, client_options={'flush': 1, 'bucket': 0, 'lz4': 1, 'store': 38141, 'rgb_format': 'BGRX'}
2016-11-18 09:48:52,567 rgb_encode using level=1 for 35520 pixels at  72 speed, lz4 compressed   15x592  in rgb24/BGRX: 35520 bytes down to   265
2016-11-18 09:48:52,567 compress:   0.4ms for   15x592  pixels at 1167,90   for wid=2     using rgb24 with ratio   0.7% (   34KB to     0KB), sequence 21620, client_options={'bucket': 4, 'lz4': 1, 'store': 38143, 'rgb_format': 'BGRX'}
2016-11-18 09:48:52,654 rgb_encode using level=1 for 36156 pixels at  72 speed, lz4 compressed  393x23   in rgb24/BGRX: 36156 bytes down to  4516
2016-11-18 09:48:52,655 compress:   1.7ms for  393x23   pixels at    0,659  for wid=2     using rgb24 with ratio  12.5% (   35KB to     4KB), sequence 21621, client_options={'delta': 38141, 'bucket': 0, 'lz4': 1, 'store': 38145, 'rgb_format': 'BGRX'}
2016-11-18 09:48:53,045 compress:  74.1ms for 1182x682  pixels at    0,0    for wid=2     using   png with ratio  14.7% ( 3148KB to   463KB), sequence 21622, client_options={'compress_level': 3}
2016-11-18 09:48:54,557 compress:   3.1ms for  405x95   pixels at  762,251  for wid=2     using   png with ratio  13.7% (  150KB to    20KB), sequence 21623, client_options={'compress_level': 1, 'flush': 2}
2016-11-18 09:48:54,562 compress:   4.4ms for  405x161  pixels at  762,90   for wid=2     using   png with ratio  10.3% (  254KB to    26KB), sequence 21624, client_options={'compress_level': 1, 'flush': 1}
2016-11-18 09:48:54,563 rgb_encode using level=1 for 35520 pixels at  71 speed, lz4 compressed   15x592  in rgb24/BGRX: 35520 bytes down to   178
2016-11-18 09:48:54,563 compress:   0.4ms for   15x592  pixels at 1167,90   for wid=2     using rgb24 with ratio   0.5% (   34KB to     0KB), sequence 21625, client_options={'delta': 38143, 'bucket': 4, 'lz4': 1, 'store': 38153, 'rgb_format': 'BGRX'}
2016-11-18 09:48:54,718 rgb_encode using level=1 for 97524 pixels at  73 speed, lz4 compressed  189x129  in rgb24/BGRX: 97524 bytes down to 90219
2016-11-18 09:48:54,719 compress:   0.6ms for  189x129  pixels at  276,307  for wid=2     using rgb24 with ratio  92.5% (   95KB to    88KB), sequence 21627, client_options={'bucket': 3, 'lz4': 1, 'store': 38159, 'rgb_format': 'BGRX'}
2016-11-18 09:48:54,789 compress:  17.0ms for  383x129  pixels at  276,307  for wid=2     using   png with ratio  42.7% (  192KB to    82KB), sequence 21628, client_options={'compress_level': 1}

I would also mention that as I was doing a couple of last stabs at testing this, I somehow managed to trigger a strange behavior where whenever I moused over the window, the mouse seemed to do a grab and move the window... making it impossible to mouse to any buttons or anything else. I wasn't able to repro at all, so it was probably just a missed un-click event... though subsequent clicks didn't fix it - only disconnecting then re-connecting. I have some logs and xpra info, but I suspect they'll just indicate that the window was being moved. I'll make a ticket if I can repro.

As for this, I'll hand it back to you to glance at the logs then most likely just close this one.


Sat, 19 Nov 2016 06:02:02 GMT - Antoine Martin: status changed; resolution set

The rgb updates are for smaller regions than the png ones, which is what we want. (the exact "rgb_threshold" varies)

The rgb ones tend to compress a lot less but almost always take under 1 ms to do so! png uses a lot more CPU time.

The grab-the-window bug sounds like a real problem for another ticket. What application was this? (you should always be able to get out of grabs using the escape key - assuming that it is xpra that triggered the grab)


Sat, 23 Jan 2021 05:15:57 GMT - migration script:

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