CN116530087A - Partial video asynchronous support using R-MACPPHY devices - Google Patents

Abstract

Systems and methods for providing timing information from an R-mac hphy device to a video core when receiving video data from the video core when the R-mac phy device is operating in an asynchronous mode are disclosed herein. In some embodiments, the R-mac phy device may alternately and selectively configure its operating mode to alternate between synchronous and asynchronous modes, and provide timing information to the video core when it switches to asynchronous mode.

Description

Partial video asynchronous support using R-MACPPHY devices

Cross Reference to Related Applications

The present application claims the benefit of U.S. provisional patent application No. 63/168,032 filed 3/30 in 2021 and U.S. provisional patent application No. 63/119,954 filed 12/2020, both of which are incorporated herein by reference in their entirety.

Background

The subject matter of the present application relates generally to delivering video content using a Distributed Access Architecture (DAA) of a hybrid CATV network, and more particularly to an architecture that distributes the functionality of a cable modem termination system between a core and a remote device synchronized to the core, such as a remote PHY device or a remote mac PHY device.

While cable television (CATV) networks originally used dedicated RF transmission systems to deliver content to subscribers over long distances, modern CATV transmission systems have replaced most of the RF transmission paths with more efficient optical networks, creating a hybrid transmission system in which cable content is terminated as RF signals on coaxial cables, but optical signals are used to transmit over most of the distance between the content provider and the subscribers. Specifically, the CATV network includes a headend at a content provider for receiving signals representing the content of a number of channels, multiplexing them, and distributing them along the fiber optic network to one or more nodes, each node proximate to a group of subscribers. The node then demultiplexes the received optical signal and converts it into an RF signal so that the viewer can receive the signal. A system in a headend that provides video channels to subscribers typically includes multiple edge qam units operating on different frequency bands that are combined and multiplexed before being output onto an HFC network.

Historically, headend has also included a separate Cable Modem Termination System (CMTS) for providing high speed data services, such as video, cable internet, voice over internet protocol, etc., to cable subscribers. Typically, the CMTS will include both an ethernet interface (or other more conventional high-speed data interface) and an RF interface so that traffic from the internet can be routed (or bridged) through the ethernet interface, through the CMTS, and then onto an optical RF interface connected to a Hybrid Fiber Coax (HFC) system of a cable company. Downstream traffic is passed from the CMTS to the cable modem in the subscriber's home, while upstream traffic is passed back from the cable modem in the subscriber's home to the CMTS. Many modern HFC CATV systems combine the functionality of a CMTS with a video transmission system (EdgeQAM) on a single platform known as a Converged Cable Access Platform (CCAP).

As networks expand, and as a result, devices at the headend become more crowded, many content providers recently use a distributed architecture to disseminate the functionality of CMTS/CCAPs throughout the network. This distributed architecture keeps the cable data and video signals in digital format as long as possible, extends the digital signals beyond the CMTS/CCAP, deep within the network, and then converts them to RF. It does this by replacing the analog link between the headend and the access network with a digital fiber (ethernet/PON) connection.

One such distributed architecture is a remote PHY (R-PHY) distributed access architecture that relocates the physical layer (PHY) of a conventional CMTS or CCAP by pushing it to the fiber nodes of the network. Thus, while the core in the CMTS/CCAP performs higher layer processing, the R-PHY devices in the nodes convert downstream data sent by the core from digital to analog for transmission on radio frequencies and convert upstream RF data sent by the cable modem from analog to digital format for optical transmission to the core. Another distributed access architecture is remote MAC PHY (R-MAC PHY), where not only the physical layer of a conventional CMTS is pushed into the network, but also a functional Medium Access Control (MAC) layer, which is one of the two layers that make up the data link layer of the transport stream, is allocated to one or more nodes in the network in what is known as remote MAC PHY device (RMD).

