Live Video Services Using Fast Broadcasting Scheme

The Fast Broadcasting scheme is one of the simplest schemes that provide video services. In this scheme, the video is divided into equal-sized segments depending upon the bandwidth allocated by the video server. If the video length is not known, then this scheme cannot be applied as the number of video segments cannot be determined. In a live video wherein the video size is unknown, especially the ending time of the live broadcast, e.g., cricket match, this scheme cannot be applied. In this paper, we propose a model that helps the Fast Broadcasting scheme to support live video broadcasting. The basic architecture of the system consists of a live system with one video channel that broadcasts the live video and a video server that broadcasts the already broadcast live video to users.


Introduction
Video-on-Demand (VOD) services are one of the important classes that has several potential applications, such as entertainment, advertisement, distance education, etc.In spite of vast usability, these applications could not gain much attention because the earlier network technologies were not sufficient enough to support high data rate and same was with the storage technologies.These technologies have been developed significantly and are further being enhanced.New applications are also being explored that again put high demand on these resources.Therefore, efficient utilization of the resources especially the bandwidth is must.Several schemes exist in literature, but all are meant for the stored videos.These schemes require the video length to construct its segments.If the video length is not known in advance, which is generally the case for live videos, these schemes can be applied.To develop a broadcasting scheme for live videos is the motivation of this work.In this paper, we propose a mechanism that helps the Fast Broadcasting scheme to support the live video services.The Fast Broadcasting scheme is one of the simplest schemes that provides the video services.For broadcasting a video, there is a need to have a video server to transmit the video data.Designing a video server has many issues, e.g., efficient system design [1][2][3], storage management [4][5][6][7], broadcasting techniques.The broadcasting techniques are very important as they help utilizing the bandwidth efficiently.Some of the important broadcasting techniques are discussed in [8][9].
The basic model in this paper consists of a system (we call it as a live system) with a video channel that is called as the live channel.This system is active for the duration of the live video and broadcasts the live video data only once using its channel.There is another system that stores the video data from the live channel in its buffer and then broadcasts.This system simultaneously stores the new data from the live channel into its buffer and broadcasts the already stored data by using its channels.This process continues for the duration of the live video transmission.When the live video is over, the data is broadcast by the video server only.If the live video broadcast is still there and the video server has no free channel to broadcast the newly downloaded data, then the last channel of the video server is made free by transferring its data to other channels and the last channel can broadcast the newly downloaded data.This mechanism is called the channel transition mechanism.The important issue in channel transition is that the current as well as future users should get continuous data delivery.In literature, there does not seem to appear any work that discusses live video broadcasting.It is perhaps that the broadcasting schemes existing in literature require the video in terms of prespecified number of segments depending on the allocated bandwidth.To determine the number of video segments of a live video is not possible because the video length is not known.In this paper, we develop a mechanism so that the Fast Broadcasting scheme can support the live videos.The remaining of the paper is organized as follows.Section 2 reviews the previous work.Section 3 proposes a system model to sup-port the live video transmission.The main concept in this paper is channel transition, which is of two types intermediate and final channel transition.In intermediate channel transition the live video is not over, whereas in the final channel transition the live video is over.Section 4 presents the results and finally Section 5 concludes the paper.

Previous Work
The broadcasting schemes are an important class of protocols supporting the video-on-demand services.Some schemes use a segment as the basic data unit for transmission and a video channel a basic transmission unit.Some schemes further divide the segments into subsegments and the video channels into subchannels.A subchannel transmits all the subsegments of a particular single segment.Taking subsegment as a basic data unit and subchannel as a basic transmission unit reduce the resources requirement.This however increases the complexity.Some of the important broadcasting schemes include harmonic scheme [11], geometrico-harmonic scheme with continuous delivery [12], Pyramid Broadcasting scheme [13], Fast Broadcasting scheme [14].The harmonic and geometrico-harmonic schemes have their basic data and transmission units as subsegments and subchannels, respectively.The pyramid and Fast Broadcasting schemes employ the segments and video channels as their basic data and transmission units, respectively.A video channel is a logical channel that has bandwidth equal to the consumption rate of the video.The Fast Broadcasting scheme is one of the simplest schemes for providing the video services.In this scheme, the bandwidth is equally-divided into channels, each having bandwidth equal to the video viewing rate.The video is also uniformly divided into segments.The first video channel transmits the first segment, repeatedly, and the second video channel transmits the second & third segments, alternately and periodically.The ith video channel transmits 2 i-1 segments from 1 2 i S  to 2 1 i S  , sequentially and periodically.The segment size determines the user's waiting time.The video transmission time is also divided into fixed time units, called time slots.In a time slot, a segment can be exactly viewed at the viewing rate.The number of segments of the video of length D for allocating K video channels is 2 K -1. Figure 1 shows transmission of the video segments over four video channels, denoted by C 1 , C 2 , C 3 , and C 4 , in the Fast Broadcasting scheme.

