British Telecommunications Public Limited Company

Palo Alto Research Center Inc.

British Telecommunications Corporation

Ian Barry Crabtree

Michael Erling Nilsson

Rory Stewart Turnbull

Stephen Clifford Appleby

Timothy Sean Stevens

Richard John Titmuss

Nicolae Marius Busuioc

Patrick J Mulroy

Matthew J Polaine

John J O'Donoghue

Jeremy M Bowskill

Brahim Allan

Bharat Purohit

Alexander Loffler

Jacob Yadegar

Glenn Carter Scott

Ignacio Solis

Michael F Plass

Timothy Stevens

Charles A Swaine

Ivan Roper

Stephen Charles Baker

John Joseph O'donoghue

Matthew John Polaine

Jeremy Michael Bowskill

Michael Eilling Nilsson

Stephen Clifford Aplleby

Patrick Joseph Mulroy

Examples of the present invention provide a method of converting a multicast stream into unicast segments. In particular, sequence identifiers are generated based on a clock reference field in the transport stream packets that make up the multicast stream. Every time a new sequence identifier is calculated, a new unicast segment is generated and assigned with the new sequence identifier. Transport stream packets are placed into the new segment until a packet is processed that causes a new sequence identifier to be generated, at which point another new segment is generated and packets placed into that segment. In an improved method, random access indicators in the transports stream packets are used to further constrain when a new segment is generated, to ensure that new segments are coincident with a packet having a random access indicator. This improvement makes random access easier back and forth between and within a stream.

Multicast to unicast conversion

The invention presents a method of providing feedback for receipt of a multicast video stream. The feedback mechanism allows the number of clients receiving over multicast to be determined, which can then be used to manage multicast delivery, including switching decisions between multicast and unicast. Video content is delivered over a multicast stream from a content server to a plurality of client devices. The client devices are each configured to respond at regular intervals whilst receiving the multicast video stream by transmitting an HTTP HEAD request message to the content server. The HTTP HEAD request refers to metadata relating to a manifest file associated with the video stream. The number of client devices receiving the multicast video stream is determined based on the number of HEAD requests received at the content server. The multicast video delivery can then be managed accordingly, and can also take into account the number of unicast clients that are requesting the corresponding unicast stream to the multicast stream.

Multicast streaming

Examples of the present invention present a method of controlling content delivery in a network. A global quality of experience measure, QoE, is calculated based on the packet loss rate in the network. As packet loss rate varies as a result of congestion conditions in the network, so will QoE. A server delivering content over the network will attempt to reach QoEfor the content in its respective session. Those sessions with a quality of experience, QoE, less than QoEwill have its packet dispatch rate increased, and those with a QoE higher than QoEwill reduce its packet dispatch rate, subject to any delivery deadlines associated with the session. If the delivery deadlines of the sessions can be met without exceeding QoE, then all sessions will end up achieving QoE. Since QoEis only a function of packet loss rate that all sessions miming over the same shared network agree upon, all sessions should converge on the same QoE.

Deadline driven content delivery

The invention presents a method of providing a modified manifest to a video client for streaming a video sequence associated with the manifest. An original manifest is modified to replace references to locations of lower quality, or bit rate, segments with references to equivalent segments at a higher quality, or bit rate, if the higher quality segment is cached locally. Then, when the video client determines that a given quality of segment should be streamed, it uses the modified manifest to retrieve the appropriate reference for that segment, and if a replacement has taken place, will be provided with the reference to the replacement segment at the higher quality. Thus, the client will always be provided with the highest possible quality segment taking into account local caching.

Video caching

A method for providing equitable media streaming between an HTTP server and a number of receivers via shared network. The streaming data is processed to split the data across a number of sub-streams. Each sub-stream contains non-contiguous data. A receiver requesting the streaming media establishes a number of TCP sessions, one for each sub-stream and the received sub-stream data is reassembled at the receiver so that the streaming media can be presented.

Content delivery

A client device receives streamed encoded content data, such as encoded video data, which has been encoded at a constant perceptual quality. Several different versions of the content are available to be streamed to the device, at different perceptual quality levels. In order to decide which quality level to request from a content server at intervals the device calculates the delivery rates that would be required for each level of quality. The calculation of the delivery levels is made in dependence on whether the actual delivery rate that has been received so far is greater than or less than a constant bit rate delivery schedule that decreases monotonically but which guarantees to deliver the encoded data in a timely manner such that no buffer underflow and interruption of reproduction takes place. The monotonically decreasing bit rate schedule is defined by one or more 'critical points', which are the points at which the bit rates are decreased, and correspond to the points where the delivery schedule is just equal to the decoding schedule of the encoded data. At such points there would be no encoded data in a buffer at the client. If the delivery rate has been greater than the constant bit rate schedule for a quality then the delivery rate required going forward for a particular quality level can be calculated from the critical point information, and no more complicated calculation is required.

Method for delivering video content encoded at one or more quality levels over a data network

A route-tracing application can measure the performance of a path in a named-data network using trace agents deployed across various network nodes. During operation, a network node can process a route-tracing Interest by performing a lookup operation in a forwarding information base (FIB) using the Interest's name, in which a respective FIB entry may map the name to a forwarding rule. If the FIB does not include an entry for the Interest's route-tracing name, a trace agent at the network node determines one or more outbound interfaces for the route-tracing operation based on the Interest's name, and creates new route-tracing FIB entries that each maps the Interest's name to a forwarding rule for the determined interfaces. The network node returns a Content Object that satisfies the Interest, in which the Content Object includes the names of the new FIB entries, as well as performance information for the path.

End-to end route tracing over a named-data network

