Adaptive video slew rate for video distribution

Abstract

A system and method for adaptively adjusting the slew rate of a de-jitter buffer in a remote device in a distributed access architecture. The slew rate may be adjusted based on a measurement of the fullness state of the buffer over time. The measurement may be used to calculate a frequency offset value between the rate at which data enters the buffer versus the rate at which data leaves the buffer, and / or may be used to calculate a current operational depth of the buffer. The adaptive slew rate adjustment may be based on the frequency offset value and / or the current operational depth.

Description

Technical Field

[0001] Cross-Reference to Related Application The present application claims the benefit of U.S. Provisional Patent Application No. 63 / 144,367, filed on February 1, 2021.

Background Art

[0002] The subject matter of the present application generally relates to distribution of video content using a distributed access architecture (DAA) for hybrid CATV networks, and more particularly relates to an architecture that distributes the functions of a cable modem termination system between a core and a remote device such as a remote PHY device or a remote MACPHY device that is synchronized with the core.

[0003] Originally, cable television (CATV) networks delivered content to subscribers over long distances using dedicated RF transmission systems. Current CATV transmission systems replace much of the RF transmission path with more efficient optical networks, thus constructing a hybrid transmission system where although cable content terminates as an RF signal on a coaxial cable, the content is transmitted using optical signals over most of the distance between the content provider and the subscriber. Specifically, a CATV network comprises, at the content provider, a headend for receiving signals representing multiple channels of content, for multiplexing the signals, and for distributing the signals along the fiber optic network to one or more nodes each proximal to a group of subscribers. The node then demultiplexes the received optical signal and converts it into an RF signal, thereby making it receivable by a viewer. A system for providing video channels to subscribers within the headend typically comprises a plurality of EdgeQAM units that operate in different frequency bands that will be combined and multiplexed before being output onto the HFC network.

[0004] Traditional HFC architectures feature a headend with a Cable Modem Termination System (CMTS) used to deliver high-speed data services such as video, cable internet, and voice-over-internet protocols to cable subscribers. Typically, the CMTS includes both an Ethernet® interface (or other conventional high-speed data interface) and an RF interface, allowing traffic coming from the internet to be routed (or bridged) through the Ethernet® interface, through the CMTS, and then onto an optical RF interface connected to the cable company's hybrid fiber coaxial (HFC) system. Downstream traffic is delivered from the CMTS to the subscriber's cable modem, while upstream traffic is delivered from the subscriber's cable modem back to the CMTS. Many current HFC CATV systems have combined the functionality of the CMTS with the video distribution system in a single platform called a converged cable access platform (CCAP).

[0005] In these conventional HFC architectures, video is modulated over the RF network by a video edge QAM (VEQ). The VEQ receives single and multi-program transport streams (SPTS and MPTS) encapsulated in Internet Protocol (IP) from various sources (unicast / multicast), removes any jitter from the network ingress stream, and then statically or dynamically maps these streams to the QAM channel via one or more ports of the VEQ, remaps the program identifiers (PIDs), and multiplexes the required individual SPTS into a single MPTS. The VEQ may also perform local encryption of the video elementary stream (ES). To deliver the MPTS stream to the QAM channel according to ISO 13818-1, the VEQ must recover the ingress program clock reference (PCR) value encoded within each SPTS and re-stamp it with the VEQ's internal 27MHz clock so that all streams are delivered on the same time base.

[0006] As networks expand and headends become increasingly congested with equipment, many content providers have in recent years been extending CMTS / CCAP capabilities across the entire network by using distributed architectures. This distributed architecture preserves cable data and video signals in digital format as much as possible, extends the digital signals beyond the CMTS / CCAP into the deeper parts of the network, and then converts the digital signals to RF. This is achieved by replacing analog links between the headend and the access network with digital fiber (Ethernet® / PON) connections.

[0007] One such distributed architecture is the Remote PHY (R-PHY) distributed access architecture, which relocates the physical layer (PHY) of a conventional CMTS or CCAP (including VEQ) by pushing the physical layer into the network's fiber nodes. In this way, the core within the CMTS / CCAP performs higher-layer processing, while the R-PHY devices within the nodes convert downstream video data packets transmitted by the core from digital to analog for transmission over radio frequencies, and convert upstream RF data transmitted by cable modems from analog to digital for optical transmission to the core. Another distributed access architecture is the Remote MAC PHY (R-MACPHY), which not only pushes the physical layer of a conventional CMTS into the network but also assigns the functionality of the Media Access Control (MAC) layer, one of the two layers that make up the data link layer of the transport stream, to one or more nodes in the network called Remote MACPHY devices (RMDs).

