TWI531961B - Identifying devices in a topology of devices for audio/video streaming - Google Patents

Description

Method and apparatus for indicating a device for audio/video streaming in a topological arrangement

The present invention is generally directed to apparatus for transmitting and receiving video and audio material.

Displayed as the Digital Audio/Video Interconnect Standard of the Video Electronics Standards Association (VESA). It allows video and audio to be coupled from a computer to a video display or audio playback system. The display connector supports 1, 2, or 4 data pairs in the primary link. The primary link also carries clock and random audio signals with a symbol rate of 1.62, 2.7, or 5.4 gigabits per second. The 1.1 standard was approved in May 2006 and a 1.2 standard with an increased data rate was released in 2009. The 埠1.2 standard is shown to double the bandwidth of the 1.1 standard.

By displaying the 埠1.2 standard, two WQXGA monitors can receive audio/video data from a single source link, or four WUXGA monitors can receive data from a single source link. In addition, the 1.2 standard allows for higher speed AUX, mentioning some applications that can be used for general-purpose serial bus (USB) peripheral device data transmission, microphone audio transmission, or camera video transmission.

The display or slot device can be connected to the source device, for example, a personal computer or a consumer electronic device, either directly or through a so-called branching device. There are many types of branching devices, including repeaters for repeating audio or video information, converters for converting audio or video information from one format to another, regenerators for reproducing data, and hubs, hubs from two or more sources. The device takes the stream as an input and transmits them on its downstream link. The interface standard (eg, display 埠 1.2) allows multiple streams to be on one link; in this case, these two or more input streams can be transmitted onto a single downstream link. Some hubs can operate in a switched manner, that is, only one selected source can be transmitted at a time.

The source, slot, and branching devices together form a topological arrangement in which a given source can stream video to one or more slots through zero or more branching devices. Active video data flows through links that connect various device types. Each link is limited by its bandwidth and the number of streams it supports. The slot will have a limited number of audio and video endpoints to submit the stream. Therefore, based on the topology, there may be contention for available audio or video resources.

One such topology (shown in Figure 1) can include two sources and five slots, as shown. Source 1 wants to stream video to slot 1, and source 2 wants to stream video to slot 2, and the link between branch 2 and branch 3 is common to both paths. Thus, with regard to this contention, the problem may occur at the source, and how much bandwidth is included in the link or along any other link along the path. Another issue is how resources on the path can be preserved. Still another question is how much audio/video streaming can be driven. Other issues include how access to shared resources can be managed and how errors can be communicated.

SUMMARY OF THE INVENTION AND EMBODIMENTS

According to some embodiments, a particular message may be exchanged between devices that send and receive video and audio material. In response to those messages, the device along the path between the source and the trough device can take an adjustment action. The message can be sent to the destination destination indicated by its address. The messages ENUM_PATH_RESOURCES, COMMIT_PATH_RESOURCES, and RELEASE_PATH_RESOURCES can be used, as shown in Figure 2. For example, these messages can show that the 埠 specification is transmitted on the AUX channel.

