Abstract: Content is received within a network by a content receiver based upon fetch requests by the content receiver to a content source, where the fetch requests for content are based upon a first adaptation logic scheme to fill a buffer of the content receiver at a selected rate and to download segments of content at selected encoding rates. A network priority is detected at the content receiver that includes an observed download rate at the content receiver that is greater than a fair share rate for other content receivers in the network. Fetch requests for content are revised in response to detection of the network priority, where the revised fetch requests are based upon a priority adaptation scheme that results in at least one of filling the buffer at a faster rate and downloading segments of content at higher encoding rates compared with the first adaptation logic scheme.

Abstract: A method is provided in one example embodiment and includes generating a transmission control protocol (TCP) flow; marking a plurality of packets of the TCP flow with one of two differentiated services code points (DSCPs) according to a proportion that is selected to control a throughput associated with the TCP flow; and communicating at least a portion of the plurality of packets to a network.

Abstract: A method is provided in one example embodiment and includes generating a bandwidth estimation for an adaptive bitrate (ABR) client; evaluating a current state of a buffer of the ABR client; and determining an encoding rate to be used for the ABR client based, at least, on the bandwidth estimation and the current state of the buffer. A fetch interval for the ABR client increases as the buffer becomes more full, while not reaching a level at which the ABR client is consuming data at a same rate at which it is downloading the data.

Abstract: A method is provided in one example embodiment and includes receiving media data at an adaptive streaming client; updating an estimated available bandwidth associated with a media stream associated with the media data; filtering the estimated available bandwidth; mapping the filtered estimated available bandwidth to a media bitrate for the media stream; and updating a target segment delay that is to control time intervals between consecutive segment downloads of the media stream.

Abstract: A method is provided in one example embodiment and includes receiving video data at an adaptive bitrate (ABR) client that includes a buffer; determining whether a buffer level for the buffer is below a target buffer level; applying a random delay for a fetch interval associated with requesting the video data; and requesting a next segment of the video data after the random delay. The random delay can provide for a plurality of fetch times to become decorrelated from each other.

Abstract: In one embodiment, a method includes identifying a current encoding rate requested by a client device for content received from a content source, setting at a network device a rate limit to limit the rate at which the content is received at the client device based on the current encoding rate, and adjusting the rate limit based on changes in the current encoding rate. The rate limit is set to allow the client device to change the current encoding rate to a next higher available encoding rate.

Abstract: A method is provided in one example embodiment and includes generating a bandwidth estimation for an adaptive bitrate (ABR) client; evaluating a current state of a buffer of the ABR client; and determining an encoding rate to be used for the ABR client based, at least, on the bandwidth estimation and the current state of the buffer. A fetch interval for the ABR client increases as the buffer becomes more full, while not reaching a level at which the ABR client is consuming data at a same rate at which it is downloading the data.

Abstract: A method is provided in one example embodiment and includes communicating content to a content receiver, where a first portion of the content has a first drop priority. The method also includes determining a buffer status for a buffer at the content receiver, and adjusting the first drop priority to a second drop priority for a second portion of the content based on the buffer status. In more particular embodiments, the second drop priority can be higher than the first drop priority of the first portion of the content if the buffer is full or above a threshold. Also, the second drop priority can be lower than the first drop priority of the first portion of the content if content in the buffer has not started to render.

Abstract: A method and system for managing media streaming between clients on a client side of a network and stream servers on a stream server side of the network, wherein communications between the client side and the stream server side require a network address translation (NAT), involves allowing the same stream server side IP address to be shared amongst multiple stream servers so that the stream servers can simultaneously use the same IP address to source different media sessions. Because the stream servers can simultaneously use the same IP address to source different media sessions, a media session can be switched from one stream server to a different stream server without triggering STUN signaling or a change in the NAT mapping.

Abstract: A technique is provided for rapid channel change (RCC) processing in a programming distribution network. The RCC process herein is configured to transmit unicast stream of packets (“RCC burst”) during a “fast-fill” interval for up to a full duration of the multicast join window, or until it is stopped by a an explicit message sent from the user terminal. The unicast stream of packets is transmitted at a full rate of an access link (i.e., the bottleneck link) on a path to the user terminal beyond an earliest time when the user terminal could join a multicast stream of packets for a new channel requested by the user terminal.

Abstract: In one embodiment, a method includes requesting accelerated delivery of a specified media stream. The media stream contains a plurality of video frames. The method also includes receiving a response to the accelerated delivery request. The method also includes selecting, based on the response, a media stream source. The method also includes receiving a media stream from the selected media stream source into a buffer, and decoding the received media stream from the buffer, at a selected playout rate.

Abstract: In one embodiment, a method includes requesting accelerated delivery of a specified media stream. The media stream contains a plurality of video frames. The method also includes receiving a response to the accelerated delivery request and selecting, based on the response, a source media stream. The method also includes receiving the source media stream into a buffer and decoding the received media stream from the buffer, at a selected playout rate.

Abstract: In one embodiment, a separate surrogate monitor stream provides real-time media monitoring statistics for non-media savvy protocols. The surrogate monitor stream contains packet transmission parameters, such as sequence numbers and time stamps, for associated media packets in the non-savvy media stream. The surrogate monitor stream also contains checksums derived from the media packets. The checksums are used to correlate the packets in the surrogate monitor stream with the media packets in the media stream. The information in the surrogate monitor stream is then used in conjunction with the non-savvy media stream to provide real-time media monitoring without having to modify existing infrastructure. For example, head-end video servers do not have to add Real-time Transport Protocol (RTP) support or deal with protocol upgrades like RTP/UDP co-existence.

Abstract: A method and system for managing media streaming between clients on a client side of a network and stream servers on a stream server side of the network, wherein communications between the client side and the stream server side require a network address translation (NAT), involves allowing the same stream server side IP address to be shared amongst multiple stream servers so that the stream servers can simultaneously use the same IP address to source different media sessions. Because the stream servers can simultaneously use the same IP address to source different media sessions, a media session can be switched from one stream server to a different stream server without triggering STUN signaling or a change in the NAT mapping.

Abstract: In one embodiment, a method includes requesting accelerated delivery of a specified media stream. The media stream contains a plurality of video frames. The method also includes receiving a response to the accelerated delivery request and selecting, based on the response, a source media stream. The method also includes receiving the source media stream into a buffer and decoding the received media stream from the buffer, at a selected playout rate.

Abstract: In one embodiment, a method includes requesting accelerated delivery of a specified media stream. The media stream contains a plurality of video frames. The method also includes receiving a response to the accelerated delivery request. The method also includes selecting, based on the response, a media stream source. The method also includes receiving a media stream from the selected media stream source into a buffer, and decoding the received media stream from the buffer, at a selected playout rate.

Abstract: In one embodiment, a separate surrogate monitor stream provides real-time media monitoring statistics for non-media savvy protocols. The surrogate monitor stream contains packet transmission parameters, such as sequence numbers and time stamps, for associated media packets in the non-savvy media stream. The surrogate monitor stream also contains checksums derived from the media packets. The checksums are used to correlate the packets in the surrogate monitor stream with the media packets in the media stream. The information in the surrogate monitor stream is then used in conjunction with the non-savvy media stream to provide real-time media monitoring without having to modify existing infrastructure. For example, head-end video servers do not have to add Real-time Transport Protocol (RTP) support or deal with protocol upgrades like RTP/UDP co-existence.