Digital video network interface

[0002] This application is being filed with a software code appendix which contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the software code or the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all copyright rights whatsoever.

[0003] A compact disc, and an identical duplicate thereof, containing a computer program listing appendix of the Software Appendix has been submitted, both of which are herein incorporated by reference. Each compact disc contains a single ASCII text file named “09_—166,487 Appendix.Txt”, which was created on Jan. 22, 2002 and is 44 kilobytes in size.

[0004] 1. Field of the Invention

[0005] The present invention relates to a system for transmitting real time digital video data (including both audio and video) over a local area network. More specifically, the present invention relates to a system for transmitting digital video data from an isochronous source such as a digital video camera using IEEE 1394 isochronous protocol, through an asynchronous local area network, to an isochronous destination such as another digital video camera or a monitor via IEEE 1394 isochronous protocol, all while maintaining isochrony of transmission and delivery.

[0006] 2. Description of Related Art

[0007] Local Area Networks (LANs) have traditionally been used for accessing files or sending print data to a networked printer. Data delivery on a network such as Ethernet is asynchronous, meaning that there is no synchronization between transmission time and delivery time. Rather, for the typical application, the most critical feature of the network is its guarantee that data will be delivered successfully.

[0008] Digital video data, on the other hand, is unique in that the timeliness with which data is delivered is more important than the guarantee of data delivery. Specifically, because of the fleeting nature of digital video data, if it is not delivered in time, then its guaranteed delivery at a later time is meaningless since the data will be stale and simply not used.

[0009] One popular protocol for carrying digital video data is the IEEE 1394 isochronous protocol, where the timely delivery of digital video data is more critical than the guarantee of its delivery. Digital video data is carried on an IEEE 1394 serial bus (popularly referred to by the trademark “Fire Wire”) as isochronous data. The term isochronous means equal-time, and in the context of IEEE 1394 protocol means that new data is available at cyclical intervals (such as every 125 microseconds) although the timing of data within any one interval is uncertain. The isochronous nature of this data is such that data of this type has no value if it is received after its specific time window of use. In fact, the timely delivery of this data is so critical that in the case of a transmission error no retries are attempted. It was recognized by the designers of the IEEE 1394 bus protocol that by the time any retry attempts could be made, the time window for the usage of isochronous data would be passed.

[0010] Digital video (“DV”) data is transmitted under IEEE 1394 as isochronous data packets that may contain both audio and video components. Although there is no guarantee that a packet can be sent exactly at a periodic rate, IEEE 1394 guarantees that data is available sometime within each periodic interval (equal to 125 micro-seconds). Another feature of the IEEE 1394 interface is that applications can reserve bandwidth (or “channels”) in the IEEE 1394 bandwidth and therefore delivery of a digital video packet can be guaranteed.

[0011] The IEEE 1394 industry standard interface provides superior bandwidth for high speed transmission of data. Because of its unique features, the IEEE 1394 high speed serial bus is used for transmitting full-motion digital video from a digital video camera, to a digital video recorder, to a personal computer, or to any peripheral device which may store or display the video. Currently, however, the IEEE 1394 standard interface has at least one shortcoming: the maximum cable length is limited to 4.5 meters. Therefore, digital video data cannot be transferred and viewed in real time at a remote location greater than 4.5 meters from the source of the video data.

[0012] Although the cable length limitation is being addressed by a new version of the IEEE 1394 standard, this newer version would involve costly and non-standard usages, such as a fiber optic cable with different IEEE 1394 components.

[0013] On the other hand, asynchronous networks such as Ethernet are in widespread use, and provide geographically remote access to large volumes of data. Particularly, with-the recent introduction of 100 BaseT and Gigabit Ethernet, fast access to large volumes of data is also provided. It is therefore expected that the Ethernet interface will continue to offer a lower cost, higher speed and longer distance connection than an equivalent IEEE 1394 connection. It is for this reason there is a benefit to find a way to provide the transport of isochronous digital video data across an asynchronous transport that does not inherently provide isochrony.

[0014] It is therefore an object of the present invention to transmit digital video data (video and audio) over a high speed local area network. More specifically, the present invention relates to sending isochronous data over an asynchronous network transport that does not specifically support isochrony.

[0015] It is another object of the present invention to provide a system for transmitting digital video data, which is output isochronously, between peripheral devices in real time by integrating a local area network between the transmitting digital video camera and the receiving digital video camera. It is also an object of the present invention to provide a method and an apparatus for maintaining real time transfer of the isochronous video data without degradation of the video signal.

[0016] Thus, according to one aspect, the present invention is a digital video network interface for transferring isochronous video data over an asynchronous local area network. The digital video network interface includes, on a transmitting side, an isochronous interface for receiving digital video data isochronously, a buffer comprising first and second memory areas for storing the isochronous video data, and a network interface for transmitting video data from either the first or second memory areas over the asynchronous local area network. On a reception side, the digital video network interface also includes a reception memory buffer manager for controlling receipt of the video data from the asynchronous network and the storage of the data into memory, which is not ordinarily partitioned into first and second memory areas. An input pointer is used to track where newly received asynchronous data is stored to memory, and an empty pointer is used to track where data is extracted from memory for conversion to isochronous data. The memory buffer manager shifts the input of data into the memory pointed to by the input pointer and begins outputting video data from the memory pointed to by the empty pointer to an isochronous packet handler that converts the asynchronous data to isochronous. The isochronous data may thereafter be utilized in accordance with IEEE 1394 protocol, such as by viewing on a digital video camera.

