In-band synchronization of data streams with audio/video streams

[0002] The present invention pertains to a method and apparatus for synchronizing data streams with audio/video streams, and more particularly, to a method and apparatus for synchronizing a presentation of audio and/or video with the execution of data control information.

[0003] Referring to FIG. 1, a known system for rendering audio and video streams is shown. A central processing unit (CPU) 1 executes application code typically stored in a memory 9. CPU 1 is coupled to a host bus 3 which is coupled to memory 9 via a first bridge circuit 5 (also referred to as a host bridge circuit or a north bridge circuit). The first bridge circuit is, in turn, coupled to a first bus 7, such as a bus operating according to the Peripheral Component Interconnect specification (PCI Special Interest Group, P.O. Box 14070, Portland, Oreg. 97214). A second bus 11, such as an expansion bus, is coupled to the PCI bus 7 via a second bridge circuit 10 (also referred to as a south bridge circuit). A modulator/demodulator (modem) 13 is coupled to the expansion bus 11 and is adapted to receive data from a transmission medium 110 (e.g., so-called plain old telephone service (POTS) lines or the Internet system). In FIG. 1, a client 100 is adapted to receive data from a server 120 via transmission medium 110. In current applications, this data can be audio and/or video (A/V) data that is transferred using the so-called Real-time Transfer Protocol (RTP). Under the RTP protocol, data such as A/V data is transferred from transmission medium 110 to the client as packets and are processed by an A/V subsystem 15 coupled to the PCI bus 7.

[0004] An example of such an A/V subsystem 15 is shown in FIG. 2. Referring to FIG. 2, the incoming RTP data packets are received at a packet preparation module/payload handler 18. The RTP protocol is defined by the Internet Engineering Task Force (IETF) and provides an end-to-end network transport function suitable for applications transmitting real-time data over multicast or unicast network services. Payload handler 18 analyzes each incoming RTP data packet by reading RTP header information and “stripping” this data off of the packets. An exemplary RTP data packet 50 is shown in FIG. 3. Each RTP header includes a variety of information, such as a Payload Type field that identifies the type of information contained in the RTP packet (e.g., a specific type of video or audio data). A Marker Bit (M) can be provided to identify whether the RTP packet 50 contains the end of a current frame of video data. The RTP header 51 also includes a Timestamp field that is used to synchronize audio and video data appearing as a data payload 52 in the RTP data packet 50.

[0005] The payload handler 18 determines whether the data payload 52 contains audio or video data and forwards it to the appropriate data packet handler (e.g., video data packet handler 20 and audio data packet handler 22). Video data packet handler 20 and audio data packet handler 22 can be coupled to the payload handler 18 directly or can be coupled indirectly (e.g., through bus 7). Therefore, video data packet handler 20 receives a stream of video data packets and audio data packet handler 22 receives a stream of audio data packets. Payload handler 18 controls synchronization of the audio and video data packet streams via the timestamp field appearing in RTP header 51. Accordingly, audio data that is synchronized to a specific frame of video data are sent approximately at the same time to the respective data packet handlers 20, 22.

[0006] Video data packet handler 20 analyzes video packets that can have a format according to any of a variety of compression algorithms. Typical compression algorithms include any of a variety of block transform based video compression algorithms such as H.261 (International Telecommunication Union—Telecommunications Standardization Sector (ITU-T), March, 1993), H.263 (ITU-T, Dec. 5, 1995), JPEG (“Joint Photographic Expert Group”)(International Organization for Standardization/International Electrotechnical Commission (“ISO/IEC”) 10918-1), MPEG-I and MPEG-II (“Motion Picture Expert Group”)(ISO/IEC 11172-2 and 13818-2). The video data packet handler 20 includes a coder/decoder (codec) where the decoder portion of the codec is responsible for converting the compressed video data from the video packet into raw, uncompressed video data for video rendering device 23, which transfers this data to an output device such as display 24. The audio data packet handler 22 works in a similar manner in that received data packets are converted into digital audio data and passed to an audio rendering device 25 that converts the digital data to analog data for output at a speaker 26.