However, once the functionality of the CMTS/CCAP is allocated between the core in the headend and the various PHY or mac PHY devices of the overall network, protocols must be established to accurately maintain the timing of the reconstructed video data transmitted throughout the network. One typical arrangement for accurately maintaining the timing of transmitting video data is to ensure that the clocks of the various devices in the network are synchronized. For example, fig. 1 illustrates an exemplary topology 10 that provides synchronization between a CCAP core 14 and an RPD 16 connected to one or more "Consumer Premise Equipment (CPE) devices 18, although it should be noted that a similar topology may be used between the core and RMD, for example. Stator Shi Zu master 12 provides timing information to both CCAP core 14 and RPD 16. Specifically, destination Shi Zu master 12 has a first master port 20a connected to slave clock 22 in CCAP core 14 and a second master port 20b connected to slave clock 24 in RPD 16, but alternatively, both the respective slave clocks of CCAP core 14 and RPD 16 may be connected to a single master port in timing master 12. CCAP core 14 may be connected to timing progenitor master 12 through one or more switches 26, while RPD 16 may be connected to timing progenitor master 12 through one or more switches 28. Although FIG. 1 shows only one RPD 16 connected to a clocked master 12, many such RPDs may be connected to master 12 at the same time, with each RPD having a slave clock 24 that receives timing information from port 20b in master clock 12.

While both core 14 and RPD 16 are locked to timing progenitor master 12 without any significant problem, problems may occur when RPD 16 or core 14 loses connection to timing progenitor master 12. In a hold period where one or both devices are not connected to the timing clock of master 12, the unconnected device will drift in frequency and phase with the timing master 12 and the other device. The magnitude of this drift will depend on many factors including the length of the hold period, temperature variation, internal oscillator performance, etc. For example, an RPD with a typical TCXO oscillator may even phase drift by 1ms within one hour. Typically, the drift of RPD is worse than the drift of the core, as the core typically has a better oscillator and is in a temperature controlled environment. If the duration of the hold period in which drift occurs is long enough, the video quality will drop to an unacceptable level.

Alternative asynchronous architectures do not rely on synchronization between the core and downstream devices (like RPD and RMD), but these architectures involve more complex processing and often result in data packets being discarded.

Accordingly, there is a need for improved architectures and methods for accurately maintaining timing information associated with video data transmitted in a distributed access architecture.

Drawings

For a better understanding of the invention, and to show how the same may be carried into effect, reference will now be made, by way of example, to the accompanying drawings in which:

FIG. 1 illustrates an exemplary R-PHY system in which both the CCAP core and its RPD are timing slaves to an external master clock (GM).

Fig. 2 illustrates an architecture in which a video core sends video data to an RPD in a synchronous mode.

Fig. 3 illustrates an architecture of the video core of fig. 2 to send video data to the RPD of fig. 2 in an asynchronous mode.

Fig. 4 illustrates an exemplary method of dynamically transitioning the architecture of fig. 2 and 3 between synchronous and asynchronous modes.

FIG. 5 illustrates an exemplary RMACPHY architecture operating in a partially asynchronous mode.

Detailed Description

As previously described, in a distributed access architecture for delivering video content, two video processing modes, synchronous and asynchronous, may be used. Typically, the network device has hardware capable of operating in either mode, with software enabling configuration into either of these modes through its own video core and connected downstream devices when setting up the video channel. In synchronous mode, the RPD (or RMD) and its video core are synchronized in time to the same reference clock. In this sync mode, only RPD is needed to detect lost video packets using layer 2 tunneling protocol v.3 (L2 TPv 3) sequence number monitoring and insert MPEG null packets for each lost packet. This is a relatively simple implementation in which no additional modifications to the video stream are required.

For example, fig. 2 shows a system in a first configuration 100 in which video core 102 communicates with RPD 104 in a synchronized mode using a common master timing server 106. The timing server 106 maintains the same timing lock (i.e., frequency and phase) as 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 L2TPv 3. Video packets sent from video core 102 to RPD 104 typically include all information necessary to decode the packetized elementary video transport stream, such as Program Identifiers (PIDs), program Clock Reference (PCR) data, and the like.

RPD 110 then receives the video packets sent from video core 108 in de-jitter buffer 116 of processing device 114. The de-jitter buffer 116 receives and outputs packet data at a rate that eliminates network jitter caused by different paths of the received packet data or other sources of different network delays between the video core and the RPD. Because some packets sent by video streamer 112 may be lost or misplaced during transmission to RPD 104, packets output from de-jitter buffer 116 may be preferably forwarded to module 118, which inserts invalid packets in the data stream to account for those lost packets in order to maintain the proper timing rate of video transmission in the case of synchronous mode. The transport stream (including any necessary insertion of invalid packets) is then forwarded to PHY device 120, which may decode the packetized elementary stream into a series of decoded video frames for downstream delivery to the end user by outputting QAM modulated data in a format as desired by the customer premise equipment of the set top box. Alternatively, the PHY device may simply (without decoding) forward the packetized data to, for example, a cable modem for decoding by a user device such as a computer, tablet, cellular telephone, or the like.

