On Thu, May 21, 2020 at 1:39 PM Sean Reid <sean.re...@gmail.com> wrote:
> On Thu, May 21, 2020 at 4:24 PM sciUser <shulb...@securitycentric.net> > wrote: > > > > As long as you have a GPU assigned to the VM it will handle the > rendering, > > Guacamole is just the broker for the RDP protocol. > > The pixels that come from RDP or VNC may be compressed in some way, > but before guacd sends them out to the client, it still has to unpack > them and convert them to png, jpeg, webp (if it was compiled to > include webp) in the guacamole protocol. With this in mind, I'd be > interested in seeing guacd could scale better than it already does > with GPU-based image encoding. It's possible we could see more > connection to unique displays with GPU encoding. > > In addition, guecenc is an area I've toyed with adding GPU support to > personally since I've spent a lot of time adding H.264 support to > guacenc and modern GPUs almost certainly have H.264 hardware encoding > support. The issue I ran into was one of user interface: requiring a > user to know their set up well-enough to tell guacenc to use the nvenc > encoder seemed like a bad UI choice to me, and I had no good ideas for > how to automatically detect that support and use it. So I didn't push > it too much further. But if you have ideas, I'd love to see optional > GPU encoding support there! If you have something (or *can *have something) which could produce an H.264 stream within guacd, I have some working POC code which decodes H.264 streams received within the Guacamole client (streams sent via the "video" instruction and subsequent blobs). The code leverages the "Broadway" H.264 decoder. I think we'd need legal confirmation that including such a decoder and encoder is OK, but overall definitely worth doing. It sounds like we may be closer to having this than I thought. - Mike
