Telepresence vs HD Video Conferencing

Now let's move Larry up to 1080p at 30 frames per second, which uses about 4 megs of bandwidth. So as you can see, significantly increasing the traffic on your network does not necessarily translate into better image quality. Note, Lisa will appear in better quality as her frame rate remains at 60. This underscores the importance of display size and selecting the appropriate the resolution. While increasing frame rate has the same impact on any size screen, the impact of resolution declines in proportion with the display size. For example PDA or cellphone displays support low resolutions but look great because of their small size.

As a rule of thumb, the human eye can discern 1080p only when the display size is equal to or greater than 70 inches and the viewer is sitting about 10 feet from the display. Not all video applications today involve face-to-face interaction. Now that Larry and Lisa appear to have made out, let's take a quick look at some applications illustrating the relative importance of resolution and frame rate.

In this live musical performance, where motion smoothness and the ability to discern fine motion movements take priority, optimal viewing occurs at 720p resolution and 60 frames per second. Another example of where motion smoothness takes precedence over maximum resolution is in this clip where a doctor is instructing a remote group of students in a new medical procedure using captured video as part of his lesson.

In some cases though, clarity and fine detail matter more than motion. These examples from healthcare highlight the importance of maximum 1080p resolution. It's essential for the remote physician to see fine detail such as an enlarged blood vessel or changes to the cornea. And in this example, the remote consulting physician sees the diagnostic image in 1080p high definition enabling an accurate diagnosis of a patient hundreds of miles away.

The importance of detail also extends into commercial applications. In these two examples, 1080p enables remote quality inspection of two very different products; a printed circuit board intended for using consumer electronics and a garment being manufactured for the retail market.

In the world of video, clearly one size does not fit all. Balancing quality with cost effectiveness by choosing the right combination of frame rates, resolution, and bandwidth for your environments and requirements is critical.

Whether your video enabling desktops, conference rooms, lecture halls or immersive suites, we have hope this video helps you make a more educated decision. For more information, we welcome you to contact your Polycom representative. Thank you.

Telepresence vs HD Video Conferencing

Video conferencing today is fundamentally changing business communication whether in an office or the field, under web camera or immersive suites, video is increasing communication efficiency and reducing the cost of doing business for companies around the world.

Video's popularity however has resulted in a host of terms, acronyms and technologies that can complicate finding the right solution for your organization.

What do you need to assess to make the right choice? First, review your applications. Will video be used to face-to-face interactions, content sharing, high motion graphics or more, what resolutions and frame rates are needed to ensure optimal experiences, how much bandwidth do you need, what about display sizes and types and can you ensure the choices you make today will last into the future?

Let's take a look at these technical variables and consider how they influence one another in different applications. The first factor as most people consider with video are resolutions and frame rates. Right now you are seeing me in 1080p resolution. 1080 represents the lines of vertical resolution while the letter P stands for progressive scan in which all of the lines of each frame appear in sequence. You may also see resolutions like 1080i, the I stands for interlaced and generally in the world of video, progressive scan is preferred because interlacing causes details to twitter and blur at the cost of image clarity.

Now let's compare the impact of resolution and frame rate on an actual video interaction. Lisa and Larry are in a traditional video conference that uses CIF resolution in about 384 kilobits of bandwidth. Now let's see Lisa in standard definition or SD, which is about four times the resolution of CIF and requires about 768k of bandwidth. Notice the level of detail and clarity Lisa has over Larry.

Now let's move Larry to 720p, also known as high definition or HD. 720p at 30 frames per second uses about 1 megabyte of bandwidth and is the primary driver behind today's widespread video adoption.

In this interaction, Larry's gestures and expressions become immediately more impactful. Everything we have seen up to now has been shown at 30 frames per second. But now let's take Lisa to 720p and also double the rate to 60 frames per second. This mode uses about a meg and a half of bandwidth and is the equivalent of high definition broadcast TV.

Notice that even at the same resolution because Lisa is being shown at twice the frame rate, her motions are much smoother.

To be continued...

Telepresence Equipment Interoperability Part VI