The address space is generated before the message is transmitted. Each source 10 transmits an ENUM_PATH_RESOURCE message 18 to the desired slot 16 to enumerate the primary link bandwidth and the number of streams. The branching device 14 (just upstream of the desired slot 16) responds with the available bandwidth (BW = x) and the number of streams (# STREAMS = s), as shown at 20. Before this reply is passed further upstream, upstream branch 12 changes the available bandwidth (BW = x') and the number of streams (# STREAMS = s') from downstream branch 14 to reflect what is achievable from the downstream path As shown at 22.

Finally, source 10 gets the path resource. The message is transmitted on the control bus (eg, AUX for display), but the query is for the primary link resource. Even when the primary link resources are completely requested by one or two sources, there is no reserved bandwidth on the control bus and the control messages are exchanged between the devices in the topology.

As part of the message processing, each device may need to train the primary link along the indicated path to determine the amount of bandwidth available for the downstream link. Audio resources are also listed as part of this process. This is to determine the number of endpoints available for streaming at any given point in time.

The link bandwidth enumeration is fed into an operating system operation, such as a video mode enumeration. Based on this and the asynchronous selection by the end user of the video mode being driven, the COMMIT_PATH_RESOURCES message 24 can be used to complete the specified procedure, as follows. At the specified time, the enumeration bandwidth may not be available. For example, different sources can send different ENUM_PATH_RESOURCES messages to the same slot at any given time. They can also be used for different slots with multiple paths (which have a common link). As an example, source 1 enumeration, source 2 enumeration, source 1 specified sequence followed by source 2 designation, source 2 designation failed due to previous source 1 designation.

Source 10 transmits a COMMIT_PATH_RESOURCES message 24 to slot 16. This message has the desired bandwidth and number of streams. All devices along the specified path (such as branches 12 and 14) reserve resources for this source. Replys 26 and 28 may indicate success or failure.

Each device transmits a COMMIT_PATH_RESOURCES message 24 only if each device can successfully specify the desired resource. In addition to independent resource designation from different source devices, it is possible that the intermediate link along the path can be retrained to a lower bandwidth, thus providing additional reasons for failure. The link training is a handshake, which is implemented such that the transmitter or receiver agrees to the electrical configuration. Considering the topology of the device, this concept is extended to the entire path, where each link on the path needs to be trained in an adjustment called path training.

Possibly, some devices may have successful designated resources for video streaming before the downstream device can be specified. In order to release these resources, the source device may send a RELEASE_PATH_RESOURCES message 30 after receiving the failure of COMMIT_PATH_RESOURCES.

An active video begins after the successful completion of COMMIT_PATH_RESOURCES. Conversely, when the stream is to be aborted, the source issues RELEASE_PATH_RESOURCES 32 to cause the specified resource to be released at the device along the path.

Referring to FIG. 3, source 10, slot 16, and each branch device 12 or 14 are labeled 34 in FIG. The processor 36 can be coupled to the receiver 38 and the transmitter 40. In one embodiment, the processor 36 can also be coupled to the storage 42 to store software including the enumerated software 44. Thus, the storage 42 can be a computer readable medium that stores instructions that are executed by the processor 36. The reservoir 42 can be a semiconductor, optical, or magnetic memory.

The enumerated sequence 44 (shown in Figure 4) may be a soft body in one embodiment, but it may also be implemented in a hard or tough body. The check at diamond 46 determines if the branch device has received the listing message. If so, the message receiving branch device replies to the upstream branch device by the available bandwidth of the receiving device and the number of available streams.

If the receiving device does not receive the enumeration message after a cycle time, the check at diamond 50 determines if the non-receiving device is the upstream device (which receives the message indicating the bandwidth and the number of streams from the downstream device). If so, the upstream device modifies the received bandwidth and number of streams that need to reflect its performance. It then transmits the original bandwidth and the number of streams or the modified number (if needed) to the next branch or to the source, as indicated by block 54.

Referring to Figure 5, the message sequence diagram for the deletion and addition of streams includes source 60 and two slots 62, 64 having suitable stream identification codes. The identification code of slot 1 62 is "1" and the identification code of slot 2 64 is 1.2. Each device contains a plaque labeled "1" or "2".

6, a sequence diagram between source 60, branch and slot 1 62, and slot 2 64 is depicted. AUX refers to the control channel, and the primary link refers to the data channel.

Each link in the topology arrangement (e.g., as shown in Figure 5) may, for example, include separate control and data channels, and the connections are point-to-point. Ability to use the addressing and routing mechanism to send messages to any device on the control channel. The program involves the local unique identification of the stream at the source and the maintenance of the hub and mapping table, as shown in FIG.

In the address generation phase, a message 66 is generated by transmitting the address, and each device in the topology arrangement agrees to the address. Thereafter, the source transmits an ENUM_PATH_RESOURCES message 68 to the branch and slot 1 62 through the control channel, denoted AUX. It also transmits a COMMIT_PATH_RESOURCES message 70 to the branch and slot 162 via the control path.

The binding is a program, and the device in the topology arranges the destination of the next stream by linking. The linking procedure begins after enumeration: the source waits to transmit a new stream, and transmits an ADD_STREAM message 72 to the desired destination slot device (specified by the local unique stream identifier (eg, 1.2 for slot 2)). All devices along the path from source 60 to slot device 64 remember the stream identification code and input 埠 (e.g., 1 or 2) in their mapping table, on which the stream has been received.

Each branch device 62 performs a mapping of the input stream identification code (ID 1 for itself) to the output stream identification code (1.2 for slot 2 64). In the absence of multiple sources, the input stream identification code is the same as the output stream identification code. Each branch device also remembers the output stream identification code and the output port number in their mapping table.

Finally, assuming that the devices have no other resource constraints, the branch device forwards the message to the destination (as indicated by the routing/addressing contained in the message), as indicated at 74. In the case of such resource constraints, the branching device only transmits a negative acknowledgement return to the source. The message ends at the desired destination. If the slot device can receive the stream, it responds to the source with a confirmation 76. Otherwise, the slot device transmits a negative acknowledgement return. After that, the slot knows that it needs to use a new stream below the data channel. All branch devices pass back an acknowledgement 78 to the source.

Upon receiving the acknowledgment, the source device transmits a new stream 80 on the data path on its link, the link of which is directed to the desired destination. As noted from their mapping table, the branching device routes the stream along the path for the new stream, as indicated at 82. The slot device knows that it needs to use the new stream based on its previously received message and renders the stream on the display.

De-linking or deleting is performed by the delete stream messages 84, 86 sent to the desired destination having the same stream identification code. This causes the slot device to desirate to terminate the stream, and for the slot device, its mapping table is changed accordingly. The receipt of the acknowledgment message for deleting the stream message triggers the source to stop transmitting the stream on the data channel.

In Figure 7, various display configurations can be created for the topology arrangement shown in Figure 4. The "single display" configuration is just one display device that presents audiovisual data. It uses the messages 72, 74, 80, 82, 84, and 86 that have been described. The "copy mode" configuration is such that the same content 92 is transmitted and displayed on two monitors or display devices. The "Extended Desktop" is an alternative dual display configuration in which different images 94, 96 are displayed on both monitors.

When multiple sources exist in the topology arrangement (as shown in Figure 8), from source 1 98 to source 2 100, each source can issue the same stream identification code at the same time on the overlapping path (here) In the example: #1) ADD_STREAM message. In this example, the hub branching device 102 on the overlapping path for these new streams transmits only the ADD_STREAM message for one source (in this example: source 1) while blocking the others. That is, only one new stream can be added at a time. After the unblocked source message has been transmitted on the data channel, an additional ADD_STREAM message is sent for the blocked source.

In the case where there are multiple input ports on the branching device 104, the next available stream identification code is assigned, and the branching device remembers the input stream identification for its output stream identification code and 埠 number in its mapping table 108. Code and number.

As an example of use, new streams can be added. When the hub branch device sees an increased stream message with an unenabled identifier, it adds a new entry to its mapping table. It generates a new output identification code for that stream if needed, and uses that identification code when transmitting the ADD_STREAM message. The hub branching device can increment the destination address for this identification code in its mapping table. Another example of use is the presence of a stream extension. If the same source increases the second slot to enable one of the streams through another ADD_STREAM message, the hub branch device will not add a new item to its mapping table because the mapping it has generated is still available. However, the hub does have an input identifier that adds the second destination address to its mapping table.

Still another example of use is to remove the slot from the stream. When the hub receives the delete stream message with the address of the slot for enabling the identification code, it identifies the address of the slot to be deleted from a list of destination devices. Thereafter, when it receives the delete stream confirmation message from the slot device, it returns the message to the source using the mapping table to change the identification code to be identified by the source. It then deletes the address of the slot for that stream from its mapping table. If that is the last slot that received the stream with the identification code, it deletes the item from its mapping table. Otherwise, if at least one other slot uses the stream with the identification code, the item in the mapping table is not deleted.

Referring to Figure 9, a sequence 110 for implementing the above-described concatenation is illustrated in accordance with an embodiment. The sequence can be implemented in software, hardware, or firmware. In a software embodiment, the sequence may be implemented by instructions executed by a processor (e.g., processor 36 shown in FIG. 3) for branching device 34. In this example, the sequence can be stored in the storage 42.

Initially, the branch device receives the ADD_STREAM message, as indicated by block 112. It stores the input 那个 and STREAM_ID from that message in its mapping table, as indicated by block 114. Thereafter, the branch device maps the input STREAM_ID to the output STREAM_ID as indicated by block 116. It stores the output STREAM_ID and the output port number in its mapping table, as indicated by block 118. Thereafter, its preamble message is as shown in block 120. Finally, if the message is successfully sent, an acknowledgment message will be received from the downstream device, and the branch device forwards the acknowledgment message to the upstream, as indicated by block 122.

In some embodiments, messaging infrastructure 124 (shown in Figure 10) may allow for the operation of all devices along the path or only the operation of the destination device. The message has an identification code, and each new message is defined by assigning a new identification code. The definition of the message contains a decision as to whether it is a path or destination message. Depending on the direction in which the actuation is performed, there are two types of path information: in the downward direction to the slot, in this case it is the downward actuation path message; or in the direction of the upward return to the source device, in this case it is Actuate the path message up. The message can be initiated by any device in the topology. Each message has a destination address and associated routing information.

The messaging architecture 124 (shown in Figure 10) can be implemented in software, hardware, or firmware. For example, it can be implemented in software in the form of instructions stored in a computer readable medium (e.g., storage 42 shown in FIG. 3) in device 34 (which is, for example, a branching device or a slot device).

According to an embodiment, the sequence shown in FIG. 10 begins by receiving a message from an upstream device, as indicated by block 126. The device receiving the message can be a branch device or a slot device as two examples. The receiving device (whether or not it is the final destination) obtains a message definition, as indicated by block 128. Thereafter, in diamond 130, the device checks to determine if the message definition indicates an up-going message. If so, it performs the action required in the message when receiving the message, as indicated by block 132.

Otherwise, it is not an upward action message, and the diamond 134 check will determine if it is a downward action message. If it is a downward action message, as indicated by block 136, the action is performed on the acknowledgment, as opposed to when the message is received.

Conversely, if it is not a downward action message, then, as determined by diamond 138, if it is a destination message, the action is only performed if the device receiving the message is the final destination, as indicated by block 140. .

The messaging architecture allows the device to perform adjustments on a specified path in a point-to-point topology in which the audio visual source, branch, and slot device are connected. The architecture can be used for a variety of operations, including discovery topology, address generation, routing, link and stream management, resource management, and power management.

The downward actuation message (shown in Figure 11) acts as follows. Source 110 performs any desired message specific actions 119 prior to transmitting the message. Message 112 is only transmitted if the source is successful. The source device transmits the message to the destination device (determined based on addressing/routing information) by transmitting a message on the downstream port. Each branch device 114 or 116 or slot 118 that receives the message performs the action 119 required by the type of message. When the destination (e.g., slot 118) successfully completes the action, it responds with an acknowledgment (ACK) 120. This confirmation is uploaded back to the source.

The actuation of the up action message 122 is illustrated in FIG. Here, the actuation 119 is performed as part of the confirmation 120.

The action of the destination message is shown in Figure 13. Actuation 119 is only performed by the destination, in this example slot 118. Other devices in the path only forward messages and acknowledgments.

The purpose of the down-going path message is for path training (as shown in Figure 14), which trains all links on the path. In Figure 13, the actuation 119 at each device is link training. Although any other message can be used, the message used is TRAIN_LINKS_ON_PATH. In Figure 13, the message is directed at branch 116.

Figure 15 is a sequence diagram of the message when TRAIN_LINKS_ON_PATH is implemented as an up-go message. Here, all actions 119 occur as part of the confirmation 120.

The specific interface architecture allows the source device to determine that the functions listed through the different paths are part of the same device. An example of the "interface" is displayed. The different paths used for enumeration can be: a) paths characterized by different interface types, or b) only different paths within the same interface type. This architecture enables devices to be associated with container identifier initiatives (Microsoft Windows It is used in conjunction with other technologies (such as the Universal Serial Bus (USB)) and enables device-centric rather than function-centric user interfaces for connected devices.

The architecture may include a globally unique identifier (a globally unique identifier) of a 16-byte uncovered through a set of container_ID registers (DisplayPort configuration data (DPCD) in the example of display 埠). GUID)). DPCD is essentially a set of registers for status checking, command communication, and providing context for interrupts. The container_ID register can be supported by a branch device, a synthesized slot device, and any device with multiple transmissions.

