- This topic has 12 replies, 3 voices, and was last updated 6 years ago by
.
-
Posts
-
I’ve been using VP8 fallback for a while and it looks fine, but all the NoMachine documentation says H264 should look better and use less bandwidth, so I worked on getting that going. I built the library and put that in the correct location so it’s now working.
The downside is that it looks absolutely awful. It looks like what I’d expect when I select “ultrafast” encoding speed and 3Mb bitrate when streaming. This is with the client set to not use adaptive quality and the quality set to the far right option (max quality).
I’ve attached images of the same scene but with both encoders. Notice the lack of quality on the H264 version, it’s just a smudgy mess in comparison.
Additionally, as I’m using this on gigabit, is there any way to increase the max allowed bitrate? Artificially limiting it on such a high bandwidth connection seems unnecessary.
Can you try reducing the size of the image and reattaching those screenshots? Alternatively, send them to forum[at]nomachine[dot]com. Thanks!
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.
The blurring looks the result of the deblocking filter. You can disable it in the “Display settings” pane checking “Disable client side image post-processing”.
Deblocking filtering is automatically tuned or turned off, with criteria adapting to the different decoder in use, so the final effect could differ on VP8 and H.264. The algorithm is supposed to disable deblocking if the image is almost perfect like in this case, by the way it is going to be improved in order to find a better trade-off with the quality level.
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.
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.
We dug deeper in to the problem because, actually, things were not fully clear. Maybe we’ve found a bug with the nVidia hardware encoder that causes post-processing to be applied when it shouldn’t. We’ve sent you an email with instructions to confirm the problem.
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.
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).
Here is the Trouble Report for this issue:
https://www.nomachine.com/TR07P08737
Please sign up to receive a notification of when the patch has been released using ‘notify me’.
Make sure you download the latest release 6.3.6. It contains the patch for this bug.
This topic was marked as solved, you can't post.