Alternatively, the system just described may be configured to operate in an asynchronous mode. In asynchronous mode, the RPD 104 and its video core 102 are not synchronized in time to the same reference clock. In contrast, RPD 104 is required to detect the difference between its own clock 110 and clock 108 of video core 102 and to be able to insert or remove MPEG packets as needed to maintain the desired MPEG bit rate and also adjust the MPEG PCR value due to the removal/insertion of MPEG packets.

For example, fig. 3 shows the hardware of fig. 2 configured to operate instead in an 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. Video streamer 112 of video core 102 forwards the packets of the packetized elementary stream of video data to RPD 104, which again receives the data in de-jitter buffer 116 to eliminate network jitter, as previously described. However, unlike the configuration of fig. 2, packets output from de-jitter buffer 116 are forwarded to module 118, which adds invalid packets when needed and discards the packets when needed in order to maintain a suitably constant bit rate of data received from de-jitter buffer 116. Further, after adding/dropping packets as needed, the PCR module 119 re-stamps the data packets with PCRs updated due to the removal/insertion of MPEG packets, and then forwards the re-stamped packets to the PHY device 120.

Although the systems 100 and 101 shown in fig. 2 and 32 are shown for illustrative purposes using RPD 104 connected to video core 102, one of ordinary skill in the art will appreciate that RMDs may also be connected to video core 102 and have the same components shown with respect to RPD 104, operating in the same manner as RPD 104.

Each of the synchronous and asynchronous modes of operation has advantages and disadvantages. Regarding asynchronous mode, the main advantage is not dependent on clock synchronization between video core 112 and RPD 114; RPD 114 will detect these clock differences and "repair" the MPEG output accordingly. The main disadvantage of asynchronous mode is that this mode is more complex than video processing that occurs in RPD 114 during synchronous mode, and to correct timing differences, RPD 114 needs to discard MPEG packets from the input stream occasionally. This adverse effect may be mitigated if the video core adds invalid packets to the stream such that the RPD will have invalid packets at hand when it needs to drop packets, but this option adds unnecessary bandwidth to the data stream and/or adversely affects video quality, and the video core often does not add enough invalid packets to completely eliminate the necessity of dropping data-carrying packets.

For synchronous mode, the main advantage is that video processing in RPD is simple, where RPD does not need to track changes between the incoming video stream and its internal clock, and does not need to apply any MPEG modifications, except to maintain a constant bit rate at its output by adding MPEG invalid packets in case of detected lost incoming packets. The main disadvantage of the synchronization mode is the reliance on clock synchronization between the RPD and the video core. Although this assumption is generally valid because the video core and/or RPD does not often lose connection with the master clock, there are cases where such connection is lost, and even if not, there may be cases where the clocks of the core and RPD are not sufficiently synchronized due to differences in network delays in timing messages with, for example, the master clock, or internal problems of the core or RPD. In any of these cases, since the RPD in sync mode does not adjust any MPEG PCR, clock differences may cause illegal MPEG streaming out of the RPD, which may lead to a perceptible degradation of video quality.

In some preferred embodiments, the system depicted in fig. 2 and 3 may dynamically transition RPD 104 from synchronous mode to asynchronous mode based on information retrieved from de-jitter buffer 116. In such embodiments, the RPD may be configured to operate in the synchronous mode as shown in fig. 2 by default until a trigger condition event, after which the RPD 104 switches to the asynchronous mode as shown in fig. 3. Thereafter, the RPD 104 will remain in asynchronous mode until a second conditional event is detected, after which the RPD 104 will change back to synchronous operation as shown in fig. 2.