[0008] Therefore, the DAA architecture includes a VEQ in the RF network that modulates a fully formed MPTS stream, which is a remote video-enabled device such as an RMD or RPD. One advantage of this arrangement is that the RMD / RPD device is generally lower power and requires less computing and memory resources than traditional video edge QAM located at the headend. Similar to a VEQ located at the headend, the VEQ located in the RPD / RMD must map and modulate the IP-encapsulated, fully formed MPTS video stream received from the headend into one or more QAM channels (one stream per channel) and eliminate network jitter in the process. However, the difference from a VEQ at the headend is that the VEQ in the remote device receives only fully encapsulated MPTS streams, thus eliminating the need to multiplex various SPTS content.

[0009] Furthermore, in a DAA architecture, when the CMTS / CCAP functions are divided between the headend core and various PHY or MACPHY devices throughout the network, a protocol must be established to accurately preserve the timing of the reconstructed video data communicated across the entire network. Therefore, even though remote devices only receive MPTS video data that has already been synchronized together, they must consider any differences between the clock rate at which they receive data and the clock rate at which they output data. For example, a DAA remote device may not be synchronized to the same time base as the CCAP core (asynchronous operation), or even if the CCAP core and remote device are synchronized to a common clock (synchronous operation), the CCAP core and remote device may lose their timing locks.

[0010] Therefore, there is a need for improved systems and methods for accurately storing timing information associated with video data transmitted in a distributed access architecture. [Brief explanation of the drawing]

[0011] To better understand the present invention and to show how it can be carried out, the following accompanying drawings are referenced here as an example.

[0012] [Figure 1] This example illustrates a conventional HFC architecture with a video EQAM unit that packages MPTS transport streams and transmits them to downstream nodes. [Figure 2] This example illustrates a distributed access architecture that includes a video / CCAP core that sends packetized IP data to a remote physical device (RPD). [Figure 3A] Figure 2 shows an exemplary system in which the video / CCAP core transmits video data to the RPD in synchronous mode. [Figure 3B]Figure 2 shows an exemplary system in which the video / CCAP core transmits video data to the RPD in asynchronous mode. [Figure 4] Figure 3B shows a first exemplary method of using an adaptive frequency slew rate to ensure that the video data output from the asynchronous system is properly synchronized while avoiding buffer overflow. [Figure 5] Figure 3B shows a second example of using an adaptive frequency slew rate to ensure that the video data output from the asynchronous system is properly synchronized while avoiding buffer overflow. [Figure 6A] The results obtained using the adaptive frequency slew rates disclosed herein are shown. [Figure 6B] The results obtained using the adaptive frequency slew rates disclosed herein are shown. [Modes for carrying out the invention]

[0013] As mentioned above, video EQAM (VEQ) devices are used to receive multiple channels of video and output an RF-modulated (i.e., QAM or quadrature amplitude modulation) signal that combines multiple different channels received by the VEQ. Figure 1 shows a conventional architecture 10 in which, for example, the HFC network 12 includes a headend 14 that delivers content to the subscriber's equipment 24 as the subscriber's facility shown in the figure, as a cable modem, but a person skilled in the art will understand that the subscriber's equipment may include a set-top box, gateway, radiotelephone, computer, etc.

[0014] The HFC network 12 includes a headend 14, multiple hubs 20, each hub associated with multiple nodes 22, and multiple subscriber devices 24 such as cable modems. The headend 14 typically includes a cable modem termination system (CMTS) 13 and multiple video EQAM units 16. Each node 22 has one or more corresponding access points, and each subscriber may have one or more corresponding network elements 24 as shown in Figure 1, such as cable modems.

