Any idea to implement hardware encoding/decoding support?

[seflerZ]

This rfxcodec is a compatible mode which send compressed jpeg data stream to client which is out of date and can not make use of hardware decoding in client site.

I've noticed the Gnome-Remote-Desktop project has fully implemented the remotefx codec and support hardware acceleration. Is it possible to transmit the codecs used there to this project?

[Nexarian]

You're saying that GRD uses hardware accelerated JPEG compression?

XRDP has a version that's in prototyping that supports H264 with hardware acceleration for both Nvidia's NVENC and Intel's QuickSync encoder: neutrinolabs/xrdp#1422 (comment)

[seflerZ]

I'm not quite sure about the compression. But when using Gnome-Remote-Desktop provided by Ubuntu22.04 is much faster than xrdp. I noticed the difference is in the client side the GPU is not make used to decode the data stream.

with xrdp GPU usage:

with gnome-remote-desktop GPU usage:

[seflerZ]

I've checked the code, the Gnome-Remote-Desktop is using freerdp's rfx codec.

[Nexarian]

What are you looking at that convinces you that RFX is in use here? I have never heard of hardware accelerated encode/decode, it's got to be H264.

[seflerZ]

What are you looking at that convinces you that RFX is in use here? I have never heard of hardware accelerated encode/decode, it's got to be H264.

Oh, maybe my mistake. The source code in Gnome-Remote-Desktop reports following codecs available:

  if (rdp_settings->SupportGraphicsPipeline)
    rdp_peer_refresh_gfx (session_rdp, rdp_surface, buffer);
  else if (rdp_settings->RemoteFxCodec)
    rdp_peer_refresh_rfx (session_rdp, rdp_surface, region, buffer);
  else if (rdp_settings->NSCodec)
    rdp_peer_refresh_nsc (session_rdp, rdp_surface, region, buffer);
  else
    rdp_peer_refresh_raw (session_rdp, rdp_surface, region, buffer);

So the first one can make use of the H.264 as the following code suggests:

if (rdp_settings->GfxH264 &&
      g_hash_table_lookup_extended (graphics_pipeline->surface_hwaccel_table,
                                    GUINT_TO_POINTER (surface_id),
                                    NULL, (gpointer *) &hwaccel_context))
    {
      g_assert (hwaccel_context->api == HW_ACCEL_API_NVENC);
      success = refresh_gfx_surface_avc420 (graphics_pipeline, hwaccel_context,
                                            rdp_surface, buffer, &enc_time_us);
    }
  else
    {
      success = refresh_gfx_surface_rfx_progressive (graphics_pipeline, rdp_surface,
                                                     buffer, &enc_time_us);
    }

Which means we need to implement H.264 in xrdp. Is that the reason Gnome-Remote-Desktop is faster than xrdp?

[seflerZ]

@Nexarian Is it possible to use H.264 with CPU only? At least the client can benefit from hardware decoding. I've tried the script you provide, it tells should configure PCI Bus for framebuffer.

[seflerZ]

After doing some research, the "graphics_pipeline" is feature used in RDP 8+ and xrdp not implement yet. So this is why Gnome-Remote-Desktop is faster than xrdp, not because it uses H.264. Is that correct?

[Nexarian]

Sorry for the delay in getting back to you. To answer your questions:

Yes, GRD uses H264 with NVENC encoding, and that is why it is faster than the devel branch of XRDP. However, there is a version of XRDP that exists that uses H264, it's the script I provided above. I maintain a branch that factors in all the work that @jsorg71 has done on this and rebase if off of devel.

1. Is it possible to do H264 with CPU only? Yes. It was one of the first implementations created in the egfx branches. I haven't tested recently if it still works, but it probably does. If it doesn't, it should be easy to get it working again.

2. The script I provided above installs H264 accelerated, NVENC accelerated XRDP that has equivalent image quality and performance to GRD if I understand how their implementation works. I get 18k FPS using glxgears, which I've found to be a good napkin-math benchmark.

[seflerZ]

Understood, Thanks @Nexarian !