Challenge Overview
Describe what you want to accomplish.
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.
he recorder is a Unix, and it includes Makefiles that can be used on Linux and Mac and there are also ways to build for Windows.
This challenge will focus on a scenarios below and optimising how quickly playback starts when a new recording is initiated.
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 or Mac for compilation and unit testing, since that will be the nearest to the deployment environment of the actual production app. You can also use the Windows build environment, but note that your changes will be reviewed and tested in either Linux or MacOS.
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/
We will target Git commit hash ee934e7b9905b27e7f3696f9167a2763e63289c1
Requirement 1
The current Fog implementation is used in an embedded environment, specifically the "/tsb" endpoint of the API. A sample URL would like like this, where "192.168.86.31" is the address of the Fog server, and http://link.po.ccp.xcal.tv/s/ofHU/4hWDCVC_7W8J4097gubuBEHG_1PAYL10 is the link to the live manifest that will be recorded and played back through Fog.http://192.168.86.31:9080/tsb?clientId=FogCodeChallenge&recordedUrl=http:%2F%2Flink.po.ccp.xcal.tv%2Fs%2FofHU%2F4hWDCVC_7W8J4097gubuBEHG_1PAYL10
The embedded system will make a request like this, and that tells Fog to:
1. Start recording the given "recordedUrl"
2. Make a custom manifest and return a 302 redirect to the recorded manifest
The embedded system will wait for the 302 redirect and will then start playback.
The problem we are seeing is that this process is slow:
0. Make the request to /tsb
1. Start the recording
2. Generate the manifest
3. Wait until we fill up the recorded buffer
4. Return the new manifest in the redirect
In the actual use case, a new "/tsb" request is made every time the user changes a channel on their TV. Think of it as having to do this every time a user presses "channel up" or "channel down" on their remote control. Because this is a common use case and is something that is time sensitive, we need to optimise this so that playback starts as quickly as possible.
Things we can do:
* The configuration used in production is the same as the one currently in Git. If there are potential optimisations there, we can investigate, but the client is going to be very hesitant to make changes here, for various reasons.
* One idea the client had was to proxy the request of the initial fragments to the end-server instead of through Fog. This means that Fog would initially serve up the manifest that points to the remote server, which could be used for the first 5-10 seconds while the recording buffer fills up and then on subsequent manifest requests we would give the player one that points solely to Fog instead of to the remote server. This is something they would like to see investigated and implemented.
Submission:
Please submit a Git patch file and a separate README (don't update the README in Git) that describes your changes and how to validate the optimisation.