[0015] As previously mentioned, in these conventional HFC architectures 10, video is modulated over the RF network by the VEQ 16, which receives Internet Protocol (IP) encapsulated single and multi-program transport streams (SPTS and MPTS) from various sources (such as content providers) via the content distribution network 26. The content distribution network is typically a switching network where packetized IP data is routed from one address to another, and the received packets may exhibit unpredictable variable delays. Therefore, it is preferable for the VEQ 16 to remove this jitter from the network ingress stream before mapping and modulating the video data to multiple QAM channels. Also, as previously mentioned, in order to deliver MPTS streams to QAM channels according to ISO 13818-1, the VEQ needs to recover the ingress program clock reference (PCR) value encoded within each SPTS and re-stamp it with the VEQ's internal 27MHz clock so that all streams are delivered on the same time base.

[0016] Figure 2 shows an alternative distributed access architecture (DAA) in which the functionality of the VEQ is moved to the nodes. Specifically, Figure 2 shows what is known as a remote physical architecture (R-PHY) 50 in which the video / CCAP core 54 transmits data to a remote physical device (RPD) 56, which is then connected to one or more consumer facility equipment (CPE) devices 18, such as a set-top box or cable modem. While the R-PHY architecture is shown in Figure 2, it should be understood that the description herein is equally applicable to other DAA architectures, such as the R-MACPHY architecture. In some embodiments, a timing grandmaster device 52 may be available to provide timing information to both the video / CCAP core 54 and the RPD 56. Specifically, the timing groundmaster 52 has a first master port 60a connected to a slave clock 62 in the CCAP core 54 and a second master port 60b connected to a slave clock 64 in the RPD 56. Alternatively, the respective slave clocks of the CCAP core 54 and the RPD 56 may both be connected to a single master port in the timing groundmaster device 52. The CCAP core 54 may be connected to the timing groundmaster 52 via one or more switches 66, while the RPD 56 may be connected to the timing groundmaster 52 via one or more switches 68. Figure 2 shows only one RPD 56 connected to the timing groundmaster 52, but a number of such RPDs may be connected to the groundmaster 52 simultaneously, in which case each RPD has a slave clock 64 that receives timing information from port 60b in the groundmaster clock 52.

[0017] The architecture in Figure 2 shows a common grandmaster device 52 that can synchronize the video / CCAP core 54 to the RPD 56, but the architecture in Figure 2 may be configured to operate asynchronously, where the grandmaster device 52 does not send common timing information to the core 54 / RPD 56. For example, if the video / CCAP core 54 does not support the IEEE 1588 timing protocol, or if it is desired that the RPD 56 be more robust to holdover periods in the event that the RPD and / or core loses connection to the timing grandmaster, the RPD 56 may be configured to operate asynchronously. Furthermore, in an R-MACPHY system, the RMS stream may be switched to synchronous mode if other services such as wireless backhaul require IEEE 1588 services, or if the oscillator of the video core 54 is of low quality and requires an external timing source, but since the DOCSIS service does not require it, the RMD may typically be set to asynchronous mode by default to eliminate the need for 15888 timing. Therefore, the system shown in Figure 2 may be configured to operate in either synchronous or asynchronous mode for processing video content, and the video / CCAP core 54 and RPD(RMD) 55 each preferably include hardware capable of operating in either mode, enabling configuration by the video core itself, and including software to connect downstream devices to either of these modes when setting up the video channel.

[0018] In sync mode, the RPD (or RMD) and its video core are temporally synchronized with the same reference clock. In this sync mode, the RPD only needs to detect lost video packets using Layer 2 Tunneling Protocol v.3 (L2TPv3) sequence number monitoring and insert an MPEG null packet for each missing packet. Figure 3A shows a system in a first configuration 100, for example, where the video core 102 communicates with the RPD 104 in sync mode using a common grandmaster timing server 106. The timing server 106 maintains the same timing lock (i.e., frequency and phase) for both the clock 108 in the video core 102 and the clock 110 in the RPD 104. The video core 102 has a video streamer 112 that forwards video data packets to the RPD 104 via a downstream external PHY interface (DEPI) using L2TPv3. The video packets sent from video core 102 to RPD 104 typically contain all the information necessary to decode the packetized elementary video transport stream, such as program identifiers (PIDs) and program clock reference (PCR) data.

