Tagged: vp8 h264
July 26, 2018 at 08:21 #19135
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.July 26, 2018 at 08:40 #19144
Can you try reducing the size of the image and reattaching those screenshots? Alternatively, send them to forum[at]nomachine[dot]com. Thanks!July 26, 2018 at 15:12 #19146July 27, 2018 at 14:41 #19169graywolfModerator
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.July 30, 2018 at 07:53 #19173
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.July 30, 2018 at 07:55 #19175
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.August 2, 2018 at 09:24 #19219
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.August 2, 2018 at 10:16 #19220
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.August 2, 2018 at 10:26 #19227
I was referring to the encoder. Send us the logs as per the instructions and we’ll take a look 🙂August 2, 2018 at 10:32 #19230
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).August 2, 2018 at 10:36 #19239
OK, thanks for letting us know.October 9, 2018 at 10:20 #19891
Here is the Trouble Report for this issue:
Please sign up to receive a notification of when the patch has been released using ‘notify me’.October 19, 2018 at 14:28 #20078
This topic was marked as solved, you can't post.