Live Fast Broadcasting Scheme
In live video broadcasting, the video size is not known in the beginning and hence its number of segments cannot be determined.The Fast Broadcasting scheme needs the number of segments in advance, so this scheme cannot be applied.In order to use this scheme for live video transmission, we make a simple modification in its ar chitecture.We transmit N number of segments using K video channels, which are related by 2 2 The basic system model for supporting the live videos consists of a system, called the live system.This system broadcasts the live video by using its video channel (live channel).There is another system; we call it as the video server.The video server downloads the data from the live channel into its buffer in terms of fixed time durations, which are time slots.The data stored in a time slot is referred to as a video segment.The video server performs two activities.It stores new segments from the live channel into its buffer and simultaneously broadcasts the already stored segments.This server supports the video data to any user request, which misses the initial portion of the live video.A user request received after the live video has been started gets future data from the live channel and the initial missing data from the video server.The video server is always tuned to the live channel for new segments to store into its buffer.The stored segments are broadcast by the video server according to the following broadcasting procedure.

Broadcasting Procedure
The number of video segments for allocating K video channels is 2 K -2.Denote the video segments by S i (i=1,2,..,N).The first video channel transmits the first segment S 1 , repeatedly, and the second video channel transmits the segments S 2 and S 3 , alternately and repeatedly.The ith video channel transmits the segments i S  , sequentially and periodically, provided this ith channel is not the last video channel.The last video channel, i.e., Kth video channel transmits the segments K S  , sequentially and periodically.The video server is always connected to the live channel for downloading the new segments.When a segment has been downloaded, the video server broadcasts that segment by using its channels along with other segments.This process continues till there is a free channel with the video server and the live video transmission is going on.Since the bandwidth allocated to the video by the video server is of fixed amount, this will get exhausted at some point of time.In that case, the video server would not be able to broadcast the newly downloaded segments.One solution to this problem is to increase the bandwidth, which may not always be possible.A better solution is to make the last channel free by transferring its segments to other video channels so that this video channel can broadcast the new segments.This process is called channel transition.The important issue while doing a channel transition is that all (present or future) user requests must get timely video data delivery.There are two types of channel transition: intermediate channel transition in which the live video is not over and the final channel transition in which the live video is over.We first discuss the intermediate channel transition.

Intermediate Channel Transition
The intermediate channel transition is performed when the video server is downloading new segments from the live system, but it does not have a free channel to broadcast them.We transmit (2 K -2) segments using K channels, not (2 K -1) as required in the Fast Broadcasting scheme.This is done because the capacity of the last channel is equal to total capacity of all other channels.Here the 'capacity' of a channel refers to the maximum number of segments transmitted by that channel.While transferring segments of the last video channel to other channels to make it free, we simply need to double the segments' size.If S 1 , S 2 ,…,S k, … are the old segments, then the new segments, denoted by S 1  1 , S 1 2 ,…, are given by S 1 1 = S 1 + S 2 , S 1 2 = S 3 + S 4 ,…, S 1 k = S 2k-1 + S 2k ,…, and so forth.After a channel transition the segment size (i.e., new waiting time) becomes twice of the old one (old waiting time).To avoid the increase in the waiting time, we should delay the channel transition as much as possible, which can be delayed till all channels have their capacity full.It is not difficult to show that by delaying a channel transition maximally, all user requests (before and after the channel transition) get the video data in time.
Figure 2 shows the first channel transition at thick black line for allocating four video channels to the video by the video server.The gray-colored channel signifies the live channel and remaining are the video server's channels.The problem of data availability may be for a request that begins viewing the video just before the channel transition.This request, denoted by R 13 in Figure 2, begins downloading the data from the time slot TS 14 .This request R 13 downloads the segments S 15 onward from the live channel and S 1 to S 14 from the video server.The segments available for downloading from the video server using the 1 st , 2 nd , 3 rd , and 4 th video channels in the time slot TS 14 are S 1 , S 2 , S 6 , and S 14 , respectively.The segment S 1 can be viewed while downloading from the video server and does not requires storage space.Just after the channel transition, R 13 needs the segment S 2 for viewing and it is already in its buffer because it had been stored just before the channel transition.After viewing S 2 , R 13 needs S 3 segment which is the first half part of the second segment S 1 2 (=S 3 + S 4 ) transmitted by the second channel after channel transition.Thus, the data of the segment S 3 can be made available to R 13 .Using similar discussions, we can show that a request received in any time slot can receive timely video data.We now discuss the final channel transition.