[0019] RPD 110 then receives the video packets transmitted from the video core 108 in the de-jitter buffer 116 of the processing device 114. The de-jitter buffer receives and outputs packet data at a rate that eliminates network jitter caused by different paths of the received packet data, or caused by other sources that vary network delay between the video core and the RPD. Since some packets transmitted by the video streamer 112 may be lost or misarranged during transportation to the RPD 104, the packets output from the de-jitter buffer are preferably transferred to a module 118 that inserts null packets into the data stream in consideration of those lost packets so as to maintain an appropriate timing rate of the transmitted video in the synchronization mode. The transport stream with null packets inserted as appropriate is then transferred to the PHY device 120, which outputs QAM-modulated data in a format expected by customer premises equipment such as a set-top box, for downstream distribution to end users, the packetized elementary stream may be decoded into a sequence consisting of decoded video frames. Alternatively, the PHY device may just transfer the packetized data to, for example, a cable modem without decoding the packetized data, for decoding by a user device such as a computer, a tablet, a mobile phone, etc.

[0020] In the synchronization mode, since the RPD 104 and its video core 102 must be synchronized to the same reference clock, the frequency of the PCR clock included in the ingress MPTS matches the frequency of the local clock on the remote device. Therefore, there is no frequency offset on the RPD between the ingress stream and the egress stream. As mentioned above, in order to maintain appropriate timing information for the transmitted video data, the RPD 104 needs to eliminate network jitter, detect lost video packets using L2TPv3 sequence number monitoring, and insert an MPEG NULL packet for each missing packet.

[0021] Alternatively, the RPD and the video core may be configured to operate in an asynchronous mode. In the asynchronous mode, the RPD 104 and its video core 102 are not temporally synchronized with respect to the same reference clock. Instead, the RPD 104 needs to detect the difference between its own clock 110 and the clock 108 of the video core 102, needs to be capable of inserting or removing MPEG packets as necessary to maintain the expected MPEG bit rate, and further needs to adjust MPEG PCR values based on the removal / insertion of MPEG packets.

[0022] FIG. 3B shows, for example, the hardware of FIG. 2 alternatively configured to operate in asynchronous mode. In this configuration 101, the clock 108 of the video core 102 and the clock 110 of the RPD 104 are not synchronized and therefore may drift relative to each other. A video streamer 112 of the video core 102 transfers packets of the packetized video data elementary stream to the RPD 104, which again receives the data in a de-jitter buffer 116 and removes network jitter as described above. However, unlike the configuration of FIG. 2, packets output from the de-jitter buffer 116 are transferred to a module 118 that both adds null packets as needed and drops packets as needed to properly and constantly maintain the bit rate of data received from the de-jitter buffer 116.

[0023] Furthermore, since the RPD and its video core are not synchronized to keep up with the same reference clock, the frequency of the PCR in the ingress MPTS is offset from the frequency of the local RPD clock. Therefore, in addition to performing the aforementioned functions common to those running in synchronous mode, the RPD must detect the magnitude of the frequency offset from the video core and correct it. For this reason, after packets have been added / dropped as needed, the PCR module 119 re-stamps the data packets with an updated PCR based on the removal / insertion of MPEG packets, and then forwards the re-stamped packets to the PHY device 120.

[0024] Another consideration in asynchronous mode is the size limitation of the dijitter buffer. Because an offset exists between the ingress and egress frequencies, the jitter buffer is prone to overflowing / becoming empty depending on the sign of the frequency difference. Therefore, systems and methods must be employed to prevent the buffer from overflowing or becoming empty. Subsequent disclosures disclose a novel method for detecting and correcting this frequency offset in asynchronous mode operation while taking into account its limited memory (buffer) size and maintaining accurate synchronization of video data being processed simultaneously.

[0025] As already mentioned, network jitter is eliminated by using the “digita” buffer 116 shown in Figure 3B. It is preferable that this digita buffer 116 is initially filled to its midpoint when MPTS stream delivery begins. Since digita is usually achieved using a low-pass filter that averages the delay over a sufficiently long interval, it is preferable that the digita buffer 116 is large enough to absorb the fluctuations in buffer depth caused by jitter on the ingress stream without underflow or overflow.

