Due: 10PM, Fri 5/9.
This assignment can be done individually or in pairs.
You may use late days if you have any left.
This assignment is worth 60 points.
You are part of a company building a new streaming video service.
Your job is to develop a client application that plays streaming video loaded from your company's web server farm.
The player needs to adapt to network conditions, changing its playback rate and quality as necessary to achieve an aesthetically pleasing user experience.
Overview.
You need to develop a streaming video player.
The exact client technology is up to you, though a Java desktop application is probably the easiest choice.
Other possibilities include a web-based version using HTML5, an Android app, or an iIOS app.
Video details.
We will do video playback using a simple scheme of flashing a series of JPEG images.
Each frame of a video is stored as a separate file on your company's web server farm.
The client program should have a way to specify a tracking URL.
If you are doing a Java desktop application, this should be sent as the first command-line argument:
Here is what each line of the tracker files means:
The human readable name of the video. Your program should display the title somewhere in the player (e.g. as the title of the Java application).
Total frames in this video (a positive integer).
Frames per second that the video should playback at (a positive floating point number).
Width of the video in pixels (a positive integer).
Height of the video in pixels (a positive integer).
Whitespace delimited list of base URLs where the video frames live on the web farm (a positive integer).
I have deployed tracker files and the videos on the two servers 66.62.125.52 and 66.62.125.64.
The following tracker files are available in the root directory of both web servers:
lakes.tracker - Paddling video (2:41), 640x480 at 30 fps, loads frames only from server hosting tracker.
lakes-low.tracker - Paddling video (2:41), 320x480 at 30 fps, loads frames only from server hosting tracker.
washington.tracker - Climbing video, 1280x720 at 29.97 fps, loads frames only from server hosting tracker.
lander.tracker - Mars Lander program (0:50), 1008x551 at 7 fps, loads frames only from server hosting tracker.
lakes2.tracker - Paddling video (2:41), 640x480 at 30 fps, loads frames from entire farm.
lakes-low2.tracker - Paddling video (2:41), 320x480 at 30 fps, loads frames from entire farm.
washington2.tracker - Climbing video, 1280x720 at 29.97 fps, loads frames from entire farm.
lander2.tracker - Mars Lander program (0:50), 1008x551 at 7 fps, loads frames from entire farm.
Both servers have a videos subdirectory containing separate directories for each of the different videos.
You can browse the directory structure at http://66.62.125.52/videos/lakes/
As you can see, each video has a subdirectory qXX where XX is one of 8 different JPEG quality settings: 10, 20, ..., 80.
The higher the quality level, the bigger the frame size is.
In each quality level subdirectory, all the video frames are stored using a filename consisting of the 1-based frame number padded to 8 digits, e.g. 00000001.jpg, 00000002.jpg, etc.
Your player should spread retrieval approximately equally between all servers in listed in the tracker file.
For the purposes of this assignment, you can assume all servers are online and operational (i.e. the server farm exists for scalability, but not for high availability).
Playback details.
You are allowed an initial small (3 seconds or less) buffering period before playback starts.
After the playback commences, you must continue at the video's recorded FPS regardless of network conditions.
You are NOT allowed to pause playback to do any further buffering.
You may not be able to display every single frame in the source video.
You may also need to reduce the quality of the image frames delivered to the player if the network or client can't cope.
The exact policies you implement is up to you, but you will need to justify your choices in the report for the project.
Your player should adapt intelligently degrading or improving playback quality as conditions warrant.
Your player should look aesthetically pleasing as possible given the network realities (e.g. you shouldn't flash blank white or black frames).
Interface details.
Your player's interface needs to have a Play button and a Stop button.
Playback should automatically start when the page loads.
The Play button should be disabled while playback is active.
During playback, the Stop button stops all playback and frame retrieval activity and also purges all loaded frames.
When playback is not active, only the Play button is enabled.
Playback always restarts from the very beginning.
The interface should adapt its size based on the target video's resolution.
You should employ double-buffering to avoid unsightly flashing during playback.
Your interface needs to display the following details:
Current frame number and total number of frames.
A moving average showing the FPS the client is experienced in the last second of playback.
That is, over the last second how many of the target video's actual frames were loaded and playable when they were needed.
Elapsed wall clock time since playback started (after completion of any initial buffering period).
A list of numbers showing the percent of frames in 9 classes:
not available, available at quality 10, available at quality 20, ..., available at quality 80.
My player also has a visualization of the playback location, the loaded frames (top, purple), the quality of loaded frames (middle, grey), the present location of frame retrieval threads (green lines), the player's requested FPS (bottom, yellow line), and the location of a thread that prepares image buffers (blue line).
This is completely optional.
Though I found the visualization was very helpful in debugging and tuning my player.
You could also use System.out.println debug messages.
Player configuration.
Whatever your client-side technology, there should be a way to specify the required tracking URL.
For a Java desktop client, this should be the required first command-line argument.
Your player should default to a sensible pre-buffering amount of three seconds or less.
But it should also be possible for clients to specify a non-default buffering time in milliseconds.
For a Java desktop client, this should be an optional second command-line argument.
Your player should also default to a sensible number of frame retrieval threads.
But it should also be possible for clients to specify a non-default number of threads.
For a Java desktop client, this should be an optional third command-line argument.
Deliverables.
Along with your source code, you should also need to complete this report, answering the questions and providing benchmark results.
Example videos.
Here are links to videos I recorded of my solution using different videos, number of retrieval threads, and network conditions:
