Things to know to get started – Recording and Editing Videos or Screen Graphics

For demos, promotional videos, user support calls and assessing graphical performance....

Updated 26/05/2020 to add info on Green Screens, lighting, headsets and a few more products plus some specific hints for teachers looking to record lessons

RobBeekmansLightboard1
Rob Beekmans recording a video using his DIY Lightboard – details below

How to Record Graphics?

There are lots of scenarios where it is useful to record graphics:

  • To make a support call – a quick video can save a tonne of words and confusion
  • To assess performance and quality
  • To make instructional videos to demonstrate configurations and set-up steps
  • To make promotional videos just showing off the pretty responsive graphics

With the advice from colleagues in the VFX, Cloud/VDI and CAD/AEC/CAE industries we’ve put together a few suggestions including many for the budget conscious of solutions you might want to explore. The products are listed in absolutely no meaningful order with no implied rating. It’s a product space with a lot of competition and many of the products recommended were new to especially me. However, in a space with 1000s of products some personal recommendation helped me limit my search. Continue reading “Things to know to get started – Recording and Editing Videos or Screen Graphics”

Microsoft RDP: End-client H.264 (4:4:4) Hardware-decode Support on existing decoders 4:2:0! Elegant and Cool!

2376-image_thumb_20aa6c9e
Great pictorial explanation on Microsoft Blogs!

Microsoft have just announced a series of tech preview enhancements to their RDP protocol, which you can read here. I’ve blogged endlessly about the problems of image quality for CAD line data and text with H.264 4:2:0 protocols which have been a long established standard for older encoders and GPUs.

The Microsoft announcement gives a very good overview (with pictures) of some of the visual issues that can arise with H.264 4:2:0 in their announcement – which I recommend looking at, here. Continue reading “Microsoft RDP: End-client H.264 (4:4:4) Hardware-decode Support on existing decoders 4:2:0! Elegant and Cool!”

Why CAD users really care about hidden-line and what you need to know about it to test remote graphics!

In a past life I was a kernel engineer on Parasolid the numerical heart within many top CAD applications such Ansys Workbench, Dassault Solidworks, Siemens NX and Solid Edge, Bentley, Nemetscheck, Missler Top Solid; I lived, breathed and obsessed about CAD workflows, how users construct parts and use CAD applications. Now I’m in Cloud computing and VDI, I still get to work with CAD applications but am working in an industry where for many other than the customer – a CAD application is just another VDI or virtualised app or workload.

Continue reading “Why CAD users really care about hidden-line and what you need to know about it to test remote graphics!”

H.264 Alone is Not Enough! Plus Why Cloudbridge REALLY Matters!

H.264 is a limited technology, where delta frames are transmitted per user, this means only changes are transmitted so on a single session it’s low on bandwidth but does require CPU or GPU resource to work out the changes between frames. CPU and GPU invariably also means power and on mobile devices that means your battery power.

H.264 is also fundamentally weakest on data users really care about such as text and hidden-line/wireframe data in CAD applications, it’s fundamentally a now quite old codec designed for static video compression (read more here and here). Continue reading “H.264 Alone is Not Enough! Plus Why Cloudbridge REALLY Matters!”

Comparing Apples to Pears! Benchmarking Thinwire Compatibility and Other HDX Graphics Modes

applesOne of our really experienced experts has just done a blog on some evaluation he did on Citrix’s hot new graphics mode: http://trentent.blogspot.ca/2015/09/performance-differences-in-citrix-hdx.html. Now this guy knows what he is doing but I’m a little worried others might not fully understand what has been done or the implications for the results. Trent did some tests flipping the encoder via a registry key. We do not encourage users to play with registry keys, occasionally they can prove useful to tweak a system, but really if that is being done we should be exposing the control via properly documented policies.

Continue reading “Comparing Apples to Pears! Benchmarking Thinwire Compatibility and Other HDX Graphics Modes”

Great real user feedback on thinwire compatibility mode (thinwire plus)!

My colleague, Muhammad, blogged a few weeks ago about a new optimised graphics mode that seems to be delighting users with significant ICA protocol innovations, particularly those users with constrained bandwidth (read the details – here). During its development and various private and public tech previews this feature has been known as Project Snowball/Thinwire Plus/Thinwire+/Enhanced Compatibility mode but in the documentation it is now “Thinwire Compatibility Mode” (read the documentation – here).

I was delighted to read a detailed review by a Dutch consultant (Patrick Kaak) who has been using this at a real customer deployment. In particular it’s a good read because it contains really specific detailed information on the configuration and bandwidth levels achieved per session (<30kbps). Unfortunately (if you aren’t Dutch) it is written in Dutch so I had to pop it through google translate (which did an amazing job).

You can read the original article by Patrick here (if you know Dutch!): http://bitsofthoughts.com/2015/10/20/citrix-xenapp-thinwire-plus/

What I read and was delighted by is the google translated version below:

Since Windows 2012R2, Microsoft make more use of DirectX for the graphic design of the desktop, where they previously used GDI / GDI + API calls. This was evident at the ICA protocol, which was heavily optimized for GDI and triggering a higher bandwidth in Windows 2012R2.

