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: Plural representations of a video stream may be provided. The plural representations may comprise a first chunk, a second chunk, and a transition chunk. The first chunk may comprise a first bitrate and the second chunk may comprise a second bitrate. The first and second chunks may be in decode order starting with an instantaneous decoding refresh (IDR) frame. The transition chunk may be in decode order starting with a non-IDR frame. Next, a request to transition from the first chunk to the second chunk may be received. Then a transition from the first chunk to the transition chunk responsive to the request may occur and the transition chunk may then be provided to another device.

Abstract: In one embodiment, a method that receives a manifest for plural encoded representations of a single content stream, each representation fragmented into plural chunks, each representation comprising a different quality level, the manifest listing a plurality of representations, each representation comprising the plural chunks at one of a plurality of quality levels, and requests one of the plural chunks based on selection of one of the plurality of quality levels explicitly indicated in the manifest.

Abstract: In one embodiment, a method that receives at a client device a unicast content stream; receives from a network an indication of a future time corresponding to when to send a join message to acquire a multicast content stream; accesses historical information about transitions between unicast and multicast content streams; and sends a join message for the multicast content stream at a time corresponding to the indicated future time subject to a time offset determined by the client device, the time offset based on the historical information.

Abstract: In one embodiment, a method that receives at a cache server device a request from a client device for a first representation of a content chunk; determines whether the first representation is available at the cache server device; responsive to determining that the first representation is available at the cache server device, provides the first representation to the client device; responsive to determining that the first representation is unavailable at the cache server device, determines whether a congestion-like condition is present in an upstream network; and responsive to determining that the congestion-like condition is present in the upstream network, provides a second representation of the content chunk.

Abstract: In one method embodiment, receiving from the network device a multiplex of a compressed video stream and a compressed audio stream, the multiplex comprising a succession of intervals corresponding to a video program corresponding to a first playout rate; and at the start of each interval, replacing the compressed audio stream with a compressed, pitch-preserving audio stream corresponding to a second playout rate different than the first.

Abstract: In one method embodiment, transmitting a transport stream formatted according to a defined coding specification to a receive-and-process (RP) system, the transport stream format further comprising a non-Internet protocol (IP) format or a raw-IP format; providing a mapping stream, the mapping stream correlating the transport stream to a Real-time Transport Protocol (RTP)-formatted data stream that encapsulates the transport stream, the mapping stream comprising identifying information corresponding to the transport stream and second identifying information corresponding to the data stream; and transmitting the mapping stream to the RP system over an IP connection to enable RTP capabilities at the RP system.

Abstract: Techniques are provided herein to enable monitoring of a real-time transport protocol (RTP) packet flow in devices along the path that the RTP packet flow traversed from a source to a destination. A device that is a source or destination of a RTP packet flow transmits a monitor request message that requests one or more other devices along a path of the RTP packet flow to monitor the RTP packet flow. The device that is the source or destination of the RTP packet flow receives one or more monitoring reports from the one or more other devices along the path of the RTP packet flow. This allows a device that requested monitoring of the RTP packet flow to analyze the monitor reports in order to determine a location of a cause of reduced performance in the RTP packet flow. e.g., missing packets, overly delayed packets, etc.

Abstract: A client device that is receiving streaming content on a connection from a streaming server over a network determines a need to suppress transmission of one or more packets from the streaming server on the connection over the network. The client device sends to the streaming server a message configured to cause the streaming server not to transmit the one or more packets to the client device for the connection without terminating the connection. The client device sends a further message that is configured to cause the streaming server to empty a buffer of packets that are queued for transmission but have not yet been transmitted (at a first bit rate) to the client device, so that the client device can send a request to the streaming server for transmissions of packets on the connection at a second bit rate.

