Source: https://patents.google.com/patent/EP1517295A2/en
Timestamp: 2020-01-21 17:05:51
Document Index: 554370968

Matched Legal Cases: ['Application No. 10', 'Application No. 10', 'Application No. 10', 'Application No. 10', 'Application No. 10', 'Application No. 10', 'Application No. 10', 'Application No. 10', 'Application No. 10', 'Application No. 10']

EP1517295A2 - Packet based stream transport scheduler and methods of use thereof - Google Patents
Packet based stream transport scheduler and methods of use thereof Download PDF
EP1517295A2
EP1517295A2 EP04255611A EP04255611A EP1517295A2 EP 1517295 A2 EP1517295 A2 EP 1517295A2 EP 04255611 A EP04255611 A EP 04255611A EP 04255611 A EP04255611 A EP 04255611A EP 1517295 A2 EP1517295 A2 EP 1517295A2
EP04255611A
EP1517295A3 (en
2003-09-18 Priority to US50406003P priority Critical
2003-09-18 Priority to US504060P priority
2004-03-10 Priority to US55235204P priority
2004-03-10 Priority to US552352P priority
2004-07-29 Priority to US10/909,085 priority patent/US7487273B2/en
2004-07-29 Priority to US909085 priority
2004-09-16 Application filed by Genesis Microchip Inc filed Critical Genesis Microchip Inc
2005-03-23 Publication of EP1517295A2 publication Critical patent/EP1517295A2/en
2006-03-15 Publication of EP1517295A3 publication Critical patent/EP1517295A3/en
241001197925 Theila Species 0 description 1
A method of coupling a multimedia source device to a multimedia sink device by providing a source device having a transmitter unit coupled thereto, providing sink device having a receiver unit coupled thereto, receiving a source data stream in accordance with a native stream rate by the transmitter unit, coupling the transmitter unit and the receiver unit by way of a linking unit, forming a multimedia data packet stream formed of a number of multimedia data packets and generating a transport schedule for transferring the multimedia data packet stream in accordance with a link rate between the transmitter unit and the receiver unit wherein the multimedia data
This patent application takes priority under 35 U.S.C. 119(e) to (i) U.S. Provisional Patent Application No.: 60/504,060 (Attorney Docket No. GENSP013P2) filed on September 18, 2003, entitled "DIGITAL/ANALOG VIDEO INTERCONNECT AND METHODS OF USE THEREOF" by Kobayashi, and (ii) U.S. Provisional Patent Application No.: 60/552,352 (Attorney Docket No. GENSP127P) filed on March 10, 2004, entitled "DATA STREAM TRANSPORT SCHEDULING AND DATA STREAM CLOCK RECOVERY APPARATUS AND METHODS OF USE THEREOF" by Kobayashi each of which are hereby incorporated by reference herein in their entirety. This application is also related to the following co-pending U.S. Patent applications each of which are incorporated by reference, (i) U.S. Patent Application No. 10/726,802 (Attorney Docket No.: GENSP014), entitled "METHOD OF ADAPTIVELY CONNECTING A VIDEO SOURCE AND A VIDEO DISPLAY" naming Kobayashi as inventor; (ii) U.S. Patent Application No. 10/726,438 (Attorney Docket No.: GENSP015), entitled "METHOD AND APPARATUS FOR EFFICIENT TRANSMISSION OF MULTIMEDIA DATA PACKETS" naming Kobayashi as inventor; (iii) U.S. Patent Application No. 10/726,440, (Attorney Docket No.: GENSP105), entitled "METHOD OF OPTIMIZING MULTIMEDIA PACKET TRANSMISSION RATE", naming Kobayashi as inventor; (iv) U.S. Patent Application No. 10/727,131 (Attorney Docket No.: GENSP104), entitled "USING AN AUXILARY CHANNEL FOR VIDEO MONITOR TRAINING", naming Kobayashi as inventor; (v) U.S. Patent Application No. 10/726,350 (Attorney Docket No.: GENSP106), entitled "TECHNIQUES FOR REDUCING MULTIMEDIA DATA PACKET OVERHEAD", naming Kobayashi as inventor; (vi) U.S. Patent Application No. 10/726,362 (Attorney Docket No.: GENSP107), entitled "PACKET BASED CLOSED LOOP VIDEO DISPLAY INTERFACE WITH PERIODIC STATUS CHECKS", naming Kobayashi as inventor; (vii) U.S. Patent Application No. 10/726,895 (Attorney Docket No.: GENSP108), entitled "MINIMIZING BUFFER REQUIREMENTS IN A DIGITAL VIDEO SYSTEM", naming Kobayashi as inventor; and (viii) U.S. Patent Application No. 10/726,441 (Attorney Docket No.: GENSP109), entitled "VIDEO INTERFACE ARRANGED TO PROVIDE PIXEL DATA INDEPENDENT OF A LINK CHARACTER CLOCK", naming Kobayashi as inventor; (ix) U.S. Patent Application No. 10/726,934 (Attorney Docket No.: GENSP110), entitled "ENUMERATION METHOD FOR THE LINK CLOCK RATE AND THE PIXEL/AUDIO CLOCK RATE", naming Kobayashi as inventor, and (x) U.S. Patent Application No. 10/726,794 (Attorney Docket No.: GENSP013), entitled "PACKET BASED VIDEO DISPLAY INTERFACE AND METHODS OF USE THEREOF" naming Kobayashi as inventor.
Raster scan video transport protocols were originally developed for use with cathode ray tube (CRT) based display systems that must take into account the fact that an electron gun(s) is used to physically "paint" the displayed image one line at a time. For example, a standard definition (VGA) video image is formed of an active region that nominally includes 480 active display lines each of which is formed of 640 pixels (i.e., 640 x 480 resolution). In addition to the active region, however, a blanking region that is not displayed but nonetheless is included in the video signal since it represents that amount of time that is required for both horizontal and vertical retrace. For example, each frame of a VGA image (i.e., one full frame being 480 lines of 640 pixels each) requires approximately 160 pixel clocks per line for horizontal retrace and a period of time equal to approximately 45 line periods for vertical retrace. In this way (assuming one pixel per pixel clock) the video signal required to transport the video data necessary to display the VGA image must be on the order to 800 pixel clocks (640 active pixel clocks + 160 blanking pixel clocks). Therefore, the transport efficiency (as defined as the bandwidth of the displayable data over the total data stream bandwidth) is on the order of 80% (i.e., 640/800).
More recently, as the resolution of CRTs has increased in order to accommodate HDTV and other high end graphics applications, the efficiency of raster scan video transport protocols have been increased to approximately 90% by requiring that the horizontal retrace be limited to 160 pixel clocks (thereby reducing the associated blanking period). For example, given a UVGA image (i.e., 1600 x 1200), the transport efficiency is approximately 90% when the horizontal retrace is maintained at 160 pixel clocks (1600/(1600+160)) Although raster scan video transfer protocols are efficient (on the order of 90%) and do not require large buffers, they are, however, inflexible in that it is essentially capable of only displaying data as it is rendered.
In addition to raster scan video transport protocols, the emergence of digital video based systems has created the need for digital video transport protocols. One such digital video transport protocol referred to I.E.E.E. 1394, or FireWire™ is based upon isochronous packet transport that relies upon a large buffer (on the order of 60Kb) in order to guarantee a uniform bit rate and maintain synchronicity between multiple data streams (such as a video stream and an associated soundtrack in the form of an audio stream). Although isochronous packet transfer protocols are inherently flexible (due to their packet based nature), the large buffer requirements can be very costly.
Figs. 2A - 2C illustrates a video interface system that is used to connect a video source and a video display unit in accordance with a number of embodiments of the invention.
Figs. 27 - 31 illustrate various computer based implementations of the invention.
Each data stream is formed of a number of associated data packets whose size depends upon the relative portion of link bandwidth required for that particular data stream. For a particular data stream i an associated packet size PS i is related to a maximum packet size MPS, a link bit rate LBR and a stream bit rate SBR i by way of the following relationship: PS i = MPS * SBR i / (LBR i + 1).
In this way, a packet size is determined for each data stream based upon the relative bandwidth of the data stream compared to a data link bandwidth. For example, in the case where the maximum packet size is 64 link symbols, and the link bit rate LBR is 2.5Gbps per lane Table 1 shows reprehensive packet sizes corresponding to selected stream bit rates
The scheduler time division multiplexes (at the transmitter) and demultiplexes (at the receiver) the packets of the multiple streams into a corresponding link data stream. In the described embodiment, the transmitter reads the capability of the receiver in terms of, for example, the maximum data link rate, the available buffer size and the number of time base recovery (TBR) units. With this knowledge, the transmitter is able to determine the most efficient transport configuration and whether or not subsequent data streams can be accommodated by the receiver all without the need to send additional inquiries to the receiver. Prior to commencing the data stream transport, the transmitter notifies the receiver of stream attributes such as in the case of video data, color format and depth, geometry as well as the packet size associated with each data stream. By communicating this attribute data, the size of the packet headers can be substantially reduced to the point where only a stream ID is required. In this way, the transport efficiency is greatly increased over that provided in conventional packet based transport protocols that require substantially more overhead due to the larger size of the packet headers.
Accordingly, Fig. 1 shows a generalized representation of a packet based digital video display interface 100 well suited for implementing any of a number of embodiments of the invention. The interface 100 connects a transmitter 102 to a receiver 104 by way of a physical link 106 (also referred to as a pipe). In the described embodiment, a number of data streams 108 - 112 are received at the transmitter 102 that, if necessary, packetizes each into a corresponding number of data packets 114. These data packets are then formed into corresponding data streams each of which are passed by way of an associated virtual pipe 116 - 120 to the receiver 104. It should be noted that the link rate (i.e., the data packet transfer rate) for each virtual link can be optimized for the particular data stream resulting in the physical link 106 carrying data streams each having an associated link rate (each of which could be different from each other depending upon the particular data stream). The data streams 110 - 114 can take any number of forms such as video, graphic, audio, etc.
Other embodiments describe a simple enumeration method for the link rate and the pixel/audio clock rate. It has been researched and understood that all the standard pixel/audio clock frequencies that exist today are a subset of the following master frequency: 23.76GHz = 210 x 33 x 57 x 111 Hz
This means that a pixel (or audio) clock rate can be expressed with four parameters, A, B, C, and D as: Pixel clock rate = 2A * 3B x 5C x 11D A = 4 bits, B = 2 bits, C = 3 bits, and D = 1 bit.
Even for a link whose link rate (which is the serial link bit rate / 10 for a link that uses 10-bit character such as 8B/10B characters) may be different from the pixel clock rate, there is a benefit in defining the link rate with these four parameters, A', B', C', and D': The benefit is the simplicity in regenerating pixel/audio clocks from a link clock. For example, let's say the link rate is set as A' = 6, B' = 3, C' = 7, and D' = 0 and the corresponding link rate is 135MHz. However, suppose the pixel clock rate is set as A = 8, B = 3, C = 6, and D = 0 (= 108MHz), then the pixel clock can be generated from link clock as pixel clock rate is equal to the link rate * 22 / 5 1 .
Referring back to those systems requiring time base recovery, the time-base recovery unit 226 may be implemented as a digital clock synthesizer. For an uncompressed video stream, the time stamp is stored in the packet header which as described in more detail below, is a 20-bit value. For a given stream, four of 20 bits are stored in each header successively (TS3-0, TS7-4, TS11-8, TS15-12, TS19-16). Native stream frequency (Freq_native) is obtained from link character clock frequency (Freq_link_char) as: Freq_native = Freq_link_char * (TS19-0)/220.
It should be noted that, no time stamp is communicated for an audio stream. In this case, the source device informs the display device of the audio sample rate and number of bits per sample. By determining the audio rate as below and the link character rate, the display device regenerates the original audio stream rate. Audio rate = (audio sample rate) x (# bits per sample) x (# channels)
Fig. 12 shows a representative system 1200 having a data stream scheduler 1202 in accordance with an embodiment of the invention. It should be noted that the system 1200 is based upon the system 500 described with reference to figures 5A and 5B and should therefore be considered only one of any number of implementations of the invention. Accordingly, the stream scheduler 1202 is incorporated in or coupled to the video source 202 and is, in turn, coupled to a multiplexor 1204 and a data buffer 1206 suitable for storing only those portions of the incoming data streams (S1, S2, and S3) used to populate a link data stream 1208 during a period of time referred to as a scheduler cycle time Tsched. In the described embodiment, the data buffer 1206 is typically on the order of tens of bytes in size as opposed to over 60K bytes typical for isochronous video transfer protocols such as FireWire™. In this way, the link efficiency (based upon a comparing of the aggregate of the payload bandwidth of data streams divided by the available link bandwidth) is approximately on the order of 90% or greater.
In the described embodiment, the link data stream 1208 is formed by the scheduler 1202 by using time division multiplexing to combine size data packets P1, P2, and P3 (whose size reflects the relative bandwidth for each data stream in relation to a link bandwidth) from each of the data streams S1, S2, and S3, respectively. As described previously, the size of each data packet is a function of the particular data stream bit rate (SBR) and the link bit rate (LBR). In particular, the greater the particular data stream bit rate, the larger the particular data packet size as shown by the example of Table 1. For example, if the link bit rate LBR is on the order of 2.5 Gbps and the maximum packet size is approximately on the order of 80 link symbols (where one link symbol is defined as a data unit per link clock and is typically 4ns) and using the assumptions of Table 1 (i.e., SBR1 is 1.0 Gbps, SBR2 is 0.3125 Gbps and SBR3 is 0.25 Gbps) then data packet P1 associated with stream S1 is 32 link symbols while the data packets P2 and P3 associated with streams S2 and S3 are 10 link symbols and 8 link symbols, respectively. It should be noted that at the beginning of each scheduler cycle time Tsched, the scheduler 1202 inserts an interlane alignment packet (ILA) that provides an alignment tool for the receiver 204 that is typically on the order of 2 link symbols in size. In this example, therefore, the scheduler cycle time Tsched is on the order of (32 + 10 + 8 + 2) 52 link symbols (which would translate to approximately 208 ns when each link symbol represents approximately 4 ns).
It should also be noted that each data packet P has an associated active data ratio of the number of data symbols D and stuffing symbols N related to the stream bit rate (SBR) and the link bit rate (LBR) by SBR/LBR = D/(D+N).
Therefore in those saturations where a data stream is either added (or deleted) resulting in an increase (or decrease) of the scheduler cycle time Tsched, the packet size P for remains constant by varying the number of stuffing symbols N in relation to the number of data symbols D. Since with the addition (or deletion) of a data stream, since the particular packet sizes remain the same for the other data streams and the scheduler cycle time Tsched increases (or decreases) then the number of stuffing symbols N increases (or decreases) commensurate with the change in Tsched. In the "degenerate" case where there remains only a single data stream, then there are no stuffing symbols N.
Fig. 13 shows a more detailed portion 1300 of the data stream 1210 in accordance with an embodiment. In particular, Fig. 13 shows the arrangement of data symbols D and stuffing symbols N for the data stream 1208 using the values shown in Table 1. It should also be noted that dynamically adding or deleting a particular data stream leaves the particular packet sizes for the remaining data stream unaffected. Accordingly, Fig. 14 illustrates the addition of a fourth data stream S4 having a stream bit rate of .625 Gbps that corresponds to a packet size P4 of 20 link symbols resulting in an increase in Tsched from 52 to 72 link symbols (that corresponds to 288 ns for a link symbol equal to 4 ns). However, in order to keep the particular packet . sizes P1, P2, and P3 constant, the number of stuffing symbols N increases for each data packet. Conversely, in the case where a data stream is deleted (such as S3, for example) the scheduler cycle time Tsched will decrease accordingly with an commensurate increase in the number of data symbols D in relation to the number of stuffing symbols N. In the "degenerate" case where all data streams save one is deleted, then the remaining data packet has no stuffing symbols N and there is no need for any buffer thereby simulating the raster scan transport protocols discussed above.
Also, in the case where of the degenerate connection when the link data stream 1208 is a single, uncompressed video stream (as shown in Fig. 15) the ILA packets are placed in the idle period (the horizontal blanking region) of S 1 and the active display region is then represented by a mixture of data symbols D and stuffing symbols N (see Fig. 16).
It should also be noted that the relative number of data symbols D provides an embedded time stamp in that by counting the number of data symbols D for a particular data stream with relation to data symbols not related to the particular data stream provides the stream clock for the data stream in question. For example, in the case shown in Fig. 13, in order to recover a stream clock Fstream_clk for a particular data stream can be determined by simply determining the number of stream data symbols (M) as compared to the total number of stuffing symbols and stream data symbols (P). More particularly, the stream clock Fstream_clk is determined by the following: Fstream_clk = (M/P) * Flink_clk where M and P can be measured by the receiver 204.
It should be noted that the 8B/10B encoding algorithm is described, for example, in U.S. Patent Number 4,486,739, which is hereby incorporated by reference. As known by those of skill in the art, the 8B/10B code is a block code that encodes 8-bit data blocks into 10-bit code words for serial transmission. In addition, the 8B/10B transmission code converts a byte wide data stream of random 1s and 0s into a DC balanced stream of 1s and 0s with a maximum run length of 5. Such codes provide sufficient signal transitions to enable reliable clock recovery by a receiver, such as transceiver 110. Moreover, a DC balanced data stream proves to be advantageous for fiber optic and electromagnetic wire connections. The average number of 1s and 0s in the serial stream is be maintained at equal or nearly equal levels. The 8B/10B transmission code constrains the disparity between the number of 1s and 0s to be -2, 0, or 2 across 6 and 4 bit block boundaries. The coding scheme also implements additional codes for signaling, called command codes.
The display device physical layer 1916 isolates the display device link layer 1910 and the display device APL 1916 from the signaling technology used for link data transmission/reception. The main link 222 and the auxiliary channel 224 have their own physical layers, each consisting of a logical sub layer and an electrical sub layer that includes the connector specification. For example, the half-duplex, bi-directional auxiliary channel 224 has both a transmitter and a receiver at each end of the link as shown in Fig 22. An auxiliary link transmitter 2902 is provided with link characters by a logical sub layer 1908-1 that are then serialized serialized and transmitted to a corresponding auxiliary link receiver 2904. The receiver 2904, in turn, receives serialized link character from the auxiliary link 224 and de-serializes the data at a link character clock rate. It should be noted that the major functions of the source logical sub layers include signal encoding, packetizing, data scrambling (for EMI reduction), and training pattern generation for the transmitter port. While for the receiver port, the major functions of the receiver logical sub layer includes signal decoding, de-packetizing, data de-scrambling, and time-base recovery.
Still referring to Fig. 29, the auxiliary channel electrical sub layer contains the transmitter 2902 and the receiver 2904. The transmitter 2902 is provided with link characters by the logical sub layer, which it serializes and transmits out. The receiver 2904 receives serialized link character from the link layer and subsequently de-serializes it at link character clock rate. The positive and negative signals of auxiliary channel 224 are terminated to ground via 50-ohm termination resistors at each end of the link as shown. In the described implementation, the drive current is programmable depending on the link condition and ranges from approximately 8mA to approximately 24mA resulting in a range of V differential_pp of approximately 400mV to approximately 1.2V. In electrical idle modes, neither the positive nor the negative signal is driven. When starting transmission from the electrical idle state, the SYNC pattern must be transmitted and the link reestablished. In the described embodiment, the SYNC pattern consists of toggling a auxiliary channel differential pair signals at clock rate 28 times followed by four 1's in Manchester II code. The auxiliary channel master in the source device detects hot-plug and hot-unplug events by periodically driving or measuring the positive and negative signals of auxiliary channel 224.
In the described embodiment, the main link 222 supports discrete, variable link rates that are integer multiples of the local crystal frequency (see Fig 3 for a representative set of link rates consonant with a local crystal frequency of 24-MHz). As shown in Fig. 16, the main link 222 (being an unidirectional channel) has only a transmitter 1602 at the source device and only a receiver 1604 at the display device.
As shown, the cable 2304 takes the form includes a set of twisted pair wires, one for each of the Red (R), Green(G), and Blue(B) video signals provides in a typical RGB color based video system (such as PAL based TV systems). As known by those of skill in the art, twisted pair cable is a type of cable that consists of two independently insulated wires twisted around one another. One wire carries the signal while the other wire is grounded and absorbs signal interference. It should be noted that in some other systems, the signals could also be component based signals (Pb, Pr, Y) used for NTSC video TV systems. Within the cable, each twisted pair is individually shielded. Two pins for +12V power and ground are provided. The characteristics impedance of each differential pair is 100 ohms +/- 20%. The entire cable is also shielded. This outer shield and individual shields are shorted to the connector shells on both ends. The connector shells are shorted to ground in a source device. A connector 2400 as shown in Fig. 24 has 13 pins in one row having a pinout that is identical both for the connector on the source device end and that on the display device end. The source device supplies the power.
The main link 222 is terminated on both ends and since the main link 222 is AC coupled, the termination voltage can be anywhere between 0V (ground) to +3.6V. In the described implementation, the drive current is programmable depending on the link condition and ranges from approximately 8mA to approximately 24mA resulting in a range of V differential_pp of approximately 400mV to approximately 1.2V. The minimum voltage swing is selected for each connection using a training pattern. An electrical idle state is provided for power management modes. In electrical idle, neither the positive nor the negative signals are driven. When starting a transmission from electrical idle state, the transmitter must conduct a training session in order re-establish the link with the receiver.
The invention will now be described in terms of state diagrams shown in Figs. 25 and 26 described below. Accordingly, Fig.25 shows the source state diagram described below. At an off state 2502, the system is off such that the source is disabled. If the source is enabled, then the system transitions to a standby state 2504 suitable for power saving and receiver detection. In order to detect whether or not the receiver is present (i.e., hot plug/play), the auxiliary channel is periodically pulsed (such as for 1us every 10ms) and a measure of a voltage drop across the termination resistors during the driving is measured. If it is determined that a receiver is present based upon the measured voltage drop, then the system transitions to a detected receiver state 2506 indicating that a receiver has been detected, i.e, a hot plug event has been detected. If, however, there is no receiver detected, then the receiver detection is continued until such time, if ever, a receiver is detected or a timeout has elapsed. It should be noted that in some cases the source device may choose to go to "OFF" state from which no further display detection is attempted.
During a training start notification phase, the display responds to the training initiation by the transmitter by adjusting the equalizer using training patterns, updating the result for each phase. If the training fails, then wait for another training session and if the training passes, then go to normal operation state 2610. If there is no activity on the auxiliary channel or on the main link (for training) for more than a predetermined (10ms, for example), the auxiliary channel slave port is set to the standby state 2604.
Figs. 27 - 31 show particular implementations of the cross platform display interface.
The methodology of the invention will now be described in terms of a number of flowcharts each describing a particular process for enabling the invention. Specifically, FIGS 32 - 36 describe a number of interrelated processes that when used singly or in any combination described aspects of the invention.
Fig. 32 shows a flowchart detailing a process 3200 for determining an operational mode of the interface 100 in accordance with an embodiment of the invention. In this process, the operational mode will only be set to a digital mode if the video source and the display device are both digital. Otherwise, the operational mode will be set to analog mode. It should be noted that "analog mode" in this context can include both conventional VGA mode as well as enhanced analog mode having differential analog video with embedded alignment signal and bi-directional sideband. This enhanced analog mode will be described below.
A packet based display interface arranged to couple a multimedia source device to a multimedia sink device, comprising:
a linking unit coupling the transmitter unit and the receiver unit arranged to transfer a multimedia data packet stream formed of a number of multimedia data packets based upon the source packet data stream in accordance with a link rate that is independent of the native stream rate between the transmitter unit and the receiver unit; and
A display interface as recited in claim 1, wherein the multimedia data packet stream is one of a number of multimedia data packet streams each having an associated adjustable data stream link rate that is independent of the native stream rate.
A display interface as recited in claim 1, wherein the link unit further comprises:
A display interface as recited in claim 3, wherein the bi-directional auxiliary channel is formed of a uni-directional back channel configured to carry information from the sink device to the source device and a uni-directional forward channel included as part of the main channel for carrying information from the source device to the sink device in concert with the back channel.
A display interface as recited in claim 2, wherein the main link unit further comprises:
A display interface as recited in claim 5, wherein a main link bandwidth is at least equal to an aggregate of the virtual link bandwidths.
A method of coupling a multimedia source device to a multimedia sink device, comprising:
providing sink device having a receiver unit coupled thereto; receiving a source data stream in accordance with a native stream rate by the transmitter unit;
coupling the transmitter unit and the receiver unit by way of a linking unit;
generating a transport schedule for transferring the multimedia data packet stream in accordance with a link rate between the transmitter unit and the receiver unit wherein the multimedia data packets are each a fixed size based upon the link rate and a data stream bit rate.
A method as recited in claim 8, wherein the bi-directional auxiliary channel is formed of a uni-directional back channel configured to carry information from the sink device to the source device and a uni-directional forward channel included as part of the main channel for carrying information from the source device to the sink device in concert with the back channel.
A method as recited in claim 9, wherein the main link unit further comprises:
A method as recited in claim 10, wherein a main link bandwidth is at least equal to an aggregate of the virtual link bandwidths.
A method of scheduling a transport of a number of data packets between a data source and a data sink by way of a data link, comprising:
combining at least one of each data packet; and
transporting the combined data packets from the source to the sink.
Computer program product for scheduling a transport of a number of data packets between a data source and a data sink by way of a data link, comprising:
computer code for sending data packet attributes from the data packet source to the data packet sink;
computer code for comparing a stream bit rate to a data link bit rate for each of a number of data streams to be sent from the source to the sink;
computer code for setting a packet size for each of the data streams based upon the comparing wherein the packet size is a fixed packet size;
computer code for combining at least one of each data packet;
computer code for transporting the combined data packets from the source to the sink; and
EP04255611A 2003-09-18 2004-09-16 Packet based stream transport scheduler and methods of use thereof Withdrawn EP1517295A3 (en)
US504060P 2003-09-18
US55235204P true 2004-03-10 2004-03-10
US552352P 2004-03-10
US909085 2004-07-29
US10/909,085 US7487273B2 (en) 2003-09-18 2004-07-29 Data packet based stream transport scheduler wherein transport data link does not include a clock line
EP1517295A2 true EP1517295A2 (en) 2005-03-23
EP1517295A3 EP1517295A3 (en) 2006-03-15
EP04255611A Withdrawn EP1517295A3 (en) 2003-09-18 2004-09-16 Packet based stream transport scheduler and methods of use thereof
JP (1) JP2005173553A (en)
SG (1) SG110144A1 (en)
TW (1) TWI353167B (en)
EP1930813A2 (en) 2005-08-30 2008-06-11 Ricoh Company, Ltd. Information processing system, data transfer method, and computer product
GB2480133A (en) * 2010-05-06 2011-11-09 Intel Corp Connected HDMI device detection using a pulsed HPD signal
EP2472896A3 (en) * 2010-12-28 2013-06-05 Sony Corporation Electronic device, electronic device control method, and electronic device system
JP5272409B2 (en) * 2005-09-29 2013-08-28 株式会社ニコン Content playback system
EP2059877B1 (en) * 2006-09-06 2010-08-18 Thomson Licensing Device for processing a stream of data words
TWI360803B (en) * 2007-01-26 2012-03-21 Realtek Semiconductor Corp Apparatus and method for reducing output speed of
EP2141925B1 (en) * 2008-03-05 2016-12-21 Sony Corporation Transmission device and reception device
FR2969336B1 (en) * 2010-12-17 2013-01-04 Sagem Defense Securite Multiple ethernet connection device with computer unit and computer unit assembly and related equipment together
TWI482472B (en) * 2012-04-06 2015-04-21 Realtek Semiconductor Corp Multimedia transmission server, multimedia transmission method, and relevant computer program product
DE69832691D1 (en) 1997-02-17 2006-01-12 Comm & Control Electronics Ltd Local communication system
2004-07-29 US US10/909,085 patent/US7487273B2/en active Active
2004-09-16 EP EP04255611A patent/EP1517295A3/en not_active Withdrawn
2004-09-17 SG SG200405115A patent/SG110144A1/en unknown
2004-09-17 JP JP2004271144A patent/JP2005173553A/en not_active Withdrawn
2004-09-17 KR KR1020040074690A patent/KR20050028869A/en not_active Application Discontinuation
2004-09-17 TW TW93128282A patent/TWI353167B/en not_active IP Right Cessation
2004-09-17 CN CN 200410087460 patent/CN1602001B/en active IP Right Grant
BLOKS R H J: "The IEEE-1394 high speed serial bus" PHILIPS JOURNAL OF RESEARCH, ELSEVIER, AMSTERDAM, NL, vol. 50, no. 1, 1996, pages 209-216, XP004008212 ISSN: 0165-5817 *
JOHJI MAMIYA ET AL: "6.1: Invited Paper:Digital PV Link for a Next-Generation Video Interface, and Its System Architecture" SID 2000 DIGEST, vol. XXXI, 16 May 2000 (2000-05-16), pages 38-41, XP007007324 *
WICKELGREN I J: "THE FACTS ABOUT FIREWIRE" IEEE SPECTRUM, IEEE INC. NEW YORK, US, vol. 34, no. 4, April 1997 (1997-04), pages 19-25, XP002051393 ISSN: 0018-9235 *
EP1930813A3 (en) * 2005-08-30 2008-09-03 Ricoh Company, Ltd. Information processing system, data transfer method, and computer product
US8707374B2 (en) 2010-12-28 2014-04-22 Sony Corporation Electronic device, electronic device control method, and electronic device system
TWI353167B (en) 2011-11-21
CN1602001B (en) 2010-09-08
US20050066085A1 (en) 2005-03-24
EP1517295A3 (en) 2006-03-15
TW200520542A (en) 2005-06-16
US7487273B2 (en) 2009-02-03
CN1602001A (en) 2005-03-30
JP2005173553A (en) 2005-06-30
KR20050028869A (en) 2005-03-23
SG110144A1 (en) 2005-04-28
JP5705901B2 (en) 2015-04-22 Signal interface for higher data rates
JP2011066935A (en) 2011-03-31 High data rate interface
JP2007028645A (en) 2007-02-01 Method and system for transmitting n-bit video data over serial link
TWI352945B (en) 2011-11-21 Display, timing controller and data driver for tra
JP2004531916A (en) 2004-10-14 Interface for generating and implementing communication protocols and transferring high data rate signals
Ipc: G06F 3/13 20060101AFI20060124BHEP