WO2005084031A1

WO2005084031A1 - Method and apparatus for varying a data rate in broadcast/multicast video systems

Info

Publication number: WO2005084031A1
Application number: PCT/US2004/004825
Authority: WO
Inventors: John Gervais; Mike Derrenberger
Original assignee: Thomson Licensing S.A.
Priority date: 2004-02-18
Filing date: 2004-02-18
Publication date: 2005-09-09

Abstract

An upstream distribution point of a video distribution system adjusts a transmission data rate of at least one program channel as a function of tuning data associated with at least one endpoint. In one illustration, the upstream distribution point of a cable broadcast system receives tuning data representing the currently tuned, or selected, program from one or more set-top boxes via Internet Group Management Protocol (IGMP) signaling The upstream distribution point collects the tuning data from the one, or more, endpoints and adjusts a transmission data rate for at least one program channel as a function of the received tuning data.

Description

METHOD AND APPARATUS FOR VARYING A DATA RATE IN BROADCAST/MULTICAST VIDEO SYSTEMS

BACKGROUND OF THE INVENTION

[0001] The present invention generally relates to communications systems and, more particularly, to multi-media communications systems, such as, e.g., a cable broadcast system. [0002] In a multi-media communications system such as, e.g., a cable broadcast system, a cable provider (or system operator) transmits, or broadcasts, video programs (content) to subscribers. This transmission typically takes place from an upstream distribution point, e.g., a cable head-end, over the transmission medium, e.g., cable, to an endpoint, e.g., a set-top box located at a subscriber's home. In such a system, the cable provider may transmit 100 channels, or more, of programming to subscribers — even when no subscribers are watching them. This, in effect, wastes bandwidth that could otherwise be used for additional or new services.

SUMMARY OF THE INVENTION [0003] Therefore, and in accordance with the principles of the invention, a distribution point adjusts a transmission data rate of at least one program channel as a function of received tuning data, wherein the received tuning data represents selection data for the at least one program channel. [0004] In an embodiment of the invention, an upstream distribution point of a video distribution system (e.g., a cable broadcast system) receives tuning data representing the currently tuned, or selected, program from one or more endpoints (e.g., set-top boxes). Illustratively, the upstream distribution point receives the tuning data via signaling using a modified IGMP (Internet Group Management Protocol). The upstream distribution point collects the tuning data from the one, or more, endpoints and adjusts a transmission data rate for at least one program channel as a function of the received tuning data.

[0005] In another embodiment of the invention, an upstream distribution point of a video distribution system (e.g., a cable broadcast system) stores tuning data representing historical data with respect to program selection for one or more endpoints (e.g., set-top boxes). The upstream distribution point adjusts a transmission data rate for at least one program channel as a function of the stored tuning data. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] FIG. 1 shows an illustrative video distribution system in accordance with the principles of the invention;

[0007] FIG. 2 shows an illustrative flow chart in accordance with the principles of the invention for use in head-end 5 of FIG. 1 ;

[0008] FIG. 3 shows an illustrative viewer history list in accordance with the principles of the invention;

[0009] FIGs. 4 and 5 show other illustrative flow charts in accordance with the principles of the invention for use in head-end 5 of FIG. 1 ; [0010] FIG. 6 shows an illustrative data rate adjustment table in accordance with the principles of the invention;

[0011] FIG. 7 shows an illustrative flow chart in accordance with the principles of the invention for use in set-top box (STB) 10 of FIG. 1 ;

[0012] FIG. 8 shows an illustration of IGMP (Internet Group Management Protocol) message flow;

[0013] FIG. 9 shows a modified IGMP packet in accordance with the principles of the invention;

[0014] FIG. 10 shows modified IGMP message flow in accordance with the principles of the invention; and [0015] FIG. 1 1 shows another illustrative flow chart in accordance with the principles of the invention for use in STB 10 of FIG. 1.

DETAILED DESCRIPTION

