guacamole-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Jumper <mike.jum...@guac-dev.org>
Subject Re: Performance testing of Guacamole
Date Sat, 10 Mar 2018 18:54:13 GMT
On Sat, Mar 10, 2018 at 10:19 AM, Antony Awaida <antony@apporto.com> wrote:

> Thanks for the prompt reply Mike: Follow up questions:
>
> On Sat, Mar 10, 2018 at 10:10 AM, Mike Jumper <mike.jumper@guac-dev.org>
> wrote:
>
>> On Sat, Mar 10, 2018 at 9:44 AM, Antony Awaida <antony@apporto.com>
>> wrote:
>>
>>> Hi Mike:
>>>
>>> Is there a way to tell Guac if this is a video stream - just pass it
>>> through to the client without going through the codec process?
>>>
>>>
>> Not exactly, but that wouldn't be a workable solution in the general
>> case. Even if it were possible to hook into the video stream within the
>> browser within the remote desktop, that video stream is in some arbitrary
>> codec supported by that browser, initially negotiated between the site
>> streaming the content and the browser itself. There is no guarantee that
>> the codec agreed upon by that browser will be supported by the browser of
>> the user on the Guacamole connection, let alone all users sharing that
>> connection via Guacamole's screen sharing capabilities.
>>
>
> AA> We already tell end users to use Chrome when using Guacamole. It would
> not be unreasonable to tell them that, when watching video, they should use
> Chrome in the remote desktop. Thoughts? will this work?
>
>

No:

1) It is not possible. More on this below.
2) If it were possible, it would not be a workable solution for the project
as a whole for the reasons cited above.


>> More efficient handling of video streams is still possible long term
>> through either or both of the following:
>>
>> 1) Adding hardware encoding support. While PNG may not lend itself well
>> to this, JPEG and WebP both have hardware encoders via GPU, and the
>> compression used by PNG (deflate) does have hardware implementations (via
>> dedicated cards). Offloading encoding of graphics to hardware would remove
>> the majority of processing requirements for things like watching YouTube.
>> Simply adding hardware encoding support for JPEG and WebP would be
>> low-hanging fruit here, given the ready availability of those encoders and
>> the fact that Guacamole will already automatically switch over to JPEG/WebP
>> when it heuristically detects video.
>>
>
> AA> this would be harder to control since users will watch any video they
> want including PNG.
>
>

The decision regarding whether to encode graphics received over RDP as
JPEG, WebP, or PNG is made by the optimizer within guacd, not the user.

By the time Guacamole receives the data for what appears to be video, it
has already been decoded by the application playing the video and turned
into raw graphical operations by the RDP server. The data available to
Guacamole as an RDP client is essentially equivalent to the data visible on
your screen, and Guacamole will not have access to the original video
stream any more than your eyeballs do.

- Mike

Mime
View raw message