[0026] The frequency difference between the ingress PCR and the local RPD clock (i.e., the egress rate) manifests as a drift in the dijitter buffer depth after low-pass filtering. This generates a cue depth drift rate caused by the frequency offset. This drift rate is directly proportional to the frequency offset between the ingress PCR and the local clock. Specifically, the ingress frequency Fi is directly proportional to the ingress bit rate Bi,

number

number

number

[0027]

number

[0028] To stop the increase / decrease in the dejitter buffer occupancy, the RPD must pass through its egress frequency to match the ingress frequency. ISO / IEC 13818-1 calibrates the maximum value of this frequency slew rate. Therefore, the system clock frequency value measured in Hz should and will satisfy the following constraints: 27,000,000 - 810 <= System clock frequency <= 27,000,000 + 810 The rate of change of the system clock frequency over time <= 75 × 10⁻³ Hz / second

[0029] A typical frequency offset for hardware-based video engines is + / - 5 ppm. However, for software-based video engines where timing is provided by a standard crystal oscillator, this accuracy is likely to be substantially lower. The ISO 13818-1 specification allows for an accuracy of + / - 810 Hz on a 27 MHz clock, which is equivalent to a 30 ppm offset. If video core 102 delivers MPTS asynchronously in the opposite direction with a 30 ppm frequency offset and an RPD clock offset of 5 ppm, the relative frequency offset is 35 ppm.

[0030] If no compensation is performed for this frequency offset, the time it takes to hit the buffer's overrun / underrun condition depends on the size of the RPD device's digitter buffer. The available operating depth of the digitter buffer is determined by: Qlen / 2 - Jmax, where Jmax is the maximum jitter. Therefore, if frequency correction is not applied, the time overflow / underflow of the digitator buffer can be determined as follows:

number

number

[0031] The systems and methods described herein preferably pass the egress frequency through at a rate high enough to prevent the dijitter buffer from overflowing / underflowing, matching that of the ingress frequency, and doing so at a rate as close as possible to the 75 mHz / s limit, although the actual frequency slew rate may need to exceed this limit if the buffer size is limited.

[0032] As mentioned earlier, the VEQ typically recovers the PCR clock of the ingress stream, applies the necessary slew to compensate for any frequency offset between that clock and the local VEQ 27MHz clock, and re-stamps the PCR output from the VEQ with this compensated clock. An alternative to re-stamping the PCR may be to apply a cumulative offset to each PCR to compensate for the frequency offset. If this cumulative PCR offset exceeds the transmission time of a single transport stream packet (TSP), the TSP can be added to / removed from the egress MPTS stream, and the PCR offset value can be adjusted to return towards zero by this transmission time.

number

[0033] The applied frequency offset is preferably able to change over time until the entry and exit MPTS bit rates become equal, i.e., synchronized. This initial rate of change of the PCR offset is proportional to the observed frequency slew observed on the egress stream. This avoids the need for RPD / RMD to recover and re-stamp the MPTS PCR clock, beneficially eliminating significant computational and memory overhead.

[0034] The applicable frequency slew rate depends on the estimation of the ppm frequency offset. As previously stated, the frequency offset is the rate of change in the dejitter buffer occupancy, i.e., Equation 1. Thus, after a short set-up period in which the high-frequency network jitter can be averaged, the rate of change in the dejitter buffer occupancy can be calculated, thereby providing an approximation of the current ppm frequency offset. According to the preferred systems and methods disclosed herein, this frequency offset can be reduced / removed over time in a manner that does not result in buffer overrun / underrun. More specifically, the preferred embodiments described herein employ adaptive frequency slew rate adjustment, which means changing the frequency slew over time based on the measured state of the dejitter buffer. In some embodiments, the measured state of the dejitter buffer may indicate the current frequency offset, which may be the basis for the change in slew over time. Alternatively, or additionally, the measured state of the dejitter buffer may be based on the remaining available buffer occupancy.

[0035] Referring to Figure 4, the first embodiment may include a method 150 in step 152 for determining the initial or current frequency offset between input data entering the dijitter buffer 116 and output data leaving the dijitter buffer 116. The frequency offset can be determined, for example, by measuring the fullness state of the dijitter buffer 116 at intervals and applying a low-pass filter at those intervals to determine the depth drift of the dijitter buffer. In a preferred embodiment, the grind may be used to determine the current frequency offset value measured in ppm.

