Backstory
When lots of people meet in a stadium or concert hall, it can get quite difficult to get any data into or out of your mobile phone. Mostly that doesn't really matter because you're there for the event itself.
But every once in a while, you can get quite envious of the people at home who see the event on their screens because the camera crew can show close-ups and replays when something exciting is happening just on the other side of the concert hall or stadium.
You should be able to tune in with your phone - but you cannot. There are too many people trying to do the same and the WiFi or 5G capacity is insufficient for all of you. Wouldn't it be nice if those people who installed those networks had heard about multicast? Instead of failing to send separate TCP streams to every single mobile phone, they could send a single UDP stream to everybody.
So what if people have the idea to watch the replay at slightly different times? Wouldn't matter if we had patching.
But certainly there are packet losses and the quality would suffer? Sure, but there is Forward Error Correction (FEC), which could fix this most of the time.
But can all these pieces really come together in a way that people will use? That will be integrated into mobile phones?
Specific question for this thesis
ffmpeg is the one of the most popular video processing tools in the world. It does not have any GUI, but it is an open source tool that comes with a fantastic set of libraries written in C (collectively called libffmpeg), which is part of a lot of other software, including Android's applications. It is even available on the notoriously close iOS platform.
Among many, many other things, ffmpeg can retrieve video over HTTP/TCP/IP (like Netflix, YouTube etc) and over RTP/UDP/IP (like Zoom, Teams, mobile phones' "WiFi Calling" etc). The scenario presented above can be solved by combining these two properties of ffmpeg, although an implementation of RFC 8627 is missing in ffmpeg.
The main work of this thesis is to create this combination of RTP and HTTP streaming for ffmpeg, after two "toy" implementations that have already shown that the principle is sound.
Having solved the implementation issue, it is important to explore how, when and where, the RTP and HTTP streams should be combined to create the streaming experience that mobile phone users expected.
So - would you like to be the one to put these features into ffmpeg?
Learning outcome
- In-depth understanding of both popular streaming methods these days: DASH/HLS (as used by YouTube, Netflix etc) and RTP (as used by Zoom, Meet, etc)
- Deep understanding of WiFi networks
- Applied knowledge about the properties and implementation of forward error correction
- Experience programming and extending ffmpeg, the most popular video encoder and decoder tool for both commercial and academic use
Conditions
We expect that you:
- have been admitted to a master's program in MatNat@UiO - primarily PROSA
- take this as a long thesis
- will participate actively in the weekly SINLab meetings
- are present in the lab and collaborate with other students and staff
- are interested in and have some knowledge of C programming
- are interested in video streaming and networking
- are willing to share your results on Github
- include the course IN4230 in the study plan unless you have already completed IN3230 or equivalent
- include the course IN5060 in the study plan, unless you have already completed a course on classical (non-ML) data analysis