[0017] By virtue of the foregoing arrangement, even though the network is an asynchronous data carrier, isochronous data can be transmitted over a network that does not support isochrony, since it is the sending and receiving stations that are responsible for maintaining isochrony. In particular, buffering at the transmitting end accommodates delays that might occur while waiting to access to the asynchronous network, while buffering at the receiving end accommodates delays in new asynchronous packets, by buffering data packets that had previously arrived too quickly for the isochronous packet handler to accommodate. As a result, although latency is introduced in the digital video data (corresponding to the length of the buffers but preferably below around 0.3 seconds), isochronous transmission and reception is preserved, even over an asynchronous network that does not support isochrony. Moreover, as the data-carrying capacity of the network increases, the latency can be reduced since the amount of buffering needed to ensure data availability can be reduced. For example, in a Gigabit Ethernet whose bandwidth is 125 MBytes/second, as compared to digital video data of 3.7 MBytes/second, the delivery of 1000 data packets in 125 milliseconds is virtually certain, and can be achieved with a latency of only 0.125 seconds.

[0018] In another aspect of the invention, the present invention is a method for transferring data between an isochronous data source and an asynchronous local area network. Data packets are received isochronously from an isochronous data. source, the data packets from the isochronous data source are stored in a buffer having first and second memory areas, and the asynchronous local area network is accessed. To transfer the data packets over the asynchronous local area network, the data packets are stored in either the first or second memory areas of the buffer such that when one memory area is filled, the other memory area receives data, and data packets from the filled memory area are transferred. Upon the filling of a memory area, network access is requested and, upon receiving access, the data packets from the filled memory location are output over the asynchronous local area network.

[0019] In yet another aspect of the invention, the present invention is a digital video network system which includes an asynchronous local area network for transferring data, a digital video camera for generating digital video data isochronously, and a remote digital video device for receiving digital video data isochronously. A transmitting-side digital video network interface transfers data between the digital video camera and the asynchronous network, with the transmitting-side digital video network interface having an isochronous interface for receiving data packets from the digital video camera isochronously, a transmit buffer having first and second memory locations for storing data packets, a network interface for transferring the data packets from either the first or second memory locations of the buffer through the asynchronous local area network, and a transmit memory buffer manager for 1) controlling the transfer of data packets from the isochronous interface to either of the first or second memory locations in the buffer, and 2) controlling the transfer of data packets from either the first or second memory locations of the buffer through the network interface by requesting access to the asynchronous local area network. According to this aspect of the invention, the transmit memory buffer manager controls the storage of the data packets into either the first or second memory location of the buffer, and, when one memory location has been filled, the transmit memory buffer manager requests access to the network. Upon receiving access, data packets from the filled memory location are transmitted.

[0020] On the receiving side, the digital video network system includes a receiving-side digital video network interface for transferring data between the asynchronous local area network and the peripheral digital video device. The receiving-side digital video network interface includes a network interface for receiving video data packets from the asynchronous local area network, a receipt buffer for storing asynchronous data, a receiving isochronous interface for transmitting video data packets to the peripheral digital video device, and a receipt memory buffer manager for 1) controlling the transfer of data packets from the network interface to the receipt buffer at a location pointed to by an input pointer, and 2) controlling the transfer of video data packets from the buffer at a location pointed to by an empty pointer to the receiving isochronous interface. The receipt memory buffer manager controls the output of video data in an isochronous fashion from the buffer through to the receiving isochronous interface.

[0021] In another aspect of the invention, for use in a digital video conferencing system, the full-duplex capability of the asynchronous network is used to simultaneously transmit isochronous digital video data between 1394 network controllers in each direction. A second digital video camera, recording device, or display monitor is added to the 1394 interface bus of each controller such that the isochronous bandwidth of the bus is shared by a transmitting device and a receiving device on that bus. Each 1394 network controller establishes both an isochronous transmit communications process and a isochronous receiving communications process with the other 1394 network controller through the asynchronous network that connects them.

[0022] In yet another aspect of the invention, for use in a digital video conferencing system, digital video data is transmitted bi-directionally from one isochronous bus to another isochronous bus via an asynchronous network. An isochronous communication and an asynchronous network connection are established at the receiving side, and an isochronous communication and an asynchronous network connection are established at the sending side. The sending side and receiving side negotiate to open an asynchronous transmission. Isochronous digital video data is converted into asynchronous network data at the sending side, the asynchronous network data packets are transmitted to the receiving side, the asynchronous network data is received at the receiving side, and the asynchronous network data is converted to isochronous digital video data at the receiving side. Likewise, isochronous digital video data is converted into asynchronous network data at the receiving side, the asynchronous network data packets are transmitted to the sending side, the asynchronous network data is received at the sending side, and the asynchronous network data is converted to isochronous digital video data at the sending side.