A slot device having a given number of video endpoints is expected to respond with this number of Extended Display Identification Data (EDID) structures. The EDID data structure tells the source about the performance of the monitor. EDID is the VESA standard. When the slot device has an integrated universal serial bus (USB) or hub device, the slot's global unique identification code will match the global unique identifier in the container descriptor block of that USB device or hub. All functions integrated into the device will announce the same global unique identifier, regardless of which interface type they are accessed through. In a slot with multiple video endpoints, the container_ID register from each address returns the same global unique identifier. For each device in the topology, the source device reads the global unique identification code as part of the topology ranking discovery process. If the device contains a globally unique identification code, the source device reads the globally unique identification code to determine if the same device has been accessed for multiple paths or has been accessed through multiple interfaces.

Otherwise, the source device infers the functionality in the same physical device through some interface specific mechanisms. In the case where the interface is a display standard, this may be based on the relative address (RAD) of the downstream device. When faced with a topology-arranged device, each device initial communication needs to generate an address for use in a valid destination device in the network. That address is referred to as a relative address because the address generated by each device is valid, but may be different from the address generated at another source for the same destination. The source then reads the EDID from each relative address. A global unique identification code is generated and is associated with the device identified by the EDID. This generated global unique identifier is used with the container identifier architecture in the operating system.

