Frequently Asked Questions

We're guessing you've got questions. Here are answers to the ones we can think of. Contact us with your question at TestYourIPVideo@brixnet.com, or call 1-888-BRIXNET, or 978-367-5600.

1. How does TestYourIPVideo.com Work?
2. What's VQI™?
3. Can you explain the VQI scale?
4. I got a VQI score of x. What does that tell me?
5. So, is this a Mean Opinion Score (MOS)?
6. What factors impact end-to-end IP video quality?
7. Do you measure quality the same way for all kinds of IP video applications?
8. What is latency and how does it contribute to my IP video quality?
9. What is jitter and discarded packets and how do they contribute to my IP video quality?
10. What is packet loss and how does it contribute to my IP video quality?
11. What are buffering and rebuffering and how do they contribute to my IP video quality?
12. How do you actually calculate a VQI score?
13. Why do I have measurements in both directions?
14. What's a codec?
15. I really want to find out what kind of performance I'm getting from my live or on demand streaming service. Can I do that?
16. What's RTSP?
17. What is the IP Video Traceroute Analysis I see in my Detailed Test results?
18. What do I use the IP Video Traceroute Analysis for?
19. How is TestYourIPVideo Traceroute different from the traceroute on my computer?
20. How come sometimes I have IP Video Traceroute results and sometimes I don't? These IP Video Traceroute results do not represent my complete call path, what's with that?
21. I like the way I can keep my test scores over time at TestYourVoIP.com. Any plans for that feature for TestYourIPVideo.com?
22. There are no TestYourIPVideo.com test points in my area (or country)! How come?
23. How come my web browser is acting weird?
24. I don't have Java installed. What now?