[0023] These and other features and advantages according to the present invention will be more readily understood by reference to the following detailed description of the preferred embodiment taken in conjunction with the attached drawings.

[0024] FIG. 1 is a topological view of representative local and wide area networks to which the present invention may be applied;

[0025] FIG. 2 is a block diagram of a digital video interface network according to the present invention;

[0026] FIG. 3A is a block diagram of a network interface used in the digital video network interface according to the present invention;

[0027] FIG. 3B is an illustration of the IEEE 1394 isochronous data packet format;

[0028] FIGS. 4A-4D are flowcharts depicting the transfer and receipt of isochronous data over asynchronous network; and

[0029] FIG. 5 is a flow diagram illustrating a second embodiment of the invention.

[0030] FIG. 1 is a topological view of a representative local area network (LAN) or wide area network (WAN) to which the present invention may be applied. Shown in FIG. 1 are three separate LANS, 100, 110 and 120, connected to each other through modem 130 and backbone 140 into an overall WAN 5. Each of LANs 100, 110 and 120 may be configured physically into any of the known network configurations, such as Ethernet or high speed Token Ring, and each LAN may carry network transmissions using one or more network protocols over one or more frame types. At least some of LANs 100, 110 and 120 transmit data asynchronously in the sense that they do not support isochrony. Presently preferred embodiments of the invention, however, utilize a Gigabit Ethernet network, using UDP protocol.

[0031] Connected to each of the LANs 100, 110 and 120 are plural work stations and plural networked devices, some of which provide for isochronous digital video data pursuant to the invention. For example, connected to LAN 100 are work stations 101 and 108, together with network devices including printers 102 and scanner 109. Also connected to LAN 100 is file server 106 which manages access to files stored on large capacity network disk 107. Other unshown network devices and work stations may also be connected to LAN 100.

[0032] Particular attention is directed to 1394 Network Controller 103, which interfaces to LAN 100, and to which is connected a digital camera 104 through an isochronous IEEE 1394 interface designated as 104a. According to the invention, 1394 Network Controller 103 is operable in either a sending mode or a receiving mode, or both modes simultaneously in the case of digital video conferencing. In a sending mode, 1394 Network Controller 103 converts isochronously-received digital video data from digital camera 104 into asynchronous network transmissions for transmission out onto LAN 100. In the receiving mode, 1394 Network Controller 103 operates to convert asynchronously-received digital video data from LAN 100 into corresponding isochronous data, for viewing by camera 104. In a digital video conference mode, 1394 Network Controller 103 operates in both modes simultaneously, so as to send and receive asynchronous data from LAN 100 and to send and receive isochronous data from IEEE 1394 bus 104a. In the video conferencing mode, more than one digital video camera 104 might be required (or a camera and a monitor might be required) so that one digital video camera receipt can input digital video images while the other device is outputting digital video images received from a remote station. FIG. 1 further shows digital video camera 105 connected to work station 108 through a IEEE 1394 bus 105a.

[0033] The depiction of camera 105 is meant to emphasize that the invention can be implemented in a stand-alone device, such as 1394 Network Controller 103, or can be implemented with software and hardware modifications to a work station such as 108 that supports IEEE 1394 bus protocol.

[0034] Directing attention to other LANs depicted in FIG. 1, LAN 110 has connected to it work stations 111 and 112, as well as networked devices such as printer 115, and file server 113 which manages access to large capacity network disk 114. Also connected to LAN 110 is 1394 Network Controller 118 having digital camera 119 that provides isochronous digital video data according to a IEEE 1394 protocol on 1394 bus 119a. 1394 Network Controller 118 is similar in construction to 1394 Network Controller 103, as described in more detail hereinbelow. In addition, and complementary to the construction shown in connection with LAN 100, work station 112 may include a digital video camera 116 interfaced via a IEEE 1394 bus 116a.

[0035] LAN 120 includes work stations 121 and 122, as well as various unshown network devices which may includes 1394 Network Controllers similar in construction to 1394 Network Controller 103 and 118.

[0036] FIG. 2 is a functional block diagram depicting the interaction between two devices on the network, such as 1394 Network Controller 103 and 1394 Network Controller 118, or any other two devices on the network for which isochronous-to-asynchronous-to-isochronous data transmission is being provided according to the invention. Thus, in FIG. 2, the two devices are depicted generally, by a local network interface component 4 and a remote network interface component 6. The block diagram of FIG. 2 shows a digital video network interface in which isochronous digital video data formatted in IEEE 1394 standard is transmitted across an asynchronous local area network, such as a Gigabit Ethernet network, to a remote side which receives and decodes the asynchronous network digital video data and converts the digital video data from asynchronous data back to isochronous digital video data.

[0037] Specifically, FIG. 2 represents a system in which isochronous digital video data originating inma transmitting digital video (DV) camera is sent by a transmitting network interface across an asynchronous local area network, such as a Gigabit Ethernet network, to a receiving network interface which decodes and outputs the digital video data in isochronous mode to a receiving DV camera.