We also were able to record all of these sessions with RSS 2000 and the recording shows multiple sites and it gives a very good overview of what happened during the tests. There was a consensus that the telepresence interoperability demo was successful and very impressive and it also proves that standards and interoperability are alive and can connect systems from different vendors running on different networks. And I think for me personally the lessons learned is that you really require a very diverse team from different organizations with different agendas, by the way, to get such tests implemented and not that -- we should also note here that some of these organizations were competing and it is very important that we found this common goal that brought everybody together and allowed us to achieve this spectacular interoperability results.

Scott Whitney: Very good. Now, I know that you have written a very detailed series of blog posts about is process. Why don't you tell everybody where we can find that along with any other information that you might recommend that we read?

Stefan Karapetkov: Well, the blog post is Video Networker and it's easy to find in Google. But if you want to type the link in, it's videonetworker.blogspot.com and I split the article on telepresence interoperability in eight different parts because of the size of the content and each of them has a separate section. I have a separate section on the reasons for telepresence interoperability; I have a section on the logistical and technological challenges to telepresence interoperability, analysis of the performance of RMX 2000 and the video conferencing manufacturer telepresence server and explanation how the whole test was conducted and what the results were.

So I would encourage everybody who is interested in that information to look at the blog spot, that is the full story, absolutely the full story of the telepresence interoperability.

Scott Whitney: Okay.

Stefan Karapetkov: And another very good link for those of you who are looking for third party independent view of what happened during the test, I would recommend looking at Bob Dixon's presentation that is posted on the Internet2 web page. A simple search in Google for interoperability -- telepresence interoperability is here and Internet2, maybe you can add Internet2 to the search, will take you to this link. And this presentation has a lot of information about the configuration, the test cases, the eight test cases that I mentioned, screenshots from the different test cases and also from the recording that we did on the RSS 2000. It also has comments and recommendations to the different vendors how to improve telepresence interoperability.

Scott Whitney: Very good. Hey, Stefan, thanks very much for joining us in the show today.

Stefan Karapetkov: Thank you very much for inviting me, Scott.

Scott Whitney: You are welcome. And also to the person listening right now, thank you. Please visit PolycomOnDemand.com for links to our other shows and again, feel free to reach out to us via email at podcast@polycom.com. Until our next show, I am your host, Scott Whitney. We'll see you next time.

Telepresence Equipment Interoperability Part V

Scott Whitney: I think you had a blog post that said it's kind of like herding cats.

Stefan Karapetkov: It is exactly the experience we had in the summer of 2009. As you mentioned, we started in July. Throughout July and August we were trying to get participants from different organizations and trying to connect systems from different vendors. And we had some partial successes in July and August but really the breakthrough came in the beginning of September when we kind of aligned everybody, maybe because the people came back from vacation and there was more focus on this effort. But in the beginning of September, we finally had a total of five or six organizations with multiple systems, with many systems participate in this interop test.

Scott Whitney: Now, Stefan, when we spoke prior to this interview, you had mentioned that there were some specific issues with the VIDEO CONFERENCING MANUFACTURER telepresence solution.

Stefan Karapetkov: Yes, that was a good, the interoperability test was a great opportunity for me to experience the performance of this new product. VIDEO CONFERENCING MANUFACTURER announced the telepresence server in early 2009 and it was really positioned as ultimate solution for telepresence system connectivity. So I was very curious to find out what it does and it doesn't do. And what I found out it is actually a 16-port MCU, a fairly small MCU in comparison that allows you to connect multiple telepresence systems and support some additional layouts that allow you to manipulate the images from a multi screen or multi codec telepresence systems. But I didn't find anything that is groundbreaking or particularly interesting about this product. In fact we did some back to back interoperability tests running on the VIDEO CONFERENCING MANUFACTURER telepresence server and also on the RMX 2000 from Polycom in combination with so called MLA application that creates additional layouts on RMX. And the findings are really that RMX was more reliable, more scalable and it was more flexible because it was able to handle not just telepresence system but any kind of systems and it wasn't a specialized server just specifically for telepresence. From a quality perspective, we captured some video recordings, video clips and still images that can prove easily that RMX could handle telepresence layout much better than the VIDEO CONFERENCING MANUFACTURER telepresence server.

I think that the bottom line here is that I don't see the need for a specialized telepresence server product. I think a regular conference server like RMX 2000 or the new RMX 4000 with a free application like the MLA can do the job much better than designing a separate hardware product creating a separate skew and trying to sell an additional networking component to customers.