1.	How does TestYourIPVideo.com Work? TestYourIPVideo.com is supported by a video performance management system from EXFO Service Assurance (formerly Brix Networks). The Brix System consists of distributed test points called Verifiers that communicate with, and are managed by, a centralized server application called BrixWorx. We installed appliance-based Verifiers, that act like other video endpoints, in the network in locations such as Boston and London. The Java applet on your PC initiates a video transaction using the SIP setup protocol and emulating the MPG-4 codec. The Verifier establishes the session and then measures the quality of the interactive session. BrixWorx assembles all of the test results and provides you with the nifty graphs and tables you see when your test is completed.
2.	What's VQI™? VQI stands for Video Quality Index. The VQI is an objective quality measurement for Video over IP networks and applications.
3.	Can you explain the VQI scale? The VQI is measured on a scale of 1-5. Lower scores mean you're more likely to be disappointed in the IP video quality you receive. Higher scores mean that you're more likely to be satisfied with the IP video quality you receive. Generally speaking, everyone with scores in the range of 1-2 will experience significantly degraded IP video quality. Scores in the mid range of 2-4 indicate moderate network impairments, and most users will experience some IP video quality problems ranging from blurriness, blockiness (or tiling), or IP video that is out of synch with the audio. How dissatisfied users with mid-range scores are, again, depends on the quality of their endpoints. Typically, all users achieving scores from 4-5, reflecting few network impairments, experience good IP video quality.
4.	I got a VQI score of x. What does that tell me? Your VQI score tells you how significant an impact network impairments had on your IP video transaction. The higher the score, the less impact the network had on your perceived network quality. Lower scores indicate increasing network problems and an increasing likelihood that you are not going to like what you see. Because some IP video endpoints do a better job than others at masking network impairments, we can't tell you exactly what your IP video will look like when you view it. But we can help you and your service provider determine if IP video quality problems are caused by network performance or whether they're more likely related to your choice of endpoint or codec. The best way to use VQI is to baseline your typical performance by visiting TestYourIPVideo.com several times. When you receive a score in the future, you'll know whether it is typical or atypical for you.
5.	So, is this a Mean Opinion Score (MOS)? The VQI is designed specifically to measure IP video quality while the MOS was developed for voice quality. Conceptually though, the two are similar - each is a single number that incorporates and quantifies the impact of the most important quality-impacting factors.
6.	What factors impact end-to-end IP video quality? There are three factors that contribute to the quality of Video over IP services: Network transmission quality Endpoint capability Codec used to compress the IP video for transmission For network-based IP video, by far, the most important impact on quality is the quality of the network transmitting the IP video. TestYourIPVideo.com addresses this IP video quality factor specifically and we will talk most about it. Before we move on though, let's address the other two. First, what's an IP video endpoint? Think of the thing on your desk or in your office that you see the video from - for example, it could be an IP video conferencing station, a video-phone, or the video player on your PC. The manufacturers of IP video endpoints all implement different and often proprietary IP video decoding and rendering mechanisms that allow them to mask network impairments from IP video viewers. For example, if a video packet/frame is lost, the endpoint may display the contents of the last packet it correctly received. Viewers are less likely to notice the loss of that information if the endpoint shows something rather than a blank space. What this means is that network impairments that make endpoint 1 sputter and choke might not be noticed by endpoint 2. It's like comparing apples to oranges. The fact that each endpoint manufacturer uses their own clever means for hiding network problems makes it next to impossible to measure the endpoint impact in an objective measurement like the VQI. Similarly, the implementation of a given codec may also perform quite differently in different vendors' systems. This makes measurement and categorization of the impact of the codec impact difficult, again, because it varies from system to system.
7.	Do you measure quality the same way for all kinds of IP video applications? Excellent question! Broadly speaking, there are two types of IP video applications - interactive and streaming - and there are some differences in how quality is measured for each. Interactive applications are those like IP video telephony, chat, gaming, and conferencing and require the real-time participation of you and whomever you're interacting with. Streaming applications include live, broadcast, and on-demand IP video. With streaming applications, you may be able to control how you see the content, for example, pausing it while you run to the kitchen for a snack, but ultimately, there is no interaction. You can either view the content or not. Interactive IP video applications rely on two-way "conversations" - the transmission of IP video from you to the party you're communicating with and transmission of IP video from them to you. Because it's important to understand the quality of the content you're sending and receiving, TestYourIPVideo measures network impairments and calculates a VQI in both directions too. For interactive applications, the most important quality-impacting factors to consider are latency, packet discards due to network jitter, and lost packets. For streaming applications, quality is all about how well you can see and hear what you're receiving. The most important quality-impacting factors to consider are buffering/rebuffering attempts, packet discards due to network jitter, and lost packets. This is a long-winded way to say that we calculate VQI in an application-specific way. In the initial version of TestYourIPVideo.com, we've focused on measuring the performance of interactive IP video applications, but will be adding a streaming-specific test soon.
8.	What is latency and how does it contribute to my IP video quality? Latency is a measure of delay in IP video transmission. TestYourIPVideo.com measures both round trip and one-way delay. One-way delay refers to the time it takes for information leaving point A to arrive at point B. While not used in the VQI calculation, one-way delay nevertheless is important in helping to diagnose latency-related network problems. Round trip delay measures the time it takes between when information leaves point A to when a response is returned from point B. Round-trip latency affects the dynamics of an interaction and is used in the VQI calculation for interactive IP video applications. Round trip delay has only an indirect affect on the quality of streaming IP video applications and, therefore, is not used to calculate the VQI for streaming applications. Here is an example of the impact of latency on an interactive IP video session. If during an IP video conference, party A nods in agreement to party B's question "Do you want to see my vacation pictures?" - you can think of the round trip latency as the time it took from the point when A nods to when B sees the nod and puts up the first picture. The one-way latency is the time it took from the point when A notes to when B sees the nod. Obviously, the longer the latency, the longer B is kept wondering whether A wants to see his pictures and A is kept wondering why B doesn't just get on with the slide show! Higher latencies tend to interfere with the natural flow of a two-way interaction.
9.	What is jitter and discarded packets and how do they contribute to my IP video quality? Jitter is a measure of the variability of latency in the network and affects another quality factor - discarded packets. IP Video applications must replay video packets in the same order and with the same timing they were transmitted. If you're watching a movie, you want to see the frame where the hero gets injured and falls from his horse before you see the frame of the riderless horse galloping off into the sunset! However, in typical networks, jitter causes packets to arrive at their destination with different timing and possibly in a different order than they were sent - some arrive faster and some slower than they should. To correct for the effects of jitter, IP video endpoints collect packets in a buffer and put them back together with the proper timing and order before playing them to the receiving user. When the buffer gets full, arriving video packets will be dropped and never played - these packets are called discarded packets. Why not have a very long jitter buffer so that no packets will have to be discarded? A tempting but impractical solution for live streaming and interactive IP video applications. The act of processing the buffer itself adds latency to the play back process, and we've already discussed the negative impact latency can have on interactive IP video sessions. There's a similar problem for live streaming IP video - when a friend calls to ask "Did you see that touchdown?!", no one wants to admit, "What touchdown?" Highly inconsistent jitter as well as values in excess of 50 ms can cause increased latency and higher rates of discarded packets, resulting in annoying two-way interactions, and blurry or blocky IP video.
10.	What is packet loss and how does it contribute to my IP video quality? Just like discarded packets, users also experience lost packets as bits of the video that are missing, resulting in blurry or blocky IP video. Lost packets are those that are dropped by network routers and switches due to congestion or in response to priority queuing settings or those that are discarded by the jitter buffer. While knowing the average packet loss for an IP video session gives you an overall sense for the quality of the session, it doesn't tell the whole story. This is because not all packet loss is created equal. In fact, there are two kinds of packet loss: random and bursty. Imagine two IP video sessions each with average two (2) percent packet loss. Session A loses two in every 100 packets over the entire session (random loss) while Session B loses all of the packets in two clumps at the beginning and the end of the session (bursty loss). Many IP video endpoints can mask the effects of small amounts of random packet loss, however, most are unable to successfully hide the effects of modest bursty loss.
11.	What are buffering and rebuffering and how do they contribute to my IP video quality? The effects of buffering and rebuffering can significantly impact the quality of streaming video applications. To ensure that there is always IP video data available to play and that it will play smoothly and continuously, a portion of the IP video content gets copied into a buffer on your PC. As copied content gets played, the buffer gets replenished with new content. In a perfect world this all works smoothly. On imperfect networks, however, the buffer can become exhausted. When this happens, the player pauses playback to collect more IP video data. This phenomenon is called rebuffering. When rebuffering happens, you know it because your IP video freezes until rebuffering has completed and play is resumed. Here's an analogy to help you think about this. Think of the buffer as your kitchen sink, the water coming from the faucet as the IP video you're receiving from the network, and the water going down the drain as the IP video you are playing (watching). In order for you to start watching the IP video, the sink must first be full. The process of filling the sink is analogous to the initial buffering - when you press play and then wait for the IP video to start. If the water pressure is low, it will take longer to fill the sink. That is, if you have insufficient network bandwidth, you will have a longer wait before your IP video starts playing. Depending on its length, the initial buffering process can be hardly noticeable or a significant quality impairment. Now, if the faucet is supplying water to the sink at the same rate you are draining it, there will always be water in the sink. That is, if the network can supply IP video at the same (or greater) rate that you are playing it at, there will always be IP video to play and all is well. But...if the faucet stops supplying water (loses packets) or can't keep up (latency-related congestion), you'll run out of water (IP video). When this happens, there's no more water to be drained and the sink must be filled again. This process of refilling the sink is called rebuffering. And unlike the initial buffering, rebuffering always has a significant impact on IP video quality. Who wants to watch an IP video clip or movie that freezes every 10 seconds!
12.	How do you actually calculate a VQI score? Every IP video transaction starts with a score of 5. Each of the quality factors - latency, packet discards and lost packets for interactive applications; and packet discards and lost packets and rebuffering events for streaming applications - can degrade the score. For interactive applications, as round trip latencies increase, the VQI value is degraded. Packet loss and discards are treated the same for both applications. The VQI is degraded by the overall percentage of packet loss, each burst loss event, and the length of each burst loss event in relation to the length of the overall IP video session. For streaming applications, the VQI reflects both the impact of buffering and rebuffering events. The VQI is degraded if it takes longer to display the first IP video packet than the time allotted for initial buffering, for each rebuffering event, and the length of each event in relation to the initial buffer time. For each VQI quality factor, repeated events (e.g. multiple burst losses or multiple rebuffers) and increments above an acceptable threshold (e.g. for latency and packet loss values), cause a non-linear degradation in the final VQI score.
13.	Why do I have measurements in both directions? Because interactive IP video implies a two-way transaction, we measure the performance in two directions - from you to the test location and from the test location to you. This is important because upstream and downstream broadband bandwidth are often different, with more downstream bandwidth than upstream. It's also typical for traffic to travel along a different (asymmetric) path from point A to point B than it does when traveling back from B to A.
14.	What's a codec? Codec is an acronym for COder/DECoder. The codec at the sending end compresses (Codes) the IP video signal for transmission over the network. The codec at the receiving end decompresses (Decodes) the signal. There are many types of IP video codecs, but each has the following consequences on IP video quality: Compression results in loss of IP video quality - frame rate and picture resolution Processes of compression and decompression add latency to the IP video transmission process for interactive or live IP video applications
15.	I really want to find out what kind of performance I'm getting from my live or on demand streaming service. Can I do that? Right, in order to really test streaming performance, you want to test to the IP video server itself. We'll be adding that capability shortly to TestYourIPVideo.com. You will be able to measure the availability, response time, and overall performance of an RTSP-compliant IP video server through the simulation of session setup, play, and teardown transactions.
16.	What's RTSP? It's all about the acronyms! RTSP stands for Real Time Streaming Protocol. RTSP is a standard that defines how clients control a streaming media server through commands like "play" and "rewind." You hear about RTSP in connection with on-demand IP video applications. The IETF (Internet Engineering Task Force) standards organization developed the RTSP standard and published it in 1998 as RFC 2326.
17.	What is the IP Video Traceroute Analysis I see in my Detailed Test results? When you establish an IP video session over the Internet or other IP network, the packets in your session don't leave your endpoint or computer and immediately arrive at your intended destination. Instead, the packets often travel between multiple "hops" - Internet routers or other host computers - on the way to their destination. The patent-pending TestYourIPVideo Traceroute tells you what path your RTP call packets took through the network and how long it took to arrive at each hop. Specifically, we test and chart the path from the TestYourIPVideo Verifier test point you selected back to you. Sometimes, an intermediate hop does not support traceroute queries. For example, in a typical home network, the router may not respond to the Traceroute queries. In this case, the TestYourIPVideo Traceroute analysis will display each hop your call traverses through the Internet and to your broadband provider, but cannot show your home router. Generally, unless your PC has its own public IP address, it will not show up in the Traceroute analysis. The left hand side of the graph (Y-axis) lists the name of each hop in your call path. The X-axis, measured in milliseconds, displays how long it took to reach each hop. A longer line means it took more time to reach that hop.
18.	What do I use the IP Video Traceroute Analysis for? The TestYourIPVideo Traceroute path and timing information can be very helpful in diagnosing where problems are occurring. If you're having problems with your IP video or broadband service, be sure to send your TestYourIPVideo Traceroute Analysis to your service provider. Unless you're having trouble, you don't really need to check the Traceroute results on every test run. So we don't show the results by default. Click on the button next to the IP Video Traceroute Analysis title to expand and view your Traceroute results.
19.	How is TestYourIPVideo Traceroute different from the traceroute on my computer? Traceroute is a utility available on most computers. It tells you what path a data packet takes through the network and how long it takes to arrive at each hop. The big difference? Your typical traceroute function is telling you how data packets are being routed not video packets. In many of today's networks, video packets are prioritized and routed differently from regular data packets. Using a generic traceroute function produces incorrect and misleading results.
20.	How come sometimes I have IP Video Traceroute results and sometimes I don't? These IP Video Traceroute results do not represent my complete call path, what's with that? A couple of things to keep in mind: The process of completing an IP Video Traceroute takes some time -- each hop has to be identified, contacted and respond back. It may be the case that you were just too quick and none (or only some) of the final results were in. Give it another 30 seconds and check again. As we discussed above, some intermediate hops cannot or choose not to respond to our IP Video Traceroute queries. When this happens, we still report as much of the path as we can, but you might see holes or not find a hop that you expect.
21.	I like the way I can keep my test scores over time at TestYourVoIP.com. Any plans for that feature for TestYourIPVideo.com? Absolutely! We will be adding support for historical test scores shortly. This feature will make it easy for you to baseline your IP video performance and then identify abnormally poor performances when they occur.
22.	There are no TestYourIPVideo.com test points in my area (or country)! How come? We're always looking for new locations for our Verifiers (test points). Email us and let us know you want one near you. Be sure to tell us what country you're in and what city is closest to you.
23.	How come my web browser is acting weird? TestYourIPVideo.com is developed and tested on the following platforms. If you think your browser is behaving oddly or locking up, make sure you have the latest version of one of these: Special note to Firefox users: the popular "AdBlock" browser extension can hangs Firefox when you try to run the TestYourIPVideo tests using older versions of the Java JRE. Make sure you are running the latest Java JRE Version 5 - this version works around the AdBlock problem.
24.	I don't have Java installed. What now? The Java applet we use at TestYourIPVideo.com requires Java Virtual Machine (JVM) version 1.4 or higher to be installed. If you don't have a JVM installed, or are running an older version, we'll give you the option to install it before we test your VQI. The installation takes a couple of minutes, but you only have to do it once.

Back to Home >>