[0038] The transmitting network interface component 4 and receiving network interface component 6 of FIG. 2 are preferably implemented using high performance 233 MHz RISC processors and an embedded operating system which supports real time multitasking, such as VxWorks™ or pSOS™. (Of course, with improvements in operating systems and processor speed, non-real time systems may be used.) By using such real-time multitasking operating systems, the peripheral components which connect to the IEEE 1394 interface and the network interface can be controlled directly, in a real-time and multitasking environment, to maximize video data throughput. A simple datagram protocol such as UDP or IPX is used for video data packet transmission on the asynchronous network. Although datagram protocols do not provide guaranteed packet delivery, the overhead normally associated with packet acknowledgement and sequence control (such as that in TCP/IP) is completely eliminated, making additional throughput available to restore isochronous video data flow at the receiving end.

[0039] Shown in FIG. 2 is a digital video (DV) camera 1 which is set up to transmit digital video data over its IEEE 1394 interface connection. The video data can be either the image currently viewed by the camera lens or previously recorded data now being played back through the camera from a digital recording tape unit. DV camera 1 is connected to the transmitting 1394 network interface 4 via an IEEE 1394 serial cable 2. The IEEE serial cable 2 carries packets of digital video data which are being sent isochronously, one packet in every 125 microsecond isochronous interval, by DV camera 1. Each data packet contains 488 bytes of compressed video data and at the rate of one packet in each isochronous interval or 8000 packets per second, the resulting video data flow rate can be calculated to be 3.9 megabytes per second.

[0040] Transmitting-side 1394 network interface 4, described in detail below, is a system for receiving digital video packets from the 1394 serial cable 2, removing the 1394 data packet headers, repackaging two or more (preferably three) data packets into network protocol format and transmitting the data over the asynchronous network 5. In the preferred embodiment, asynchronous network 5 is preferably a Gigabit Ethernet network which may utilize fiber optics or copper wire as a communication medium and which has sufficient bandwidth (here, 125 megabytes per second is sufficient although 100BaseT also provides sufficient bandwidth) to accommodate the video data flow from transmitting 1394 network interface 4 as well as other data packets originating from other work stations and/or devices attached to the asynchronous network.

[0041] Receiving-side 1394 network interface 6, like transmitting 1394 network interface 4, is connected to the asynchronous local area network 5 and provides a connection to the IEEE 1394 serial cable 7. Receiving 1394 network interface 6 receives and unpackages network data packets arriving from asynchronous network 5, reformats the video data into IEEE 1394 format and transfers the video data packets via the IEEE 1394 serial cable 7 to the isochronous receiving unit, DV camera 8. Cable 7, like cable 2, has a data transfer rate of 3.7 Mbytes/sec.

[0042] After receiving and unpackaging network data packets from local area network 5, network interface 6 outputs data isochronously through cable 7 to DV camera 8, which is also a full motion DV camera. DV camera 8 at the receiving side decodes the data for output to monitor 9 and, if connected, DV recorder 10 records the data received in DV camera 8.

[0043] The system can be operated uni-directionally, with video data streaming to one receive-only station or being broadcast or multicast to one or more receive-only stations; or the system can be operated bi-directionally with both receive and transmit capabilities at each of two or more stations.

[0044] In operation, DV camera 1 may be used at a remote monitoring station to transmit video data packets isochronously over IEEE 1394 cable 2 to the receiving side. The data is received by network interface 4 which buffers the data and negotiates access to the network until access is provided by network 5. Network 5 is a local or wide area network, preferably a Gigabit Ethernet network, which is a multi-user network which may be also connected to other peripheral devices such as a facsimile, printer and individual work stations, as described above in connection with FIG. 1. Wide area network 5 is an asynchronous network which does not guarantee access to the network at any specific time interval or data cycle. Because the DV camera 1 outputs data in an isochronous fashion (every 125 usec), that is, at specific time intervals/data cycles, 1394 network interface 4 must buffer the received video data packets until access to network 5 is obtained. 1394 network interface 4 also repackages the data into a specific network protocol format, such as Gigabit Ethernet format. The data is transmitted to a receiving side, or broadcast or multicast to multiple receiving sides.

[0045] At the receiving end, network interface 6 buffers the data that is received as well as unpackages the data from its network format into a IEEE 1394 format which is the format the receiving isochronous unit, DV camera 8, expects to receive. 1394 network interface 6, after unpackaging the data and restoring the data to its proper format, outputs the data at an isochronous timing/data cycle over IEEE 1394 standard cable 7 to DV camera 8. Upon receiving the data, DV camera 8 decodes the data and transmits the video data to monitor 9 for viewing or transmits the video data to be stored in DV recorder 10.

[0046] FIG. 3A is a block diagram depicting the internal components of 1394 network interface 4. In this embodiment, which supports bi-directional transmission and reception so as to enable video conferencing, 1394 network interface 4 and network interface 6 are identical in hardware structure;

[0047] therefore, a description of hardware components for 1394 network interface 6 will not be presented for the purposes of brevity.