Scott Whitney: Okay. So after all has been said and done, the testing culminated in some kind of public forum, yeah?

Stefan Karapetkov: On October 6, 2009, we had series of interoperability demos at the Internet2 conference. We ran the test three times in a row. We had a session in the morning, then we had another one at lunch and another one in the afternoon. In every session, we demonstrated eight interoperability scenarios that included systems from Polycom, VIDEO CONFERENCING MANUFACTURER, LifeSize and included conference servers from Polycom; that's the RMX 2000 as well as the VIDEO CONFERENCING MANUFACTURER telepresence server.

Now, we try to connect all the systems to the Polycom RMX 2000. However, there is a problem with the VIDEO CONFERENCING MANUFACTURER system; it doesn't really allow you to connect directly. So you have to go through a VIDEO CONFERENCING MANUFACTURER telepresence server to get the full image quality and that's the proprietary element in the VIDEO CONFERENCING MANUFACTURER solution. And anyway we ended up with connecting the RMX 2000 and the VIDEO CONFERENCING MANUFACTURER telepresence server and then we had part of the systems connected to RMX 2000 and another part connected to the VIDEO CONFERENCING MANUFACTURER telepresence server. The system that we had on site in San Antonio, Texas was a TPX 306 from Polycom and that system performed very well; we had absolutely no glitches, we had perfect bandwidth and perfect network provided by Internet2. One of the benefits of doing this demo at the Internet2 event is that they are bringing 10 gigabit per second link to the site. So we had absolutely no issues with packet loss, jitter or any other networking issues. We had very good video quality and we connect it usually at 4 megabit per second per screen, which is a total of 12 megabit per second for the TPX system.

On the eight scenario, I can always say we stayed away from doing point to point calls because that is pretty straightforward. We know that Polycom and LifeSize can connect point to point. But when you connect to VIDEO CONFERENCING MANUFACTURER for example, you get a decreased video quality. As I mentioned, you have to go for the VIDEO CONFERENCING MANUFACTURER telepresence server to get the full quality.

In the multipoint scenarios, when we had the systems connected to RMX and the VIDEO CONFERENCING MANUFACTURER telepresence server, we run a series of layouts, we tried layouts that work best and used a (real state) of the screens to the maximum extent and that's where we actually found out that the MLA application on RMX 2000 delivers better utilization of the screen and the (real state) of the TPX screen. We were able to create layouts that cover 100% of the screen while when we are using VIDEO CONFERENCING MANUFACTURER telepresence server, we could only get portions of the screen used and some of the portions were completely black. And the reason for that is that the VIDEO CONFERENCING MANUFACTURER telepresence server automates the whole process and it doesn't give you any flexibility to adjust the layouts and automation is good and we have automation in MLA as well. However, it has to give you some additional flexibility to adjust layouts for better utilization of the display. So in this case, RMX 2000 clearly provided better layout control than the VIDEO CONFERENCING MANUFACTURER telepresence server.

Scott Whitney: So then, Stefan, after all of this testing, what finally were the results?

Stefan Karapetkov: The results were that we had the first successful multivendor telepresence interoperability test and demo. That was the first time we used multiple networks. We used the Internet2 network, Commodity Internet, which we call Internet1 from time to time, Polycom's corporate network, VIDEO CONFERENCING MANUFACTURER's corporate network and also the IBM's network. So we connected several different networks, systems from several vendors and that was -- worked very well, very successful and we had interoperability on the networking level, on system level and also, as I mentioned, on a layout level we were able to create this special layouts to provide the best representation of the systems.

Telepresence Equipment Interoperability Part IV

Another participant in this test was the OARnet; that's the Ohio Academic Research Network. They provide networking and support services for the Ohio high education, research in government and medical community. The results of this test were presented at the Internet2 conference in San Antonio, Texas, that was on October 6, 2009. For those of you who do not know Internet2, it's an organization that manages the next generation high speed IP network that connects 200 -- more than 200 U.S. universities and the research institutions.

Actually I have two questions based upon what you said. First of all, I'm assuming that having a third party take the lead on this was probably important, right?

That was very important because there is a certain level of mistrust in the industry. If one company tests something internally and then publishes the results, usually they do not get wider acceptance in the industry. People usually say, "No, we don't know exactly how you test it and what criteria you used."

