| 1 | | Replying to [comment:41 Antoine Martin]: |
| 2 | | > > (3) !ResetVideoRegion (not sure if I need this) |
| 3 | | > Not needed. |
| 4 | | > |
| 5 | | > > When I do this the video region gets stuck forever on x264 unless I disable x264 at startup |
| 6 | | > That's what setting a video region does. |
| 7 | | > |
| 8 | | > > (and x264 is laggy, also not sure if that is a bug). I'm not sure if this is a bug, or if I'm doing something wrong. |
| 9 | | > Are you talking about the laggyness? |
| 10 | | > What exactly is the symptom? Did you capture {{{xpra info}}}? |
| 11 | | > |
| 12 | | > Using "video" may trigger some delayed frames with x264. (but not with nvenc - not yet anyway) |
| 13 | | > Assuming that you're using the x264 encoder, you may want to only enable vpx and not x264: {{{--video-encoders=vpx}}}. |
| 14 | | > Or you can also try to cap the number of delayed frames with x264: |
| 15 | | > {{{ |
| 16 | | > XPRA_X264_MAX_DELAYED_FRAMES=1 xpra start .. |
| 17 | | > }}} |
| 18 | | > |
| 19 | | > Maybe what we need to do is to define a new content-type ("animation" perhaps?) that enables video encoders but without the features that cause delayed frames (b-frames, multiple reference frames) as those are only really useful for true video content (ie: video player or youtube). |
| 20 | | |
copyleft 2010 - 2021