[0048] Shown in FIG. 3A is physical layer 15 which is an IEEE 1394 interface connection which provides the electrical and mechanical interaction with cable 2. Physical layer 15 is connected with 1394 link layer 16 which is an IEEE 1394 interface link which controls access to the IEEE 1394 bus and which ensures that received data is properly formatted for further transmission. Link layer 16 is connected to the peripheral component interconnect (PCI) bus which operates within 1394 network interface 4. PCI bridge 19 manages the flow data through network interface 4 over the PCI bus from link layer 16, CPU 20, ROM 21, SDRAM 22 and network controller 23.

[0049] In the preferred embodiment, link layer 16 is an IEEE 1394 link, with a PCI interface which includes DMA (direct memory access) 17; CPU 20 is preferably a 233 hz StrongArm RISC processor; ROM 21 is preferably an 8 Mbyte memory which stores all software including initialization software for 1394 network interface 4 including isochronous and network initialization software; SDRAM 22 is preferably a 16 Mbyte or larger memory which, in the present embodiment, is separated internally into first and second buffers of equal size and a working memory region; and network controller 23 is preferably a Gigabit Ethernet PCI MAC (Media Access Controller) which utilizes UDP transport protocol for transmitting/receiving data through network 5 and includes various software drivers for operation in the present invention. Network controller 27 operates under control of an unshown network protocol stack, which is software executed by CPU 20.

[0050] Upon power-on and initialization, the operating system software, such as VxWorks® or the like, is loaded from ROM 21, into the working memory region of SDRAM 22. In addition, initialization software for 1394 network interface 4 is loaded into SDRAM 22 and executed by CPU 20. The initialization software includes process steps which, upon execution, create asynchronization sync semaphore (which is used to coordinate use of the first and second buffers), establish a network connection with the Gigabit Ethernet network, and build a USP socket for transmitting/receiving network packets. The initialization software further checks the functionality of hardware on 1394 network interface 4, enables 1394 digital video interrupts, connects digital video interrupts to PCI bridge 19, which in turn connects the interrupts to CPU 20, and allocates memory for data to be stored in first and second buffers in SDRAM 22. The digital video interrupts interrupt CPU 20 upon filling of one of the buffers in SDRAM 22, as described more fully below. Briefly, the amount of memory space allocated for one buffer has been determined to be approximately {fraction (1/30)} seconds worth of video data, which is about 130 Kbytes. This amount of data is one frame of data and is about the greatest amount of data that should be stored per buffer in order to prevent visible output latency at the receiving side due to output delay caused by buffering the isochronous data flow. Finally, the initialization software builds a channel program, which directs DMA 17 to store data in the first and second buffers of SDRAM 22.

[0051] After initialization, 1394 network interface 4 is up and running and waits to receive the first digital video data packets from DV camera 1.

[0052] From the sending station, DV camera 1 transmits isochronous data packets over cable 2 into 1394 network interface 4. The digital video data packets enter 1394 network interface 4 through physical layer 15. Physical layer 15 transmits the 1394-formatted data to link layer 16, which interprets the received data and identifies which device sent the data and which device should receive the data. In this regard, link layer 16 receives data packets, which are formatted in IEEE 1394 standard, and which contain various headers and fields to identify and route the contained data.

[0053] FIG. 3B illustrates a typical IEEE 1394 formatted isochronous data packet. The fields and headers of each data packet have the following definitions:

[0054] Header: includes fields for data length, tag, channel, tcode and sy, all of which are described below.

[0055] Data_length: is the length of data in bytes.

[0056] tag: is the tag field, which defines the type of data being transmitted, i.e., digital video, facsimile data, etc.

[0057] channel: is the channel field which specifies the IEEE 1394 channel that this packet is being transmitted on. IEEE 1394 standard provides for 0-63 broadcast channels.

[0058] tcode: is the transaction code that specifies what type of transaction shall be performed on the packet.

[0059] Sy: is the synchronization code which is application specific.

[0060] header CRC: the CRC (Cyclical Redundancy Check) is provided to verify that the header was transmitted accurately.

[0061] data field: contains the data for the packet.

[0062] data CRC: the CRC (Cyclical Redundancy Check) is provided to verify that the data was transmitted accurately.

[0063] Upon receiving the IEEE 1394 data packet, physical layer 15 transmits the data packet to link layer 16. Link layer 16 interprets the data in the data packet and removes all except data, meaning that header information, header_CRC information and data_CRC information, are all removed. This leaves just the data field from the packet, which DMA 17 transmits to SDRAM 22. That is, link layer 16 interprets the IEEE 1394 header and the information regarding the data in the data packet in order to know where the data came from and where the data is going. Link layer 16 then strips off unneeded information leaving only the data field. DMA 17, which resides in link layer 16, outputs only the data field directly into a buffer in SDRAM 22 via PCI bridge 19.

[0064] DMA 17, in accordance with the channel program, sends data to SDRAM 22 which is set up with a double buffer arrangement. Each buffer is 490 bytes wide and each, according to the present invention, is 267 packets deep, where 490×267=130,830 bytes in correspondence to one frame of video data. DMA 17 captures digital video packets and places them into the first buffer until it is full.