Final Channel Transition
In order to carry out the final channel transition, the video size must be known and it is possible only when the live video transmission is over.Since the video size is known, we can construct the video segments.The live video can be over at any point of time.If the data broadcast by the live channel does not form a complete segment, we can add dummy data to make it a complete segment.The live video can be over in any time slot, which means that the last video channel can have any number of segments ranging from one to its maximum capacity.If its capacity is full, then nothing is required to do.To carry out the final channel transition, the last channel must have at least one segment and at least one empty time slot.To occupy empty time slots with the video data, we need to increase the number of segment to (2 K -2) so that all time slots of all the video channels K are occupied.Increasing the number of segments decreases the segment size as the video size is of fixed length.The first channel C 1 transmits S 1 ℓ-1 and the second channel C 2 transmits the segments S 2 ℓ-1 and S 3 ℓ-1 just before the final transition.Here the superscript ℓ of a segment (time slot) signifies the segment (time slot) after the final (last) channel transition and (ℓ-1) for a segment (time slot) just before the final channel transition.After the final channel transition, the segment size decreases, i.e., some last portion of S 1 ℓ-1 segment is added to the beginning of S 2 ℓ-1 and some last portion S 2 ℓ-1 is added to the beginning of S 3 ℓ-1 , and so forth.The number of new segments is (2 K -2) and they can occupy all the time slots on all channels.While carrying out this process, timely video data delivery to the current as well as future requests must be ensured.
We now discuss how the video data delivery can be timely maintained to all user requests by taking an example.Consider that the video server has allocated four video channels to the video.The last (i.e., fourth) video channel can accommodate the segments S 8 , S 9 ,…, S 14 .The live video can be over in any time slot ST i ℓ-1 (7<i<14).Let i=8, i.e., the last video channel has to transmit the last segment as S 9 ℓ-1 in the time slot ST 8 ℓ-1 .The segment S 9 ℓ-1 will be available at the video server for transmission in the time slot ST 9 ℓ-1 (refer Figure 3).We can carry out the channel transition immediately after the time slot ST 9 ℓ-1 .The request R 8 that begins to download the data from the time slot ST 9 ℓ-1 onward can download, if required, the segments S 1 ℓ-1 , S 3 ℓ-1 , S 5 ℓ-1 , and S 9 ℓ-1 in that time slot (refer Figure 3).The segment S 1 ℓ-1 is viewed while downloading in the time slot ST 9 ℓ-1 and in the next time slot (i.e., after channel transition) this request needs S 2 ℓ-1 .The segment S 2 ℓ-1 is distributed among the segments S 2 ℓ and S 3 ℓ after the channel transition.The segment S 2 ℓ is available for downloading just after the channel transition, but the initial portion of segment S 2 ℓ comprises some last portion of S 1 ℓ-1 and the remaining is some initial portion of the segment S 2 ℓ-1 .It means that just after channel transition the initial portion of S 2 ℓ that is from the segment S 1 ℓ-1 will be available, not the segment S 2 ℓ-1 .Thus, the request R 8 will not get the data of the segment S 2 ℓ-1 in time.To circumvent this problem, we delay the final channel transition one time slot after the live video is over.In the instance case, we carry out final channel transition at the end of the time slot ST 10 ℓ-1 , not ST 9 ℓ-1 .By doing so, we have one empty time slot (shown as gray-colored on the last video channel in Figure 3) on the last video channel that can be used to broadcast S 2 ℓ-1 or S 3 ℓ-1 depending upon the last segment broadcast by the live channel is even or odd.The segments available for downloading to the request R 8 in the time slot ST 10 ℓ-1 are S 2 ℓ-1 and S 6 ℓ-1 . The request R 8 has segments S 2 ℓ-1 and S 3 ℓ-1 in its buffer and will need S 4 ℓ-1 for viewing in the time slot ST 12 ℓ-1 , which is not in the buffer storage.After the channel transition, the segment S ℓ-1 can be made available in time to request R 9 .Using similar discussions, we can show that all requests can be provided the required data in time.
We now find out those segments S i ℓ that have the data of the segment S 4 ℓ-1 after the final channel transition.The indices of the segments S i ℓ that have the data of segment S 4 ℓ-1 are I L , I L+1 , …, I H , where I L and I H are given by and where p is the index of the last segment broadcast by the live channel and N is the number of segments that is given by (1).

