Understanding Video Bandwidth in Lync 2013
In part one we looked at how to determine Audio Bandwidth in Lync Server 2010 and 2013. In this post we will dig into how to determine how much bandwidth will be consumed with video in the new Lync Server 2013. In Lync Server 2010 this process was pretty straight forward. If we look back to 2010 because of RTVideo codec we had potentially two resolutions that would be used – VGA and CIF. They used a maximum of 610 Kbps and 260 Kbps respectfully. If you were doing Peer to Peer, we also had the potential of HD Video but only if a person went full screen with the video feed. Calculating video bandwidth was as straight forward as the previous article on calculating audio traffic.
In Lync 2013, things get a lot more complicated and hopefully this post will give you some background on why that’s true.
The first reason is the video codec change. The move from RTVideo to H.264 completely changes how we determine the amount of bandwidth that will be consumed and used. Remember this table from the previous post:
http://technet.microsoft.com/en-us/library/jj688118%28v=ocs.15%29.aspx
He were see we have a potential of eight different video resolutions (and three panoramic) and therefore eight potential maximum bandwidth that could be consumed.
The second reason is the addition of the gallery view (standing and sitting row). Here, we have the potential to have up to five active video streams in the client plus a single panoramic view. This means as a consumer of bandwidth the Lync 2013 client has the potential to consume a lot more. Additionally, the client itself can send up to five video streams as well.
Here are the important part of the above TechNet Article:
If video is used, all participants can receive up to five receive video streams and one panoramic (for example, aspect ratio 20:3) video stream. By default the five receive video streams are based on active speaker history but users can also manually select the participants from which they want to receive a video stream.
Each participant that turns on the user’s send video stream will send one or more video streams. Lync 2013 add the capability of sending up to five video streams to optimize the video quality for all the receiving clients. The actual number of video streams being sent is determined by the sender based on CPU capability, available uplink bandwidth, and the number of receiving clients requesting a certain video stream. The most common case is that one H.264 and one RTVideo video stream are being sent in case a legacy client joins the conference. Another common scenario is that several H.264 video streams (for example, with different video resolutions) are sent to accommodate different receiver requests.
So let’s look at an example. What if my Lync Client looks like this:
In this example I’m actively consuming 5 video streams. Now, the trick is to determine what bandwidth is actually being consumed. Here is where the estimation is going to start. When you start the gallery view, the images of each person is fairly small and most likely at 212×160 which means each feed is going to consume a maximum of 250 Kbps or approximately 1250 Kbps. So in addition to me consuming that much, I will also be providing my video stream as well so there would be another 250 Kbps. So we break it down as:
AV/MCU to Client – 1250 Kbps
Client to AV/MCU – 250 Kbps
Total: 1500 Kbps
Keep in mind these are the maximum amounts. At this resolution I could consume/send as little as 15 Kbps per stream. Most likely, it won’t be this low unless we are constrained for bandwidth for some reason but there is the possibility.
Now this is the simplest possible example.
Let’s examine the next scenario.
Here we have “popped” out the video feed and now I can resize my window and create larger thumbnails in the gallery view. When we do this we have the potential for multiple sizes and multiple streams.
So let’s go back to my example from above. Let’s pretend our conference has 10 people and no one has done anything with the size of their video/gallery so each of those 10 people are consuming 1250 Kbps and sending 250 Kbps. Now three people have popped out their video and resized the window so they are no longer at 212×160 but now at 424×320. So these users will now consume five video streams at a maximum of 450 Kbps or 2250 Kbps. Additionally, all clients are going to need to send both the lower 212×160 resolution for the seven people and now the higher 424×320 resolution for the three people – so 250 Kbps + 450 Kbps or another 700 Kbps.
So now all ten clients are sending both the lower and higher resolution stream or 700 Kbps. Seven people are downloading five streams at the lower 1250 Kbps (5 x 250 Kbps) and three people are download five streams at the higher 2250 Kbps (5 x 450 Kbps).
As you can see this gets really complicated. What if one of those three people went from 424×320 to 960×540, we would then suddenly have three streams in play.
So how do we estimate bandwidth? First, it’s important to remember that all of these are the maximum numbers. So we could potentially use something like Call Admission Control or some new conferencing policies to force a lower amount. Second, there is a maximum number of streams and the lowest common denominator always wins. So if you were in a situation where there were many video streams at play and a sixth lower resolution was introduced all of the clients would need to start sending that lower stream and some at the higher level would need to negotiate to a lower resolution. Third, according to sources at Microsoft, the average number of streams is typically less than two per client based on testing. This of course will vary based on your business needs but should reassure you that simple because we can send up to five streams doesn’t mean it’s going to happen all the time. Fourth, if you need to, you can always disable the multiple video streams based on the conferencing policy of the user/site/pool/global.
Hopefully this information will help you understand how to plan for the new conferencing features of Lync Server 2013. In the next post we will discuss how you can control bandwidth in your environment.
Pingback: Understanding Video Bandwidth in Lync 2013
Hello,
I am trying to understand how Lync video works in a conference. Let’s say if I arrange a conference and invite 200 people. Out of these, 100 people are from my internal organization and connecting to the conference over the internal LAN. The other 100 people are external guests from various organizations who will join my conference either through federated Lync clients or over Lync web app.
I configure the conference allowing no-one else to share the video. I share my video with everyone. When all the people in conference are viewing my video, how much bandwidth will I be using to transmit this video to each endpoint? Let’s say video is standard 640×480 VGA. Everyone is viewing my video.
How much bandwidth will be used initially when every one starts my video?
My understanding is that once the video starts, then the subsequent bandwidth usage depends on how much movement is there in my video and only the changed frames are sent over. Am I understanding it right?
Thanks in advance.
Paul – calculating video bandwidth is hard because as you mentioned at the end of the question it depends on the movement in the screen and how much data needs to be sent in the B Frame and P Frame. When it comes to planning, I always assume a middle ground but it’s good to know the top and bottom end. Looking at the video bandwidth chart provided by Microsoft we see H.264 or RTVideo should be between 800 and 450 Kbps. (In 2010 the number was 610 Kbps for planning purposes for the same resolution.)
The internal folks are less worrisome as they most likely are on a wired/wireless environment you control. Assuming there are no WAN’s in play the people you want to be concerned about is the external folks connecting via the Edge.
So at 100 users at 800 Kbps we are talking almost 80 Mb of data to the internet. Now before we all jump off a bridge because that number is very high (which it is) lets keep a few things in mind.
1. This is the high water mark and Microsoft low mark is still a big number of nearly 45 Mb for those 100 users.
2. As you mentioned, unless you are filming a gymnastics routine in the background you most likely will not be pushing that much bandwidth at any given time.
3. Your conference honestly isn’t going to be at 640 x 480. Why?
When you exceed 75 people the Lync client does a few things in the background. It turns off a bunch of items including roster updates, multi-person video and the ability for the presenter to send multi-stream video as well. This means the client essentially drops back to Lync 2010 mode. A single stream from the presenter. The question now is what size is that stream going to be? By default, the client is going to send a 320×240 stream to all clients unless more than 10% of the participants request a larger stream size. How would they do this request, by making the video larger (i.e. full screen) on their client, and frankly end users rarely go to full screen.
Most likely more information than you were looking for but gives you an idea of the complexity of the Lync client when it comes bandwidth planning.
Thanks for the detailed info Richard! Exactly the information I was looking for. Please keep up the great work 🙂
Hi
Great article!! Thank you.
I thought that the Lync MCU was combining and transcoding the video of your peers before send it to you, like a traditional video conference MCU. So the BW doesn’t depend on the number of the peers only on the quality.
But, after reading this post it seems that the Lync MCU is acting more like a H.264 SVC router than a MCU.
Correct. It does absolutely no mixing of video. That is both good and bad. The good is it allows massive scale on hardware. The bad, no combining of video to send a single stream and typically less bandwidth.
Thanks,
Richard
MS needs something like Polycom HighProfile and support GPU hardware acceleration
i have a doubt on Multi party video . if i receive 5 video streams each of 250Kbps during the call, how does this effect CAC settings. Does the CAC see it as 5 video calls?
Kinda, CAC doesn’t see a total number of calls, but rather sees an amount of bandwidth between point A and point B. So in the event of multi-party video. If I have a CAC policy of 700k for Video, than it’s going to try to squeeze all the streams into that small allotment.
What happens with FEC in this case? If one of the stream “consumers” is experiencing drop packets and FEC needs to be enabled, who is adding the redundant packets: the AVMCU or the stream “originator”? How much intelligence is there?
My concern is that the one person on the poorest network will cause all conference participants to receive the redundant FEC packets… like “one for all, all for one” 🙂
There is no FEC for video so it won’t send it. H264 doesn’t need FEC as the concept is kind of built into the codec already. H264 utilizes a GOP or Group of Pictures. So it sends an I Frame (full image) followed by a series of B frames with a few P frames (larger than B frame, smaller than I frame) before another I Frame is sent. So if I lose a packet and only lose a B frame, no big deal, because the change between B frames is small enough most people won’t notice it. Obviously, if I lost an entire GOP, than you see jitter in the image but the purpose of the codec is to prevent those as much as possible.
Hi Richard, could you please tell me if there is any difference between just “pause” video or “leave” vídeo from Lync client to reduce bandwith ?
When I’ve traced this, they are similar but not exactly the same. Essentially when I found was a pause was like putting a call on hold for audio. If you go through the SDP, you will find an:
a=recvonly
So from Client A, if they pause video, they will go into “receive only” which means they are still in the video call so if someone was sending they could receive their stream but not send anything back. Leaving the video call, drops all of the video channel to that client.
OK. Thanks. But, if the sender doesn’t send any vídeo, is there any difference in terms of bandwidth usage? I mean, if, in meeting with many people with no vídeo broadcast (only áudio), everyone pause its vídeo instead of leave them, make any difference in terms of bandwidth ocupation? In other words, if the meeting will not use vídeo, make any difference just pause or leave vídeo? Thanks a lot.
In this situation, it would make no difference at all, bandwidth would be the same.
This may be a dumb question, but in my organization they disable video except for those with cameras (and conference rooms). But that means those without cameras can’t see the video from those with cameras. If they enabled video on everyone (assuming it’s turned on thru a policy for only those with a camera), would that increase the bandwidth substantially? Say I have 10 people and only one has a camera. If all are video enabled, but only viewing one video stream, then the computation is just the one stream, right?