[0065] Upon filling one buffer, in SDRAM 22, CPU 20 is interrupted and, if necessary, pads each data packet length to be consistent with the size of the data packet. For example, 1394 data is 488 bytes wide; thus, padding is added to the end of each packet to 490 bytes, in correspondence to the width of the double buffer in memory in SDRAM 22. Once the first buffer is filled and CPU 20 has padded the data packet length, CPU 20 requests network controller 23 to request access to the network and to transfer the contents of the first buffer to the internal transmit buffer of network controller 23. The request to network controller 23 is through an unshown software module such as a network protocol stack or other network driver. While CPU 20 is controlling the padding and flow of data packets from the first buffer of SDRAM 22 to network controller 23, DMA 17 is capturing data packets and filling the second buffer of SDRAM 22. This procedure of emptying the first buffer while filling the contents of the second buffer, and thereafter emptying the second buffer while filling the first buffer, is repeated until all data packets have been transmitted.

[0066] Upon receiving a request from CPU 20 to access the network, network controller 23 transfers the data from the SDRAM buffer to an internal transmit buffer in controller 23. Controller 23 then negotiates the network 5 for access to the network. In addition, network driver software for network controller 23 packages the received data in conformance with the standard protocol for the network, to the extent that the software protocol stack has not already done so. When access is provided, network controller 23 transmits the contents of its internal buffer over network 5.

[0067] As network data packets are received at the remote side, 1394 network interface 6, which has identical hardware as that of 1394 network interface 4, begins to unpackage the network packets. After unpackaging and stripping off network headers, the receiving data packet is temporarily stored in its receipt buffer.

[0068] Because 1394 network interface 6 has the same hardware, reference to hardware in FIG. 3A will be used. In 1394 network interface 6, the receiving side SDRAM 22, while being the size as the transmitting side SDRAM, uses only one buffer to store data packets and, according to the present invention, does not output data from that buffer until at least 2 frames worth of data are stored in the buffer. This ensures that the buffer will not run out of data before the next input of data from the network.

[0069] Once at least two frames of data have been stored in SDRAM 22, link layer 16 receives data from SDRAM 22 via DMA transfer over the PCI bus, repackages the data into isochronous format, and sends the data out through physical layer 15. In turn, physical layer 15 outputs the digital video data through the IEEE 1394 bus to the receiving unit, DV camera 8.

[0070] FIGS. 4A through 4D are flow diagrams illustrating process steps so as to effect transmission of isochronous data over an asynchronous network to a receiving station and conversion of the asynchronously-received data back to isochronous format at a receiving station. The process steps shown in FIG. 4A are executed primarily by link layer 16 and DMA 17 so as to effect storage of isochronously-received data into SDRAM 22; the process steps shown in FIG. 4B are executed primarily by CPU 20 in conjunction with a software module containing a network protocol stack that controls network controller 23; the process steps shown in FIG. 4C are executed primarily by network controller 23 and an associated network protocol stack at a receiving side; and the process steps shown in FIG. 4D are executed primarily by CPU 20 in conjunction with link layer 16 and DMA 17 so as to repackage asynchronously received data into isochronous format for transmission to an isochronous device over a 1394 bus.

[0071] In more detail, in step S410, DMA 17 stores digital video data packets into one of buffers 1 and 2 in SDRAM 22. As previously described, the data packets are stored without header information or cyclical redundancy information, and may be padded so as to extend the length of each packet from 488 bytes to 490 bytes.

[0072] In step S411, in response to a determination that one of the two buffers is full, a digital video interrupt is signaled. Steps S412 through S417 determine which buffer has been filled, so as to send an appropriate semaphore to CPU 20. Thus, if the buffer full interrupt has been received and buffer 1 is full, then flow branches to steps S414 and S415 in which a flag indicating that buffer 1 has been filled is set, and an appropriate semaphore is sent to CPU 20. Likewise, if step S412 determines that buffer 1 has not been filled, then flow branches to steps S416 and step S417 in which the flag is set to indicate that buffer 2 is full, and an appropriate semaphore is sent to CPU 20.

[0073] In either event, flow thereafter exists so as to re-enter at step S410, to wait further receipt of digital video data packets.

[0074] When a buffer full interrupt has been received, indicative that one of buffers 1 and 2 has been filled, the process steps of FIG. 4B are executed. In step S420, CPU 20 determines which of the two buffers has been filled by reference to the flags set at steps S414 and S416. If, in step S423, CPU 20 determines that buffer 1 has been filled, then flow branches to steps S424 through S428 in which data in buffer 1 is sent out asynchronously over network 5. Specifically, data in buffer 1 is prepared for network transmissions (step S424) a check is made to see if the last packet from a previous transmission from buffer 2 has already been completed (step S425), remaining data from buffer 2 is emptied (step S426) if any data remains, data in buffer 1 is sent asynchronously over network 5 (step S427) and flow thereafter exits to await receipt of a next buffer interrupt (step S428).

