[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.