High Scalability Streaming Server

This work aims at developing a highly scalable streaming server which should be able to handle thousands of concurrent connections per server. This server has to be developed in C/C++.

Streaming Server:

On a high level the streaming server has the following function.

[url removed, login to view] a live stream from a client.

[url removed, login to view] it to multiple formats if required.

[url removed, login to view] the transcoded stream to multiple clients.

Apart from this it also captures thumbnails and some management tasks such as authentication & authorization.


In order to achieve high scalability the server design has to be optimal up to the micro level. Certain design models are common and necessary in achieving scalability of this level. The most essential of these are mentioned below.

Asynchronous IO

For a server to be able to handle very high number of connections simultaneously the service threads should never block on IO. This demands for use of Asynchronous IO where a system is never blocked on IO.

Zero buffer duplication

In the streaming server the data transferred is heavy in nature. The design has to take care that data in the server never gets duplicated in memory or outside it throughout the data path.

Leveraging multi-core architectures

The streaming server will cab be deployed on high-end machines if it is cost effective. Such machines are likely to have multiple cores which can be of high use when using asynchronous IO. Suggestions for any advanced hardware are also welcome. The sever design thus should be able to leverage multi-core architectures fully.

Furthermore, the design should also support and leverage 64 bit architectures. 64 bit machines are beneficial for memory bound operations because of a wider data bus and asynchronous IO is both very much memory bound.


The streaming server has to support a pre-existing proprietary protocol. The protocol has provision to encapsulate audio video data as well as control data. It is in essence a packet based binary protocol.

Format details for audio video are as follows.


Codec: AAC, LC profile, No SBR.

Channels: Mono (1 channel).

Sample rate: 8 KHz.

Bit rate: 8 Kbps.


Codec: MPEG-4 Part 2, Simple profile, Level 1.

Dimensions: QVGA (320x240) , QCIF (176x144)

Bit rate: Constant bit rate (CBR mode); Low (32 kbps), Medium (128 kbps), High (256 kbps).

Frame rate: Constant frame rate; 5, 10, 15.

Display aspect ratio: 4:3.

The control data is in XML, UTF-8.


As can be noticed in the audio video format details, the video can be sent in multiple dimensions, bit rate and frame rates. Thus it is possible that the format in which uploading client sends stream is not same as the format in which the downloading/viewing clients consume. For this purpose transcoding is needed.

Transcoding includes the following operations.

1. Reduce dimension. There only 2 dimensions that are supported. QVGA and QCIF. Transcoding from QVGA to QCIF is required. Transcoding from QCIF to QVGA is not required.

2. Reduce FPS. There are 3 supported frame rates 5, 10 & 15. 15 can be reduced to 10 & 5. 10 can be reduced to 5. Other combinations are not required.

3. Reduce bit rates. Like FPS bit rates too can be reduced from a superior value to a inferior value.

Audio is never transcoded. Rest of the video parameters should remain intact.

Transcoding must not introduce any audio video synchronization problems and should not lead to end to end latency of over 10 seconds.

Transcoding is a CPU intensive task of high complexity. It should be done only when required. For example, if a client is uploading in QVGA@15 fps; 256 kbps and two clients are download at QCIF@5 fps; 32 kbps and one client is downloading at QVGA@15fps; 256 kbps. Then transcoding should happen only once to QCIF@5 fps; 32 kbps and the same transcoded data should be written to the two clients without any buffer replication. For the third client, data from the upload stream should be used as it is.

We recommend use of the ffmpeg library for transcoding for several reasons.

Integration with Application Server:

The streaming server will act as the data conduit of a pre-designed system. In this system each streaming server will be under control of one and only one application server. The application server and the streaming server are loosely coupled with an intermediate component – memcached.

At connection establishment the streaming server authenticates a connection before proceeding with the streaming. Both upload and download are authorized and initiated through an application server. The streaming server has to authenticate a connection against the authorization challenge setup by the application server. These authorization challenges are maintained in memcached.

Capturing thumbnails:

