Xvnc backend: does not support tight encoding when using vnc-any

[hellothere-yan]

When I use vnc-any to forward VNC sessions, I found that tight encoding is not supported. I would like to ask if it will be supported in the future,thanks a lot.

[matt335672]

Hi @hellothere-yan

I need some clarification.

Are you asking for support for the tight encoding encoding type, or the tight security type or both?

Can you be more specific about the problem you're trying to solve here?

Thanks.

[hellothere-yan]

Hi @hellothere-yan

I need some clarification.

Are you asking for support for the tight encoding encoding type, or the tight security type or both?

Can you be more specific about the problem you're trying to solve here?

Thanks.

Hi，I am using the tight encoding, which is the default encoding method used by both tight VNC and tight VNC，because my VNCserver only supports the tight encoding method,i want to connect to my VNCServer through vnc-any.

[matt335672]

Thanks for the clarification.

I can' promise you anything soon, I'm afraid. Our project is ASL licenced, and although there are VNC clients (and libraries) out there which support tightVNC encoding, all the ones I can find are licenced under the GPL. The tightvnc decoder is available (see here) but not on terms which are compatible with the ASL.

In other words, we can't simply embed an existing implementation of the tightvnc encoder in our code. That gives us two options, both of which involve significant development effort:-

• we could possibly make calls into libvncclient specifically to handle this encoding.
• we could provide a clean room implementation of the encoding.

I'm welcome to any other suggestions from anyone.

[lcniel]

I'm a bit curious about having a look at a clean-room implementation of this encoding as it's been a long time since I did high-performance coding in C and I could use some practice, and I would like to get more familiar with the xrdp code base.

Tight encoding is kind of a de facto standard and so would be nice to support, but I wonder a bit about the performance implications of this. Generally this would be used for inter-process communication on a single server, and I wonder if it would really be useful for anything other than the special case where the VNC server doesn't support any other encoding? My intuition here would be that it is hardly worth to do an extra layer of encoding unless you are communicating over a network (and thus balancing latency and bandwidth and so on) and I could see it performing worse both in terms of quality and responsiveness (not entirely unlike the kind of issues Guacamole suffers from).

Would be interesting to hear input from the experienced devs with more video coding experience - what's your intuition here, do you think this encoding could be useful even for cases where the VNC server supports other encoding methods? I would probably hesitate to put too much time into a tricky case like this if there is not a performance benefit.

[matt335672]

I can't claim any significant video encoding experience campared to @jsorg71 and @Nexarian, so bear anything I say here with a pinch of salt.

I agree that this would only be useful when communicating with a remote 3rd part VNC server which is configured to use TightVNC only. As an ex-sysadmin I can see why this would be desirable.