[0007] The A/V subsystem 15 can also be used as an input device (e.g., in a video phone application). A camera 28 is provided coupled to a video capture component 29 which supplies frames of uncompressed data to video data packet handler 20 at a rate of approximately 30 frames per second. As stated above, the video data packet handler 20 includes a codec and the coder portion of the codec is used to compress the video frame data according to a video compression algorithm. The video data packets generated by the video packet handler 20 are passed to the packet preparation module/payload handler 18 which creates RTP packets for transport to the end-user (e.g. over transmission medium 110 in FIG. 1). Accordingly, a microphone 27 can be provided which supplies input analog audio data to audio rendering device 25. Audio rendering device 25 converts the analog audio signals into digital signals for the audio data packet handler that creates audio data packets for payload handler 18. Payload handler 18 uses the audio data packets to create RTP packets for transport to the end-user.

[0008] The A/V subsystem 15 controls the synchronization of the presentation of audio and video data. However data control information other than traditional audio and video data is sent outside of the RTP protocol (if it is sent at all) and is not synchronized with the A/V data streams. It would be desirable to synchronize the presentation of data objects pursuant to data control information for a more complete and accurate presentation of information to an end-user.

[0009] According to an embodiment of the present invention, a payload handler is provided adapted to receive a plurality of data packets, each of the data packets including a data payload including either video data or data control information, a first header including a timestamp field, and a data control header identifying a type of data contained in the data payload. A data control filter coupled to the payload handler can receive the data control header and data payload for each of the data packets. The data control filter passes data payloads including data control information to a data handler and data payloads including video data to a video data packet handler. The data control information includes a command in an action identifier field which is executed by the data handler. The payload handler synchronizes a transfer of the video data and data control information to the data control filter based on information in the timestamp field of the data packet header.

[0010] FIG. 1 is a block diagram of a computer system including an audio/video subsystem as is known in the art.

[0011] FIG. 2 is a block diagram of a audio/video subsystem as is known in the art.

[0012] FIG. 3 shows a sample RTP packet as is known in the art.

[0013] FIG. 4 is a block diagram of an audio/video subsystem constructed according to an embodiment of the present invention.

[0014] FIG. 5 shows an RTP packet having a format according to an embodiment of the present invention.

[0015] FIG. 6 shows a format for data control information according to an embodiment of the present invention.

[0016] FIG. 7 is a block diagram of a second audio/video subsystem constructed according to an embodiment of the present invention.

[0017] Referring to FIG. 4, a general block diagram of an A/V subsystem 15′ constructed according to an embodiment of the present invention is shown. The A/V subsystem 15′ can be coupled to the PCI bus 7 (shown in FIG. 1) and includes a packet preparation module/payload handler 70 that receives data packets (e.g., RTP data packets) and analyzes the header information. Referring to FIG. 5, an example of an RTP data packet 60 having a construction according to an embodiment of the present invention is shown. The RTP data packet 60 includes an RTP header 61 having a format similar to the RTP header 51 of FIG. 3. Payload handler 70 analyzes the RTP information (e.g., the RTP header 61), and strips this data off of the data packet. If the payload type field of the RTP header 61 indicates that the data packet contains video data, then that data packet is sent to a data control filter 72, and if the payload type field indicates audio data, then that data packet is sent to an audio data packet handler 73. If the data packet is an audio data packet, it is handled in the same manner as described with respect to FIG. 2. The header information of the audio data packet is analyzed and stripped off and the remaining digital audio data is transferred to an audio rendering device 74 which may include a coder/decoder or the like to convert the digital signal into an audio signal for a speaker 75.

[0018] Data control filter 72 analyzes a data control field 62 (FIG. 5) in the portion of the RTP data packet 60 that it receives to determine whether the data payload 63 contains data control information or video data. Data control field 62 can be as small as one bit (e.g., 1 indicating data control information and 0 indicating video data), but may be larger in order to have the beginning of the subsequent data payload 63 fall on a specific boundary (e.g., a byte or word boundary). If data payload 63 includes video data, it is sent to a video data packet handler 77 where the packet header is analyzed, such as an H.263 packet header, and used to convert the compressed video data (i.e., by using a codec) into a form that can be handled by the video rendering device 78. The uncompressed video data can then be displayed at display 79.