Thus, EDID contains a unique serial number in some embodiments. If this is not valid, the same global unique identifier associated with multiple EDIDs will change, resulting in poor user experience.

A plurality of connections between the source and the branching device are shown in FIG. In this example, the source produces two addresses for the slot device because there are two paths leading to that slot. Since the source reads the same global unique identifier through the two paths, it can be inferred that the two paths read the same slot device. If the global unique identifier has been lost, the source reads the EDID (which will be the same) from the two paths, generates a global unique identifier, and associates that global unique identifier with the slot device. This identification code is then passed back to the operating system.

Figure 17 shows an example with two video endpoints. The sequence of this source is as follows. The source again generates two addresses, one for each video endpoint in the slot device. The source reads the container identification code for the scratchpad from each video endpoint address. Since the slot has two interfaces into it, the architecture requires a global unique identification code to be present in the slot, and that the global unique identification code is required to be the same in both interfaces. The source detects that the global unique identification code is the same, and infers that the two video endpoints are part of the same physical device.

Referring to Figure 18, sequence 150 can be implemented with a source in the form shown in Figure 3, in accordance with an embodiment. In some embodiments, the sequence shown in Figure 18 can be implemented in software, hardware, or firmware. In an embodiment of the software, the sequence may be implemented by a sequence of instructions executed by a processor (e.g., processor 36) and may be stored in memory 42.

