In the older days of server-based computing, we could get away with telling our users that we didn't support multimedia, and users knew it wouldn't work so they didn't even try. Life was simpler then.

In the older days of server-based computing, we could get away with telling our users that we didn’t support multimedia, and users knew it wouldn’t work so they didn’t even try. Life was simpler then.

But now things are different. First, there’s a lot more multimedia in the corporate world that are used by people for actual business purposes. (BTW, we have over 250 videos available for free at brianmadden.com/videos.) Second, in today’s world we’re trying to deliver complete and fully featured desktops instead of a few tactical apps here and there.

When it comes to multimedia and remote display protocols, there are two ways we can handle it:

Render the media on the remote host and send it to the client just like any other visual screen element.

Recognize that the media stream should be something special. Have the remote host pass it down to the client in its original format where the client will render it locally.

This doesn’t mean that host-based rendering can’t work—it just means it doesn’t work via ICA and RDP. There are other protocols out there, like Teradici’s PC-over-IP and HP’s RGS that do everything—video included—via host-side rendering. Of course these protocols were purpose-built for this, they consume a lot of bandwidth (certainly more than the native media stream they’re rendering), and they typically consume a lot of host-side CPU. (Or in the case of Teradici, they require special host-side hardware.)

Client-based media rendering

Fortunately it didn’t take too long for people to realize, “Hey, this host rendering might be kind of crazy. If we already have this media stream in its original compressed form, why not tell the host to leave it alone and to just shove it down to the client in its original form? Then the client can render it locally.”

This technique, commonly called “multimedia redirection,” (or “MMR”) has been in ICA for five years and is now in RDP 7 as well. It’s also part of third-party RDP add-ons like EOP and TCX. MMR is great because it doesn’t consume stupid amounts of bandwidth and the media plays back at native performance since it’s being played locally on the client.

The downside to MMR is that your client has to have the capabilities (both in terms of codecs and hardware capacity) to decode each media stream it hopes to play.

The reason we’re talking about server-versus-client media stream rendering is because Wyse just announced a new series of thin clients (the “C” class) that has a dedicated media stream processor on board. This processor (a Via VX855) provides hardware acceleration for up to 1080p playback of common media types, including H.264, MPEG, DivX, and WMV9.

It’s important to note that this Via chip is not a GPU. GPUs have been in thin clients for years. This is more like the chip that’s inside a Tivo that enables it to play back HD video even though the main CPU could barely run a calculator. (Seriously. You ever wonder how your Tivo can record two separate 1080p stream at once, but it takes 6 hours to download the guide? This is why!)

So this Via chip basically lets Wyse take their cheap “S” class hardware and give it the video playback performance of their high-end “R” class devices. (The “C” class devices start out with MSRP of $350, which means you should be able to find them for about $300 on the street.)

The new “C” class devices work in conjunction with Wyse’s TCX extensions for RDP. (One of the extensions is for multimedia redirection, so if a “C” class device receives a redirected media stream that the Via chip can handle, it takes care of it automatically.)

If you decide to stream Windows 7 to your “C” class device, Windows will also recognize the Via chip automatically and start leveraging it. Actually it seems like the only thing that can’t leverage this chip right now is ICA. (Since Citrix’s HDX MediaStream doesn’t know to look for the chip, it will just have the client CPU do the rendering.) But I would think this would be a relatively easy thing for Citrix to support in the future.

The future: more on the client

I really like the concept of a cheap thin client having the capability to render H.264 locally. (I focus on H.264 because so much is going there, like Flash, Silverlight, Quicktime, etc.) But let’s face it: it just makes sense for some things (like media streams) to be rendered directly on the clients. Who wants to spend so many CPU cycles doing things in the datacenter that will just increase your bandwidth and decrease your user experience. Spend the cycles where they make the most sense.

Wyse will be demoing the C class devices at VMworld next week. Gabe and I will be there with our video cameras, so we’ll be sure to grab some demos.

Join the conversation

