Citrix Blogs

“Use Video Codec for Compression”: to Use or Not to Use?

Muhammad Dawood

With the release of 7.6 FP3 in September 2015 came a new graphics policy, “Use Video Codec for Compression,” with new settings:

1. Use video codec when available. (default)
2. Do not use video codec.

With the introduction of 7.9, a third option became available:

3. Use video codec when preferred. (new default)

Confused? Probably. But after you’ve finished reading this blog, hopefully all will be clear and I’d have helped answer questions like:

First, a little history lesson…

Several years ago, Microsoft made some changes to the way graphics are done on Windows. Vista introduced DWM, a compositing window manager able to leverage GPU acceleration and offer a really engaging experience. Traditional GDI-based apps were still supported but the move away from GDI had begun.

This meant we [Citrix] had to move away from GDI, too. Our Legacy Thinwire graphics mode is essentially a GDI-based remoting solution with some very clever optimizations that established ICA as the frontrunner in remoting protocols. However, in the new, bitmap-only world of Windows 8 and Windows Server 2012, these optimizations had little or no effect and it became clear that a new solution was needed.

In XenDesktop 7.0, we introduced Thinwire Advanced. This added adaptive H.264 (a.k.a “Deep Compression”), previously available only with HDX 3D Pro, to the armoury of codecs in the Thinwire SuperCodec. At the same time, we made Thinwire prefer use of H.264 by default, providing the user’s Receiver supported it (Windows Receiver 3.3 or later). For those Receivers that did not support H.264 – for example, old thin clients that cannot be upgraded – Thinwire Advanced provided a “compatibility” mode. Of course, we also retained GDI-optimized Legacy Thinwire for use with Windows Server 2008 [R2] and Windows 7 or XP.

Thinwire’s use of H.264 is special in that some very clever techniques are used to ensure text remains sharp and crisp. However, this comes at a cost and when compared to Legacy Thinwire (on a legacy version of Windows), server scalability is generally lower and bandwidth usage typically higher. Moreover, the original compatibility mode also came at a considerable cost in increased bandwidth consumption and server CPU usage.

Thanks to our multimedia redirection technologies, many Citrix customers only occasionally require server-side video rendering, and may not use 3D graphics applications. For such customers, the benefits of full-screen H.264 don’t justify its cost. Recognizing this, project “Snowball” was born. The challenge? To develop a non-H.264 solution maintaining the same amazing server scalability and bandwidth characteristics and the same great user experience that customers enjoyed with legacy GDI-based Windows in this new world of DirectX and fully-composited desktops.

With that said, Thinwire’s compatibility mode was redeveloped from the ground up to match (or beat) server scalability and bandwidth usage of Legacy Thinwire. We achieved this in 7.6.3 and informally dubbed this advancement “Thinwire Plus”. What’s more impressive is that we did this without requiring a Receiver / end-point upgrade. So no need to worry about those old thin clients that can’t be upgraded, we’ve remoted Windows 10 on eight year old 800 Mhz hardware running Receiver 11.x just fine!

So to recap, Thinwire with H.264 was the “default” no-policy setting in XenDesktop 7.0 for modern Windows and this remains the case in the 7.6.3 Long Term Service Release (LTSR). However, Thinwire without full-screen H.264 encoding – also known as compatibility mode – is less costly and very often the better choice.

Up until 7.6 FP3, there was no way for the admin to express a preference to use compatibility mode. So, how does Thinwire’s mode selection map onto the “Use Video Codec for Compression” policy?

“Use Video Codec for Compression”

It became clear that, in addition to the revised compatibility mode implementation, we needed a way for the admin to express a preference to use this mode instead of the then-default Thinwire with full-screen H.264. So we introduced the “Use Video Codec for Compression” policy which essentially toggled this selection by means of two policy settings:

At this point, you might be asking yourself, “If the new compatibility mode looked so good, why did Citrix leave the default in 7.6.3 as Thinwire with H.264“?

There is a simple answer to this: we wanted more data. At Citrix, we tread very carefully when considering a change to default settings. Many customers use defaults and switching the behaviour under the covers can sometimes be very disruptive. We wanted to be absolutely sure that the new mode performed as well as we’d seen internally before considering a change to the default Thinwire graphics mode.

Well, that time has come, and following lots of positive customer feedback reporting improved server scalability and lower bandwidth usage, we’ve made the switch. In 7.9, we introduced a new setting to the policy:

Today, this literally maps onto the “Do not use” setting, so why did we add a new setting and not make “Do not use” default instead? Simple: we want to allow future versions of the product to make the decision automatically, rather than expecting the administrator to choose one or the other.

There is one exception to this – again based on lack of data – which I will discuss next.

When would I want to set “Use video codec when available.”?

Or, put another way, “when would I want my users to be given Thinwire with full-screen H.264?”

There are some workloads for which Thinwire with H.264 performs best. In particular, workloads with video or large moving images on WAN connections tend to perform better. Being a video codec, H.264 is excellent at delivering good quality imagery over low bandwidth. For this reason, when the XenDesktop VDA is installed in HDX 3D Pro mode it will prefer to use Thinwire with H.264, unless overridden by the “Visual Quality” policy.

Another reason one may prefer Thinwire with H.264 is for devices that can decode H.264 efficiently. For example, the recently announced Citrix Ready Raspberry Pi thin client based on the Pi 3 has hardware H.264 decode capabilities and makes easy work of full-screen 1080p server-rendered video – providing the server can keep up! However, for most workloads, Thinwire’s compatibility mode is still the better choice. Indeed, at this year’s Synergy conference in Las Vegas, the Citrix Sandbox had 1080p-30FPS desktop and 3D app demos on the Pi _not_ using H.264!

Summary

As requested, here’s a table summarizing the above:

XA/XD version “Use Video Codec for Compression” policy default What mode will I get?
7.0 – 7.6 n/a Thinwire & H.264 (*)
7.6.300 – 7.8 Use when available Thinwire & H.264 (*)
7.9 Use when preferred Thinwire Compatibility (TW+)

(*) Only selected if Receiver is new enough. Otherwise, Thinwire Compatibility is selected instead.

My advice

In most cases, the “Use Video Codec for Compression” policy shouldn’t need changing from it’s default setting of “Use when preferred.”. Keeping this as-is ensures Thinwire compatibility is selected for all Citrix connections, and is optimised for scalability, bandwidth, and superior image quality for typical desktop workloads. For those intensive 3D / host-rendered video workloads – especially on a WAN – you may want to try setting this policy to “Use when available” and see if the user experience improves.

Where might this go in the future?

Today, the Adaptive Display technology in Thinwire identifies moving images (video, 3D in motion) and applies more aggressive JPEG compression to deliver a smooth user experience. What would happen if Adaptive Display were enhanced to use H.264? The overall impact on server scalability would be lower since the use of H.264 would be selective (only when the user is watching a video, and only for that portion of the screen). Certainly some intriguing possibilities…

Exit mobile version