[This the fourth and last part of a series of several posts about bandwidth estimation for IP based video calling.]
- Part 1: NetSense 101: Why do we need bandwidth estimation?
- Part 2: NetSense 101: Packet-loss-based Bandwidth Estimation
- Part 3: NetSense 101: Delay-based Bandwidth Estimation
- Part 4: NetSense 101: Q&A (this post)
You should know by now the two techniques of estimating bandwidth: based on packet losses and based on delays (=NetSense). This is what this series is all about.
In this post, I’d like to focus on a few questions I am usually asked about NetSense and provide the answers for them.
Is NetSense interoperable?
Yes it is. Even if only one participant in a video call uses NetSense, there will be an improvement in the experience of the call. In such a case, the person who will enjoy the increased experience will be the one running NetSense – the video he will receive will be of a higher quality.
Do I need to run H.264 or SVC to use NetSense?
No. NetSense doesn’t care about the actual media being sent – it is an algorithm that looks at incoming RTP packets and deduces out of it what the available bandwidth is. How to convey that information and change bitrates in the video encoders is up to the layers on top of NetSense.
Does NetSense work with both audio and video?
NetSense deals with finding available bandwidth from looking at incoming RTP packets. This means it has nothing to do with audio or video directly. We use it for video calls, where NetSense decides on the amount of bandwidth, and then our internal decision making processes will decide how to allocate that bandwidth between the audio, video and data channels of the calls.
I want to reduce bandwidth use. I understood that SVC is what I need. How does that fit with NetSense?
The truth is that SVC increases the bandwidth required for a point-to-point call for the same media quality. SVC is a technology that allows encoding video in layers, and it can be used for increasing the robustness of the video or to build better switching MCUs.
You might be able to use a bandwidth estimation mechanism to decide which layers out of your encoded SVC stream to send, but then – why would you encode all the layers? Better just estimate the bandwidth and tell the encoder dynamically how much bitrate it has available. This is what NetSense does.
Why do I need SVC if I have NetSense then?
The two technologies deal with two separate network problems.
- NetSense deals with congestion: packet loss caused due to too much data being sent
- SVC deals with corruption: packet loss that cannot be solved by reducing bitrate
You need both to get high video quality in all packet loss cases.
Does NetSense use timestamp of rtp?
kexin,
Yes it does. NetSense uses timestamps from the RTP packets as well as other parameters for its operation.
How does NetSense tell the other side what bitrate to use? TMMBR and use of AVPF?
Randell,
NetSense doesn’t really deal with the signaling itself – it just determines the effective bitrate. The signaling indication telling the remote participant how much bitrate to use is indeed done using tools such as AVPF on RTCP, INFO messages on SIP or VideoFastUpdate on H.323 – depending on the capabilities of the call’s participants.
Tsahil
I enjoyed your article of netsense very much very informative. I have a project I am working on at this time involving HD cameras and bandwidth. I am instaling HD cameras into a small Sports Arena and what I hope to achieve is a connection to 6 HD cameras one camera to a court each wired back to the LAN. I was hoping you might be able to take a minute from your very busy schedule to help me understand just what kind of bandwidth I might require if all of the cameras were working at the same time and at 30 frames a second. I appreciate you taking the time to read and reply to my question. Thank you in advance
Craig vicino MCSA
TeamLogicit
cvicino@teamlogicit.com
Craig,
There are a lot of unknown variables in your questions:
* What types of cameras?
* Can you configure the bitrate they produce?
* How accurate are they with this bandwidth?
* Is this the only thing going over on the LAN or does this goes with other existing stuff?
* How does the monitoring/recording system looks like and is wired to the network?
Usually, these are the types of questions that needs to be asked and handled. It is also why today’s managed video conferencing solutions (the pricy enterprise ones) are so damn expensive – some of the purchasing costs go to integrators that do the work of setting up the whole system including the network’s configuration.
I know I haven’t assisted much – you probably need to find an integrator/expert in your area for such things and hire his services for the installation work – you are also dealing here with streaming and not video conferencing (one way video), which is a bit different – so search for someone who handles surveillance camera installations.
This article is informative for managing audio/video calls. But I have doubt regarding the usage of RTCP reports for the bitrate management. Say I send with X rate I come to know that I have less available bandwidth by RTCP report, we will reduce the rate, but after that instance my available bandwidth became more . How will I come to know about the existing bandwidth which is more then my current bitrate, as I will be sending my rate lesser then X as per the report. If there is no loss with what factor can we increase our rate and when.
vishal,
The work of NetSense is done from incoming RTP packets more than from RTCP reports, as it is done on the receiver side.
While NetSense is used for lowering bitrate by estimating bitrate, it can also be used when increasing bitrate – when increasing the bandwidth you’ll see similar effects – delay will start accumulating before you get packet losses – which will in turn mean that you can’t increase the bandwidth and NetSense will be able to lower it back before packet losses occur again.
Here it is mentioned that NetSense senses significant increase or decrease in the delay / packet loss and reacts accordingly., it will re-estimate available bandwidth and act accordingly – without getting to the point of experiencing packet losses/delays. But how we can relate the delays to available bandwidth at the sender , as the factors for delays may not be only the available bandwidth at the sender , there may may other factors .I mean to say if the rate (considering the number of packets and delay between them) at which I send and the rate at which I receive how can I relate it to my available bandwidth.
Vishal,
NetSense works on the receiver and not the sender. The sender knows about the available bandwidth in the path from him to the receiver by way of signaling from the receiver to the sender over the signaling protocol (SIP or H.323) and not inside the media itself.
What is measured is not the rate at which packets are sent, but rather the variance in the rate they are being received, which will occur due to network conditions.
Tsahi