The streaming server has to capture thumbnails periodically (1-5 secs) from the upload stream. The thumbnail size should be around 24x24 and should be in the JPEG format. The captured thumbnails have to be written to the memcached along with their generation timestamps.

Load balancing:

As already mentioned, streaming server must be designed to scale horizontally. In such a configuration there can be multiple streaming servers among which the load has to be balanced. Load balancing will be done based on resource usage of each streaming server. Thus it is required that each streaming server dumps its resource usage in the memcached based on which the application servers can implement load balancing.

Secondly, a client can only upload to a single streaming server. It is possible that the stream can be downloaded by a large number of clients and all these connections cannot be handled at the same streaming server as that of upload. Thus the downloads will have to be spread across more than one streaming servers. Since client can upload to only one streaming server it must be able to replicate the uploaded stream across multiple servers.


The streaming server has to support the following configurations.

Bitness: 32 bit, 64 bit.

OS: Linux (flavour and kernel can be chosen).

Processors: Intel Pentium, Intel Core 2 Duo, Intel Xenon.

Processors: Single processors, Dual processors, Quad processors.

In long term, streaming server has to be deployed in a cloud computing services like Amazon’s EC2. Thus the streaming server should be implemented such that it is can be deployed in a cloud computing environments too.


Following deliverables will be required.

• High level plan. Based on this statement of work a high level plan with time and resource estimates has to be provided before beginning of the project. The high level plan should incorporate times for design, implementation and bug fixing phases. Company will be responsible for the QA activites. It should be as accurate as possible.

• Usage manual. The usage manual should be delivered at the end of the implementation phase. It should cover in detail how the code is compiled and installed. It should also describe in detail all configuration options available in the streaming server.

Acceptance criteria:

The project or a specific deliverable will be deemed delivered only if the following criteria are met at their respective times.

1. One instance of streaming server must be able to handle several connections. The specific number for corresponding to the hardware will be agreed upon before the design phase begins. This number will be in order of few thousands on a low end hardware to multiple thousands on a high end hardware.

2. The design must take of the points mentioned in the Scalability section. Blocking on IO and buffer duplication should be avoided. Further any hardware provisions should be efficiently utilized.

3. Quality of the video and the overall stream as such has to be good. Audio video synchronization in the stream should be exactly same as that of generated at the source. It is extremely important that the end to end latency of the stream is constant and below 5 seconds. The video quality has to be sharp without pixilation or green blocks or other common artefacts that can result from poor transcoding. As audio is not transcoded at all its quality too must not change over the air. Any quality issue can be logged as a bug at the appropriate priority.

4. Quality of thumbnails captured should be good.


Taidot: C-ohjelmointi, Videopalvelut

Näytä lisää: scalable streaming server, which of the following is not part of configuration management, video live streaming service, video blocks, value options, use of binary, transcoding service, time complexity of code, time complexity in c, time complexity function, time complexity, system challenges, statement of the problems, simple challenges, simple binary code, simple binary, sharp component, service stream, service channel, service by air, sample problems, quality acceptance, profile formats, problems statement sample, platform cab

Tietoa työnantajasta:
( 0 arvostelua ) New delhi, India

Projektin tunnus: #498906

5 freelanceria on tarjonnut keskimäärin %project_bid_stats_avg_sub_26% %project_currencyDetails_sign_sub_27% tähän työhön


Hi we have similar products to this project. Please check our website at [url removed, login to view] for live video broadcasting and transcoding server warez.

$10000 USD 90 päivässä
(4 arvostelua)

Please check details in PM.

$3000 USD 90 päivässä
(0 arvostelua)

Please look PM

$3000 USD 120 päivässä
(0 arvostelua)

Mel Media is a Web Design & Development company, situated in Romania, with the main office in Timisoara, which offers Web Design, Web Development (online shop, CMS, complex applications), site re-design, maintenance, o Lisää

$3000 USD 120 päivässä
(0 arvostelua)

Please check your PM.

$15000 USD 90 päivässä
(0 arvostelua)