At the initial enumeration or topology alignment discovery stage, the identification code is read for each device in the topology arrangement (block 152). In other words, the source obtains an identification code for the device in the topology. The identification code can be any of the identification codes discussed herein. Thereafter, the source establishes a connection downstream of the destination of the source through the path, as indicated by block 154. Thereafter, the source compares the identification code of the device in the connection path, as indicated by block 156. If (as determined by block 158) the identification code matches, the source concludes that the path device with the matching identification code is part of the same branch or slot device. Thus, in some embodiments, the ambiguity that may result when two devices have the same identification code can be simply processed.

The phrase "one embodiment" or "an embodiment" as used throughout this specification means that the specific features, structures, and characteristics described in connection with the embodiments are included in at least one embodiment of the invention. Thus, appearances of the phrase "in an embodiment" or "in an embodiment" are not necessarily referring to the same embodiment. In addition, the particular features, structures, and characteristics may be set in other suitable forms than the specific embodiments illustrated, and all such forms may be included in the scope of the application.

While the invention has been described with reference to a a a It is intended that the appended claims be interpreted as covering all such modifications and modifications

10. . . source

18. . . ENUM_PATH_RESOURCE message

16. . . groove

12, 14. . . Branch device

twenty four. . . COMMIT_PATH_RESOURCES message