11 comments

Register

I agree to TechTarget’s Terms of Use, Privacy Policy, and the transfer of my information to the United States for processing to provide me with relevant information as described in our Privacy Policy.

Please check the box if you want to proceed.

I agree to my information being processed by TechTarget and its Partners to contact me via phone, email, or other means regarding information relevant to my professional interests. I may unsubscribe at any time.

Your password has been sent to:

Please create a username to comment.

This is great. Offloading the media from the boxes is a good idea that should help the user experience quite a bit. Hopefully this will allow for Aero as well in Windows 7 VDI deployments. With hardware in the thin client dedicated for rendering, you might be locked in to a particular set of codecs and capabilities, but it looks like this particular chip handles all of the most common. I doubt business are going to be using some of the more obscure codecs that one might find on torrents.

Regarding using this chip for Aero, that is definitely not possible, since this is a purpose-built streaming media processor. Aero is handled by a GPU, and fortunately there are plenty of thin clients (from Wyse and others) with GPUs. So Aero on a thin client is definitely possible, but I just wanted to clarify that Aero is possible from a GPU, not this Via chip.

@appdetective - this type of dedicated media chip is being added in some cases to netbooks that lack the necessary horsepower to process HD h.264 video for example. I don't think it is much of an issue on the desktop. From a commodity desktop perspective, current AMD based solutions leveraging a modern AMD/ATI chipset with integrated graphics (780G for example) should be able to handle HD video of various formats without a problem. From Intel's side, their current integrated chipsets should be able to handle it as well (915, G31, etc.).

I agree that you probably cannot get full-screen, high-def video using host-based rendering to work very well, but we have a good solution for playing full-screen YouTube-type videos over WAN connections in VERDE. Here's a demo on YouTube in fact of me showing this over a small-business-grade broadband connection (DSL):

While I'm extremely excited to see people putting more thought and ideas into smart rendering technologies, this is an extremely tough nut to crack, why?

a) Client side streaming (even with a the help of a client side dedicated chip) is still going to be more about QoS / bandwidth than it is about CPU decoding capabilities. Let's put it this way, you can't stream 1080p (HD) content over a typical wireless network for several reasons (bandwidth, packet loss/interference, latency, etc). You need wired connectivity to get good streaming performance without relying on a ton of prefetch. That being said, any type of high(er) quality video requires crazy bitrates that are just not realistic on most companies WAN environments. Even those that have appropriate bandwidth for SD content, aren't planning on the entire thing being sucked down by a single user. So yes, client side rendering is a good thing, but if possible it's much better for the client to fetch the content themselves off a content distribution network and not touch the corp connection at all (this is how Citrix' flash remoting works, but it's not how their MMR currently works.

b) This is and will continue to be a codec cat/mouse game. There's literally hundreds of different media rendering codecs. While this seems to cover DivX (no mention of versions, is it 3,4,5?), WMV9 (what about 7,8,10,11?), H.264, MPEG-2/4, etc. What about XVid, Quicktime Sorensen, 3vix, HVC, RealMedia, etc. There's literally hundreds of other codecs that would all be host rendered. I'm not saying that the codecs they are accelerating isn't a good thing, just don't kid yourself that it covers all of your needs.

c) Video technologies are constantly evolving. These chips, like all software will soon be outdated. While the linked article references support for Windows 7 and VMR, is this VMR7? VMR9? Does it support the new EVR mode from Vista/Win7? Is it DirectShow only (i.e. does it support MediaFoundation? etc etc.

Me personally, I'd rather just have a nice GPU with some DXVA acceleration on it. Well, I suppose that would be great if some media playback softwares and codecs fully supported DXVA accelerated playback that is. LOL

Another thing to consider when referencing Thin Clients in the context of Multi Media is the fact that many of the less expensive Thin Clients that are purchased are Linux based. Codec's that are commonly available for Windows OS's are not available for Linux based OS's. There is no real codec parity between the various operating systems period.