| 10 | | |
| 11 | | Replying to [comment:14 Antoine Martin]: |
| 12 | | > As per previous comments, '''do not''' disable the other video encoders. |
| 13 | | > |
| 14 | | > What I found in the logs despite that: |
| 15 | | > * {{{DPI set to 45 x 25 (wanted 96 x 96)}}} |
| 16 | | > You should be using the patched dummy driver from the repo. |
| 17 | | > * we don't find a video encoder for small areas (because you disabled the other video encoders): |
| 18 | | > {{{ |
| 19 | | > video size 484x92 out of range for nvenc, min 128x128 |
| 20 | | > (..) |
| 21 | | > Error: no video pipeline options found for BGRX at 485x93 |
| 22 | | > }}} |
| 23 | | > * your card is limited to 2 contexts since you're using a gamer card without a license key: |
| 24 | | > {{{ |
| 25 | | > CUDA 9.2.0 / PyCUDA 2018.1, found 1 device: |
| 26 | | > + GeForce GTX 1060 6GB @ 0000:AF:00.0 (memory: 98% free, compute: 6.1) |
| 27 | | > (..) |
| 28 | | > setup_pipeline failed for (84, (1, 1), None, 0, 0, None, 'BGRX', (1, 1), 520, 188, video_spec(nvenc)): cannot open encoding session, context is NULL |
| 29 | | > }}} |
| 30 | | > And that causes failures when we reach the limit. 2 contexts should be enough if you only have one "video" window though. |
| 31 | | > When we do hit this limit, things go downhill fast: |
| 32 | | > {{{ |
| 33 | | > setup_pipeline(..) failed! took 2197.59ms |
| 34 | | > }}} |
| 35 | | > That's the encoding pipeline blocked for over 2 seconds! ouch. |
| 36 | | > * the batch delay is already high because of this: |
| 37 | | > {{{ |
| 38 | | > update_batch_delay: congestion : 1.87,8.74 {} |
| 39 | | > }}} |
| 40 | | > You may want to turn off bandwidth detection to see if that helps with {{{--bandwidth-detection=no}}}. (#1912) |
| 41 | | > Or post the {{{-d bandwidth}}} log output so we can fix this. |
| 42 | | > But then it also goes up because of this: |
| 43 | | > {{{ |
| 44 | | > update_batch_delay: compression-work-queue : 2.64,5.12 {u'target': 1000, u'weight_multiplier': 3648, u'smoothing': u'logp', u'aim': 250, u'aimed_avg': 5247, u'div': 1000, u'avg': 12057, u'recent': 13314} |
| 45 | | > }}} |
| 46 | | > That's nvenc hogging the compresion work queue because it is slow to setup, and even worse when it hits the 2 context limit and fails (2 seconds as per above)... not much we can do about this. |
| 47 | | > * the video context seems to get recycled too quickly, then we see: |
| 48 | | > {{{ |
| 49 | | > check_pipeline('auto', 451, 134, 'BGRX') setting up a new pipeline as check failed - encodings=['h264', 'h265'] |
| 50 | | > }}} |
| 51 | | > why it failed is not logged, so I can't be sure why, but here are some possibilities: |
| 52 | | > * r20914: a refresh issue fixed recently (ticket:1816#comment:14) |
| 53 | | > * r20926: a bug fixed today causing unnecessary video context churn |
| 54 | | > |
| 55 | | > r20927 also adds an env var you can use to turn on video context cleanup debugging: |
| 56 | | > {{{ |
| 57 | | > XPRA_DEBUG_VIDEO_CLEAN=1 xpra start ... |
| 58 | | > }}} |
| 59 | | > This should tell us why the video context is being destroyed so quickly. |
| 60 | | > |
| 61 | | > There are new centos 7.5 builds here: [https://xpra.org/beta]. |
copyleft 2010 - 2021
