Abstract:
A device is provided for use with an encoder, source video data and a source video clock. The encoder can encode video data at a timebase corrected video clock and can encode audio data at a timebase corrected audio clock. The source video data includes a video data portion and an audio data portion. The device includes a video processing portion, an audio processing portion and a clock generating portion. The video processing portion is arranged to receive the source video data based on the source video clock. The audio processing portion is arranged to receive the source video data based on the source video clock. The clock generating portion can generate the timebase corrected video clock and can generate the timebase corrected audio clock. The video processing portion can provide, to the encoder, the video data portion of the source video data based on the timebase corrected video clock. The audio processing portion can provide, to the encoder, the audio data portion of the source video data based on the timebase corrected audio clock.

Description:
BACKGROUND 
       [0001]    In many cases where a video is provided to an end user, the data of the video had been encoded into a format that is different from the original format of the data of the video. In the broadcast TV industry, “encoding” typically means “compressing”, “video” refers only to visual data, and audio refers to data related to sound. Combined, visual data and audio data are referred to as audio/video data. A/V data is compressed into a first format by an encoder for transmission to an end user. Compression/encoding is typically done prior to data storage or transmission in order to reduce the amount of data that must be stored or transferred. At the end user, the compressed data is the decompressed to another format by a decoder. 
         [0002]    The decoder must uncompress the A/V data and “present” it to a consumer such as a television (TV). For the A/V data to be displayed/heard properly, the decoder must recreate the original rates at which the data was encoded. In order to do this, the decoder relies on timing information embedded in the encoded data. For precise and glitch-free recovery by the decoder, the encoder must: (1) utilize a very stable and accurate timing reference to generate the embedded timing information; and (2) be “frequency locked” to the rate of the audio/video data being compressed. The encoder is not always able to perform these functions. The rate of the A/V data may occasionally deviate significantly from the encoder&#39;s timing embedder&#39;s requirements. Therefore, the A/V data must be transferred to a “clean” time domain prior to encoding. In other words, in many cases, the data of the video is provided at a first rate or a first clock signal, whereas the encoder is able to encode data at a second, different rate or a second clock signal. To complicate matters, the video data and audio data may additionally be provided at different clock signals and may be processed by the encoder with still different clock signals. 
         [0003]    The process of transferring audio and video data from its source to an encoder is typically a complex process that involves synchronizing the audio and video data to respective clocks signals, while taking care to maintain audio/video (AV) synchronization between the frames in the video data and the audio signal. If there is no AV synchronization, then the audio data may be played at a time that is inconsistent with the video data that originally corresponded to the audio data. For example, when watching a video on television, if the sound does not synchronize with the image, the viewer may see a person&#39;s lips moving whereas the resulting sound (speech) does not match the lip movement. In order to maintain high performance and minimize bandwidth usage in the process of transferring audio and video data from its source to an encoder, this transfer process typically requires fairly complicated systems using costly components. 
         [0004]    First of all, the video clock signal accompanying video data sent to an encoder is required to meet certain requirements (e.g. should be glitch-free, frequency must be within a certain range). Therefore, a clock signal synthesizer is typically used to generate a clock signal that is locked to the source video clock signal but meets these requirements. This is known as the time-base corrected (TBC) video clock signal. Using a frame buffer, the video data is then transferred from the domain of the source video clock signal to the TBC video clock signal so that it can be sent to the encoder. 
         [0005]    Video data is typically accompanied by audio data, which may be embedded in the video data (known as ancillary audio) or may come from another source. Audio data that is not embedded in the video data, i.e., ancillary audio data, is required to be in the source audio clock domain before it can be encoded. Ancillary audio data needs to be extracted and transferred to a source audio clock domain. However, since the video data sent to the encoder is in the domain of the TBC video clock signal, the audio data must also be sent using a clock signal derived from the TBC video clock signal. Thus, it is necessary to transfer the audio data to a domain of the TBC audio clock signal. Thus, in the typical conventional process of transferring video and audio data from a source to an encoder, there are the following four clock signals: 1) the source video clock signal; 2) the source audio clock signal, consisting of an audio clock signal derived from the source video clock signal; 3) the TBC video clock signal; and 4) the TBC audio clock signal, consisting of an audio clock signal derived from TBC video clock signal. 
         [0006]    Transferring audio data to the domain of the TBC audio clock signal, while maintaining AN synchronization, can be a fairly complicated process, due to various considerations and limitations. One possible method is to simply re-sample the audio data in the domain of the TBC audio clock signal. However, this solution is not versatile as it is can only be implemented for uncompressed audio data, and not for pre-compressed audio data. 
         [0007]    Another possible solution is to allow the ancillary audio data to be written to the video frame buffer along with video data, such that the audio data as well as the video data is transferred to the domain of the TBC video clock signal. However, this has the disadvantage of increasing the memory bandwidth utilization. Furthermore, this solution is also not versatile since it can only be used for embedded audio data, which has a known timing relation to the corresponding video data. Audio data from external sources is required to have a known timing relation with the video data as mentioned above. This approach is not feasible for audio data from an external source because it would complicate the frame buffer design to account for writing audio data, in addition to video data, to the frame buffer. Further, as with ancillary audio data, memory bandwidth utilization will increase. 
         [0008]    With all these considerations, it is apparent that a versatile method for the clock signal transfer of the audio data must support both uncompressed and compressed audio data, and both embedded (ancillary) and external audio data. Furthermore, it must be able to maintain AV synchronization. The most common approach used to meet these requirements involves first transferring the audio data to a domain of the source audio clock signal, and then transferring that audio data to the encoder while providing the TBC video and audio clock signals to the encoder as a reference. The encoder must then manage the clock domain transfer of the audio data in its own buffers, while constantly exchanging frame buffer status with the frame buffer in order to maintain AV synchronization. An example of this approach will now be discussed with reference to  FIG. 1 . 
         [0009]      FIG. 1  is a schematic illustrating a conventional system  100  for transferring audio data from a domain of the source clock signal to a domain of the TBC audio clock signal. 
         [0010]    Conventional system  100  includes a source clock synthesizer  102 , a field programmable gate array (FPGA)  104 , a double data rate synchronous dynamic random access memory (DDR 2  SDRAM)  106 , a numerically controlled oscillator (NCO)  108 , a video clock synthesizer  110 , an audio clock synthesizer  112  and an encoder  114 . 
         [0011]    FPGA  104  includes a DDR 2  controller  146 , an audio de-embedder  118 , a first-in-first-out (FIFO) buffer  120  and an NCO controller  148 . Encoder  114  includes an audio data buffer  124 . DDR 2   106  and DDR 2  controller  146  together may be considered a frame synchronizer and buffer  116 . NCO  108  and NCO controller  148  together may be considered a TBC clock synthesizer  122 . 
         [0012]    Note that in this embodiment, frame synchronizer and buffer  116  includes a portion external to FPGA  104  (DDR 2   106 , the “buffer” portion) as well as a portion implemented within FPGA  104  (DDR 2  controller  146 , the “frame synchronizer” or “controller” portion). Similarly, TBC clock synthesizer  122  includes a portion external to FPGA  104  (NCO  108 ) as well as a portion implemented within FPGA  104  (NCO controller  148 , which may include clock signal synthesis components such as a phase comparator and loop filter). 
         [0013]    Source clock synthesizer  102  is arranged to receive source video clock signal  126  and to output a source audio clock signal  130 . Audio de-embedder  118  is arranged to receive source video data  128  and to output audio data  134 . FIFO buffer  120  is arranged to receive audio data  134 , source video clock signal  126  and source audio clock signal  130  and to output audio data  136 . TBC clock synthesizer  122  is arranged to provide reference clock signal  138 . Video clock synthesizer  110  is arranged to receive reference clock signal  138  and to output TBC video clock signal  140 . Audio clock synthesizer  112  is arranged to receive reference clock signal  138  and to output TBC audio clock signal  142 . Frame synchronizer and buffer  116  is arranged to receive source video clock signal  126 , source video data  128  and TBC video clock signal  140  and to output TBC video data  132  and frame sync status  144 . Encoder  114  is arranged to receive TBC video data  132 , frame sync status  144 , audio data  136 , source audio clock signal  130 , TBC video clock signal  140  and TBC audio clock signal  142  and to output frame sync status  144 . Audio data buffer  124  is arranged to receive audio data  136 . 
         [0014]    Source video data  128  includes portions of video data and portions of audio data. Source video data  128  is provided by source video clock signal  126 . In order for encoder  114  to be able to encode source video data  128  for transmission, source video data  128  must be provided to encoder  114  at a TBC clock signal speed. In many cases, source video clock signal  126  is not a TBC clock signal speed. Accordingly, frame synchronizer and buffer  116  is operable to synchronize and buffer frames of the video data of source video data  128 . In other words, video data of source video data  128  is written into frame synchronizer and buffer  116  using source video clock signal  126 . The video data of source video data  128  will then be read from frame synchronizer and buffer  116  as TBC video data  132  using TBC clock signal  140 . 
         [0015]    Audio de-embedder  118  is operable to strip out the portions of audio data from source video data  128  and provide those portions to FIFO buffer  120  as audio data  134 . Audio data  134  is written into FIFO buffer  120  with source video clock signal  126 . Audio data  136  is read from FIFO buffer  120  with source audio clock signal  130 . 
         [0016]    As discussed above, video and audio data are written into their respective buffers with the same write clock signal, but are read from their respective buffers with different clock signals. This is a source of problems with the conventional system. 
         [0017]    In particular, audio data  136  is read from FIFO buffer  120  using source audio clock signal  130 , which is based on source video clock signal  126 . If there is a problem with source video clock signal  126 , then there will be a problem with source audio clock signal  130 . In such a case, there will be a problem reading audio data  136  from FIFO buffer  120 , but TBC video data  132  will still be read from frame synchronizer and buffer  116  with TBC video clock signal  140 . In this situation, encoder  114  will recognize, by way of frame sync status  144 , that audio data  136  does not synchronize with TBC video data  132  and will adjust the amount of audio data buffered in audio data buffer  124  to compensate. 
         [0018]    In many cases AN data has different amounts of video data than audio data (in most cases there is much more video data than audio data). To account for the disparity in the types of data, encoder  114  will encode the video data and the audio data at different rates, which are phase-locked. Video clock synthesizer  110  generates TBC video clock signal  140  from reference clock signal  138 . Similarly, audio clock synthesizer  112  generates TBC audio clock signal  142  from reference clock signal  138 . Video clock synthesizer  110  and audio clock synthesizer  112  are set such that TBC video clock signal  140  and TBC audio clock signal  142  meet the requirements of encoder  114  for encoding AV data in accordance with the predetermined coding scheme. 
         [0019]    TBC video data  132  is written into encoder  114  by way of TBC video clock signal  140 . Audio data  136  is written into audio data buffer  124  by way of source audio clock signal  130 . Audio data  136  is read from audio data buffer  124  by way of TBC audio clock signal  142 . 
         [0020]    Video clock synthesizer  110  generates TBC video clock signal  140  and audio clock synthesizer  112  generates TBC audio clock signal  142  based on reference clock signal  138 . Therefore TBC video clock signal  140  and TBC audio clock signal  142  are of the same domain. Encoder  114  uses TBC video clock signal  140  to write TBC video data  132  for encoding. Encoder  114  uses TBC audio clock signal  142  to write audio data from audio data buffer  124  for encoding. 
         [0021]    An example method  200  for the operation of conventional system  100  will now be described with reference to  FIG. 2 . 
         [0022]    In operation, process  200  starts (S 202 ) and source video clock synthesizer  102  receives source video clock signal  126  and produces source audio clock signal  130  (S 204 ). 
         [0023]    Source video data  128  for encoding is additionally supplied to the video and audio buffers (S 206 ). Audio de-embedder  118  receives source video data  128 , which includes video data portions and audio data portions, and extracts the audio data portions as audio data  134 . Audio de-embedder  118  then provides audio data  134  to FIFO buffer  120 . Source video data  128  is concurrently provided to frame synchronizer and buffer  116 . 
         [0024]    At this point, source video data  128  is then written to the video and audio buffers (S 208 ). Source video clock signal  126  enables source video data  128  to be written into frame synchronizer and buffer  116  and additionally enables audio data  134  to be written into FIFO buffer  120 . 
         [0025]    Audio data is then supplied to the encoder (S 210 ). Audio data  136  is read from FIFO buffer  120  using source audio clock signal  130 . Audio data  136  is then provided to audio data buffer  124  within encoder  114 . 
         [0026]    TBC video data  132  is then supplied to encoder  114  (S 212 ). TBC video data  132  is read from frame synchronizer and buffer  116  using TBC video clock signal  140 . TBC video data  132  is then provided to encoder  114 . 
         [0027]    At this point, TBC video clock signal  140  writes TBC video data  132  into encoder  114  while TBC audio clock signal  142  writes audio data  136  from audio data buffer  124  into encoder  114  (S 212 ). Audio data buffer  124  may full up if too much audio data is provided for a corresponding portion of video data. This may occur when data is read from frame synchronizer and buffer  116  at a rate that is slower than the required rate for the data that is read from FIFO buffer  120 . In other words, if source audio clock  130  is not synchronized with TBC video clock  140 , audio  136  may be read into audio data buffer  124  at a much higher rate than TBC video data  132  is read into Encoder  114 . This situation may cause audio data buffer  124  to fill up. To account for this situation, during step S 212 , encoder  114  constantly exchanges frame buffer status (via frame sync status  144 ) with frame synchronizer and buffer  116 , in order to maintain AV synchronization. 
         [0028]    Encoder  114  then encodes TBC video data  132  and audio data  136  (S 214 ) in accordance with a predetermined coding scheme and process  200  stops (S 216 ). 
         [0029]    The problem with conventional system  100  (and corresponding process  200 ) is that it typically requires costly components, and also involves fairly complicated design and debugging efforts. Specifically, source audio clock synthesizer  102 , which is required to generate source audio clock signal  130  from source video clock signal  126  (S 204 ), might not accurately lock with source video clock signal  126 . This may case large swings, or even overflow, in data storage within FIFO buffer  120 . Further, reading audio data  136  into audio data buffer  124  with source audio clock signal  130  might not accurately correspond the reading of TBC video data  132  into encoder  114  with TBC video clock signal  140 . This may case large swings, or even overflow, in audio data buffer  124 . Overflow in data storage within FIFO buffer  120  or within audio data buffer  124  may disrupt AV synchronization. To avoid this issue in the conventional method, a very significant amount of design, integration and debugging of resources may be required. 
         [0030]    What is needed is a system and method that can perform the process of transferring audio data from a domain of the source clock signal to a domain of the TBC audio clock signal while preserving A/V synchronization in a simple, cost-effective manner, thereby providing significant cost and design time reduction benefits. 
       BRIEF SUMMARY 
       [0031]    The present invention provides a system and method that can perform the process of transferring audio data from a domain of the source clock signal to a domain of the TBC audio clock signal while preserving A/V synchronization in a simple, cost-effective manner, thereby providing significant cost and design time reduction benefits. 
         [0032]    In accordance with an aspect of the present invention, a device is provided for use with an encoder, source video data and a source video clock. The encoder can encode video data at a timebase corrected video clock and can encode audio data at a timebase corrected audio clock. The source video data includes a video data portion and an audio data portion. The device includes a video processing portion, an audio processing portion and a clock generating portion. The video processing portion is arranged to receive the source video data based on the source video clock. The audio processing portion is arranged to receive the source video data based on the source video clock. The clock generating portion can generate the timebase corrected video clock and can generate the timebase corrected audio clock. The video processing portion can provide, to the encoder, the video data portion of the source video data based on the timebase corrected video clock. The audio processing portion can provide, to the encoder, the audio data portion of the source video data based on the timebase corrected audio clock. 
         [0033]    Additional advantages and novel features of the invention are set forth in part in the description which follows, and in part will become apparent to those skilled in the art upon examination of the following or may be learned by practice of the invention. The advantages of the invention may be realized and attained by means of the instrumentalities and combinations particularly pointed out in the appended claims. 
     
    
     
       BRIEF SUMMARY OF THE DRAWINGS 
         [0034]    The accompanying drawings, which are incorporated in and form a part of the specification, illustrate an exemplary embodiment of the present invention and, together with the description, serve to explain the principles of the invention. In the drawings: 
           [0035]      FIG. 1  is a schematic illustrating a conventional system for transferring audio data from a domain of a source clock signal to a domain of a TBC audio clock signal; 
           [0036]      FIG. 2  illustrates an example method for the operation of the conventional system of  FIG. 1 ; 
           [0037]      FIG. 3  illustrates a system for transferring audio data from a domain of a source clock signal to a domain of a TBC audio clock signal, in accordance with an aspect of the present invention; 
           [0038]      FIG. 4  illustrates an example method for the operation of the system of  FIG. 3 , in accordance with an aspect of the present invention; and 
           [0039]      FIG. 5  illustrates an example set of calculation and conversion tables used in the system of  FIG. 3 , in accordance with an aspect of the present invention. 
       
    
    
     DETAILED DESCRIPTION 
       [0040]    In accordance with an aspect of the present invention, a system and method is able to perform the process of transferring audio data from a domain of a source clock signal to a domain of a TBC audio clock signal in a simple and cost-effective manner. 
         [0041]    An example embodiment in accordance with an aspect of the present invention will now be described in reference to  FIG. 3 . 
         [0042]      FIG. 3  illustrates a system  300  for transferring audio data from a domain of a source clock signal to a domain of a TBC audio clock signal, in accordance with an aspect of the present invention. 
         [0043]    System  300  includes a field programmable gate array (FPGA)  302 , double data rate synchronous dynamic random access memory (DDR 2  SDRAM)  106 , numerically controlled oscillator (NCO)  108 , video clock synthesizer  110 , audio clock synthesizer  112  and an encoder  314 . 
         [0044]    FPGA  302  includes DDR 2  controller  146 , audio de-embedder  118 , FIFO buffer  120  and NCO controller  148 . DDR 2   106  and DDR 2  controller  146  together may be considered frame synchronizer and buffer  116 . NCO  108  and NCO controller  148  together may be considered TBC clock synthesizer  122 . 
         [0045]    Similar to conventional system  100  discussed above, audio de-embedder  118  is arranged to receive source video data  128  and to output audio data  134 . TBC clock synthesizer  122  is arranged to provide TBC reference clock signal  138 . Video clock synthesizer  110  is arranged to receive TBC reference clock signal  138  and to output TBC video clock signal  140 . Audio clock synthesizer  112  is arranged to receive TBC reference clock signal  138  and to output TBC audio clock signal  142 . FIFO buffer  120  is arranged to receive audio data  134  and source video clock signal  126  and to output TBC audio data  136 . Frame synchronizer and buffer  116  is arranged to receive source video clock signal  126 , source video data  128  and TBC video clock signal  140  and output TBC video data  132 . Encoder  314  is arranged to receive TBC video data  132 , TBC audio data  136 , TBC video clock signal  140  and TBC audio clock signal  142 . 
         [0046]    Audio de-embedder  118  is operable to strip out the portions of audio data from source video data  128  and provide those portions to FIFO buffer  120  as audio data  134 . Audio data  134  is written into FIFO buffer  120  with source video clock signal  126 . Unlike conventional system  100  discussed above with reference to  FIG. 1 , in system  300 , audio data  136  is read from FIFO buffer  120  with source audio clock signal  130 . 
         [0047]    Further, unlike system  100 , system  300  does not contain a clock synthesizer to derive a source audio clock signal from source video clock signal  126  (such as source audio clock synthesizer  102  in conventional system  100 ). Rather, TBC audio clock signal  142  is instead supplied to FIFO buffer  120  as the read clock signal such that resulting output (TBC audio data  136 ) is in the domain of TBC audio clock signal  142 . Further, encoder  314  does not contain an audio buffer (such as audio buffer  124  in conventional system  100 ), nor does encoder  314  exchange frame sync status with frame synchronizer and buffer  116 . 
         [0048]    Therefore, in accordance with an aspect of the present invention, TBC video clock signal  140  and TBC audio clock signal  142  are generated from a single source, TBC reference clock signal  138 . Accordingly TBC video data  132  will always be read from frame synchronizer and buffer  116  with in a manner corresponding to audio data  136  being read from FIFO buffer  120 . 
         [0049]    An example method  400  for the operation of system  300  in accordance with an aspect of the present invention will now be described with reference to  FIG. 4 . 
         [0050]    In operation, process  400  starts (S 202 ) and source video clock synthesizer  102  receives source video clock signal  126  and produces source audio clock signal  130  (S 204 ). 
         [0051]    Source video data  128  for encoding is additionally supplied to the video and audio buffers (S 206 ). Audio de-embedder  118  receives source video data  128 , which includes video data portions and audio data portions, and extracts the audio data portions as audio data  134 . Audio de-embedder  118  then provides audio data  134  to FIFO buffer  120 . Source video data  128  is concurrently provided to frame synchronizer and buffer  116 . 
         [0052]    At this point, source video data  128  is then written to the video and audio buffers (S 208 ). Source video clock signal  126  enables source video data  128  to be written into frame synchronizer and buffer  116  and additionally enables audio data  134  to be written into FIFO buffer  120 . 
         [0053]    TBC video data  132  and audio data  136  are then supplied to encoder  114  (S 402 ). TBC video data  132  is read from frame synchronizer and buffer  116  using TBC video clock signal  140 . TBC video data  132  is then provided to encoder  314 . Audio data  136  is read from FIFO buffer  120  using TBC audio clock signal  142 . Audio data  136  is then provided to encoder  314 . 
         [0054]    At this point, TBC video clock signal  140  writes TBC video data  132  into encoder  314  while TBC audio clock signal  142  writes audio data  136  into encoder  314  (S 404 ). 
         [0055]    Encoder  314  then encodes TBC video data  132  and audio data  136  (S 214 ) in accordance with a predetermined coding scheme and process  200  stops (S 216 ). 
         [0056]    Method  400  differs from method  200  discussed above in that, process  400  does not derive a source audio clock signal from the source video clock signal (see step S 204 ) and does not buffer audio data and then transfer the audio data to the domain of the TBC audio clock signal (see step S 214 ). This is because in step S 402 , audio data  134  is transferred from the domain of source video clock signal  126  to that of TBC audio clock signal  142 , avoiding the generation of a source audio clock signal and also the need for encoder  314  to buffer audio data  136  to complete its clock domain transfer. 
         [0057]    In an example embodiment, TBC reference clock signal  138  output from TBC clock synthesizer  122  is a 27 MHz signal. As shown in system  300  of  FIG. 3 , TBC reference clock signal  138  is supplied to two devices; TBC video clock synthesizer  110  and TBC audio clock synthesizer  112 . TBC video clock synthesizer  110  is used to generate the required video frequency (TBC video clock signal  140 ), which may include frequencies such as 27 MHz, 74.25 MHz, or 74.25*1000/1001 MHz, depending on the video format. TBC audio clock synthesizer  112  is used to generate the required audio frequency (TBC audio clock signal  142 ), which may be a multiple of 32 kHz, 44.1 kHz, or 48 kHz, depending on the audio sampling rate. It should be noted that the generation of an audio frequency from a 27 MHz clock signal (TBC reference clock signal  138 ) can be easily achieved with readily available and inexpensive parts. In contrast, the generation of an audio frequency using an HD video clock signal (as done in conventional system  100 , in S 204  of process  200 ) requires costly and hard-to-obtain devices. Source audio clock synthesizer  102  is typically a very expensive and difficult-to-find clock synthesis device. 
         [0058]    As mentioned previously, frame synchronizer and buffer  116  is used to transfer source video data  128  from the domain of source video clock signal  126  to the domain of TBC video clock signal  140  (S 410  of process  400 ). A “depth” of a frame buffer is considered the register size of the frame buffer, wherein each register is operable to store image data corresponding to a single frame. For example, a frame buffer having a depth of one (1) may store image data corresponding to a single frame, whereas a frame buffer having a depth of five (5) may store image data corresponding to five frames. In an example embodiment, the minimum depth of the video frame buffer in frame synchronizer and buffer  116  is 2 video frames, and during operation, the level may vary by anywhere between 1 and 2 frames. As long as source video clock signal  126  and TBC video clock signal  140  are locked, this depth remains constant. If lock between TBC video clock  140  and TBC audio clock  142  is lost momentarily or periodically, this causes the video frame buffer to either drain or accumulate. But since FPGA  104  controls NCO  108 , which is involved in the generation of TBC video clock signal  140 , FPGA  104  can “speed up” or “slow down” TBC reference clock signal  138  (and thereby “speed up” or “slow down” TBC video clock signal  140 ) in order to counter the effect of the drift of the source video clock signal  126 . Thus, every time the depth of the video frame buffer deviates beyond some threshold from its initial depth, TBC video clock signal  140  can be adjusted until the depth returns to the initial value. 
         [0059]    Note that in the example embodiment discussed above with reference to  FIG. 3 , only a single audio channel design is presented and discussed. The single channel design however, can be replicated to support additional audio channels. Also, note that in  FIG. 3 , embedded audio data is extracted from source video data  128  and written to FIFO buffer  120  in the domain of source video clock signal  126 . For the case of external audio data, the audio data is written to FIFO buffer  120  in the domain of source audio clock signal  130 . In both cases of embedded and external audio data, the audio data is read from FIFO buffer  120  in the domain of TBC audio clock signal  142 . In this manner, audio data is transferred from either the domain of source video clock signal  126  (in the case of embedded audio) or the domain of source audio clock signal  130  (external audio) to the domain of TBC audio clock signal  142 . 
         [0060]    For this clock domain transfer of audio data, as long as the “write” clock signal (source video clock signal  126 , in the case of embedded audio) and the “read” clock signal (TBC audio clock signal  142 ) of FIFO buffer  120  are locked, there will be no problems. However, if TBC clock synthesizer  122  is unable to lock or loses lock momentarily or periodically, FIFO buffer  120  may underflow or overflow. 
         [0061]    Increasing the depth of FIFO buffer  120  can help make the overflows/underflows less frequent, but will not eliminate them. Further, as mentioned earlier, increasing the depth of FIFO buffer  120  may introduce AV synchronization delays. Thus, in accordance with an aspect of the present invention, in system  300  this problem is solved by reproducing the behavior of frame synchronization and buffer  116  in FIFO buffer  120  when the source video clock signal  126  and TBC video clock signal  140  are not locked. This can be accomplished by creating FIFO buffer  120  deep enough to hold at least one video frame worth of audio data and then initializing FIFO buffer  120  to the same depth as the video frame buffer in frame synchronization and buffer  116 . In this manner, since FIFO buffer  120  is being read with an audio clock signal that is derived from TBC reference clock signal  138 , any manipulation of TBC reference clock signal  138  to maintain the level of the video frame buffer (as discussed previously) will be reflected in FIFO buffer  120  as well, and therefore FIFO buffer  120  will track the video frame buffer&#39;s depth at all times. Thus, as long as video frame buffer level does not empty or fill up, FIFO buffer  120  will not overflow or underflow. An example implementation of this aspect of the present invention will now be discussed in further detail with reference to  FIG. 5 . 
         [0062]      FIG. 5  illustrates an example set of calculation and conversion tables  500  used in system  300 , in accordance with an aspect of the present invention. Table set  500  includes table  502  and table  504 . Table  502  includes columns  506 ,  508 ,  510  and  512 , whereas table  504  includes columns  514  and  516 . Table  502  illustrates calculations of audio samples per video lines for a variety of video formats. Table  504  illustrates a lookup table that may be maintained in FPGA  302 , which provides the formula for the number of audio samples, given the number of audio lines for a variety of video formats. 
         [0063]    The usage of tables  502  and  504  will be illustrated in the following example. For purposes of discussion, presume the format of source video data  128  is 1080i at 29.97 frames per second (fps), which corresponds to column  508  in table  502 . FPGA  302  detects source video data  128  is good and begins writing video data to frame synchronizer and buffer  116 . After one complete video frame has been written, the frame synchronizing portion of frame synchronizer and buffer  116  starts waiting for a start-of-frame signal from the frame template generator to start reading from the video frame buffer portion. Suppose that this occurs 300 video lines after the first frame was written. Thus, FIFO buffer  120  must be initialized with an equivalent amount of audio data. For audio data at 48 kHz, there are 48,000 audio samples per second. Further, 1080i at 29.97 fps with 1125 lines per frame has approximately 1125*29.97=33,716 lines per second (or 2.96593E-05 seconds per line). As shown in column  508 , this translates to 48,000/33,716=1.4236 audio samples per video line, or approximately 1.43 samples per line. 
         [0064]    Table  504  is then used within FPGA  302  to obtain the conversion factor, or the number of audio samples per video line. In the above example, the video format is 1080i, so column  514  is used. The conversion formula in this case for the number of audio samples required would be 1.44n (where n is the number of video lines required), which may be implemented as n+n/2−n/16 inside FPGA  302 . FPGA  302  may start writing data to FIFO buffer  120  and when the depth required by the above formula is achieved (300 lines×1.44 samples/per line=432 samples), it will start reading from FIFO buffer  120 . In this manner, the depth of FIFO buffer  120  will initially be equivalent to that of the video frame buffer inside frame synchronizer and buffer  116  and FIFO buffer  120  will track the frame buffer&#39;s behavior from that point on. 
         [0065]    In summary, in accordance with an aspect of the present invention, a FIFO buffer is implemented inside an FPGA that tracks the behavior of the video frame buffer, thereby allowing a glitch-free transfer of audio data from the domain of the source clock signal to a domain of the TBC clock signal, thus eliminating the need for costly clock synthesis devices that would otherwise be required for such a transfer. Furthermore, exact AV synchronization is guaranteed within the FPGA, without the need for a more complicated design involving multiple devices, such as the encoder. This approach can be implemented for all types of audio data, whether pre-compressed or uncompressed and embedded in video data or from an external source. 
         [0066]    The foregoing description of various preferred embodiments of the invention have been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise forms disclosed, and obviously many modifications and variations are possible in light of the above teaching. The exemplary embodiments, as described above, were chosen and described in order to best explain the principles of the invention and its practical application to thereby enable others skilled in the art to best utilize the invention in various embodiments and with various modifications as are suited to the particular use contemplated. It is intended that the scope of the invention be defined by the claims appended hereto.