One or more network based video servers is/are connected to one or more video receivers over a shared network. Pieces of video content are each encoded at a number of constant quality levels and stored on one or more of the network based servers. Responsive to requests from a receiver, video content is selected on a server and delivered over the shared network to the receiver. The system selects the quality level of the stream to deliver based on characteristics of the video stream currently being delivered, and the number of bits already buffered at the video receiver and the available network throughput. The aim is to select the video quality being delivered according to the available network throughput to maximize quality while ensuring that video data is delivered over the network in time to be decoded and displayed without interruption. Certain exemplary embodiments make that selection in advance.

Video streaming

A client device receives streamed encoded content data, such as encoded video data, which has been encoded at a constant perceptual quality. Several different versions of the content are available to be streamed to the device, at different perceptual quality levels. In order to decide which quality level to request from a content server at intervals the device calculates the delivery rates that would be required for each level of quality. The delivery rates are calculated in dependence on so-called critical points, which are points at which a piecewise constant bit rate delivery schedule is just equal to the decoding schedule. There are two classes of critical points, being a first class of critical points, referred to herein as 'additional critical points', which are points on the decoding schedule where, for any particular other point on the decoding schedule before an additional critical point, and assuming that a minimum threshold amount of data is buffered when delivery occurs from the particular point, a constant bit rate delivery schedule that is calculated for the particular point taking into account the buffered minimum amount of data and of such a rate such that buffer underflow does not occur is substantially equal to the decoding schedule. A second class of critical points, referred to herein as 'downstairs critical points', is also defined, which are derived from the decoding schedule as a whole, and which are the points at which a piecewise monotonically decreasing constant bit rate delivery schedule (the so-called &#x201c;downstairs&#x201d; schedule), which is calculated such that when delivering the encoded content data from the start buffer underflow does not occur, is substantially equal to the decoding schedule of the encoded content data. When the actual delivery rate received is ahead of the so-called &#x201c;downstairs&#x201d; schedule, then the delivery rate required for a particular quality level can be calculated from the second class of critical points. However, when the actual delivery rate received is behind the downstairs schedule, then the delivery rate required is calculated from the first class of critical points.

Video streaming over data networks

A plurality of video streams is transmitted over a transmission link. At intervals, one determines for each video stream at each of a plurality of encoder settings, having regard to the amount of data buffered at a receiver for that stream, a bit rate sufficient to transmit the remainder of that stream at that encoder setting such as to avoid buffer underflow at the receiver. One determines also a critical point equal to the earliest time at which that bit rate can be reduced while still avoiding buffer underflow at the receiver. An encoder setting is chosen for each video stream such that the sum of said bit rates required for transmission of the streams does not exceed the capacity of the transmission link. Any surplus capacity of the transmission link is allocated to the stream that has the earliest critical point.

Multiplexed video streaming

The network contains one or more network based video servers connected to one or more video receivers over a shared network. Multiple pieces of video content are each encoded at a number of constant quality levels and stored on one or more of the network based servers. In response to requests from a receiver, video content is selected on a server and delivered over the shared network to the receiver. The system selects the quality level of the stream to deliver based on characteristics of the video stream currently being delivered, and the number of bits already buffered at the video receiver and the available network throughput. The aim is to select the video quality being delivered according to the available network throughput so as maximise the quality while ensuring that all video data is delivered over the network in time for it to be decoded and displayed without interruption.

A video sequence is to be transmitted at a selectable quality from a server over a network. A network control protocol operates in response to a control parameter to allocate to the server a share of available transmission capacity in proportion to the value of the control parameter. First, one determines a plurality of transmission rate values that are needed over successive time periods of the sequence for successful transmission of the sequence at a reference quality; then the control parameter is set, proportional to the transmission rate value and communicated to the control protocol at corresponding time instants. The sequences can then be transmitted, encoded at a quality from time to time selected in dependence upon the actual transmission capacity made available by the network to the server.

Embodiments of the present invention provide a compact representation of a cumulative bit curve formed from piece-wise straight line approximations between upper and lower bounds about an actual cumulative bit curve (CBC). In one embodiment the lower bounds are found by applying a constraint such that if a delivery rate was to be calculated using the count at the lower bound it would result in a delivery rate which was greater than the delivery rate that would be calculated using the actual CBC data by a particular amount, for example 10%. The actual CBC data is then used as an upper bound. As a result, the approximated CBC will lie for each GoP between the actual CBC value and the lower bound, with the result that one can be certain that any data rate that is calculated using the approximation will be at least as high as a data rate that is calculated using the actual CBC data. In terms of line-fitting algorithms that are used, several different algorithms may be used of differing complexities, with the intention of trying to minimize the number of end-points required of within the piecewise approximation.

Compact cumulative bit curves

There is proposed a modification to the ECN protocol to remove the one-to-one relationship between the network signalling congestion and the sender response to that congestion. The result is to allow a receiver terminal to exhibit some control of bandwidth share relative to other receiver terminals. The idea is to calculate the average CE arrival frequency from received data packets and to set ECE flags at a rate determined as a function of the average CE arrival frequency. Preferably, the function is a multiplier applied to the average CE arrival frequency. The effect of averaging the CE arrival frequency as well as application of a multiplier is a decoupling of the ECE marked ACKs sent by a receiver to the sender, and control of the resulting transmission rate at the sender.

Controlling bandwidth share

An index to a plurality of entities is built, where each entity is represented by a point defined in a space. Entities whose points are furthest apart are identified. A first area is created, the extremities of which first area are given by the points representing the identified entities. Entities falling within the first area are assigned to a storage area corresponding to the first area. The first area is divided into a plurality of second areas. For each of the plurality of second areas, a. each of the plurality of second areas is linked to the first area, and, b. the above steps are repeated until the first area includes a single point. Storage areas corresponding to each of the first area are then written to the index.

Growing community of inventors

Ipswich, United Kingdom

Ian Barry Crabtree