26, 28. . . Reply

30. . . RELEASE_PATH_RESOURCES message

32. . . RELEASE_PATH_RESOURCES

36. . . processor

38. . . receiver

40. . . launcher

42. . . Storage

44. . . List software (listed sequence)

46, 50. . . diamond

48, 52, 54. . . Square

60. . . source

62. . . Slot 1 (branch and slot 1)

64. . . Slot 2

66. . . Address generation message

68. . . ENUM_PATH_RESOURCES message

70. . . COMMIT_PATH_RESOURCES message

72. . . ADD_STREAM message

76, 78. . . confirm

84, 86. . . Delete stream message

92. . . Same content

94, 96. . . image

102, 104. . . Branch device

108. . . Mapping table

110. . . sequence

112, 114, 116, 118, 120, 122. . . Square

124. . . Messaging architecture

126, 128, 132, 136, 140. . . Square

130, 134, 138. . . diamond

110. . . source

112. . . message

114, 116. . . Branch device

118. . . groove

119. . . Actuate

120. . . Confirmation (ACK)

122. . . message

150. . . Sequence (source)

152, 154, 156, 158. . . Square

1 is a schematic diagram of an audio/video distribution topology arrangement according to an embodiment;

2 is a sequence diagram for enumerating, specifying, and releasing according to an embodiment;

Figure 3 is a schematic illustration of one embodiment of a branching device;

4 is a flow chart for enumerating software according to an embodiment;

Figure 5 is a sequence diagram of a message according to an embodiment;

6 is a sequence diagram for enumerating path resources, in accordance with an embodiment;

Figure 7 is a sequence diagram showing how various display configurations can be established for the topology arrangement shown in Figure 6;

Figure 8 is a diagram showing possible mappings between two sources and two slots in accordance with an embodiment;

Figure 9 is a flow chart of an embodiment;

Figure 10 is a flow chart of an embodiment;

Figure 11 shows a sequence of messages in accordance with an embodiment;

Figure 12 is an upward actuation path message in accordance with an embodiment;

Figure 13 is a mapping of a destination sequence in accordance with an embodiment;

14 is a message sequence diagram for an up-going path message according to an embodiment;

Figure 15 is a diagram showing the connection between a source and a branching device in accordance with an embodiment;

Figure 16 is a diagrammatic view of a plurality of sources and branching devices in accordance with an embodiment;

17 is a diagram showing a topological arrangement of two video endpoints in accordance with an embodiment; and

Figure 18 is a flow diagram of an embodiment.

124. . . Messaging architecture

126, 128, 132, 136, 140. . . Square

130, 134, 138. . . diamond

Claims (24)

