Today we want to have a closer look on the differences between YUV420 and YUV444.
In my experience, a lot of end users in GPU accelerated projects complain about “blurriness” in their session. As mentioned already in my previous blog post of this series this is because of the “chroma subsampling effect”. As soon as we set the Citix policy to “Optimize for 3D workloads” we should see H.264 YUV420 with entire screen hardware encoding as default and this explains, why this issue is present for a lot of users.
Quite often it is not really clear that the GPU rendering is independent from the protocol choice and I have seen a lot of situations where customers simply used H.264 for their office VDI users because they thought this is the only way to leverage the GPU. H.264 protocol usage is only relevant for hardware encoding support (NVENC).
But what is the difference between YUV420 and YUV444 and why is this relevant for our protocol choice?
I don’t want to go into much detail but you should at least have a rough understanding that there are different sampling systems available to “compress” a given image. YUV presents the luminance part = Y and the chroma part = U and V. Each part is represented by 8bit or 1Byte. This leads to 24bit for YUV444 as we don’t have chroma subsampling here which means we don’t remove chroma information from our image. But for YUV420 we remove half of the vertical and horizontal chroma information to reduce the required bandwidth as we now have 12bit for YUV420, still 8bit for luminance but only 4bit for chroma instead of 16bit. If you want to learn more about sampling systems you could have a look here.
It is more important to me that you understand the impact from a user perspective and therefore let’s start with the “human eye” comparison.
Once again, we take our “quick brown fox” reference image and compare the captured session images for YUV420 and YUV444
So if you look in particular on the blue font with red background or red font on blue background you will see the chroma subsampling effect the user might explain about especially in Office based applications like MS Excel where it is pretty common to have background colors in the spreadsheet cells.
And what about the numbers if we use SSIM? As mentioned in the previous post the color accuracy for YUV420 is at around 83%. I will focus on the YUV444 numbers here:
If we look at the heatmaps in comparison, the difference is even more obvious:
We can now see a huge improvement in color accuracy when using YUV444 in favor of YUV420 for our session. But before you get the impression that YUV420 is unusable we should consider that the reference image above is kind of worst case scenario for YUV420 and I will show you another comparison with a greyscale wireframe model. Here is the reference image:
I will skip the “human eye” comparison in this case as you have to believe me that there is no difference visible for the human eye :).
So we will directly jump to the SSIM numbers:
So if we look at the numbers here we see that YUV420 is not bad with 99% color accuracy and YUV444 is slightly better with 99,7%. As explained above the luminance part of an image is unchanged also on YUV420 so the result with a greyscale based image is much better compared to our “quick brown fox” test case.
You may already expect the downside of YUV444 usage in having increased bandwidth consumption. And YES, this is true. As stated above we have 24 bits per pixel for YUV444 and only 12 bits per pixel for YUV420 so I would indeed expect to see an increase in bandwidth consumption in a range of two times the bandwidth with YUV444.
I did a video playback test in window mode (see image on next blog for more details) to show a multimedia scenario and here are the results:
Well, as you see the required bandwidth with Citrix 7.18 in this test is almost 3 times the bandwidth needed for YUV420. This is pretty important especially for low bandwidth remote connections as it may limit the use case.
YUV420 as well as YUV444 are using hardware encoding (NVENC). So we see very good end user latency that is slightly increasing with YUV444 due to increased encoding capability necessary.
Linux based Thinclients do NOT support YUV444 as this is not implemented in the Citrix Linux receiver. Be aware of this limitation as it may limit the use case for customers already having Linux based ThinClients.
Citrix Policy Set
I explained the policy set for YUV420 already so I will only focus on YUV444 here. For many years already there is the YUV444 implementation available with Citrix but it is not pretty clear how to configure it properly as I see lots of customers fail to do so.
I would recommend to use YUV444 in 3D VDI use cases where the user is sensitive to color accuracy. It is almost impossible to use YUV420 especially in cases where the user is working with specific applications where we have single pixel line drawings, for example. But you need to have your bandwidth requirements under control as we have seen a huge increase in bandwidth as soon as we use YUV444. In addition, there is no Linux receiver support from Citrix which also reduces the possible use case for YUV444. We will discuss other protocol options like hybrid codecs later but a lot of customers are currently stuck with XenDesktop 7.15 LTSR and there is no other choice if we need color accuracy but also good performance with moving images.
If you would like to view the on demand recording of our GTC session on choosing the right protocol for your VDI environment , click here