1. without tuning halfway this year we were at one of our customers engaged in a deployment of XenApp 7.6 Windows 2012 R2. Unfortunately, this client had a number of low bandwidth locations. The narrowest lines were 256kbit and there were about seven session running over, which equates to approximately 35 kbit / s per session. We had the h264 (Super Codec) compression already disabled because it caused a lot of high bandwidth and a lot of optimization applied in the policies, but we did not get the line under the 150kbit / s. On average, we came out of around 170 kbit / s. The 35 kbit / s never seemed to be achievable.

After some phone calls with Citrix Project Snowball, we decided to embrace a project that focused on optimizing ThinWire within the ICA protocol and what we call since Feature Pack 3 now ThinWire Plus. This would again reduce the bandwidth to a level which previously Windows 2008R2 was feasible.

After installing the beta on the test servers turned out that we had to force the server to choose the compatibility mode. A moment of choice, because to do so we had to turn off the Super Codec in its entirety for the server for all users that are on there. This forces you to use each session to ThinWire, even where the lines have enough bandwidth and the Super Codec can be used. This is done by implementing the following registry key:

HKLM \ Software \ Citrix \ Graphics
Name: Encoder
Type: REG_DWORD
Value: 0

It has furthermore been put to Medium in the policy Progressive Compression Level, as was indicated in the guidelines for ThinWire Plus.

snowball active – plus thin wire without optimizations: first results were superb. Immediately after installing ThinWire Plus dropped the average bandwidth already with 50% to 83 kbit / s.

After further tuning of all the components, it was even possible to still continue to go down. Previously had to some extreme measures for people on low bandwidth. The settings were made to further reduce the bandwidth. In the eye is the target frame rate that has been put to 15fps, and the use of 16 bit colors was carried out. Finally, a limitation per session bandwidth imposed maximum of 150 kbps.

gpoMaximum allowed color depth: 16 bits per level. (reduction of 10-15% of bandwidth only for entire server to switch)
Allow Visual Lossless Compression: Disabled
Audio over UDP: Disabled
Client audio redirection: Disabled
Client microphone redirection: Disabled
Desktop Composition Redirection: Disabled (prevents DCR is preferred over Enhanced ThinWire)
Desktop Wallpaper: Disabled (ensures uniform background color)
Extra color compression: Enabled (reduction of bandwidth, increased server CPU)
Additional color space threshold: 8192 kbs (default)
Heavyweight Compression: Enabled
Lossy Compression Level: High
Lossy compression threshold: 2147483647 Kbps (default)
Menu animation: Prohibited (reducing bandwidth by not using menu animations)
Minimum Image Quality: Low (always apply additional compression top sharper image)
Moving image compression: Enabled
Optimization for Windows Media redirection over WAN: Disabled (WMV prevents the WAN towards the client)
Overall Session bandwidth limit: 150 Kbps (for non-GMP, maximum bandwidth per session)
Progressive compression level: medium (required for enhanced thin wire)
Progressive compression threshold: 2147883647 Kbps (default)
Target frame rate: 15 fps
Target minimum frame rate: 10 fps (default)

3. snowball heavy tuned implementation of this policy came in the test situation, the average at 16 kbit / s. A value that we absolutely did not think we could get to in the beginning. In the user tests it was revealed that it still worked well on the environment, despite all the limitations that we had set in the policy.

After all changes were made in the production environment, we see that an average session now uses around 30 kbit / s. Slightly more than in the test environment, but certainly not values ​​that we complained about. Users can operate well and be happy.

Incidentally we discovered when testing behind it at a pass-through application (where users first connect to a published desktop and then launch a published application on another server), the ThinWire Plus configuration on both servers must be running. If we did not see we increase the bandwidth usage to the client again significantly.

(all my colleagues, thank you for providing the performance measurements!)

Testing Graphics Protocols – Try Chinese Text – With the aid of some ropey pseudo-maths!

In HDX we use a variety of compression and text recognition algorithms to ensure bandwidth is used efficiently but also that screen elements like text or CAD wireframe/hidden-line are clear and sharp. When testing graphics protocols, we often try to ensure that we don’t just look at the average or mass usage case (in the case of a product like XenDesktop that’s often test workloads like Microsoft Office on windows laptops as the end points). We also look at those use cases which are most challenging e.g. using very old and low-powered Linux thin-clients as end-points because if we can get performance and quality in such scenarios the user experience is better for all our users.

In the case of text quality, we often look at non-English fonts Continue reading “Testing Graphics Protocols – Try Chinese Text – With the aid of some ropey pseudo-maths!”

Citrix XenDesktop/XenApp – Understanding the HDX “Extra Color Compression” Policy

  • Update (16th Aug 2015) – Now a CTX: CTX201802 – FAQ: HDX Extra Color Compression (ECC) Policy in XenApp and XenDesktop

Extra Color Compression (ECC) is a policy that can be applied to control how HDX manages bandwidth vs. quality and other resources (e.g. CPU). It is documented in the XenDesktop and XenApp product documentation here.

What is Extra Color Compression (ECC)?

Continue reading “Citrix XenDesktop/XenApp – Understanding the HDX “Extra Color Compression” Policy”

Blog at WordPress.com.

Up ↑