A method for indicating a device for audio/video streaming in a topology arrangement device, comprising: acquiring at least two different video sources for endpoints in a topological arrangement of audio/video streams Providing an identification code including specifying a global unique identification code for each endpoint in the topology arrangement or using a relative address generated by a source of one of the initial audio/video stream paths as the An identification code; comparing the identification codes of the endpoints in different audio/video stream paths, from the sources of the respective audio/video streams to destinations for audio/video streaming, The endpoints have different addresses; and based on their identification code, the two endpoints are determined to be part of a physical device. According to the method of claim 1, the global unique identification code is disclosed through a set of container_ID registers. According to the method of claim 2, including the use of a register for displaying data. According to the method of claim 1, the method further comprises reading the extended display identification data structure from each of the relative addresses. The method of claim 4, comprising generating a globally unique identification code for each endpoint identified by the extended display identification data structure. According to the method of claim 1, the source of the audio/video data is used to generate a global unique identification code for the topology arrangement Each endpoint in the middle. According to the method of claim 1, the determining device has more than one video endpoint because one endpoint has the same identification code as the other endpoint. A computer readable medium storing instructions executable by the processor to cause the processor to: obtain an identification code provided by at least two different video sources for endpoints in the topology of the audio/video stream And including specifying a global unique identification code to each of the endpoints in the topology arrangement or using a relative address generated by a source of one of the initial audio/video stream paths as the identification code; The identification codes of the endpoints in different audio/video stream paths, from the sources of the respective audio/video streams to the destinations for audio/video streams, the endpoints have different Addresses; and based on their identification codes, determine that the two endpoints are part of a physical device. The computer can read the media according to item 8 of the scope of the patent application, and store instructions to compare the identification codes of the devices in the path from the source to the destination. According to the medium of claim 8 of the patent application, the instructions are further stored to obtain the relative addresses of the devices in the topological arrangement for the audio/video stream, and to generate the respective devices for identification from the relative address. Global unique identifier. Computer readable media according to item 10 of the patent application scope, Instructions are also stored to read the extended display identification data structure from each of the relative addresses. The computer readable medium according to item 11 of the patent application scope, and another storage instruction to generate a global unique identification code for each device from the extended display identification data structure. The computer readable medium according to item 10 of the patent application scope, and another storage instruction to determine that the device in the topology has more than one video endpoint because each endpoint has the same identification code. A computer readable medium according to claim 10 of the scope of the patent application, including the use of a source of audio/video data to generate a global unique identification code for use in each of the devices in the topology. The computer readable medium according to item 9 of the patent application scope, and storing instructions to determine whether the identification codes match, and if the identification codes match, determining that the two devices having the matching identification codes in the topology arrangement are the same branch device Or part of the trough device. The computer readable medium according to item 8 of the patent application scope, and another storage instruction to expose the global unique identification code through a set of container_ID register. The computer can read the media according to item 16 of the patent application scope, and store instructions to use the register for displaying the configuration data. An apparatus for indicating a device for audio/video streaming in a topology arrangement device, comprising: a transmitter; a receiver; a controller, coupled to the receiver and the transmitter, the controller is configured to obtain an identifier provided by at least two different video sources for endpoints in the topology of the audio/video stream, including Specifying a global unique identifier for each endpoint in the topology or using a relative address generated by a source of one of the initial audio/video stream paths as the identifier; comparing in different audio The identification codes of the endpoints in the video stream path, from the sources of the respective audio/video streams to the destinations for the audio/video stream, the endpoints having different addresses; And based on their identification code, the two endpoints are determined to be part of a physical device. The device according to claim 18, wherein the device is a source in a topology arrangement for streaming audio/video data. According to the device of claim 19, the source is used to expose the global unique identification code through a set of container_ID registers. According to the device of claim 20, the source is used to use a register for displaying the configuration data. According to the device of claim 18, the controller is configured to read the extended display identification data structure of each relative address. According to the apparatus of claim 22, the controller is operative to generate a global unique identification code for each device identified by the extended display identification data structure. According to the device of claim 18, the source is used to determine that the device has more than one video endpoint because each endpoint has the same identification code.