[0016] Other than the inventive concept, the elements shown in the figures are well known and will not be described in detail. As used herein the terms "multi-media communications system" and "video distribution system" are used interchangeably. Also, familiarity with video distribution systems, such as cable, satellite, terrestrial, etc., is assumed and is not described in detail herein. For example, other than the inventive concept, satellite transponders, cable head-ends, set-top boxes, downlink signals, symbol constellations, predistorters, a radio-frequency (rf) front-end, or receiver section, such as a low noise block, formatting and encoding methods (such as the Moving Picture Expert Group (MPEG)-2 Systems Standard (ISO/IEC 13818-1 )) for generating transport bit streams and decoding methods such as log-likelihood ratios, soft-input-soft-output (SISO) decoders, Viterbi decoders and a master program guide (MPG) are well-known and not described herein. In addition, the inventive concept may be implemented using conventional programming techniques, which, as such, will not be described herein. Finally, like-numbers on the figures represent similar elements.

[0017] A portion of an illustrative video distribution system 20 in accordance with the principles of the invention is shown in FIG. 1. Video distribution system 20 includes an upstream distribution point 5, a communications channel 7, at least one downstream receiver, or endpoint, as represented by set-top box (STB) 10 and a multi-media endpoint as represented by television (TV) 15. Although described in more detail below, the following is a brief overview of video distribution system 20. Illustratively, video distribution system 20 is a cable broadcast system. In this context, upstream distribution point 5 is, e.g., a cable- head-end 5 (hereafter head-end 5). Head-end 5 is a stored-program-processόr based system and includes at least one processor (e.g., a microprocessor) with associated memory as represented by processor 2 and memory 3, along with a transmitter and receiver as represented by transceiver 1, and an encoder 6. Head-end 5 receives a number of data streams as represented by signals 4- 1 through 4-K and encodes them for transmission via encoder 6 and transceiver 5. Illustratively, each of these K data streams represents a program channel for conveying, e.g., video, audio and/or data. It should be noted that although shown as K separate data streams, head-end 5 may receive one or more data streams that represent aggregations of program channels. Some of the K program channels may represent Pay-Per- View (PPV) and/or Video-on-Demand (VoD) channels and others of the K program channels may represent program channels associated with basic service packages or program channels associated with different pricing structures, e.g., premium service channels. In this regard, head-end 5 distributes the programming to a number of receivers, as represented by STB 10, via communications channel 7, e.g., a coaxial cable, fiber-optic cable, etc. Communications channel 7 supports a downstream channel 8, for conveying program channels (content) from head-end 5 to STB 10, and an upstream channel 9, for conveying data from STB 10 to headend 5. As known in the art, and other than the inventive concept, the upstream channel is also known as a reverse channel or back channel. Illustratively, the upstream channel and the downstream channel occupy different frequency bands. Turning now to STB 10, STB 10 provides programming to TV 15 via signal path 11. In particular, STB 10 also includes a selector, e.g., a remote control (not shown) that enables a user to select a program for viewing on TV 15. When the user indicates selection of a particular program channel via the remote control, STB 10 tunes to the selected program channel and provides the associated content to TV 15 via signal path 1 1, for viewing thereon. It should be noted that whether a program channel is a pay-per-view channel and/or a scrambled channel, etc., is irrelevant to the inventive concept.

[0018] As noted earlier, some program channels are not selected for viewing by the user.

This may result in wasting the associated bandwidth. Therefore, and in accordance with the principles of the invention, a distribution point (e.g., head-end 5) adjusts a transmission data rate of at least one program channel as a function of tuning data associated with at least one endpoint (e.g., STB 10).