So really a third party test was something that we were looking for and we are happy that Ohio State and OARnet agreed to take the leadership on this and coordinate this test and present the results in a very unbiased and professional manner.

Well, they weres not involved from the very beginning. They did not even participate in the original session that happened in April. Their system is not really a system, it is a service that they provide and they have absolutely no way to interoperate with the outside world without the gateway and they realized that that this a fundamental issue with their system. They did not even try to participate in this interop test. they on the other hand was very enthusiastic originally. They actually participated in the April session, and they said, "Yes, we are going to come, we are going to participate and they actually pulled back shortly before we started testing, very unexpectedly they basically pulled off all of their people and told us that they are not going to participate and that was a disappointed and a surprise for some of the people in the community, it wasn't a surprise to me because I know that the they system has proprietary mechanisms that make interoperability very difficult.

Now I have to imagine just based upon what you are saying now, I have to imagine that there were some pretty significant, you know, challenges in putting a test like this together.

The challenges are enormous and that's the reason why for several years the industry has been trying to do that and that was really the first time that we managed to pull the resources and people to get it done. The first challenge is that the technological challenge. Some of the vendors implemented proprietary elements. As I mentioned, theirs is completely proprietary; they has proprietary mechanisms embedded in their system, and it's mainly related to multiplexing, traffic from the different codecs; that is something that is not up to standard and it's very difficult for third party system to connect to a their system.

They, as I mentioned, has some proprietary extensions that make a telepresence system only connect at full quality through the telepresence server, their telepresence server and the additional proprietary elements that are present in the different systems provided by the telepresence vendors. So really that's the technological part of the issue. But even more importantly there is a huge logistical challenge to a telepresence interoperability. Traditionally video interoperability test or any kind of interoperability tests are done on sites or basically all of the equipment, bring their equipment on a certain location and then we plug it together and we test, we go for the test cases and we figure out what works and what doesn't. Well, if you have a huge telepresence system that comes in six, seven crates on a truck, it's very difficult to get that in a central location and do the test on.

Right, right.

And then some people say, "Well, why don't you test over the IP network?" The problem is that most of this telepresence installations are running on a separate segment of the IP network and it's not a (inaudible) to connect to Internet and then from the Internet to connect to a telepresence system sitting on another network. So that is, the problem is that you have to go for multiple firewalls, you need border controller elements, etcetera, etcetera. So it is really difficult to do that. It is also difficult to find the resources. People and telepresence rooms and make sure that they available at the exact same time so that you can do the test.

To be continued...

To learn more about telepresence equipment interoperability, call 1-800-224-7083, or visit www.ivci.com.

Telepresence Equipment Interoperability Part III

Scott Whitney: Right. Now, as a reminder, Stefan, who are the telepresence vendors that we are talking about here?

Stefan Karapetkov: Well, there are a lot of vendors in this space. The big ones are Polycom with the immersive telepresence solutions, TPX and RPX; Cisco, with the free screen system, CTS-3000; LifeSize with LifeSize Room 200; HP Halo; and TANDBERG with the T3 system.

Scott Whitney: Okay. And Stefan, the types of companies who would normally take advantage of a telepresence environment, they would be what kind of folks?

Stefan Karapetkov: Well, telepresence was developed primarily for business communication and it is used in large enterprises for executive meetings. Telepresence systems remove the distance between headquarter locations and allow executives to communicate quasi face to face across distances. For example, here at Polycom, we are using telepresence rooms in different locations. We have multiple systems installed in New York, Andover, San Jose and now a executive briefing center in Santa Clara. And it's not just for executive communication, we have regular business meetings over telepresence systems and we actually enjoy the flexibility of this technology and the fact that we don't need to travel such long distances to have a face-to-face meeting.

Service providers are getting very interested in telepresence today. AT&T, Verizon, BT and Orange have developed telepresence related services and we have a bunch of smaller companies like GlobePoint, iformata and Easynet, also deliver what we call video network operating services or VNOC services.

Scott Whitney: Now how would I go about connecting a telepresence system that isn't completely standards based to the outside world?

Stefan Karapetkov: Well, the only solution to connect the proprietary telepresence system with the outside world is for a gateway and gateways are okay, but they have three main disadvantages. The first one is that they decrease video and audio quality. For example, telepresence today uses 720p high definition video. Some systems like Polycom TPX and RPX use 1080p and that's pretty much the bar that is set for this kind of interaction and this kind of application.

