Measuring the Bitrate of a Video Stream

Howdy Pierce

Occasionally we need to measure the bitrate of a particular video stream on the network. Since I have found myself explaining somewhat regularly how to do this with Wireshark, I thought it might be worthwhile to post the instructions here.

In this example I will show how to measure the data rate of a video streamed from The same technique can be used to measure the rate of any network stream. And if you combine this approach with what I outlined in this post, you can measure the bitrate of a stream that is being consumed by an embedded device like an iPad or Blu-ray player.

Here’s what you do:

  1. Start Wireshark and set it to capture all traffic.
  2. Go to the application or website of interest, and start the video playing. Because the video is usually pretty bursty, you will want to average the measurement over an interesting period of time—at least a minute, and probably longer. In the screen shots below, I let my video play for 57 seconds.
  3. After capturing the video for a period of time, stop the Wireshark capture.

You probably captured quite a bit of data, so you need to narrow in to the particular TCP stream(s) in question. In Wireshark, select Statistics > Conversations, and then select the TCP tab. In my case there were 64 different TCP streams captured during the one-minute Wireshark capture. Presumably the stream we want is the one where the largest number of bytes were delivered, so to narrow in this stream, you’ll want to scroll to the right a little and sort the Conversations window by the column “Bytes A ← B”:

Sure enough, one of the streams that we captured saw 14,363,612 bytes transferred from a server to our client. That’s probably the video. Doing a reverse hostname lookup on the server’s IP address gets this:

% host domain name pointer

At this point, there are two ways to determine the bitrate of this particular stream.

The first and easiest way is to scroll the Conversation window to the right. Wireshark is telling me that this particular stream lasted for 42.7 seconds and had an average bitrate of 2.689 Mbps:

This is interesting for a couple of reasons. One: Wow, Amazon is delivering 2.6 Mbps of video to us—that seems really high! (Especially since the content in question was not particularly hard to compress or delivered at stunningly high quality.) Two: I watched roughly 57 seconds of video when performing this capture, but Wireshark is saying that the video was only moving across the network for roughly 43 seconds (the “Duration” column).

Both observations imply that the video was buffered. We know that the 14,363,612 bytes transferred in the capture contained at least enough video for 57 seconds of display. Dividing 14,363,612 by 57 seconds reduces the average bitrate to 2.015 Mbps—and this is a ceiling, because there was probably some unplayed video left in our decoder’s buffer when I stopped the capture.

Which brings us to the second and deeper way to understand the bitrate of a particular stream. To do this, you need to narrow the display filter so that only the TCP stream of interest is shown. The easiest way I know to do this is to select the stream in the Conversations window, and then click the “Follow Stream” button at the bottom. This will do two things: One, it will narrow the display filter in the main window to be exactly what we want. And two, it will bring up a “Follow TCP Stream” window that we don’t need for our purposes. So after clicking “Follow Stream” you should close both the Follow TCP Stream window and also the Conversations window. You should be left with something that looks like this:

Note the display filter—in this case eq 73. That’s an internal Wireshark index. You could equally construct a rule with some AND and OR operators and the IP address and TCP port numbers, but this way we got Wireshark to figure that out for us.

Now for the fun. Select Statistics > IO Graphs. Like most of Wireshark, the window that comes up is both very powerful, and evidently designed by someone with no eye for user interfaces. To make the chart meaningful, you will want to set the Y Axis to “Bits/Tick”, as shown here:

Here you can see when the data transited the network, and it’s awfully interesting. It looks like Amazon is pushing out quick bursts of data, and each burst contains at least 35 seconds worth of encoded video. That first hump in the graph bursts to over 10 Mbps, but since it contains video for at least 35 seconds, the underlying video is encoded at a rate no higher than 1.1 Mbps. Cool!

Related posts:


Cardinal Peak
Learn more about our Audio & Video capabilities.

Dive deeper into our IoT portfolio

Take a look at the clients we have helped.

We’re always looking for top talent, check out our current openings. 

Contact Us

Please fill out the contact form below and our engineering services team will be in touch soon.

We rely on Cardinal Peak for their ability to bolster our patent licensing efforts with in-depth technical guidance. They have deep expertise and they’re easy to work with.
Diego deGarrido Sr. Manager, LSI
Cardinal Peak has a strong technology portfolio that has complemented our own expertise well. They are communicative, drive toward results quickly, and understand the appropriate level of documentation it takes to effectively convey their work. In…
Jason Damori Director of Engineering, Biamp Systems
We asked Cardinal Peak to take ownership for an important subsystem, and they completed a very high quality deliverable on time.
Matt Cowan Chief Scientific Officer, RealD
Cardinal Peak’s personnel worked side-by-side with our own engineers and engineers from other companies on several of our key projects. The Cardinal Peak staff has consistently provided a level of professionalism and technical expertise that we…
Sherisse Hawkins VP Software Development, Time Warner Cable
Cardinal Peak was a natural choice for us. They were able to develop a high-quality product, based in part on open source, and in part on intellectual property they had already developed, all for a very effective price.
Bruce Webber VP Engineering, VBrick
We completely trust Cardinal Peak to advise us on technology strategy, as well as to implement it. They are a dependable partner that ultimately makes us more competitive in the marketplace.
Brian Brown President and CEO, Decatur Electronics
The Cardinal Peak team started quickly and delivered high-quality results, and they worked really well with our own engineering team.
Charles Corbalis VP Engineering, RGB Networks
We found Cardinal Peak’s team to be very knowledgeable about embedded video delivery systems. Their ability to deliver working solutions on time—combined with excellent project management skills—helped bring success not only to the product…
Ralph Schmitt VP, Product Marketing and Engineering, Kustom Signals
Cardinal Peak has provided deep technical insights, and they’ve allowed us to complete some really hard projects quickly. We are big fans of their team.
Scott Garlington VP Engineering, xG Technology
We’ve used Cardinal Peak on several projects. They have a very capable engineering team. They’re a great resource.
Greg Read Senior Program Manager, Symmetricom
Cardinal Peak has proven to be a trusted and flexible partner who has helped Harmonic to deliver reliably on our commitments to our own customers. The team at Cardinal Peak was responsive to our needs and delivered high quality results.
Alex Derecho VP Professional Services, Harmonic
Yonder Music was an excellent collaboration with Cardinal Peak. Combining our experience with the music industry and target music market, with Cardinal Peak’s technical expertise, the product has made the mobile experience of Yonder as powerful as…
Adam Kidron founder and CEO, Yonder Music
The Cardinal Peak team played an invaluable role in helping us get our first Internet of Things product to market quickly. They were up to speed in no time and provided all of the technical expertise we lacked. They interfaced seamlessly with our i…
Kevin Leadford Vice President of Innovation, Acuity Brands Lighting
We asked Cardinal Peak to help us address a number of open items related to programming our systems in production. Their engineers have a wealth of experience in IoT and embedded fields, and they helped us quickly and diligently. I’d definitely…
Ryan Margoles Founder and CTO, notion