U.S. patent application number 12/735008 was filed with the patent office on 2010-10-07 for apparatus and method for simulcast over a variable bandwidth channel.
This patent application is currently assigned to THOMSON LICENSING. Invention is credited to Shemimon Anthru, Jill McDonald Boyce, David Anthony Campana, Avinash Sridhar.
Application Number | 20100257572 12/735008 |
Document ID | / |
Family ID | 39746620 |
Filed Date | 2010-10-07 |
United States Patent
Application |
20100257572 |
Kind Code |
A1 |
Sridhar; Avinash ; et
al. |
October 7, 2010 |
APPARATUS AND METHOD FOR SIMULCAST OVER A VARIABLE BANDWIDTH
CHANNEL
Abstract
The present principles provide a method for a personalized
mobile broadcast service operator (Service provider) to send
content in the form of files with different compression formats in
a variable bandwidth channel to one or more users who have access
to the same service. Operators providing mobile broadcasts have the
option of using residual bandwidth to provide these services. In
such services, depending on the amount of bandwidth available for a
mobile broadcast, a scheduler can choose to broadcast file content
with higher compressed parameters thereby reducing the network
footprint of the content file during lower bandwidth situations. A
lower compressed format of the same content could then be
potentially scheduled to broadcast at a later time when more
bandwidth becomes available eventually replacing the highly
compressed copy which was received earlier on the client.
Inventors: |
Sridhar; Avinash;
(Plainsboro, NJ) ; Campana; David Anthony;
(Princeton, NJ) ; Anthru; Shemimon; (Monmouth
Junction, NJ) ; Boyce; Jill McDonald; (Manalapan,
NJ) |
Correspondence
Address: |
Robert D. Shedd, Patent Operations;THOMSON Licensing LLC
P.O. Box 5312
Princeton
NJ
08543-5312
US
|
Assignee: |
THOMSON LICENSING
|
Family ID: |
39746620 |
Appl. No.: |
12/735008 |
Filed: |
December 14, 2007 |
PCT Filed: |
December 14, 2007 |
PCT NO: |
PCT/US2007/025685 |
371 Date: |
June 9, 2010 |
Current U.S.
Class: |
725/116 ;
725/118 |
Current CPC
Class: |
H04L 65/4076 20130101;
H04L 12/1822 20130101; H04N 21/23439 20130101; H04L 67/325
20130101; H04N 21/6405 20130101; H04N 21/65 20130101; H04N 21/2402
20130101; H04L 41/147 20130101; H04L 67/28 20130101; H04L 67/2828
20130101; H04L 47/10 20130101; H04N 21/6131 20130101 |
Class at
Publication: |
725/116 ;
725/118 |
International
Class: |
H04N 7/173 20060101
H04N007/173 |
Claims
1. A method for providing data over a network comprising the steps
of: establishing a bandwidth value for providing a data over a
communication channel; providing the bandwidth value to a client
device over the communication channel; providing a version of the
data over the communication channel to the client device in
response to a comparison of the bandwidth value with a
threshold.
2. The method of claim 1, wherein the establishing comprises
estimating (302) the available bandwidth in the communication
channel.
3. The method of claim 1, wherein said establishing comprises
setting an initial value for the bandwidth.
4. The method of claim 1, further comprising setting the threshold
based on the established bandwidth value.
5. The method of claim 4, wherein the threshold is set as one half
the established bandwidth value.
6. The method of claim 4, wherein the providing further comprises
transmitting a low compression version of the data when the
bandwidth value is higher than the threshold.
7. The method of claim 4, wherein the providing further comprises
transmitting a high compression version of the data when the
bandwidth value is lower than the threshold.
8. An apparatus comprising: a head end scheduler configured to
establish a bandwidth value for providing data over a communication
channel, provide the bandwidth value to a client device, and
provide a version of the data in response to a comparison between
the bandwidth value and a threshold
9. The apparatus of claim 8, wherein the scheduler is configured
with an initial bandwidth value.
10. The apparatus of claim 8, wherein the scheduler is configured
to estimate the bandwidth of the communication channel to establish
the bandwidth value.
11. The apparatus of claim 8, wherein the scheduler establishes the
threshold based on half the bandwidth value.
12. The apparatus of claim 11, wherein the scheduler provides a low
compression version of the data when the bandwidth value is higher
than the threshold.
13. The apparatus of claim 11, wherein the scheduler provides a
high compression version of the data when the bandwidth value is
lower than the threshold.
14. An apparatus comprising: program code for establishing a
bandwidth value for providing data over a communication channel;
program code for providing the bandwidth value to a client device
over the communication channel; and program code for providing a
version of the data over the communication channel to the client
device in response to a comparison between the established
bandwidth value and a threshold.
15. The apparatus of claim 14, further comprising program code for
setting the threshold based on the established bandwidth.
16. The apparatus of claim 14, wherein the program code for
establishing a bandwidth value further comprises program code for
estimating the available bandwidth of the communication
channel.
17. The apparatus of claim 15, further comprising program code for
setting the threshold as one half the established bandwidth.
18. The apparatus of claim 15, further comprising program code for
providing a low compression version of the data when the bandwidth
is higher than the threshold.
19. The apparatus of claim 15, further comprising program code for
providing a high compression version of the data when the bandwidth
is lower than the threshold.
Description
BACKGROUND
[0001] 1. Technical Field
[0002] The following principles of the present invention relate to
data transmission. More particularly, they relate to the
transmission of simulcast data over a variable bandwidth
channel.
[0003] 2. Description of Related Art
[0004] Content services are provided by a spectrum of different
suppliers. For example, residential digital video services may
include digital television, Video on Demand (VOD), Internet video
streaming, etc., each service typically providing audio-video data
displayable at different encoded levels.
[0005] Content data is transmitted in a bitstream, or a continuous
sequence of binary bits used to digitally represent compressed
multimedia, e.g., video, audio, data. The bitstream is transmitted
over a transmission channel. When content data is sent as a
continuous bitstream, a client device buffers this stream and
offers a real time playback of the same.
[0006] Mobile broadcast networks are challenging environments in
which to deliver audio/video content. The bandwidth available over
a connection at any particular instant varies with both time and
location. This variation in bandwidth causes entire packets
containing substantial audio/video content to be lost. In addition,
the latency through the network, causing the video that is
ultimately displayed to `jitter` or lose clarity at the client.
These factors may be tolerable for file transfer traffic where
jitter does not matter since high level protocols correct for
errors and losses.
[0007] In streaming real time live content live broadcast networks,
methods already exist where transmission of audio-video content
varies as a function of available network bandwidth. Depending on
the bandwidth available, the head end or transmitter side of the
service is able to either buffer data to send them at a different
time or at real time, using an encoder to vary the content stream's
compression parameters so that it can be transmitted at current
available bandwidth.
[0008] Operators providing live televised services, stream in
real-time, a lower quality version of a televised broadcast feed to
its mobile customers. For example mobile operators like Verizon and
Sprint provide live TV services, e.g., VCast Live TV, MobiTV, etc.,
at a reduced resolution and bitrates to mobile handsets using their
services.
SUMMARY
[0009] According to an aspect of the present principles, the method
for providing data over a network of devices includes establishing
a bandwidth value for providing a data over a communication
channel, providing the bandwidth value to a client device over the
communication channel, and providing a predetermined version of the
data over the communication channel to the client device in
response to a comparison of the established bandwidth value with a
bandwidth threshold. Providing data may include transmitting data
via a wireless connection or providing data via a wired
connection.
[0010] According to another aspect, the bandwidth can be
established by estimating the available bandwidth, or could be
established by setting an initial value of the bandwidth.
[0011] A bandwidth threshold is set based on the established
threshold, and according to one implementation, the bandwidth
threshold can be set as one half the established bandwidth
value.
[0012] In accordance with another aspect, a low compression version
of the data is transmitted when the bandwidth is higher than the
bandwidth threshold, and a high compression version of the data is
transmitted when the bandwidth is lower than the bandwidth
threshold.
[0013] According to another implementation, the apparatus includes
a head end scheduler configured to establish a bandwidth value for
transmitting data over a communication channel, transmit the
established bandwidth value to a client device, and transmit a
predetermined version of the data in response to a comparison
between the established bandwidth value and a bandwidth
threshold.
[0014] According to a further implementation, the present
principles are embodied in a computer program product having a
computer useable medium having computer readable program code
embodied thereon for use in communicating data over a communication
channel. The computer program product includes program code for
establishing a bandwidth value for transmitting the data over the
communication channel, program code for transmitting the
established bandwidth value to a client device over the
communication channel, and program code for transmitting a
predetermined version of the data over the communication channel to
the client device in response to a comparison between the
established bandwidth value and a bandwidth threshold.
[0015] Other aspects and features of the present principles will
become apparent from the following detailed description considered
in conjunction with the accompanying drawings. It is to be
understood, however, that the drawings are designed solely for
purposes of illustration and not as a definition of the limits of
the present principles, for which reference should be made to the
appended claims. It should be further understood that the drawings
are not necessarily drawn to scale and that, unless otherwise
indicated, they are merely intended to conceptually illustrate the
structures and procedures described herein.
BRIEF DESCRIPTION OF THE DRAWINGS
[0016] In the drawings wherein like reference numerals denote
similar components throughout the views:
[0017] FIG. 1 is block diagram of a typical broadcast network
adapted for mobile broadcast;
[0018] FIG. 2 is a block diagram of an exemplary personalized
content broadcast system;
[0019] FIG. 3a is a block diagram of the method according to an
implementation of the present principles;
[0020] FIG. 3b is a flow diagram of the method according to an
implementation of the present principles; and
[0021] FIG. 4 is a flow diagram of the method according to another
implementation of the present principles.
DETAILED DESCRIPTION
[0022] FIG. 1 shows a typical broadcast network system 100 adapted
for mobile broadcast. The original content signal 102 is sent
through a content transcoder 108 which compresses the audio-video
content fit for transmission (110) over a mobile network 111 to a
mobile client 112. In an on-demand device (e.g., Verizon Vcast
service), users are allowed to stream multimedia files to their
respective devices. In these services, the server sends out a
transcoded version of the content, with the bandwidth of the
transcoded version determined so as to not exceed the bandwidth
offered to the user over a unicast channel when it is requested by
the user. With networked streaming of video or other multimedia,
the instantaneous bandwidth of the compressed video at any point in
time is limited to the available network bandwidth, within the
bounds of a buffer at the client, in order to maintain continuous
video playback. If the instantaneous bandwidth exceeds the
available bandwidth, playback at the client is disrupted.
[0023] When compressed multimedia is transmitted as files, rather
than streamed, the bandwidth of the compressed multimedia does not
need to be matched to the network bandwidth. The transmission time
for the multimedia file does not need to correspond to the duration
of the content of the multimedia file.
[0024] On-demand services consume bandwidth for each individual
user, which is usually a very costly operation since it does not
scale very well for large number of subscribers to the service.
Although these practices bring down the bandwidth consumption, in
most cases it need not necessarily be optimal for network and
client device operations.
[0025] FIG. 2 shows a block diagram of a personalized broadcast
video system 200, which provides simple user interface for
personalization, while efficiently using network bandwidth and
minimizing receiver battery device usage. The system 200 includes a
head end 200, a broadcast network 210 and a receiver 240. The head
end includes an input clip 202, a scheduler 204, an electronic
service guide (ESG) generator 206 and a FLUTE server 208. The
receiver includes a FLUTE receiver 212, and ESG parser 214, a
content selection control 218, a user profile 216, a content
storage device 220, and an audio/video player 222.
[0026] The user profile 216 on the receiver device 240 indicates
the interests of the user. Individual clips 202 to be broadcast are
associated with flexible metadata tags, such as keywords, are sent
to the ESG generator 206 through the scheduler 204. When content,
particularly video programs, is broadcast, the receiver device 240
selects individual programs to record based upon calculating a
score corresponding to the program. The score is calculated for a
particular piece of content using the ESG content keywords and the
user's profile, which indicates a user's level of interest in
particular keywords. The user's profile 216 can adapt based upon
the user's viewing activity.
[0027] In an opportunistic bandwidth environment (i.e., Variable
Bit Rate), the output channel bandwidth is not constant. This
affects all the broadcast timing calculations for each content file
done by the scheduler 204. Hence, to provide a reliable schedule of
broadcast, the scheduler 204 needs to schedule broadcast of content
files in a timely manner, based on available bandwidth and its own
estimates of available bandwidth.
[0028] The scheduler 204 periodically outputs a schedule for
content file broadcasts. This schedule is in the form of an ESG is
communicated to a client device. In a unidirectional broadcast
environment, the receiver 240 depends heavily on the schedule and
meta-data information it gets for selective reception of the
content. It is important that the client receive the schedule in
advance of the actual broadcast time. The schedule broadcast by the
server 208 contains meta-data information such as broadcast times
for each content. The broadcast timing information is important to
the client, since a client can use this information to selectively
switch on and off its receiver components based on the broadcast
times of different content, and hence make selective reception of
content viable. Also, since the client is switching its receiver
components on only when needed, there is efficient user of the
client's power resources.
[0029] The scheduler 204 has a transmission monitor system (not
shown) which controls the transmission of content files according
to the schedule. The transmission monitor system updates the
scheduler 204 with transmission status of each clip and variations
in output channel speed.
[0030] According to the present invention, users of broadcast
content services, such as those using the above-described systems,
may receive content with varying compression formats depending on
the bandwidth at the time the content was scheduled to be
broadcast. In such systems, the content files are also scheduled to
be re-broadcast as decided by the scheduler. If during the
re-broadcast the amount of bandwidth is sufficiently high, then the
scheduler may choose to broadcast a higher quality format of the
content file.
[0031] By way of example, consider an audiovisual content Clip A is
transcoded into two different compression formats, ClipA_lowComp
and ClipA_highComp, with higher and lower bandwidth usages,
respectively. The operator provides a number of live television
services that generally use up most of the available bandwidth.
[0032] Referring to the exemplary implementation shown in FIG. 3a,
there is shown the method 275 according to an implementation of the
present principles. Initially, the bandwidth of a communication
channel is established (280). Those of skill in the art will
recognize that there are many different methods for establishing
the bandwidth of a communication channel. It is to be understood
that the present principles can be applied using any suitable
method for establishing the bandwidth of the channel. Once
established, the bandwidth information is transmitted (282) to the
client device over the communication channel. At this point, a
version of the data is transmitted (284) over the communication
channel in response to a comparison between the established
bandwidth and a bandwidth threshold.
[0033] FIG. 3b shows the method 300 according to an implementation
of the present principles. Initially, the scheduler 204 processes
its database of content files and decides to output a schedule
based on current estimates of bandwidth (302). The schedule is then
transmitted (304) to a client device 240. The client device now has
an estimate of the times when each content file is going to be
broadcast. Based on this information, the client can optimize its
receiver routines.
[0034] Before the broadcast of each file, the scheduler 204 of the
service can be configured with an initial value of the bandwidth,
or can be configured to make an estimate of the available bandwidth
(302).
[0035] According to one implementation, the bandwidth thresholds
can be established as being half of the initial value or estimated
value of the bandwidth. If at the beginning, the bandwidth
threshold is at a high value, BW_HIGH, the scheduler 204 would
choose to broadcast ClipA_lowComp which is of lower compression and
hence higher quality but with more bandwidth usage. If during some
time elapse, the bandwidth allocated to the service changes, the
schedule would be affected. The scheduler would normally detect
this through its transmission control module. For example, if the
bandwidth of the channel now fell to a lower threshold value,
BW_LOW, the scheduler detects that change in the bandwidth, which
now affects the schedule of its content file broadcasts. This is
the example shown in FIG. 3.
[0036] The scheduler 204, instead of re-scheduling all of its
content files, will now choose to broadcast ClipA_highComp (308),
which is highly compressed version of the content file whose
quality and bandwidth usage may be lower but acceptable to the
user. If the bandwidth at a later point of time increases to a
value BW_HIGH, and content file Clip A is scheduled for a
re-broadcast, then this time around the scheduler changes the
threshold in the decision block 306 and would choose to broadcast
Clip A_lowComp (310) and the client on receiving this content could
potentially detect this as a higher quality version of a previous
file and choose to replace the lower quality content file,
ClipA_highComp.
[0037] The scheduler 204 chooses the version of the file to be
broadcast so that it would still maintain the timeliness of its
schedule. The client, hence, sees no change in the schedule
although there was a change in the bandwidth that was allocated to
the service. In this manner, the client device sees a seamless
operation of the service.
[0038] FIG. 3 shows the example where the threshold determination
of decision block 306 is BW_LOW. Those of ordinary skill will
recognize that changing the threshold from BW_LOW to BW_HIGH will
reverse the "yes" and "no" decisions of the shown implementation.
This is shown, by way of example, in the flowchart of FIG. 4. Here,
the steps 402, 404, 406 all correspond to the same steps 302, 304,
306, respectively. When the bandwidth threshold is above BW_HIGH,
(otherwise, a "no" determination), the A_highComp clip is
transmitted 408. When the bandwidth threshold is below BW_HIGH, the
A_lowComp clip is transmitted 410.
[0039] It is to be understood that the present principles may be
implemented in various forms of hardware, software, firmware,
special purpose processors, or a combination thereof. Preferably,
the present principles may be implemented as a combination of
hardware and software. Moreover, the software is preferably
implemented as an application program tangibly embodied on a
program storage device. The application program may be uploaded to,
and executed by, a machine comprising any suitable architecture.
Preferably, the machine is implemented on a computer platform
having hardware such as one or more central processing units (CPU),
a random access memory (RAM), and input/output (I/O) interface(s).
The computer platform also includes an operating system and
microinstruction code. The various processes and functions
described herein may either be part of the microinstruction code or
part of the application program (or a combination thereof) that is
executed via the operating system. In addition, various other
peripheral devices may be connected to the computer platform such
as an additional data storage device and a printing device.
[0040] It is to be further understood that, because some of the
constituent system components and method steps depicted in the
accompanying Figures are preferably implemented in software, the
actual connections between the system components (or the process
steps) may differ depending upon the manner in which the present
principles is programmed. Given the teachings herein, one of
ordinary skill in the related art will be able to contemplate these
and similar implementations or configurations of the present
principles.
* * * * *