[0075] In like manner, if CPU 20 determines in step S423 that buffer 1 has not been filled, then flow advances to steps S434 through S438 so as to send out data in buffer 2 asynchronously over network 5. Thus, step S434 prepares data in buffer 2 for transmission over the asynchronous network, step S435 determines whether all data from a prior transmission of buffer 1 has already been sent, step S436 empties any remaining data in buffer 1 if any data remains from a prior transmission, step S437 sends the data in buffer 2, and step S438 exits to await receipt of a next buffer full interrupt.

[0076] At the receiving side, the process steps of FIG. 4C are executed. Network controller 23 and its associated protocol stack receive a network packet from asynchronous network 5 in step S441. Step S442 determines if the incoming packet contains digital video data. If no digital video data is included in the incoming packet, then flow branches to step S443 since the packet would not then concern isochronous data transmission according to the invention. Thus, step S443 returns the packet to network controller 23 for default network protocol stack processing.

[0077] On the other hand, if the incoming data packet contains digital video data, then flow advances to step S445 in which the software protocol stack is completely bypassed so as to transfer the data portion of the packet directly to SDRAM 22. Specifically, under some circumstances, it is possible to make a simplifying assumption with respect to processing of digital video data received over the network: that any such digital video data properly received at the network socket for network controller 23 is ultimately destined for an IEEE 1394 bus interface. In accordance with this simplifying assumption, therefore, it is possible to bypass network protocol processing which ultimately would result in the extraction of the data portion of a network transmission. Rather, it is possible simply to obtain a raw network transmission, and to extract the needed data portion directly without any other processing inherent in network protocol stack processing.

[0078] Thus, step S445 bypasses the protocol stack normally associated with network controller 23, and, after stripping off unneeded network headers and the like, transfers only the data directly to SDRAM 22. The data is stored to an address indicated by an input pointer, whose value is updated after storage so that the next receipt of data from network 5 is stored to the correct location. Step S446 prepares the data for isochronous transmission, such as by alignment of bytes and removal of any padded bytes. Step S447 determines whether the SDRAM has been filled with at least two full frames of data. Until SDRAM 22 has been filled with at least two full frames of data, flow exits so as to re-enter at step S441, upon receipt of additional digital video data. On the other hand, when two full frames of digital video data have been stored in SDRAM 22, flow advances to step S448 so as to start sending data packets through link layer 16 and physical layer 15 to an IEEE 1394 bus, for receipt by a receiving device, as described more fully below in connection with FIG. 4D.

[0079] Specifically, in FIG. 4D, following receipt of network data packets and a wait until two full frames of data have been received (step S451 and S452, both of which are described above in connection with FIG. 4C), and a determination in step S453 that two full frames have been stored in SDRAM 22, flow branches to step S454 in which transmission of the first frame of digital video data is commenced in accordance with IEEE 1394 isochronous protocol. Specifically, an empty pointer is maintained for determining where in SDRAM 22 the next data for isochronous conversion is stored. DMA 17 accesses the SDRAM at the location of the empty pointer, and gives the digital video data to link layer 16 for reconstruction of the headers shown in FIG. 3B. After reconstruction of the IEEE 1394 headers, link layer 16 gives the data, which is now formatted in accordance with IEEE 1394 protocol to physical layer 15 for isochronous transmission out across 1394 bus to a receiving digital video device.

[0080] Flow next proceeds to step S455, in which CPU 20 determines whether there has been a data overrun or underrun in connection with storage of new network data to SDRAM 22, or in connection with emptying of SDRAM 22 by DMA 17. Specifically, two pointers are maintained, an input pointer and an empty pointer. The input pointer points to the next location in SDRAM 22 into which newly-received data from network 5 is stored. The empty pointer points to the next location in SDRAM 22 where DMA 17 obtains data for conversion to isochronous transmission. If the empty pointer is less than the input pointer (step S456), then DMA 17 has run out of data to convert to isochronous format. In such a circumstance, flow branches to step S457 in which the DMA channel program is stopped. This results in a freeze of digital video data, meaning that no new data is given to the isochronous device connected to IEEE 1394 bus 2.

[0081] On the other hand, if the input pointer is not less than the empty pointer, then flow advances to step S458 so as to accept new data packets from network 5 for storage into SDRAM 22. Operation in accordance with this step results in overwriting of digital video data already in SDRAM 22; of course, this results in a discarding of such data if it has not already been emptied by DMA 17 and not already been converted to isochronous format. Thus, if too much data is received from network 5, previously-received data is simply discarded.

[0082] FIG. 5 is a flow diagram illustrating a second embodiment of the invention, in which buffer size is dynamically altered, so as to adjust automatically and dynamically to other network traffic that might otherwise interfere with the transmission of digital video data over network 5. Specifically, according to this second embodiment, a modification may be made to the first embodiment so as to allow the size of the buffer to be modified dynamically and automatically, so as to accommodate current network characteristics such as busyness (heavy traffic, heavy loads, excessive retrys, broadcast packets, etc.), which are made on an on-going basis in real time.

