Xpra: Ticket #796: YUV444 and lossless mode with NVENC4

Split from #466 and #653.

Like it says on the tin.



Tue, 27 Jan 2015 10:49:06 GMT - Antoine Martin: attachment set

work in progress


Tue, 27 Jan 2015 12:15:32 GMT - Antoine Martin: status changed

I just don't see what we're doing wrong.. But only the "Y" plane gets encoded.

The ffmpeg nvenc code does pretty much the same thing: the input buffer is YUV444 with a dstPitch*dst_h offset.


Wed, 28 Jan 2015 11:29:58 GMT - Antoine Martin:

Took a while but the fix was simple (forgot to set the buffer format when registering it - wasn't set in previous NVENC SDK versions).

YUV444 works correctly as of r8571.

Still TODO:


Tue, 03 Feb 2015 07:09:46 GMT - Antoine Martin:

lossless mode support added in r8604.

BTW, there's a new codec supported (maybe h265 which is meant to be supported in SDK v5 - but which is completely undocumented?):

[0] H264 : 6BC82762-4E63-4CA4-AA85-1E50F321F6BF
[1] None : 790CDC88-4522-4D7B-9425-BDA9975F7603

Tue, 03 Feb 2015 09:34:26 GMT - Antoine Martin: attachment set

in order to be able to re-initialize the encoder, we need both speed and quality updated at the same time


Tue, 03 Feb 2015 10:14:50 GMT - Antoine Martin: attachment set

now split init functions so we can re-use them


Tue, 03 Feb 2015 13:32:14 GMT - Antoine Martin:

As of r8606 we can do an encoder re-init on the fly, which only takes a few milliseconds. r8608 allows us to use lossless mode properly, and also now from the system tray menu for h264.

From my limited testing: YUV444 performance is very good, only 10 to 15% slower than NV12, lossless mode is also impressive: fast and we just use more space.

Note: you need the "new" set of license keys to be able to use more than 2 encoding sessions on the same card... and we should probably detect that this is the case and tune the load balancing accordingly.


Wed, 04 Feb 2015 11:50:55 GMT - Antoine Martin: owner, status changed

The decoding problems are fixed in r8620 (was caused by B frames - we will deal with this better eventually, see #800).

Ready for testing. Some defaults to be aware of:

Lossless mode isn't as useful as before, since auto-refresh is now meant to do a decent job of eventually fixing lossy paints. But since it is reasonably cheap to use, maybe we should use it more?

The current pixel format and lossless flag can be seen with (including thresholds as of r8621):

xpra info | grep encoder

@smo: please re-assign to afarr once you've got it setup?


Tue, 24 Mar 2015 18:43:29 GMT - Smo: owner changed

I have a reasonable setup now that afarr can test this on.

Re-assigning to him.


Tue, 24 Mar 2015 20:12:31 GMT - alas:

Smo's setup against a windows client 0.15.0 r8002 works as expected.

When stretching a firefox window as some video was initiating, there was a second with a yellow and red misrendering, but it quickly solved itself and I couldn't reproduce.

Setting XPRA_NVENC_LOSSLESS_THRESHOLD=100 server side, then setting quality to lossless I was able to toggle lossless to on (window[2].encoder.lossless=1) ... it took several seconds for the heuristics to adjust, but once it had done so, the lossless (and the x264 encoder when I changed the quality to merely Best) rendered exceptionally, even when I stretched the window size to gargantuan proportions on a 4K monitor (window[2].size=(2446, 1883)).

Testing with an osx client, 0.15.0 r8006, it was a little harder to set the quality to 100/lossless (had to use the control channel, since osx menus don't have any hooks for adjusting quality). Again, it took several seconds to adjust, with some odd green and black misrendering and a few seconds more in which only a subregion was responsive to scrolling and such... but once it adjusted itself it also behaved very well.


Fri, 03 Apr 2015 01:44:03 GMT - alas: status changed; resolution set

Ok, this seems to be good enough for current purposes. Closing.


Sat, 23 Jan 2021 05:06:13 GMT - migration script:

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