In some embodiments, the conditional event(s) may be based on a measurement of the state of the de-jitter buffer 116. Thus, for example, RPD 104 may preferably implement a first threshold based on the measurement, beyond which video streams are assumed to be unsynchronized. The threshold may be defined in many different ways. For example, a suitable first threshold may be a maximum average change (plus or minus) of the fullness state of the buffer from a predefined standard operating level. Thus, the RPD 104 may measure the fullness state of the buffer, in some embodiments, optionally average or otherwise apply a filter to eliminate temporary spikes in network jitter, and if the measured value exceeds a predefined first change threshold, the flow is assumed to be unsynchronized. An exemplary such first threshold in a preferred embodiment may be +/-25%. In some preferred embodiments, this first threshold may be configurable.

The replacement threshold may be a value that measures the buffer fill/empty rate. The RPD 104 may again measure such metrics by optionally filtering it to eliminate temporary variations due to network jitter. If the rate of change exceeds a predefined threshold, the video stream is assumed to be unsynchronized.

The RPD 104 may also preferably implement a second threshold for dynamically transitioning from the asynchronous mode back to the synchronous mode. In some embodiments, the second threshold may be the same as the first threshold for transitioning to asynchronous mode, but in other embodiments, the first and second thresholds are different. If different thresholds are used, the second threshold is preferably more stringent than the first threshold. For example, using the previous example, where a first threshold of +/-25% is set to the limit at which the RPD dynamically transitions from synchronous mode to asynchronous mode, a second threshold of +/-15% may be used to dynamically transition back to synchronous mode. Again, in some preferred embodiments, the second threshold may be configurable.