[0019] Turning now to FIG. 2, an illustrative flow chart in accordance with the principles of the invention for use in head-end 5 is shown. In step 205, head-end 5 stores a viewer history for a collection of program channels in memory (e.g., in memory 3 of FIG. 1). The collection of program channels comprises I program channels, where J ≥ 0 and J is ≤ K. In other words, the collection of program channels may include all of the available program channels in video distribution system 20, i.e., J = K, may be as small as a single program channel, i.e., J = 1 , or even represent zero program channels if, e.g., the feature is available in video distribution system 20 but not being used, etc. For example, if video distribution system 20 offers 105 program channels, four of these program channels may be included in this collection of program channels. Further, these / program channels themselves may be priced differently than other program channels. An illustrative viewer history record, or list, 301 is shown in FIG. 3. Viewer history list 301 includes J rows, each row associated with a particular one of the J program channels. For each program channel, respective values for the associated channel identifier field 302, program channel downstream frequency field 303, packet identifier (PID) field 304, number of viewers field 306 and adjustable data rate field 307 are listed. The channel identifier (e.g., channel 2), program channel downstream frequency and PID values are predefined, e.g., in a master program guide (MPG) available to head-end 5. The value in the number of viewers field 306 represents the number of viewers associated with the respective program channel (described further below). The value in the adjustable data rate field 307 represents whether or not the associated program channel is "available" for data rate adjustment, e.g., "yes" or "no." As can be observed from viewer history list 301 , the last program channel entry, Fj, is illustratively not available for data rate adjustment. Alternatively, program channels not available for data rate adjustment may simply not be listed on the viewer history list. After the viewer history for the collection of programs has been stored, head-end 5 adjusts the date rate for each of the J program channels as a function of the stored viewer history for that channel in step 210 (described further below). Step 210 may be performed periodically, e.g., every five minutes, or a periodically. [0020] As described above, head-end 5 stores the viewer history for the collection of program channels in step 205. An illustrative flow chart for performing step 205 is shown in

FIG. 4. In step 305, head-end 5 receives tuning data representative of the viewer history with respect to the collection of program channels. That is, the tuning data represents selection data for one, or more, program channels. In this regard, the tuning data may be viewed as either "static" or "dynamic." With respect to "static" tuning data, this relates to the receipt by head-end 5 of viewer history statistics from, e.g., a source of viewer history data, such as a

Neilson-type rating service. Such static viewer history data may be received via, e.g., an

Internet connection (not shown), from removable media, e.g., a CD-ROM, etc. With respect to "dynamic" tuning data, this relates to head-end 5 periodically, or a periodically, accumulating viewer statistics from one or more of the endpoints of video distribution system 20, such as STB 10, via transceiver 1 of FIG. 1 (described further below). As tuning data is received in step 305 of FIG. 3, head-end 5 updates viewer history list 301 in step 310 to indicate the number of subscribers (viewers) currently associated with watching a particular program channel. In the case of static tuning data, head-end 5 simply stores the received tuning data in viewer history list 301. It should be noted that in the case of static tuning data, the number of viewers indicated in viewer history list 301 will likely not represent the actual number of viewers watching at that time but, instead, represents an estimate based on data previously collected, e.g., by the above-mentioned Nielson-type service. With respect to dynamic tuning data, head-end 5 must additionally process the received tuning data to determine for each of the J program channels the number of subscribers currently tuned to a particular program channel. For dynamic tuning data, it should be noted that while the number of viewers indicated in viewer history list 301 will likely better approximate the number of viewers currently watching a particular program channel, this is also dependent on how frequently head-end 5 receives and processes the tuning data. For example, the number of viewers for any particular channel on viewer list 301 may represent a current "snap shot," or head-end 5 may further statistically process the tuning data from the STBs such that the number of viewers for any particular channel represents an average over a predefined time period. It should also be noted that as described herein an endpoint is assumed to represent one viewer, when in fact more than one viewer may be co-located at an endpoint (e.g., an STB) watching a program on, e.g., TV 15 of FIG. 1.

[0021] After storing the viewer history, and as describer earlier, head-end 5 adjusts the data rate for each of the J program channels as a function of the stored viewer history for that channel in step 210. An illustrative flow chart for use in performing step 210 is shown in FIG. 5. For each program channel included in viewer history list 301 , head-end 5 performs steps 405, 410 and 415. In step 405, head-end 5 checks the value of adjustable data rate field

307, i.e., if the program channel is capable of having its data rate adjusted. (As noted above, this step is not necessary if, e.g., the above-noted "adjustable data rate" field is not used in viewer history list 301.) If the program channel is not available for data rate adjustment, execution proceeds to step 415. However, if the program channel is available for data rate adjustment, execution proceeds to step 410, which adjusts the data rate for the program channel (described below) before proceeding to step 415. The latter step checks if this is the last program channel of viewer history list 301. If this is the last program channel of viewer history list 301 , execution ends. On the other hand, if this is not the last program channel of viewer history list 31 1 , then execution continues in step 405 with the next program channel on viewer history list 301.