[0036] In step 154, the determined initial or current frequency offset is used to select from a plurality of predetermined scalar slew rate values. In one embodiment, the predetermined slew rates may be associated with each of a plurality of frequency offset ranges. For example, one slew rate may be applied when the measured frequency offset is 10 ppm or less, another slew rate may be applied when the measured frequency offset is greater than 10 ppm but 35 ppm or less, and a third slew rate may be selected when the measured frequency offset is greater than 35 ppm. Those skilled in the art will understand that other slew rate values ​​may be used for each of these ranges, and that a greater number of ranges may be used in various embodiments. Preferably, the pre-selected slew rates for each range are calculated in advance to ensure that the frequency slew rate is sufficiently high, and as a result, the frequency offset is corrected before any overrun / underrun events occur in the dejitter buffer.

[0037] In step 156, the selected frequency slew rate is applied, and after a certain period of time, the procedure returns to step 152, where another measurement of the frequency offset is taken, which will result in a decrease compared to the previous iteration, and the method may continue until the frequency offset is eliminated.

[0038] In particular, the rate of change of the dijitter buffer depth decreases as the frequency offset decreases, so the initial frequency slew rate has a more dramatic effect on buffer occupancy. As the frequency offset approaches zero, the selected slew rate will have less effect. Therefore, since frequency offset correction is a relatively slow process (i.e., >60 minutes in some cases for large ppm frequency offsets), periodic updates of the frequency slew can be performed at a relatively low rate.

[0039] Rather than simply adjusting the slew rate based on the frequency offset, as measured by the change in the depth of the dejitter buffer 116, an alternative implementation may adjust the slew rate based on both the measured frequency offset and the measured remaining operating depth of the dejitter buffer. In some specific embodiments, calculations may be used to determine the stepwise change in slew rate as a function of the measured frequency offset and the measured state of the buffer's operating depth. For example, the slew rate (dF / dT) may be based on the divided measured frequency drift as a flow.

number

[0040] Value (Q len / 2-J max ) represents the available working depth of the buffer, Q len / 2 represents the time-averaged (jitter-free) distance at which the buffer is completely full or completely empty, and J max represents the maximum empirical jitter. Therefore, applying this formula can generate the desired initial / update slew rate based on the measured frequency offset and the measured available operating depth of the buffer.

[0041] Referring to Figure 5, for example, another embodiment for applying adaptive frequency slew rate to a dejitter buffer may use method 160, in which step 162 the buffer state is measured over a time interval sufficient to average the network jitter in order to determine the drift in the buffer due to frequency offset.

[0042] In step 164, the measured frequency offset between data entering and leaving the buffer, and in some embodiments, a value for the working buffer depth that reflects the maximum jitter, are calculated from the measurements taken in step 162. In step 166, the initial / updated slew rate is determined. In some embodiments, the slew rate may be determined based on Equation 4 described above. In step 168, the determined slew rate is applied. After a certain period, the procedure returns to step 162 and continues until the frequency offset is removed.

[0043] Figures 6A and 6B show the results of the systems and procedures described herein. These figures demonstrate that the disclosed systems and methods rapidly adjust to prevent buffer underrun / overrun while simultaneously eliminating frequency offsets across the jitter buffer over time.

[0044] Once the adaptive frequency slew process described above is complete, the egress frequency matches that of the ingress frequency. This means that the ingress and egress bit rates also match, and therefore the drift with respect to the depth of the dijitter buffer 116 is eliminated. However, although the dijitter buffer 116 is offset from its center point, for optimal performance of the dijittering function, the dijitter buffer should be maintained at 50% fullness.

[0045] To recenter the dejitter buffer 116, the RPD / RMD 104 can accumulate DOCSIS ticks using the tolerance of PCR accuracy, thereby facilitating the addition / removal of TSPs to / from the egress stream. ISO / IEC 13818-1 defines this PCR tolerance as the maximum acceptable inaccuracy in the received PCR. This inaccuracy may result from inaccuracies in the PCR value or PCR modification during remultiplexing. Errors in packet arrival time due to network jitter or other causes are not included. The PCR tolerance is + / - 500 ns.

