Forum Replies Created
-
Posts
-
“NX-Log.tgz: Sorry, this file type is not permitted for security reasons.” – Sigh.
I’ve uploaded it here instead – (link removed)
Let me know once you’ve grabbed it so I can delete it.
Already uploaded on https://forums.nomachine.com/topic/h-264-and-disable-multi-pass-encoding-does-it-work-together/#post-19212 but it rejected the filetype, so I’ve uploaded it separately (but that post is still pending).
Encoder or decoder? The logs I sent you were from a Linux server using software X264 encoding and a Windows client using Nvidia hardware decoding.
Sorry for the delay, I had to reinstall NX on the server because apparently deleting the log files (just the log files, not any folders) breaks the server (service starts up, but no-one can connect anymore).
Anyway, log attached (I assume it doesn’t contain anything possibly describable as sensitive information).
Basically the only difference is the node session file now seems to contain this line hundreds of thousands of times:
19260 19916 22:18:54 784.006 DisplayEncoder/DisplayEncoder: Last quantizer used: 16.
Looks like you’re correct. Disabling “Client side image post-processing” removes the blurry image issue with X264. Weirdly enough VP8 doesn’t seem to suffer from this bug at all.
Well I was going to test this but I cannot get anything other than VP8 software rendering anymore and I’m not sure what’s changed. There’s no errors and no mention of H264 at all.
NXAGENT – Version 6.2.4
Copyright (C) 2001, 2018 NoMachine.
See http://www.nomachine.com/ for more information.
Session: Starting session at Fri Jul 27 20:41:28 2018.
Info: Agent running with pid 1551.
Info: Slave server running with pid 1579.
Info: Display running with pid 1580.
Info: Listening to slave connections on port 12001.
_XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6
_XSERVTransOpen: transport open failed for inet6/arcade:1001
_XSERVTransMakeAllCOTSServerListeners: failed to open listener for inet6
Info: Audio server started with pid 1594.
Info: Audio client started with pid 1595.
Info: Display server started with pid 1596.
Session: Session started at Fri Jul 27 20:41:28 2018.
1551 1599 20:41:28 763.315 TcpConnector/TcpConnector: WARNING! Can’t create the socket for proto ‘TCP’ family ‘IPv6’.
1551 1599 20:41:28 763.338 TcpConnector/TcpConnector: WARNING! In method ‘startTcp()’ context [A].
1551 1599 20:41:28 763.343 TcpConnector/TcpConnector: WARNING! Error is 97 ‘Address family not supported by protocol’.
Warning: TcpConnector: WARNING! Can’t create the socket for proto ‘TCP’ family ‘IPv6’.
Warning: TcpConnector: WARNING! Error is 97 ‘Address family not supported by protocol’.
Info: Using MIT-SHM extension.
Info: Using SSE3 for screen analysis.
Session: Connected to display server ‘:0’ at ‘Fri Jul 27 20:41:41 2018’.
Info: Screen capture running with pid 1924.
Session: Connected to events server ‘:0’ at ‘Fri Jul 27 20:41:41 2018’.
Info: Using damage extension for screen updates.
Info: Screen analysis running with pid 1925.
Info: Using grab method ‘CopyArea’.
Info: Using screen size 1600×900.
Info: RT handler running with pid 1941.
Info: Display server for 85FA1EDCE1630B3D54B5C90179B20289 connected on Fri Jul 27 20:41:41 2018.
Info: Audio server for 85FA1EDCE1630B3D54B5C90179B20289 connected on Fri Jul 27 20:41:41 2018.
Info: Audio client for 85FA1EDCE1630B3D54B5C90179B20289 connected on Fri Jul 27 20:41:41 2018.
Info: Using Vp8 software encoder.
Info: Audio reader running with pid 1983.
As you can see, no errors but also no mention of H264. It still doesn’t use it when I specify it in the node.cfg file.
I seem to have resolved this now and I’m no-longer seeing that particular issue (the issue being that Intel has like 3 different media packages now for different generations).
Unfortunately NoMachine insists on using QuickSync rather than VAAPI and the former is notoriously difficult to get working without applying a lot of hacks whereas the latter covers multiple GPU types and should “just work”.
Is VAAPI being implemented at all? As it would allow hardware encoding on pretty much all GPU types on Linux.
Compressing them would make the comparison somewhat void so I’ve uploaded them externally.
VP8
https://xnode.org/files/VP8.pngH264
https://xnode.org/files/H264.pngNotice how blurred the second (H264) image is. This is at max quality.
Could be related to this issue I reported as well – https://forums.nomachine.com/topic/how-can-i-improve-quality-when-using-h264 (my response with the images attached is still awaiting moderation unfortunately).
I’m having the same issue. I spent a while getting H264 software rendering working as it’s listed on all the support documentation as being higher quality than VP8, but it’s far, far worse. The image lacks any quality at all and is just a muddy mess (with adaptive off and quality set to max).
Does the log on your side confirm that hardware acceleration is being used, or is it falling back to software like mine?