[0022] In this illustration, and as can be observed from FIG. 3, the program channel associated with CH_/, E/ and PID/, is capable of having its data rate adjusted. As such, in step 405 execution proceeds to step 410, where head-end 5 adjusts the data rate as a function of the received tuning data. Illustratively, head-end 5 refers to a data rate adjustment table such as illustrated in FIG. 6 to determine the particular data rate for the associated program channel as a function of the received tuning data. Data rate adjustment table 31 1 associates different ranges of viewers 312 with particular data rate values, or characterizations, 313. For example, if a program channel has less than or equal to 100 viewers, then the associated data rate is "low;" if the program channel has between 100 and 1000 viewers, then the associated data rate is "medium;" and if the program channel has more than 1000 viewers, then the associated data rate is "high." It should be noted that the granularity of data rate adjustment table 31 1 is merely illustrative both as to the number of viewer ranges, the values for each of the viewer ranges and the various data rate characterizations. It should also be noted that in place of an adjustment table, head-end 5 may use a data rate adjustment equation (not shown) that provides a recommended data rate value as a function of the number of viewers. [0023] Continuing with this example, when head-end 5 checks data rate adjustment table

31 1 as a function of the number of viewers associated with channel identifier CΗ] of viewer history list 301 , head-end 5 adjusts the data rate for this program channel to "low" in step 410 since the number of viewers is less than 100. Likewise, when head-end 5 performs this check for the program channel associated with channel identifier CH₂, head-end 5 adjusts the data rate to "medium." It should be observed, that in this example when head-end 5 progresses down viewer history list 301 to the program channel associated with channel identifier CH₃, this program channel is not available to have its data rate adjusted and step 410 is not performed.

[0024] As described above, the data rate adjustment is illustratively performed in the context of a number of finite data rate levels: low, medium and high. As noted above, the number of data rate levels is not restricted to three and there can be more or less data rate levels. Further, the inventive concept is not limited to discrete data rate levels but may also utilize a spectrum of continuous data rate variations and/or a combination of discrete data rate levels and continuous data rate ranges. In this example, each of the above-described low, medium and high data rate levels is associated with a particular data rate. For example, the "low" data rate is illustratively 600 Kbits/sec. (thousands of bits per second); while the "medium" data rate is illustratively 1.5 Mbits/sec. (millions of bits per second), and the "high" data rate is 5 Mbits/sec. It should be noted that one of the number of data rate levels can also be zero, e.g., if no viewers are currently watching the program then head-end 5 disables transmission. In this case it may be preferable for the set-top box to provide a locally-stored still image to the user upon selection of the program channel. Alternatively, a still picture image may be provided to the set-top box at a very low bit rate if there are no viewers. The still image preferably alerts the user to an additional time delay for tuning to the program channel. [0025] It should be noted that head-end 5 can adjust the data rate for a particular program channel in step 410 in any number of ways. For example, and referring back to FIG. 1 , processor 2 of head-end 5 adjusts the encoding rate of encoder 6, via signal path 12, to the associated data rate. As such, a "low" data rate is representative of producing a low resolution video signal, a "medium" data rate is representative of producing a medium resolution video signal; and a "high" data rate is representative of producing a high resolution video signal. [0026] Thus, as described above, head-end 5 adjusts, or varies, the data rate of programming proportional to the number of views watching a particular program. As such, head-end 5 can increase the bandwidth allocation of, e.g., a PPV service, by using at least a portion of the bandwidth previously associated with, e.g., a "high" data rate program channel that is subsequently downgraded to a lower data rate. In addition, it should be noted that the data about the number of viewers watching a given program at a given time may be valuable and, as such, may also be marketable as a service or product to content providers. It may also be of value to organizations such as those engaged in a Nielsen-type rating service. [0027] As described above, one, or more, endpoints may send tuning data back upstream to head-end 5. Turning now to FIG. 7, an illustrative flow chart in accordance with the principles of the invention for use in STB 10 is shown. In step 320, STB 10 tunes to a selected program channel, e.g., at power-up, or in response to a user (not shown) selecting one of a number of available program channels via a remote control, etc. In step 325, STB 10 sends information (tuning data) relating to the selected program channel upstream to head-end 5. While the tuning data can take any form that identifies the selected program channel, it is assumed herein that the tuning data includes the associated downstream frequency in MHz