[0019] If the data payload includes data control information (as indicated by the data control field 62), it is sent to a data handler 80 where the data control information is converted into the user requested information. In this embodiment, the data control information can be a semantic or data packet that signals a data event that is to take place. For example, a video slide prepared by the PowerPoint® application (Microsoft Corporation, Redmond, Wash.) could be identified by the data control information. In response to this data control information, data handler 80 retrieves the requested file from a data source such as memory 9 (FIG. 1) and presents it to a data rendering device 82 which converts the file into displayable format for display 79. The data control information describes a data event that is to take place. In addition to identifying a file to be displayed (e.g., a video slide), the data control information can be a command as well. An exemplary format for data control information 90 is shown in FIG. 6. An action identifier field 92 (or command field) can be provided to store a command such as “display” (e.g., display a file), “move” (e.g., move a graphical object), “query” (e.g., query the status of a procedure), etc. Such a command would be executed by data handler 80. A data object field 91 can be provided to identify the data that is to be acted upon including, for example, the location of the file (e.g., buffer location in memory 9 or file name). Furthermore, a variable data field 93 can be provided to supply variable data for a given command (e.g., “move” a graphical object “10” pixel locations to the right). A further description of data control information data packets can be found in the U.S. Patent Application entitled “Remote Streaming of Semantics for Varied Multimedia Output” by Jeffrey L. Huckins and filed on Dec. 18, 1996, (now U.S. Pat. No. 5,890,162) the disclosure of which is hereby incorporated by reference in its entirety.

[0020] As described above, the data control information is included in RTP packets with the audio and video data packets. Therefore, the data control information is also synchronized with the audio and video data in that they are transferred to the audio/video subsystem 15′ in RTP packets synchronized with the audio and video data packets. Since each RTP header 61 (FIG. 5) includes a timestamp field, the payload handler 70 (FIG. 4) is able to forward the data control information packet to the data control filter 72 at the appropriate time relative to the video and audio data packets. This results in an improved presentation of data to an end-user allowing for more data (e.g., the display of identified files) to be presented to the end-user in synchronization with other audio and video data.

[0021] Referring to FIG. 7, a second embodiment of the audio/video subsystem 15″ of the present invention is shown. The audio/video subsystem 15″ of FIG. 7 is similar in operation to the audio/video subsystem 15′ of FIG. 4 except that data control information is placed in the audio data stream instead of the video data stream. The RTP data packets are received at a packet preparation module/payload handler 138 and video data packets are passed to a video data packet handler 139 which decompresses the video packet so that it can be presented at display 141 via video rendering device 140. Audio packets and data control information are transferred to data control filter 142 which analyzes the data control field 62 of the packet (FIG. 5). If the data payload 63 is an audio packet it is passed to audio data packet handler 143 where the packet header information is stripped off from the digital data. The data is then converted to analog form by audio rendering device 144 and output to speaker 145. If the data packet includes data control information, it is transferred to data handler 146 and processed as described above. For example, if the data control information has an action identifier field 92 (FIG. 6) indicating that a file is to be displayed and the data object field 91 identifies a file location in memory 9, the identified file is retrieved from memory 9 and passed to data rendering device 147 which converts the file into a format for presentation at display 141.

[0022] The audio/video subsystems 15′, 15″ of FIGS. 4 and 7 allow for the input of data for transfer to an end-user via transmission medium 110 (FIG. 1). For example, a microphone 76 (FIG. 4), 150 (FIG. 7) can be provided for the input of audio data and a camera 83 (FIG. 4), 148 (FIG. 7) and video capture component 84 (FIG. 3), 149 (FIG. 4) can be provided for the input of video frame data. Data control information can also be provided as an input via an input/output (I/O) device 14 (FIG. 1) coupled to the data handler 80 (FIG. 4), 146 (FIG. 7).

[0023] Though the elements of FIGS. 4 and 7 are shown as being coupled together as a group, one skilled in the art will appreciate that many of the described components can be coupled together via a bus, such as PCI bus 7. Although several embodiments are specifically illustrated and described herein, it will be appreciated that modifications and variations of the present invention are covered by the above teachings and within the purview of the appended claims without departing from the spirit and intended scope of the invention.