Challenge Overview
The Fog recorder application is a C++ application that allows a user to schedule recordings for TV shows and record live TV. We use this project to test certain functionality of client applications, which are external to just the recorder.
The recorder is a Mac application that can be opened and run in XCode, and it includes Makefiles that can be used on Linux, and there are also ways to build for Windows.
This challenge will implement some tests and document changes made to a specific class that encompasses an automatic bitrate switcher. This code is complex and has changed quite a bit, and it is going to go to a huge number of devices shortly, so we want to make sure we fully test and understand the most recent fixes.
VERSION
We maintain two separate branches of the codebase for this project. This code challenge applies to master. Do not use the new_build branch.
CODE
The existing code is here:
https://gitlab.com/hercules-fog/Fog-CLI/
A link will be provided in the forum where you will be able to get access.
Make sure to use the "master" branch!
Linux
For this challenge, we will target Linux for compilation and unit testing, since that will be the nearest to the deployment environment of the actual production app.
Submission
Your submission to OR should be a Git patch file that can be applied to see the fixes. Here is documentation on how to generate a Git patch file:
https://ariejan.net/2009/10/26/how-to-create-and-apply-a-patch-with-git/
Requirements
We have implemented a number of changes to the application recently, to deal with automatic bitrate switching when network conditions change, particularly to the ABRManager class. This challenge will implement tests and documentation for the changes to the ABRManager class at commit hash e1debfd7ddf5fc7420f449af6cae3abab577ee5f vs the current commit hash of c5ed76c216420c8954c551d5b837f113164cae4b.
For each change, we need:
1. A unit test proving that the change doesn't break anything. If a unit test isn't feasible, we need to ensure we document a way to at least manually test the code.
2. Documentation of at least a paragraph describing the change and why it was a good change
Graph generation:
To help show the improvement to the original algorithm, we want to add the ability, through a small program or script, to generate graphs based on the log output of the Fog client before the changes and the Fog client after. Below is a description of what changes were made and what the observations should be. We want to ensure that we have a way to graphically show to the client how these changes affect the performance of the app for the better. You can recommend Linux libraries to use for bandwidth throttling to test the switching.
Please target Linux for this generation.
In summation, what we are really looking for here is a graph generated based on the logs that shows the current bitrate through time, with automated throttling applied and removed at the same point in each recording. We want to be able to compare these to show that our new implementation ramps up more quickly and stays at a higher bitrate (which is preferred), and that it ramps down more quickly when needed.
The original bitrate switching improvement uses level shift and outlier detection. Decreasing the bitrate is done based on the sink buffer length. In original player code the sink buffer length is how many miliseconds of video we have buffered. Fog uses 4*targetDuration - (the number of seconds of video currently being downloaded) as the sink buffer length. In simplification, the bandwidth tracker algorithm decreases the bitrate if the sink buffer is too small. The bandwidth measurements are only used when considering increasing the download bitrate. That is, if the sink buffer is large enough, and we consistently measure that we have enough network bandwidth, we try increasing the bitrate.
With the recent changes you should be able to observe this behaviour:
Observe in the logs (fog standard output) when the Level shift and outlier detection works. There should be lines like
level shift: 2144600, 2239702, 2306102, 2382648, 2382648, | 1491369, 1491369
outliers: 2200496, 2229564, 2048783, 2351722, <3113618>, 2545440,
This means that Fog will discard the measurements 2144600, 2239702, 2306102, 2382648, 2382648 in the first case, and 3113618 in the second case.
* Observe how when you disable bandwidth throttling, fog detects a level shift, and robustly switches to a higher bitrate stream.
* Observe that when you enable bandwidth throttling, fog robustly switches to a lower bitrate stream.
* Observe that for fog configured for MODERATE bitrate switching policy, Fog does not immediately go to the lowest bitrate, and instead robustly uses the initially chosen bitrate.
* Observe how Fog bases the choice of initial bitrate of a TSB recording on the bandwidth of the previous TSB recording that was being played. That is:
* Configure Fog for moderate bitrate switching policy.
* Start a TSB recording, allow the bitrate to stabilize.
* Stop the recording, start a new TSB recording
* Observe how Fog bases the choice of initial bitrate used based on the bandwidth that was availiable in the previous TSB recording.