(millions of hertz) for the selected program channel, along with the associated packet identifier (PID) for the content (video, audio, data, etc.) of the selected program channel.

Both the downstream frequency and PID data are available from, e.g., a master program guide (MPG) stored in STB 10. Illustratively, step 325 can be performed every time the user selects a channel or, e.g., after STB 10 has been tuned to the selected program channel for a predetermined amount of time, e.g., five minutes. For example, STB 10 can notify head-end 5 each time the user changes channels. [0028] Illustratively, and in accordance with the principles of the invention, STB 10 uses a modified form of the Internet Group Management Protocol (IGMP) for signaling head-end 5 as to the currently selected program channel. Other than the inventive concept, the IGMP protocol is well-known and not described in detail herein. The IGMP protocol allows internet hosts to participate in multicasting and is defined in RFC (Request for Comment) 1 1 12 and RFC 2236. A typical message flow in accordance with the IGMP protocol is shown in FIG. 8 between an IGMP router and multiple IGMP hosts (individually not shown). For example, a first IGMP host (not shown) sends a "join group" message 106 to the IGMP router for joining a particular multicast group. Since this is the first host to request to join the particular multicast group (hence the "first join group" message 106), the IGMP router begins transmission of the multicast as represented by start data flow 121. Subsequently other IGMP hosts may also request to "join" the particular multicast group as represented by join group messages 107 and 108. Further, IGMP supports query (122) and response ( 109) messages between the IGMP router and individual ones of the IGMP hosts. Finally, IGMP hosts may eventually end receipt of the multicast by sending a "leave group" message as represented by leave group messages 1 10 and 1 1 1. When the last leave group message is received as represented by "last leave group" message 1 1 1 , the IGMP router ends the multicast transmission as represented by end data flow 123.

[0029] The IGMP protocol can be divided into two distinct portions. The upper portion of the protocol consists of well-defined messaging between a host and a multicast router and the associated membership state machines. The lower portion is tied to the IP (Internet Protocol) addressing and packet forwarding schemes. In accordance with a feature of the invention, this lower portion is discarded and the upper IGMP protocol is used to manage any type of non-IP multicast network such as the representative cable network of FIG. 1.

Illustratively, head-end 5 incorporates the characteristics of the above-described IGMP router while each STB acts as an IGMP host. The above described, join, leave, query and response packets of the IGMP protocol are illustratively exchanged via communications channel 7.

[0030] An illustration of a modified IGMP packet format is shown in FIG. 9. IGMP packet 50 includes a number of fields: version field 55, type field 60, unused field 65, checksum field 70, downstream frequency field 75 and packet identifier (PID) field 80. The illustrative format of IGMP packet 50 is based on IGMP version 1. It should be noted that other versions of IGMP can be modified in a similar fashion. The version field 55, type field 60, unused field 65 and checksum field 70 are as defined in the above-mentioned RFCs. The version field 55 is a four bit field that stores version information and is illustratively set equal to a binary value of one. The type field 60 is also a four bit field and specifies the IGMP type and is illustratively set to a binary value of one. The unused field 65 is an eight bit unused field, the checksum field 70 is a sixteen bit checksum over the IGMP packet. [0031] In accordance with the principles of the invention, the structure of the IGMP packet format is preserved with the thirty-two bit group address field (not shown) now replaced by downstream frequency field 75 and packet identifier field 80. The downstream frequency field 75 and the packet identifier field 80 represent the relevant parameters of a program channel. Thus, a program channel, in effect, is treated like a multicast group to which any STBs can join or leave. In accordance with the principles of the invention, the downstream frequency field 75 is a 16 bit value representing the frequency in MHz (millions of hertz) of the currently selected program channel and the packet identifier field 80 is also a sixteen bit field representing the PID value for the selected program channel. Both the value of the downstream frequency field and the PID for the selected program channel are available from, e.g., a master program guide (not shown) previously transmitted, or downloaded, to, e.g., STB 10 by head-end 5. It should be noted that other variations of an IGMP protocol are also possible. For example, and in accordance with the principles of the invention, a new type can also be defined, e.g., a type 6 (binary value of 6) associated with the transmission of tuning data in an IGMP packet.