In some embodiments, when the RPD 104 is operating in asynchronous mode, to reduce the probability of dropping "important" MPEG packets if invalid packets are not available, the RPD 104 may implement a priority list of packets to be dropped (where the invalid packets are the first of the priorities to be dropped, then a set of PID values (e.g., SI PID, CAT PID, etc.), other methods may be applied to reduce the probability of dropping critical MPEG packets, such as prioritizing I frames relative to P frames and B frames, and P frames relative to B frames.

Because the buffer state switches to asynchronous mode after deviating from the nominal or optimal value by a threshold amount, in some embodiments, the RPD 104 may decide to "pull" the queue back to its nominal or optimal depth before switching to synchronous mode again in order to preserve the jitter margin. This may be appropriate, for example, when the first threshold is set to a low value for a low delay.

Fig. 4 illustrates an exemplary method by which the RPD 104 may dynamically switch between synchronous and asynchronous modes. In step 132, the rpd is configured to operate in a synchronous mode. In step 134, the processing mode of the rpd 104 is set to "synchronous". At decision step 136, it is determined whether the buffer status exceeds a first threshold, as previously described. If the answer is "no," the method proceeds to step 138 where the RPD 104 processes the video stream in "synchronous" mode, then proceeds to step 140 where it is determined whether the data exits the buffer 116 at a fixed rate, and proceeds to step 142 where invalid packets are added to maintain a fixed bit rate into the PHY 120, if necessary. The flow then returns to step 136 to again determine whether the buffer status exceeds the first threshold.

If it is determined at step 136 that the buffer status exceeds the first threshold, the method then proceeds to step 144, where the RPD processing mode is set to "asynchronous". Then, at step 146, an invalid packet is added or deleted, and at step 148, the PCR stamp of the packet is adjusted due to the added and deleted packet. In step 148, the packet enters the PHY at a fixed bit rate.

At decision step 152, it is determined whether the state of the buffer 116 exceeds a second threshold. If not, flow returns to step 144. If so, flow may proceed to optional steps 154 and 156. At decision step 154, a determination is made as to whether the buffer needs to be placed back at an optimal or nominal depth. If the answer is no, the system returns to step 134 where the processing mode of the RPD 104 is set to "synchronous". If the answer is "yes," then at step 156, the asynchronous mode continues until the buffer is pulled back to its nominal or optimal depth, and flow returns to step 134, as previously described.

Those of ordinary skill in the art will appreciate that while the systems and methods described with respect to fig. 2-4 are illustrated using a video core connected to an RPD, the foregoing disclosure is applicable to communications between the video core and an RMD. However, while the RPD typically must rely on an external source to provide its timing information, the RMD typically includes hardware components that include their own oscillators for operating independent clocks in the RMD. Thus, when a network such as those previously described includes one or more mac phy devices, the present application discloses additional partially asynchronous modes that may be used in some embodiments in conjunction with the aforementioned systems and methods, or in alternative embodiments in systems or methods in which remote devices (e.g., RMD and RPD) do not dynamically alternate between synchronous and asynchronous modes.

In particular, while a downstream network device such as an RPD or RMD theoretically detects the clock difference between itself and the core and "repairs" its MPEG output accordingly when operating in asynchronous mode, in order for it to function, both the video core and RMD must have oscillators of sufficiently high quality to maintain an MPEG compliant clock (-30 PPM accuracy and-10 PPM/hour drift). Since RMD is a hardware-built platform, there is typically an oscillator that will meet these requirements for its Data Over Cable Service Interface Specification (DOCSIS) operation, with more stringent clock requirements than MPEG video delivery. However, the video core is in many cases simply a software-based implementation using an oscillator built into an Off The Shelf (OTS) server, which may not support the required accuracy. In these cases, the advantage of operating in asynchronous mode is eliminated because the video core requires an external GM to have its clock dependent.

Thus, referring to fig. 5, the system 200 may include a video core 202 connected to one or more RMDs 204a, 204b, 204c, etc., each of which may preferably be configured with the components shown in fig. 3 with respect to the RPD 104, i.e., one or more RMDs may each be equipped with a de-jitter buffer 216, modules 118 and 119 providing invalid packet insertion/packet removal and PCR adjustment, respectively, a downstream PHY 220, and a clock 210. In addition, one of ordinary skill in the art will appreciate that although only RMD is shown in fig. 5, system 200 may also include one or more RPDs.

As previously described, in some embodiments, when video core 202 loses connection with the timing master, RMDs 204a, 204b, and 204c (and any RPDs 104 in the network) may preferably be configured to operate in an asynchronous mode as previously described in order to continue processing video packets received from video core 202. However, to operate reliably in asynchronous mode, core 202 requires enough internal clocks that it may not be equipped with. In this case, core 202 may use one of RMDs 204a, 204b, or 204c as a designated master to provide more reliable timing information than its own clock can generate, as RMDs will typically be pre-configured with oscillators that meet the MPEG video encoding and transmission requirements. In fig. 5, for example, clock 210 of RMD 204a acts as a designated master and sends a clock synchronization message 222 to core 202. The synchronization message in the preferred embodiment is sent from clock 210 of RMD 204a to clock 208 of the video core. Preferably, each RMD 204a, 204b, 204c, etc. is capable of acting as a designated ancestor master in the event that, for example, a connection between the video core 202 and any RMD previously acting as a designated ancestor master is lost.

In this "partially asynchronous" mode, the video core 202 preferably locks to a specified RMD 204a, as does any "regular" master timer, and has its MPEG clock and PCR dependent on the specified RMD 204a. The designated RMD 204a may preferably synchronize only the video core clock 208 to its own clock 210, but would otherwise operate in an asynchronous mode, just as all other RMDs 204b, 204c, etc. and any RPDs 104 in the network. The only purpose of specifying clock synchronization between RMD 204a and video core 202 is to provide a reliable MPEG compliant clock for video core 202; the other RMDs 204b, 204c, etc. need not be locked to the clock because they also preferably operate in asynchronous mode. Nor is it necessary to provide any other external clock reference to the designated RMD 204a to lock its own clock, as it may rely on its own oscillator.

Any suitable method may be used to select RMD to serve as the designated source of timing information for video core 202 during asynchronous mode. As one example, a dedicated provisioning server may configure the video core 202 to connect to its designated RMD. Alternatively, each RMD 204a, 204b, 204c, etc. may be configured in an asynchronous mode to send its timing information to the video core 202, which itself will use, for example, the Best Master Clock Algorithm (BMCA) to specify which stream is to be used as the designated master.

Whichever method is used to designate RMD as the designated master, because the RMD designated as the timing source of video core 202 is not locked to an external clock, the time base of the information sent to video core 202 may change abruptly, e.g., if the designated RMD resets, or another RMD is triggered offline to act as the designated master. This will cause it to insert PCR "jumps" into the MPEG stream, which in turn may cause problems for the decoder receiving the MPEG stream. Thus, in some preferred embodiments, when video core 202 detects that the time base is changed, it may set an appropriate "discontinuity indicator" flag on the first PCR packet adaptation field. RMD (or RPD) can adjust the PCRs accordingly by which they re-stamp the video stream to remove the discontinuity.

While the foregoing disclosure of the R-mac phy device sending timing information to the video core while operating in the asynchronous mode has been described in the context of a system in which the R-mac phy device is capable of dynamically configuring itself to operate in the synchronous mode or the asynchronous mode, one of ordinary skill in the art will recognize that the embodiment of fig. 5 may also be used in other environments. For example, as previously described, RPD and RMD can generally be configured in either of an asynchronous mode and a synchronous mode, where a video core or other network device can simply configure its connected RPD and RMD to operate in an asynchronous mode at all times. Even in this case, the system shown in fig. 5 may be beneficial. For example, if the video core is configured not to receive timing information from the external master while the remotely connected device is operating in asynchronous mode, either because it is temporarily disconnected or because it is not configured to receive such information from the external master at all, the benefit of receiving more reliable timing information from RMD than provided by its own internal clock is apparent.

It is to be understood that the invention is not limited to the specific embodiments that have been described and that changes may be made therein without departing from the scope of the invention as defined in the appended claims, as interpreted in accordance with the principles of law including the doctrine of equivalents or any other principle that extends beyond the scope of the doctrine of equivalents to the scope of the claims. Reference in the claims to the number of instances of an element (whether reference to one instance or more than one instance) requires at least the specified number of instances of the element, but is not intended to exclude structures or methods having more instances than the element from the scope of the claims unless the context indicates otherwise. When used in a claim, the word "comprising" or its derivatives are used in a non-exclusive sense, not intended to exclude the presence of other elements or steps in the claimed structure or method.

Claims (40)

1. A remote mac phy (R-mac phy) device, comprising:

a clock and a de-jitter buffer that receives video packets from the video core;

at least one module capable of adjusting video packets received from the de-jitter buffer, the adjustment varying based on whether the R-mac phy device is configured to operate in a synchronous mode or an asynchronous mode; wherein,,

the clock may be configured to selectively output timing information to another device, the selecting to output timing information to the other device being configured to selectively occur when the R-mac phy device is operating in an asynchronous mode.

2. The apparatus of claim 1, wherein the at least one module selectively discards packets received from the de-jitter buffer in an asynchronous mode.

3. The apparatus of claim 1, wherein the at least one module selectively re-stamps Program Clock Reference (PCR) values to the packets in an asynchronous mode.

4. The apparatus of claim 3, the apparatus configured to selectively re-stamp the PCR values using an offset value.

5. The apparatus of claim 1, wherein the other apparatus is the video core.

6. The apparatus of claim 1, wherein the other apparatus is a provisioning server.

7. A video core, comprising:

a video streamer configured to transmit video packets to at least one remote device, including a first device;

a clock having a first input, the clock configured to receive synchronization information from the first device and to use the synchronization information to adjust a rate at which the video streamer transmits a plurality of packets to the at least one remote device; wherein,,

the core need not send the synchronization information to the at least one remote device, and wherein the video packet includes a PCR and the video streamer is configured to send an offset value associated with the PCR.

8. The video core of claim 7, configured to select synchronization information from the first device from synchronization information received from a plurality of unsynchronized remote devices.

9. The video core of claim 7, configured to receive information from a selected remote device of a plurality of unsynchronized remote devices, the selection made by a provisioning server.

10. An apparatus in a communication network, the apparatus receiving and selectively modifying an MPEG compliant transport stream received from a video core and then transmitting the transport stream in a downstream direction to a Customer Premise Equipment (CPE), wherein the apparatus is configured to determine an amount of synchronization between the apparatus and the video core and to configure itself in a selected one of a synchronous mode and an asynchronous mode alternately based on the determined amount of synchronization.

11. The device of claim 10, comprising a Remote Physical Device (RPD).

12. The apparatus of claim 10, comprising a remote mac phy device (RMD).

13. The apparatus of claim 10, the apparatus configurable to receive timing information from a common timing source that also provides the timing information to the video core, and the apparatus switches from synchronous mode to asynchronous mode when at least one of the apparatus and the video core loses lock with the common timing source.

14. The apparatus of claim 13, wherein the apparatus switches from asynchronous mode to synchronous mode when at least one of the apparatus and the video core that loses its lock with the common timing source regains lock with the common timing source.

15. The apparatus of claim 10, the apparatus configurable to receive timing information from a common timing source, the common timing source also providing the timing information to the video core, and the apparatus capable of switching from synchronous mode to asynchronous mode while both the apparatus and the video core remain locked to the common timing source.

16. The apparatus of claim 10, the apparatus having a de-jitter buffer, wherein the apparatus modifies the MPEG compliant transport stream based on an output of the de-jitter buffer.

17. The apparatus of claim 16, wherein the apparatus uses an output of the de-jitter buffer to determine the amount of synchronization.

18. The apparatus of claim 10, wherein the apparatus is configured to change from synchronous mode to asynchronous mode based on the determined amount of synchronization and from asynchronous mode to synchronous mode based on the determined amount of synchronization.

19. The apparatus of claim 18, the apparatus capable of changing from an asynchronous mode to a synchronous mode using a determined amount of synchronization and a determined offset of a fullness of a de-jitter buffer in the apparatus from a predetermined fullness amount.

20. A system, comprising:

a video core having a core clock and a video streamer;

a remote mac phy (R-mac phy) device having a clock in communication with a video core clock, a de-jitter buffer that receives video packets from the video streamer, and at least one module capable of adjusting the video packets received from the de-jitter buffer, the adjustment varying based on whether the R-mac phy device is configured to operate in a synchronous mode or an asynchronous mode; wherein,,

the remote clock selectively provides timing information to the core clock when the R-MACPY device is operating in an asynchronous mode.

21. The system of claim 20, wherein the at least one module selectively discards packets received from the de-jitter buffer in an asynchronous mode.

22. The system of claim 20, wherein the at least one module selectively re-stamps Program Clock Reference (PCR) values to the packets in an asynchronous mode.

23. The system of claim 20, wherein the core clock is configured to selectively transmit an offset value to the R-mac phy device.

24. A method, comprising:

transmitting synchronization information from a remote clock in the R-mac phy device to a core clock in the video core;

transmitting video data from a video streamer in the video core to at least one Physical (PHY) device downstream of the video core, the at least one PHY device comprising the R-mac PHY device; and

operating the at least one PHY device in an asynchronous mode, including the R-mac PHY device.

25. The method of claim 24, wherein the core clock is configured to selectively transmit an offset value to the R-mac phy device.

26. The method of claim 24, wherein the video core provides the synchronization information from the R-mac phy device to the video streamer to adjust a rate at which packets are sent from the video streamer.

27. The method of claim 26, wherein at least one other device comprises another R-mac phy device.

28. The method of claim 27, wherein timing information from the R-mac phy device is selected for transmission by the video core to the video streamer in preference to timing information from the other R-mac phy device.

29. The method of claim 27, wherein selecting timing information from the R-mac phy device is performed by the video core.

30. The method of claim 27, wherein selecting timing information from the R-mac phy device is performed by a provisioning server.

31. A method for dynamically alternating modes of operation between synchronous and asynchronous modes for a device in a communication network that receives video data from a video core, the method comprising:

initializing the device to operate in a synchronous mode;

determining a synchronization magnitude between the device and the video core; and

selectively changing to an asynchronous mode based on the determined amount of synchronization.

32. The method of claim 31, the method being performed by a Remote Physical Device (RPD).

33. The method of claim 31, performed by a remote mac phy device (RMD).

34. The method of claim 31, comprising the step of selectively changing from an asynchronous mode back to a synchronous mode based on the second determined synchronous magnitude.

35. A method as claimed in claim 34, wherein the synchronisation magnitude is determined by measuring the state of a de-jitter buffer in the apparatus, and the method comprises the step of returning the fullness of the de-jitter buffer to a predetermined level before changing the apparatus back to asynchronous mode.

36. The method of claim 34, wherein the second determined synchronization magnitude is different from the first determined synchronization magnitude.

37. The method of claim 36, wherein the second determined synchronization magnitude is less than the first determined synchronization magnitude.

38. The method of claim 31, wherein the synchronization magnitude is determined by measuring a state of a de-jitter buffer in the device.

39. The method of claim 38, wherein the measured state of the de-jitter buffer is a fullness state of the de-jitter buffer and a rate of change of the fullness state of the de-jitter buffer.

40. The method of claim 38, wherein the measured state of the de-jitter buffer is a rate of change of the fullness state of the de-jitter buffer.