Now, when you go for a gateway, you immediately drop their quality to something below that. In the case of Cisco, you go down to what we call CIF or their common intermediate format, and that is a really bad quality that has nothing to do with telepresence. On the audio side, you lose all of the wideband and super wideband audio that you have between telepresence systems and go back to something like G.711, which is the quality of the Public Switch Telephone Network. In terms of delays, a telepresence gateway is an additional box that you put in the communication path and every time you do that, you add additional delay, it can be 50 milliseconds, may be 60 milliseconds. And then you end up with this satellite TV kind of experience, satellite call kind of experience where you cannot really interact freely across the telepresence system.

Scott Whitney: Right.

Stefan Karapetkov: And in addition to that, you have to pay for this gateway. It's not for free, it can be very, very expensive and it's just an additional unnecessary piece of video conferencing equipment in the network that only decreases quality and increases your cost.

Scott Whitney: So then, in trying to determine the interoperability of all these telepresence vendors, Polycom participated in some kind of test, yeah?

Stefan Karapetkov: We participated in a multi-vendor interoperability test that included immersive telepresence systems with multiple codecs from Polycom, TANDBERG and LifeSize. The whole interoperability test was led by the Ohio State University and a gentleman named Bob Dixon took the leadership on this project. He called for interoperability at the last Internet2 meeting in Washington DC; that was in April 2009. And after that, he followed up with me and some other representatives from different vendors in the industry and try to coordinate interoperability test in the summer of 2009.

To be continued...

Telepresence Equipment Interoperability Part II

Scott Whitney: Right. Now, as a reminder, Stefan, who are the telepresence vendors that we are talking about here?

Stefan Karapetkov: Well, there are a lot of vendors in this space. The big ones are Polycom with the immersive telepresence solutions, TPX and RPX Cisco, with the free screen system, CTS-3000;; and TANDBERG with the T3 system.

Scott Whitney: Okay. And Stefan, the types of companies who would normally take advantage of a telepresence environment, they would be what kind of folks?

Stefan Karapetkov: Well, telepresence was developed primarily for business communication and it is used in large enterprises for executive meetings. Telepresence systems remove the distance between headquarter locations and allow executives to communicate quasi face to face across distances. For example, here at Polycom, we are using telepresence rooms in different locations. We have multiple systems installed in New York, Andover, San Jose and now a executive briefing center in Santa Clara. And it's not just for executive communication, we have regular business meetings over telepresence systems and we actually enjoy the flexibility of this technology and the fact that we don't need to travel such long distances to have a face-to-face meeting.

Service providers are getting very interested in telepresence today. AT&T, Verizon, BT and Orange have developed telepresence related services and we have a bunch of smaller companies like GlobePoint, iformata and Easynet, also deliver what we call video network operating services or VNOC services.

Scott Whitney: Now how would I go about connecting a telepresence system that isn't completely standards based to the outside world?

Stefan Karapetkov: Well, the only solution to connect the proprietary telepresence system with the outside world is for a gateway and gateways are okay, but they have three main disadvantages. The first one is that they decrease video and audio quality. For example, telepresence today uses 720p high definition video. Some systems like Polycom TPX and RPX use 1080p and that's pretty much the bar that is set for this kind of interaction and this kind of application.

Now, when you go for a gateway, you immediately drop their quality to something below that. In the case of Cisco, you go down to what we call CIF or their common intermediate format, and that is a really bad quality that has nothing to do with telepresence. On the audio side, you lose all of the wideband and super wideband audio that you have between telepresence systems and go back to something like G.711, which is the quality of the Public Switch Telephone Network. In terms of delays, a telepresence gateway is an additional box that you put in the communication path and every time you do that, you add additional delay, it can be 50 milliseconds, may be 60 milliseconds. And then you end up with this satellite TV kind of experience, satellite call kind of experience where you cannot really interact freely across the telepresence system.

Scott Whitney: Right.

Stefan Karapetkov: And in addition to that, you have to pay for this gateway. It's not for free, it can be very, very expensive and it's just an additional unnecessary piece of equipment in the network that only decreases quality and increases your cost.

Scott Whitney: So then, in trying to determine the interoperability of all these telepresence vendors, Polycom participated in some kind of test, yeah?