[0032] Referring now to FIG. 10, an illustrative message flow in accordance with the principles of the invention is shown between head-end 5 and STB 10. As noted above, in the context of the invention, each program channel is treated as if it were a multicast group, i.e., a program channel group. As such, when STB 10 is tuned to a selected program, STB 10 sends a respective "join group" message 151 to head-end 5, i.e., STB 10 joins a group of STBs currently tuned to that program channel. The join group message 151 includes the down stream frequency and the PID for the program channel that STB 10 is currently tuned to receive. Other STBs (not shown) may also join this same program channel group or other program channel groups as represented by join group message 152. Thus, head-end 5 tracks those program channels that are currently being selected by STBs, e.g., using the flow chart illustrated in FIG. 4, to determine the number of viewers for each of the program channels.

[0033] Conversely, although not required, STB 10 may leave a program channel group by sending a leave group message 153, where, again, the leave group message identifies the down stream frequency and associated PID of the program channel that STB 10 is no longer tuned to receive. This optional operation is shown in dashed-line form in FIG. 10. Similarly, other STBs (not shown) may also leave this same program channel group or another program channel group as represented by leave group message 154. It should be observed that in the context of a message flow, once a "leave group message" is sent from an STB to the head-end, that STB will likely shortly follow with a "join group message" since an STB is typically always tuned to at least one program channel. However, this is not required. For example, an STB may not be required to send a "join group message" when the STB tunes to a program channel associated with a electronic program guide, or an STB may not send a "join group message" unless the STB is tuned to a program channel for at least a predefined amount of time (e.g., the above-noted five minutes).

[0034] Turning now to FIG. 1 1 , an illustrative embodiment of STB 10 is shown. It should be noted that only those elements of STB 10 relevant to the principles of the invention are shown. STB 10 comprises a communications interface, e.g., cable interface 720, for coupling to communications channel 7, at least one processor as represented by processor 705, a memory 715 and a remote interface 710, which receives the earlier mentioned program channel selection from a remote control device (not shown) operated by a user. Processor 705 is representative of a stored-program processor, e.g., a microprocessor, that executes a program, or programs, (such as represented by the above-described flow charts of FIGs. 2 and 1 1) stored in memory 715, which may be internal and/or external to processor 705 and is volatile and/or non-volatile, as necessary. As can be observed from FIG. 1 1 , processor 705 receives signals from the cable interface 720 and provides signals, e.g., content, via signal path 11. [0035] It should also be noted that although described in the context of a cable-based video system, the inventive concept is not so limited and applies to terrestrial broadcast, satellite broadcast, etc. Also, although the return, or uplink, channel was illustrated as a part of the same communications medium as the downstream channel, this is not required and, e.g., the upstream channel may be of a different type and/or at a different physical location from the downstream channel. For example, the downstream channel can be a conveyed over a coaxial cable, while the upstream channel is conveyed over a dial-up telephone connection

(wired or wireless) via the public switched telephone network (PSTN). In addition, although the inventive concept was described in the context of static tuning data and dynamic tuning data, a mixture of either type may be used. Further, although in one example the STB initiates the sending of the tuning data to the head-end, e.g., via a modified form of IGMP signaling, this is not required. For example, the head-end may query each STB, which then provides a response as to the currently selected program channel. It should also be noted that groupings of components for particular elements described and shown herein are merely illustrative. For example, head-end 5 may be located further upstream in a distribution system such that other distribution points, or routers, are located between head-end 5 and STB 10. Also, although described in the context of video programming, it should be realized that the inventive concept applies to programming be it video, audio and/or data (e.g., executable code). In this regard, the term "program" may also encompass video, audio and/or data and the term "viewed" simply refers to the currently tuned program of the receiver regardless of whether the program represents video, audio and/or data.