[0083] More specifically, the ability to transmit an isochronous digital data stream over an asynchronous network, and at the same time to retain the ability faithfully to reconstruct the characteristics of the original isochronous stream, are both dependent on the isochronous receiver's ability to buffer the incoming data stream. The size of the buffer directly affects the amount of latency (or delay or timing shift) between the original isochronous data stream and the resulting reconstructed stream. At the same time, the size of the buffer is dependent on the degree of variability to access of the bandwidth available on the isochronous network. The variability of access to the network depends on available bandwidth of the network, the number of nodes on the network, network traffic patterns, and the like. According to the invention in this second embodiment, the size of the buffer, and therefore the amount of latency, is dynamically and automatically adjusted based on real-time checks that monitor current network characteristics. If the checks indicate a low degree of variability to network access (corresponding to a high bandwidth network and/or a quiescent network with low traffic patterns), then the buffer is adjusted to be small. On the other hand, if the checks indicate a high degree of variability (indicating a relatively low-bandwidth network and/or an active network with high traffic patterns) then the size of the buffer is automatically adjusted to be large.

[0084] Checks on the variability of the network are made by monitoring the state of the input pointer into the received buffer, here SDRAM 22, in which network data is placed, as well as monitor of the empty pointer to the buffer from where data is removed for conversion to an isochronous stream. The relative difference between these two pointers represents the current amount of data received, but not yet reconstructed into an isochronous stream. By monitoring the relative difference between these pointers, a receiver can calculate the amount of variability in the isochronous network 5. If the relative difference between the pointers varies widely and unstably, then the degree of variability is high indicating that a relatively larger buffer size should be created. Likewise, if the relative difference between the pointers is stable, then the degree of variability is low, indicating that the size of the buffer can be adjusted downwardly.

[0085] Thus, as shown in FIG. 5, an input pointer and an empty pointer are maintained so as to coordinate where new digital video data is stored in SDRAM 22 in connection with the receipt of new digital video data over the asynchronous network (in connection with steps S501 and S502), and in connection with emptying of SDRAM 22 by DMA 17 during conversion of the digital video data into an isochronous stream (in connection with steps S504 and S505).

[0086] Step S507 calculates the difference between the input pointer and the empty pointer, and step S508 monitors this difference. If the difference is stable, then the values of the input pointer and the empty pointer indicate that a relatively high bandwidth and/or quiescent network is present, meaning that the size of the buffer can be decreased. “Stable” may be defined as those circumstances where the difference between the input pointer and the empty pointer indicate that only about 10% or less of the total available buffer space is currently in use at any one time, over an extended period such as several seconds. If step S509 determines that the difference is stable, then flow branches to step S510 in which the size of the buffer is decreased, and the value of the empty pointer is updated in accordance with the new size of the buffer (step S511). Of course, decreasing the size of the buffer results in a temporary loss of incoming data (or of data already in the buffer), in correspondence to the newly-reduced latency of the overall video transmission.

[0087] On the other hand, if step S509 determines that the difference is not stable, then step S512 determines whether if the difference between the input pointer and the empty pointer indicates that the system is too unstable and an increase in buffer size is warranted. If the difference is not unstable enough, then no change in buffer size is made. On the other hand, if it is unstable enough, then flow advances to steps S513 and S514 so as to increase the size of the buffer. An unstable difference may be determined when the difference between the input pointer and the empty pointer indicates that greater than 50% of the total amount of the buffer space is ordinarily in use at any one time, over an extended period such as several seconds. Under such circumstances, the size of the buffer is increased (step S512), and the value of the input pointer is updated (S513) so as to compensate for the newly increased size of the buffer. Of course, with the newly-increased size of the buffer, there is a temporary halt of the outgoing isochronous data stream, until newly-received asynchronous digital video data fills up the newly-increased size of the buffer, in correspondence to the newly-increased latency of the overall system.

[0088] While the present invention has been described with respect to what is presently considered to be the preferred embodiments, it is to be understood that the invention is not limited to the disclosed embodiments. For example, it is possible to modify the invention such that the two-way digital video data communication shown above, which results in the ability to conduct digital video conferencing, is modified to a one-way system in which digital video data is streamed from a transmitting side to one or more receiving sides. Under such circumstances, 1394 Network Controllers 103 and 118 may be modified, as appropriate, so as to include only such circuitry and software modules as are needed for the particular function of transmit only or receive only. Moreover, although UDP protocol is preferred, any protocol may be utilized, although it is preferred to use a protocol which does not necessarily waste large amounts of overhead in an attempt to insure a guarantee of network transmissions. Further, although it is preferred, as a time-saving assumption, to bypass several irrelevant layers of the network protocol stack, it is possible for those layers to be executed particularly in systems for which suitable processing power is available. Moreover, although the isochronous data sources illustrated in the present embodiments are digital video cameras, other isochronous data sources may be substituted, with no change in the principle of operation of the invention.

[0089] Accordingly, the invention is intended to cover various modifications and equivalent arrangements included within the spirit and scope of the appended claims. The scope of the following claims is to be accorded the broadest interpretation so as to encompass all such modifications and equivalent structures and functions.