[0046] Applying an intentional error of + / - 500 mS to sequential PCR for each PID means that the PCR value will be + / - 13.5 ticks, i.e., (500 × 10⁻¹⁰ -9 ×27×10 6 This is equivalent to adjusting each time. When this accumulated value exceeds the PCR tick per TSP value (see Equation 3), packets can be added to / removed from the egress stream, and the PCR adjustment value can be increased / decreased by the PCR tick per TSP value. By repeating this process, the dijitter buffer can be gradually recentered without violating the ISO 13818-1 specification.

[0047] The aforementioned specification described a system and method in which one embodiment of the RPD / RMD204 operating in asynchronous mode within a DAA architecture can apply a PCR offset to incoming video rather than modifying the video data by a time value from its own clock, as a less computationally intensive means of maintaining the synchronous presentation of video data. However, those skilled in the art will understand that all of the aforementioned techniques can be applied by a headend VEQ unit, for example, as shown in Figure 1.

[0048] The present invention is not limited to the specific embodiments described, and it will be understood that modifications may be made to it so as to be interpreted in accordance with the principle of superiority law, including equivalent doctrines or any other principle that expands the legally enforceable scope of claims beyond their literal scope, without departing from the scope of the invention as defined in the appended claims. Unless the context indicates otherwise, a claim reference to a number of examples of an element, whether it is a reference to one example or to more examples, requires at least a predetermined number of examples of the element, but is not intended to exclude the scope of a claimed structure or method having more examples of that element than described. When used in the claims, the term “includes” or its derivatives is used in a non-exclusive sense and is not intended to exclude the existence of other elements or steps in the claimed structure or method. The inventions disclosed herein include the following: [Aspect 1] A remote device that receives packetized video data from a video core via a packet switching network, wherein the device A clock configured to operate in asynchronous mode, A digitizer buffer that receives the video data from the packet switching network and outputs the video data to at least one module that adjusts the video data before transmitting it downstream, A remote device comprising: a processing device for applying slew rate adjustment to the clock and the digitizer buffer, wherein the slew rate adjustment changes over time based on the measured state of the digitizer buffer. [Aspect 2] A remote device according to embodiment 1, including an RPD. [Aspect 3] A remote device according to embodiment 1, including an RMD. [Aspect 4] The remote device according to embodiment 1, wherein the slew rate adjustment is based on a frequency offset determined by measuring the fullness state of the digitter buffer over time. [Aspect 5] The remote device according to embodiment 4, wherein the slew rate adjustment is based on the measured current fullness state of the digitter buffer. [Aspect 6] The remote device according to embodiment 1, wherein at least one module applies an offset value to the PCR value in the video data received from the packet switching network. [Aspect 7] The remote device according to embodiment 6, wherein the offset values ​​are accumulated to generate an accumulated offset value, and the accumulated offset value is used to selectively add and / or selectively drop packets. [Aspect 8] The remote device according to embodiment 7, wherein the magnitude of the accumulated offset value is decreased each time a packet is selectively dropped and / or added. [Aspect 9] The remote device according to embodiment 1, wherein the slew rate adjustment removes the frequency offset by repeatedly measuring the fullness state of the digitizer buffer over time. [Aspect 10] The remote device according to embodiment 9, wherein the digitizer buffer is recentered after the frequency offset has been removed. [Aspect 11] A method for determining timing values ​​to apply to packetized video data received asynchronously from a video core through a packet switching network, wherein the method is The video data is received from the packet switching network in a digitizer buffer according to a first time base, and before transmitting the video data downstream, the video data is output from the digitizer buffer according to a second time base and at least one module that adds timing information to the video data. A method comprising applying a slew rate adjustment to reduce the difference between the first time base and the second time base over a certain interval, wherein the slew rate adjustment changes over time based on the measured state of the digitter buffer. [Aspect 12] The method according to embodiment 11, as implemented in RPD. [Aspect 13] The method according to embodiment 11, as implemented in RMD. [Aspect 14] The method according to embodiment 11, wherein the slew rate adjustment is based on a frequency offset determined by measuring the fullness state of the digitter buffer over time. [Aspect 15] The method according to embodiment 14, wherein the slew rate adjustment is based on the measured current fullness state of the digitter buffer. [Aspect 16] The method according to embodiment 11, wherein at least one module applies an offset value to the PCR value in the video data received from the packet switching network. [Aspect 17] The method according to embodiment 16, wherein the offset values ​​are accumulated to generate an accumulated offset value, and the accumulated offset value is used to selectively add and / or selectively drop packets. [Aspect 18] The method according to embodiment 17, wherein the magnitude of the accumulated offset value is decreased each time a packet is selectively dropped and / or added. [Aspect 19] The method according to embodiment 11, wherein the slew rate adjustment removes the frequency offset by repeatedly measuring the fullness state of the digitter buffer over time. [Aspect 20] The method according to embodiment 19, further comprising the step of recentering the digitter buffer after the frequency offset has been removed.

Claims

1. A remote device that receives packetized video data from a video core via a packet switching network, wherein the remote device A clock configured to operate in asynchronous mode, A digitizer buffer that receives the video data from the packet switching network and outputs the video data to at least one module that adjusts the video data before transmitting it downstream, A processing device that applies slew rate adjustment to the clock and the digitizer buffer, wherein the slew rate adjustment changes over time based on the measured state of the digitizer buffer, The at least one module applies an offset value to the PCR value in the video data received from the packet switching network, A remote device in which the aforementioned offset values ​​are accumulated to generate an accumulated offset value, which is used to selectively add and / or selectively drop packets.

2. A remote device that receives packetized video data from a video core via a packet switching network, wherein the remote device A clock configured to operate in asynchronous mode, A digitizer buffer that receives the video data from the packet switching network and outputs the video data to at least one module that adjusts the video data before transmitting it downstream, A processing device that applies slew rate adjustment to the clock and the digitizer buffer, wherein the slew rate adjustment changes over time based on the measured state of the digitizer buffer, The slew rate adjustment removes the frequency offset by repeatedly measuring the fullness state of the digitizer buffer over time. A remote device in which the digitizer buffer is recentered after the frequency offset has been removed.

3. The remote device according to claim 1 or 2, comprising a remote physical device.

4. The remote device according to claim 1 or 2, comprising a remote MACPHY device.

5. The remote device according to claim 1 or 2, wherein the slew rate adjustment is based on a frequency offset determined by measuring the fullness state of the digitter buffer over time.

6. The remote device according to claim 5, wherein the slew rate adjustment is based on the measured current fullness state of the digitter buffer.

7. The remote device according to claim 1, wherein the magnitude of the accumulated offset value is decreased each time a packet is selectively dropped and / or added.

8. A method for determining timing values ​​to apply to packetized video data received asynchronously from a video core through a packet switching network, wherein the method is The video data is received from the packet switching network in a digitizer buffer according to a first time base, and before transmitting the video data downstream, the video data is output from the digitizer buffer according to a second time base and at least one module that adds timing information to the video data. Applying a slew rate adjustment to reduce the difference between the first time base and the second time base over a certain interval, wherein the slew rate adjustment changes over time based on the measured state of the digitator buffer, The at least one module applies an offset value to the PCR value in the video data received from the packet switching network, A method wherein the aforementioned offset values ​​are accumulated to generate an accumulated offset value, which is used to selectively add and / or selectively drop packets.

9. A method for determining timing values ​​to be applied to packetized video data received asynchronously from a video core through a packet switching network, wherein the method is: The video data is received from the packet switching network in a digitizer buffer according to a first time base, and before transmitting the video data downstream, the video data is output from the digitizer buffer according to a second time base and at least one module that adds timing information to the video data. Applying a slew rate adjustment to reduce the difference between the first time base and the second time base over a certain interval, wherein the slew rate adjustment changes over time based on the measured state of the digitator buffer, The slew rate adjustment removes the frequency offset by repeatedly measuring the fullness state of the digitator buffer over time. A method comprising the step of re-centering the digitter buffer after the frequency offset has been removed.

10. The method according to claim 8 or 9, as implemented in a remote physical device.

11. The method according to claim 8 or 9, as implemented in a remote MACPHY device.

12. The method according to claim 8 or 9, wherein the slew rate adjustment is based on a frequency offset determined by measuring the fullness state of the digitter buffer over time.

13. The method according to claim 12, wherein the slew rate adjustment is based on the measured current fullness state of the digitter buffer.

14. The method according to claim 8, wherein the magnitude of the accumulated offset value is decreased each time a packet is selectively dropped and / or added.

Images