[0036] As such, the foregoing merely illustrates the principles of the invention and it will thus be appreciated that those skilled in the art will be able to devise numerous alternative arrangements which, although not explicitly described herein, embody the principles of the invention and are within its spirit and scope. For example, although illustrated in the context of separate functional elements, these functional elements may be embodied on one or more integrated circuits (ICs). Similarly, although shown as separate elements, any or all of the elements may be implemented in a stored-program-controlled processor, e.g., a digital signal processor (DSP) or microprocessor that executes associated software, e.g., corresponding to one or more of the steps shown in FIGs. 2, 4, 5 and 7. Further, although shown as separate elements, the elements therein may be distributed in different units in any combination thereof. For example, STB 10 may be a part of TV 15. It is therefore to be understood that numerous modifications may be made to the illustrative embodiments and that other arrangements may be devised without departing from the spirit and scope of the present invention as defined by the appended claims.

Claims

CLAIMS 1. A method for use in an upstream distribution point of a video distribution system, the method comprising: receiving tuning data, the tuning data representing selection data for at least one program channel; and adjusting a transmission data rate of the at least one program channel as a function of the received tuning data.

2. The method of claim 1, wherein the adjusting step includes the steps of: determining a number of viewers for the at least one program channel from the received tuning data; and determining a value for the transmission data rate for the at least one program channel as a function of the determined number of viewers.

3. The method of claim 2, wherein the determining a value step includes the step of selecting one of a number of data rate values as a function of the determined number of viewers.

4. The method of claim 3, wherein the number of data rate values comprises at least two different data rate values.

5. The method of claim 1, wherein the received tuning data is provided by at least one endpoint of the video distribution system.

6. The method of claim 5, wherein the at least one endpoint is a set-top box.

7. The method of claim 5, wherein the received tuning data is provided via a modified form of IGMP (Internet Group Management Protocol) signaling.

8. The method of claim 7, wherein the modified form of IGMP signaling includes a packet comprising downstream frequency information and packet identifier information representing the programming that is currently being viewed.

9. The method of claim 1 , wherein the video distribution system is a cable broadcast system.

10. A method for providing a video broadcast service to a number of users, comprising: identifying at least one program channel as an adjustable data rate program channel; and providing the adjustable data rate program channel to the number of users, wherein a transmission data rate of the adjustable data rate program channel may at times be adjusted as a function of the number of viewers of the adjustable data rate program channel.

1 1. The method of claim 10, further comprising the step of storing a viewer history table, wherein the viewer history table includes data representative of the number of viewers of the adjustable data rate program.

12. The method of claim 1 1, further comprising the step of changing the transmission data rate of the adjustable data rate program channel as a function of the data stored in the viewer history table.

13. Apparatus for use in an upstream distribution point of a multi-media communications system, the apparatus comprising: an encoder for use in encoding at least one program channel for transmission to at least one endpoint; and a processor for adjusting an encoding rate of the encoder such that a transmission data rate of the at least one program channel varies as a function of selection data for the at least one program.

14. The apparatus of claim 13, wherein the upstream distribution point is a cable head- end.

15. The apparatus of claim 13, further including a memory for storing tuning data for the at least one program channel, the tuning data representing the selection data for the at least one program channel.

16. The apparatus of claim 14, wherein the memory also stores a data rate selection table for use in determining the encoding rate from the stored tuning data.

17. The apparatus of claim 13, further comprising a receiver for receiving the tuning data.

18. The apparatus of claim 17, wherein the receiver receives the tuning data via a modified form of IGMP (Internet Group Management Protocol) signaling.

19. The apparatus of claim 18, wherein the modified form of IGMP signaling includes a packet comprising downstream frequency information and packet identifier information representing the programming that is currently being viewed.

20. The apparatus of claim 13, wherein the multi-media communications system is a cable broadcast system.