team-synackd / progressive-streaming Goto Github PK

Instead of directly downloading the video entirely over TCP, we can try via an HTTP request and response pair.

A simple approach can be:

• send an HTTP GET request from the client to the server requesting for the file. Look upon setting HTTP headers for the request as well.
• Server checks if that file is present in the server or not.
  • If yes, the server sends the file as response with its associated headers.
  • If not, the server signals the client that the file is not present.

This is just my view on how this could be designed, feel free to add your perspective into the context :).

Hi,

Currently, this repo contains code which does a basic implementation of progressive streaming, which in a nutshell means that we retrieve the entire video file send it through a TCP connection to the requesting peer. Which is, of course, a redundant mechanism to follow as far as streaming is concerned as this process is subjected to stall and buffering events in case of congestion effects.

Hence it is vital to us to improve this scenario with additional features implementation that could be done which could actually get us better performance and ease of usage.

Further note, I currently, only intend to implement this project for purely research purpose where users of this project could plug and play their implementation with our code.

Both the network and video side of things could be designed as different engines which is used to drive the core principles of this project implementation. Below you can find the detailed implementation design suggestion which I would like to make:

On the streaming side:

• We should also support ABR streaming algorithms, plainly having a progressive streaming application is not good enough.
• A queueing mechanism to fill the video buffer.

On the networking side:

• Add more TCP related functionalities from the socket APIs in use.
• Add HTTP functionality on top of the current TCP code to have better design proposition.

This is just the initial plans which I would like to put forward. We could further discuss the design of the whole project within this issue.

Currently, the main player window is just a static window which basically just plays out the video frames. It should be convenient if the window could be resizable by the user on runtime with a few manageable buttons to close etc.

Currently, there exists a good enough logging base that can be built upon. We should play smart on how the logging should occur, devise some command-line arguments to show whether we need verbose or basic logging, write logs to a file and much more.

The readme could contain details about:

• How to compile and run the code.
• what the code does.
• why this is prepared etc.

The current makefile is messy. There is a correct usage of Autotools to process the C code and objects. We should integrate it as such.

Currently, the player waits for the TCP module to download and fill it's receiving buffer to be completely filled before the buffer is given out to the player. This isn't an ideal workflow.

What I would suggest is, once the buffer is filled up to a threshold, the buffer should be passed on to the player for playback. Though, this will let us encounter, buffering. That is something else which we need to focus on as well.

cc main_window.cpp decoder.cpp -lstdc++ -lavcodec -lavformat -lavutil -lswresample -lswscale -lglfw -lGL -o bin/player
/usr/bin/ld: cannot open output file bin/player: No such file or directory
collect2: error: ld returned 1 exit status

If bin/ directory doesn't exist, make sure it is created before the compilation process.