A Synthetic ABR Lab Exercise

The following is a step by step lab exercise to examine ABR – Adaptive Bit Rate used in modern video content delivery. I won’t explain ABR here – you can read about ABR and what it is, and how it works here in a recent post.

We will analyze a synthetic but realistic packet capture that demonstrates Adaptive Bitrate Streaming (ABR) over HTTP. You will learn how to identify playlist requests, media segment downloads, bitrate changes, and the burst-and-idle traffic pattern that is typical of segmented video delivery.

Lab Preparation

You are going to need a few things to follow along:

1. Wireshark installed on your Windows, Linux, or MAC. It is free, and you can find it here.
2. You need to download the synthetic PCAP file by clicking here.
3. I would also suggest using my Better Default profile that you can find here.

Once you have those three things, we can get started.

Step 1:

Open the capture file provided in Wireshark with the Better Default profile selected. Your screen should look like this:

Step 2

Adaptive Bitrate Streaming works by encoding the same video at multiple quality levels, such as 480p, 720p, and 1080p. The client first retrieves a master playlist, then selects a variant playlist, and finally requests individual media segments. As conditions change, the client may request segments from a lower or higher bitrate stream.

Because this lab capture uses HTTP instead of HTTPS, you can clearly see the ABR mechanics in Wireshark.

Let’s quickly get an Initial View of the Traffic by scrolling through the packet list pane. Note the protocol column and you will confirm that the traffic is primarily HTTP and TCP. Notice that this capture is relatively clean and focused.

Step 3

OK let’s identify the initial playlist activity. In the display filter bar, enter: ‘http’ to filter for just the HTTP packets:

Select Frame 4 and expand the HTTP protocol in the packet contents pane:

This is the first request for a master playlist file. The file may have a name such as master.m3u8 or something similar. The master playlist is the top-level ABR control file. It points the client to available bitrate or resolution variants. The master playlist tells the client which stream variants are available so it can choose the appropriate quality.

Step 4

We can identify variant playlist requests by looking at the HTTP GET requests that follow. Look for additional playlist files that represent different stream qualities. These may include names or path elements showing resolution or bitrate, such as: 480p, 720p, and 1080p. Select frame 18:

Notice these type requests indicate separate quality levels. These are variant playlists or direct segment requests tied to a given bitrate ladder. Also note the URI that points to the program index – now since we are synthetic here, there is no such URI. However, we do see that the synthetic capture includes requests corresponding to multiple quality levels, including 720p, 480p, and 1080p.

Step 5

OK – let’s identify Media Segment Requests. Stay filtered on HTTP. Look for repeated GET requests for segment files. These may use file extensions such as: .ts or .m4s or .mp4 or similar segment-oriented names. What you are looking for is a repeating pattern of small object requests instead of one large continuous file transfer. Here is one example in the capture:

Instead of one large file, the client requests many small segments, which allows the player to adapt quality from one segment to the next.

Step 6

Can we track the order of the segmented qualities? The answer is yes assuming nothing is encrypted, of course. Luckily this synthetic capture is not encrypted.

There are several way to accomplish finding the answer. Let’s clear the HTTP filter and jump up to the top of the packet capture. One of the things that stands out is that everything is transported over TCP, not UDP. Just a note here that if QUIC was being used, we would see the segments being transported over UDP.

Since this capture is the TCP variant, with frame #1 selected, click on Analyze> Follow> TCP Stream.

You will get a pop up window that looks like this:

Now if you scroll down through this window – the red traffic is from the client and the blue traffic is the responses from the server. You can click on any red or blue section and in the background, Wireshark will select the actual frame. You will notice the ABR method:

• First, the client gets all the available resolutions
• Second the client gets the program indexes. It starts with the 720p index, then the 480p, and then the 1080p.
• Then the client picks one to start in frame 22. You will notice that is starts with the 720p and the server sends the 720p segments in frame 24. Quite a few segments!!
• In frame 206, the client requests more 720p. Keep scrolling.
• In frame 400 we have a change! The client switches to 480p!
• The client once again request more 480p in frame 482.
• Then is frame 561, we have another change – the client switches – this time requesting 1080p!