Abstract: In one system embodiment, a first receive-and-process (RP) system and a second RP system, the first and second RP systems each configured to receive a first broadcast stream corresponding to a service, the broadcast stream comprising either a raw Internet protocol (IP) stream or a non-IP stream, and each further configured to derive a first Real-time Transport Protocol (RTP) stream and a second RTP stream, respectively, based on the first broadcast stream, the first and second RTP streams having stream parameters in common, the first and second RP systems each further configured to provide respective first and second RTP Control Protocol (RTCP) reports, the first and second RTCP reports based on the derived first and second RTP streams, the first and second RTCP reports each comprising information associated with a viewer experience, the respective information having a common benchmark as a basis for comparison.

Abstract: In one method embodiment, receiving from the network device a multiplex of a compressed video stream and a compressed audio stream, the multiplex comprising a succession of intervals corresponding to a video program corresponding to a first playout rate; and at the start of each interval, replacing the compressed audio stream with a compressed, pitch-preserving audio stream corresponding to a second playout rate different than the first.

Abstract: In one method embodiment, providing a multiplex of compressed versions of a first video stream and a first audio stream, each corresponding to an audiovisual (A/V) program, the first video stream and the first audio stream each corresponding to a first playout rate and un-synchronized with each other for an initial playout portion; and providing a compressed version of a second audio stream, the second audio stream corresponding to a pitch-preserving, second playout rate different than the first playout rate, the second audio stream synchronized to the initial playout portion of the first video stream when the first video stream is played out at the second playout rate, the first audio stream replaceable by the second audio stream for the initial playout portion.

Abstract: In one method embodiment, transmitting a transport stream formatted according to a defined coding specification to a receive-and-process (RP) system, the transport stream format further comprising a non-Internet protocol (IP) format or a raw-IP format; providing a mapping stream, the mapping stream correlating the transport stream to a Real-time Transport Protocol (RTP)-formatted data stream that encapsulates the transport stream, the mapping stream comprising identifying information corresponding to the transport stream and second identifying information corresponding to the data stream; and transmitting the mapping stream to the RP system over an IP connection to enable RTP capabilities at the RP system.

Abstract: In one method embodiment, receiving a video stream comprising a first compressed picture without associated time stamp information and a second compressed picture having associated first time stamp information, the second compressed picture following the first compressed picture in transmission order; deriving second time stamp information based on the first time stamp information; and processing the first compressed picture based on the second time stamp information.

Abstract: In one embodiment, each of a plurality of encapsulator devices receives a source stream of encoded packets in a first transport format to be converted to packets of an output stream in a second transport format for communication over a data network. Each encapsulator device generates a one or more fundamental identifying characteristics for the output stream based on information contained in one or more fields of a packet in the source stream so that the packets in the output stream generated by each of the encapsulator devices from the source stream are coordinated with respect to each other.

Abstract: Consistent with embodiments of the present invention, systems and methods are disclosed for estimating at least one of a capacity and an available bandwidth of a communications path. Methods may be disclosed comprising: sending a measurement request to a computing device on a network and receiving data responsive to the measurement request. At least one of a capacity and an available bandwidth of a communications path from the sender to the computing device may be estimated based on the received data. The estimation may be sent to the computing device and stored. Transmission settings may be adjusted based on the estimation.

Abstract: In one embodiment, a method includes inserting a packet containing an interpolated timestamp into a burst media stream. The insertion is responsive to a channel change request. The burst media stream includes a series of cached frames.

Abstract: Embodiments may be disclosed herein that provide systems, devices, and methods of processing a program stream, the program stream comprising a video and an audio stream.

Abstract: Techniques are provided herein to enable monitoring of a real-time transport protocol (RTP) packet flow in devices along the path that the RTP packet flow traversed from a source to a destination. A device that is a source or destination of a RTP packet flow transmits a monitor request message that requests one or more other devices along a path of the RTP packet flow to monitor the RTP packet flow. The device that is the source or destination of the RTP packet flow receives one or more monitoring reports from the one or more other devices along the path of the RTP packet flow. This allows a device that requested monitoring of the RTP packet flow to analyze the monitor reports in order to determine a location of a cause of reduced performance in the RTP packet flow. e.g., missing packets, overly delayed packets, etc.