Results
The Fast broadcasting scheme is one of the simplest broadcasting schemes.That's why we have considered it for live video broadcasting.In its architecture, we have made a simple modification so that the number of segments transmitted by its last video channel is equal to the total segments transmitted by its remaining channels.This modification makes the final channel transition at the optimal time point.In other words, the channel transition is performed after all time slots of all the video channels are full with the video segments.Consider again Figure 2. The request R 0 arrived in the 0 th time slot ST 0 begins downloading the segments S 2 onward from the live channel and S 1 from the video server.The buffer requirement for this request is one segment.The request R 1 arrived in the 1 th time slot ST 1 begins downloading the segments S 3 onward from the live channel into its buffer and S 1 and S 2 from the video server.Its buffer requirement is of two segments.We describe the buffer computation for an arbitrary request.Consider an arbitrary request, say, R 9 , that arrives in the 9 th time slot ST 9 .This request begins downloading the data from the time slot ST 10 onward.The segments S 11 onward are downloaded from the live channel and the segments S 1 to S 10 from the video server.The segments available for downloading, actually downloaded, and that required for viewing, in different time slots are shown in Table 1.
In last column '+' and '-' signs signify that the segment is stored in and read from the buffer, e.g., +2-1+1=2 means 2 segments are stored from the video server into the user's buffer, one is read from the user's buffer, and one is stored from the live channel into the user's buffer.Thus, the net buffer requirement is of two segments.The segment S 1 is viewed while downloading.
Using similar discussions, we can compute the buffer requirement for any request.Table 2 shows the buffer requirement for different requests (referring Figure 2), assuming that four video channels have been allocated to the video by the video server.
In Table 2, for the requests R 7 , R 8 , R 9 , R 10 , and R 11 , there are two different storage requirements.The first requirement is one when the live video is going on.The second requirement refers to one when the live video is over after the 14 th segment.The maximum user's waiting  time in this scheme is pre-decided for the initial users and remains the same till the channel transition time.
After every channel transition except the final one the user's waiting time becomes double of the previous one.
The final channel transition is done only when the live video transmission is over.After the final channel transition the user's waiting time is stabilized and the scenario becomes like a stored video.The size of a segment (time slot) after a channel transition except the final one becomes double.If S i , ST i and S 1 i , ST 1 i are the ith segments and time slots, respectively, before and after the first channel transition (assuming four video channels), then we have the following relations: where S 0 i , ST 0 i denote the very first ith segment and time slot, respectively, i.e., S 0 i = S i , ST 0 i = ST i and ℓ denotes the final channel transition.
We can determine the size of a segment (time slot) after any channel transition in terms of the original segments (time slots).For example, consider the third channel transition (assuming it is not the final channel transition).Then, (2a) & (2b) give We can take i=1 because after any channel transition all the segments (time slots) are of same size.We will derive the relation for the segments only, and for the time slots exactly the same relation will hold.For i=3, we have from (3a) as S 3 1 = S The segments S 0 i s are the original segments.Thus, we have S 3 1 = S 99 + S 100 +…+…+ S 106 For the time slots, we have ST 3  1 = ST 99 + ST 100 +…+…+ ST 106 The segment (time slot) size after the final channel transition (i.e., ℓth) is  times of the segment (time slot) size of that of the (ℓ-1)th channel transition, where 0.5 <  < 1.Here  = 1 signifies that the live video transmission is over when all time slots of all the video channels are full.In that case, nothing is done and the user's waiting time is unchanged.For  ≠ 1, the last channel after the final but one channel transition must have at least one segment and at least one empty time slot.Consider that the last video channel has N S segments after the final but one channel transition.After the final channel transition, the segment size would be (2 K-1 + N S )*S ℓ-1 /N.For K=4, N=14, and N S =2, the segment size after the final channel transition is (2 3 + 2)*S ℓ-1 / 14=10*S ℓ-1 /14.The user's waiting time changes after a channel transition depending upon the segment size and this is fixed for the stored videos for a given bandwidth.In the proposed scheme, the initial user's waiting time is decided by the service provider and it is also equal to the segment size.This decision is necessary for arranging the video data that would be downloaded in terms of the segments and made on the basis of bandwidth allocated to the video.The video size increases after a new segment from the live channel has been downloaded, but this change affects broadcasting only after the channel transition.After the final channel transition, the user's waiting time generally decreases.The basic requirement to carry out the final channel transition is that there must be at least one segment and at least one empty time slot on the last video channel.

Conclusions
In this paper, we have proposed a technique so that the Fast Broadcasting scheme can be used for broadcasting the live videos.The Fast Broadcasting scheme does not support the live video services in its original form because it requires the number of segments of the video beforehand and for that the video length should be known, which is generally not known in advance in case of the live videos.In this proposed scheme, the live video data is stored in buffer at the video server in terms of fixed time durations, called time slots.The data downloaded in a time slot is considered as a segment.The downloaded segments are broadcast by the video server till there is free channel available with the video server.When no free channel is available and live video is there, channel transition is required.In the proposed scheme, the channel transition can be delayed maximally, i.e., up to the point when all time slots of all the video channels have been completely occupied.This study may be useful for designing a VOD system that can support the live video, such as cricket match, interactive education session, etc.

Figure 1 .
Figure 1.Data transmission in Fast Broadcasting scheme