We have therefore observed that this synthetic capture was built to show a switch from 720p to 480p and later up to 1080p. We also have found a way to “prove” the bitrate switch by locating where the client has changed the resolutions.

Another thing that should stand out to you now is that ABR is not a transport protocol, it is a method that uses standard transport protocols such as HTTP over TCP.

Step 7

If you have been to my Wireshark classes, you know I love Wireshark’s statistics. So let’s use Statistics to observe the burst behavior.

Close the TCP Stream pop-up window and return to the main Wireshark screen, remove any filter, and jump to the 1st frame in the capture.

Now, go to Statistics> Conversations and you will get the following pop-up. Make sure the TCP tab is selected:

We see there is one TCP conversation in this capture.

Select that conversation by clicking once on it (it will be highlighted in light blue). Then select (on the left side) the I/O Graphs button. You will get this pop-up window:

Here is what we notice: ABR typically creates a burst-and-idle pattern, then it downloads a segment, then it pauses while the player consumes buffered media and then we repeat.

Since we switched from 720 to 480 to 1080, we see the size of the bursts changing, therefore putting more load on the network.

If you move your mouse over the graph you will see little dots appear on the graph – look for the information regarding each dot in the lower left part of the window. Things like which frame, and how much time passes between those frames.

Step 10

Let’s close those windows and jump back to the top of the capture. Another graph we can look at is Statistics> TCP Stream Graphs> Time sequence (Stevens) and you should get this pop up:

We can see the changes in TCP behavior transporting the three different segment rates. Higher bitrate or higher resolution video segments contain more data and therefore require larger transfers.

Special note: Even if the URIs were encrypted, the burst pattern, flow timing, object sizes, and timing of transfers could still suggest segmented adaptive streaming.

Awesome! I hope you enjoyed this exploration of ABR.

Additional Wireshark Filters

Feel free to try these on the packet capture.

• http
• tcp
• http.request
• http.response

Let’s say you wanted to isolate segment requests by name, use filters based on what appears in the URI, for example:

• http.request.uri contains “720”
• http.request.uri contains “480”
• http.request.uri contains “1080”

If playlist files use m3u8 naming, try:

• http.request.uri contains “m3u8”

Can You Answer the following Questions?

1. What protocol is used for application delivery in this packet capture?
2. What file identifies the available stream variants?
3. Which video qualities appear in the capture?
4. How can you tell the client is requesting segmented content?
5. What evidence shows the stream switches quality levels?
6. What is the observed order of quality changes?
7. Why is segmented delivery useful for video streaming?
8. Why is this traffic pattern different from a standard file download?
9. Is ABR a Layer 4 transport mechanism or an application-layer behavior?
10. What is the strongest evidence in this capture that ABR is occurring?

Here are the Answers:

1. HTTP
2. The master playlist
3. 720p, 480p, and 1080p
4. Repeated GET requests for separate media segments
5. Segment URIs or paths change to different quality levels
6. 720p, then 480p, then 1080p
7. It allows the player to adapt quality one segment at a time
8. The traffic is bursty and segmented rather than one continuous transfer
9. ABR is an application-layer behavior
10. Multiple playlists or segment sets plus visible quality switching

Summary of the ABR Lab Exercise

This ABR lab exercise demonstrates the essential mechanics of Adaptive Bitrate Streaming in a format that is easy to analyze in Wireshark. By using HTTP instead of HTTPS, the playlist structure, segment naming, and bitrate transitions are visible. Students should leave this lab understanding that ABR is identified primarily by traffic behavior, repeated segment requests, and visible changes in stream quality over time.

---

Comments are welcomed below from registered users.  You can also leave comments at our Discord server. 

If you would like to see more content and articles like this, please support us by clicking the patron link where you will receive free bonus access to courses and more, or simply buying us a cup of coffee!