H.264 and "Disable multi-pass encoding" – does it work together?

[martinidry]

Hello everybody, this is my first post here.

I was not sure in which category should put it – please feel free to move it to another sub-forum. Since I believe it affects both Windows and Linux products I am putting it in the General Discussion.

I was struggling with pretty bad image quality despite the settings which should offer actually the best one. Finally I realized, that when I set the H.264 encoding and disable multi-pass encoding, I am getting blurry picture. Changing encoding to VP8 or leaving H.264 while enabling multi-pass encoding improves the situation, whereas of course in the latter case there is progressive refinement of the image from the lower quality instead of getting the image immediately in the target quality.

My observation is, that with H.264 and multi-pass encoding disabled, the image loads (and stays) in the low instead of high, target quality. I observed it with Windows host (NoMachine free) and  both Linux client (64bit NoMachine free) and Windows client. The same happens with Enterprise Client. I did also tests with Enterprise Desktop @Windows (evaluation), and finally with Linux host. In each and every case the result is the same.

In every case software was in the latest version.  In case of both Windows & Linux servers there is HW acceleration with Nvidia GPUs.

Do you have any idea, what is causing this issue?

 

 

[Enverex]

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?

[graywolf]

@martinidry and @Enverex

H.264 is the recommended choice because it offers better quality and faster encoding/decoding process. Consider it is also implemented in many GPUs, with obvious leverage of the offload to specialized hardware.

By the way, I think I’ve been able to reproduce the behavior you are complaining of. Rather than a low quality, I see a sort of light “shift” in colors. It is perceived with some specific color combination, so that hasn’t been noticed before. In order to improve the situation, keep multi-pass encoding enabled.

I’m going to open a Trouble Report to get the issue quickly fixed.

[graywolf]

New Trouble Report:

Image quality issues with H.264 encoding

Check “Notify me” to get updates.

[Enverex]

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).

[martinidry]

@enverex

Does the log on your side confirm that hardware acceleration is being used, or is it falling back to software like mine?

I will check the logs when I will be back home on Saturday.

@graywolf

Rather than a low quality, I see a sort of light “shift” in colors.

Well, what I could observe was really bad quality – I tried to view the pictures in the remote session and it was really unacceptable. With multi-pass encoding pictures were gradually reaching the original quality.

Thanks for opening the Trouble Report!

 

[graywolf]

@martinidry, do you get a situation similar to the samples uploaded by Enverex (thank you!) in the other topic: How can I improve quality when using H264 ?

[martinidry]

Hi @graywolf, yes, it seems to be the same problem. The image is blurry and lacks details. I followed your recommendation from this thread and disabled “client side image post-processing” and it seems to be doing the job, thanks.

By the way, disabling multi-pass encoding seems to affect audio quality as well. When I let e.g. a video on youtube play @firefox and then I start another program, or I try to browse pictures, sound is “choking”. It happens even with audio set to lowest quality. My both server & client are quite powerful and they do not show very high load, network is 10G.

 

@enverex, hardware acceleration works:

Info: Using Nvidia H.264 hardware encoder.
Info: Using desktop manager for screen updates.
Info: Using DirectX for screen updates.
3960 3188 14:05:21 084.122 GPUEngine: Configuring GPU resources.

 

 

[Britgirl]

@enverex and @martinidry, check your inboxes. I’ve just sent you both an email with instructions to help us find what’s causing the weird behaviour.

[Enverex]

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.

[Enverex]

“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.

[Britgirl]

We’ve downloaded the file, go ahead and remove it.

[Britgirl]

Just to confirm that a patched library has been sent to both of you for testing 🙂

[Britgirl]

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’.

[Author]

Posts