Virtual channel removal method and apparatus
Through the virtual path removal method, the bandwidth release response is used to remove the specified virtual channel, which solves the problem of poor flexibility in transmission path removal in complex networks, and realizes more flexible audio and video service flow path management.
Patent Information
- Application Number
- PCT/CN2023/133802
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2023-11-23
- Publication Date
- 2025-05-30
AI Technical Summary
The prior art has poor flexibility when removing the transmission path of audio and video service streams in complex networks, resulting in the removal of all the transmission paths of target devices corresponding to the initiating device.
Through the virtual path removal method, after receiving the bandwidth release response, the specified virtual channel is removed according to the virtual channel identification, thereby achieving flexible removal of the transmission path of the audio and video service stream.
Without changing the physical connection relationship, the flexibility of removing the transmission path of the audio and video service stream is improved, and the path switching of the audio and video service stream is supported, thereby improving the overall networking flexibility.
Smart Images

Figure CN2023133802_30052025_PF_FP_ABST
Abstract
Description
Virtual path removal method and device Technical Field
[0001] The present application relates to the field of media technology, and in particular to a method and device for removing a virtual path. Background Art
[0002] Existing audio and video transmission networks are usually tree-like networks, such as audio and video transmission networks based on the High Definition Multimedia Interface (HDMI). In a tree-like network, the transmission path of the audio and video service flow is determined by the physical connection between the ports of each device in the audio and video transmission network. When the initiating device of the audio and video service flow transmits the audio and video service flow to the target device through a transmission path in the tree-like network, if any port in the transmission path is disconnected, the initiating device will stop sending the audio and video service flow, thereby realizing the dismantling of the transmission path of the audio and video service flow.
[0003] However, in more complex networks, the initiating device of an audio or video service stream can send the audio or video service stream to multiple target devices through multiple transmission paths. The existing transmission path removal method, where the source directly stops sending the audio or video service stream, will cause the transmission paths of all target devices corresponding to the initiating device to be removed, resulting in limited flexibility in removing transmission paths.
[0004] Summary of the Invention
[0005] The present application provides a method and apparatus for removing a virtual path, thereby improving the flexibility of removing paths of audio and video service flows in a complex network.
[0006] In a first aspect, the present application provides a method for dismantling a virtual path. First, a bandwidth release response is received, the bandwidth release response including a first virtual channel identifier (channel shuttleID, or shuttleID). Then, in response to the bandwidth release response, a first virtual channel corresponding to the first virtual channel identifier is dismantled.
[0007] The virtual channel includes multiple virtual channels cascaded between a source adapter of an initiating device of an audio or video service flow and a sink adapter among multiple adapters of a target device of the audio or video service flow. The virtual channel is used to transmit the audio or video service flow on a link between two ports.
[0008] Based on the above-described virtual path removal method, devices passing through the virtual path of audio and video service flows can remove the virtual channel corresponding to the specified virtual channel identifier in response to a bandwidth release. Since a virtual path is composed of multiple virtual channels cascaded between devices, a device in the virtual path can remove a specified virtual channel, thereby achieving virtual path removal. This allows the transmission path of audio and video service flows to be removed without changing the physical connection relationship, improving the flexibility of removing the transmission path of audio and video service flows, facilitating path switching for audio and video service flows, and thus improving the overall networking flexibility for audio and video service flows.
[0009] This application does not limit the execution entity of the above-mentioned virtual path removal method. The execution entity can be a multimedia device capable of processing audio and video service flows. For example, the multimedia device is an initiating device that initiates the audio and video service flow, or a processor of the initiating device. In another example, the multimedia device is an intermediate device that forwards the audio and video service flow, or a processor of the intermediate device. For the sake of simplicity, the initiating device in the following text can refer to the initiating device or the processor of the initiating device, and the intermediate device can refer to the intermediate device or the processor of the intermediate device.
[0010] As a possible implementation, the multimedia device sends a bandwidth release request before receiving the bandwidth release response. The bandwidth release request includes a first outbound port number and a first virtual channel identifier. The first outbound port number is the outbound port of the virtual channel corresponding to the device, which is used to transmit the audio and video service stream to the target device.
[0011] Optionally, when a removal instruction is received or a port of an intermediate device is disconnected, the bandwidth release request is sent. In a possible embodiment of the present application, the bandwidth release request is generated and sent by the initiator device of the audio and video service flow.
[0012] Optionally, when the first outgoing port number is in the router forwarding table corresponding to the audio and video service flow, the multimedia device reduces the first multicast count value (receiver count) of the outgoing node by one, and sets the identifier of the forwarding entry corresponding to the first virtual channel identifier in the router forwarding table to the first identifier.
[0013] Optionally, when the first multicast count value is equal to zero, the multimedia device sets the service flow identifier of the audio and video service flow to the second identifier.
[0014] The router forwarding table indicates the forwarding rules for messages between different virtual channels within the device. The outbound node corresponds to the first outbound port number, and the first multicast count indicates the number of target devices receiving the audio and video service stream at the first outbound port. The first identifier and the second identifier indicate that the forwarding entry has expired.
[0015] Based on the above implementation, the multimedia device configures the forwarding entry corresponding to the first virtual channel to be removed in the router forwarding table based on the first multicast count value, thereby ceasing to use the first virtual channel of the virtual channel to forward audio and video service flows at the transport layer. Furthermore, if the first multicast count value is zero, meaning that no target device receiving the audio and video service flows exists at the first outbound port, the service flow identifiers of the audio and video service flows are configured to batch disable all forwarding entries for these flows, thus achieving efficient removal of multiple virtual channels in multicast scenarios.
[0016] As a possible implementation manner, the multimedia device removes the first virtual channel corresponding to the first virtual channel identifier in different ways in response to the bandwidth release response according to different first multicast count values of the outgoing flow node.
[0017] Optionally, when the first multicast count value of the outgoing flow node is equal to zero, it indicates that there is no target device receiving the audio and video service flow under the first outgoing flow port, all virtual paths used to transmit the audio and video service flow at the first outgoing flow port can be dismantled, and there is no need to reserve bandwidth, then the multimedia device releases the bandwidth of the first outgoing flow port.
[0018] Optionally, when the first multicast count value of the outbound node is greater than zero, indicating that a target device still exists under the first outbound port to receive the audio and video service stream, only the virtual path to which the virtual channel corresponding to the first virtual channel identifier belongs is removed, and bandwidth must be reserved for other virtual paths to continue transmitting the audio and video service stream. The multimedia device then clears the adapter binding information. The adapter binding information includes adapter binding information for the source adapter of the initiator device and the sink adapter of the target device of the virtual path to which the first virtual channel belongs.
[0019] Based on the above implementation, the multimedia device adopts different virtual path removal methods according to different first multicast count values, ensuring that when any logical path of the audio and video service flow in multicast mode is removed, it does not affect the data transmission of other logical paths, thereby improving the transmission stability of the audio and video service flow.
[0020] As a possible implementation, when the virtual path teardown method is applied to an intermediate device or a processor of an intermediate device, the bandwidth release request or bandwidth release response of the initiating device or the upper-level intermediate device in the virtual path can be forwarded.
[0021] Optionally, before sending the bandwidth release request, the multimedia device receives a bandwidth release request from a higher-level intermediate device. The bandwidth release request includes a second virtual channel identifier, which indicates the virtual channel that is the higher level of the first virtual channel. In this way, when forwarding the bandwidth release request to the next level, the multimedia device replaces the second virtual channel identifier with the first virtual channel identifier, thereby enabling the bandwidth release request to instruct the removal of virtual channels at all levels in the virtual path.
[0022] Optionally, after receiving a bandwidth release response from a device at the next level in the virtual path, the multimedia device identifies the path based on the virtual channel identifier in the bandwidth release response, replaces the virtual channel identifier in the bandwidth release response with a second virtual channel identifier, and then forwards the bandwidth release response. In this way, the bandwidth release response can be transmitted from the virtual path to the device initiating the audio and video service flow based on the virtual channel identifier, thereby instructing each device in the virtual path to disconnect the corresponding virtual channel according to the bandwidth release response.
[0023] In a second aspect, the present application provides a virtual path removal method, which is applied to a target device receiving an audio or video service stream, such as a multimedia device. The target device responds to a bandwidth release request by sending a bandwidth release response. The bandwidth release response includes a third virtual channel identifier.
[0024] Based on the above-mentioned virtual path dismantling method, the bandwidth release response returned by the target device carries the third virtual channel identifier, which can instruct the upper-level device in the virtual path to identify the path according to the third virtual channel identifier and dismantle the third virtual channel corresponding to the third virtual channel identifier, thereby realizing the dismantling of the virtual path corresponding to the designated path of the audio and video service flow, and improving the flexibility of dismantling the audio and video transmission path.
[0025] As a possible implementation, the target device receives a bandwidth release request before returning the bandwidth release response. The bandwidth release request includes the second outbound port number and the third virtual channel identifier.
[0026] In a third aspect, the present application provides a method for virtual path removal, which is applied to an intermediate device or a processor of the intermediate device, where "intermediate device" refers to the intermediate device or the processor of the intermediate device. First, the intermediate device receives a path removal response. The path removal response includes a fourth virtual channel identifier. Then, in response to the path removal response, the intermediate device removes a fourth virtual channel corresponding to the fourth virtual channel identifier.
[0027] Based on the above implementation method, when the port through which the intermediate device in the virtual channel communicates with the initiating device is disconnected, and the intermediate device is unable to forward the bandwidth release request to the target device, the channel demolition response can also be forwarded to the intermediate device through virtual channel addressing through the virtual channel identifier to instruct the intermediate device to demolish the virtual channel, thereby realizing the virtual channel demolition in the scenario where the port of the virtual channel is disconnected, avoiding the inability to release the bandwidth of the invalid virtual channel, and improving bandwidth utilization.
[0028] As a possible implementation, before receiving a path teardown response, the intermediate device sends a path teardown request upon detecting a disconnection event on the inbound port of its own audio or video service stream. The path teardown request includes the third outbound port number and the fourth virtual channel identifier. In this way, the path teardown request can use the fourth virtual channel identifier to address the virtual channel to which it is forwarded, triggering a path teardown response to tear down all virtual channels.
[0029] As one possible implementation, the path teardown response also includes a second multicast count value, which indicates the number of target devices receiving the audio and video service stream at the third outbound port corresponding to the third outbound port number. In response to the path teardown response, the intermediate device releases bandwidth for the third outbound port when the multicast count value of the outbound node equals the second multicast count value.
[0030] As a possible implementation, for the intermediate device at the next level or n (n is a positive integer) levels of the intermediate device whose inflow port of the audio and video service flow is disconnected, the intermediate device can forward the path removal request or path removal response.
[0031] Optionally, before sending the path removal request, the intermediate device receives a path removal request including the fifth virtual channel identifier. The intermediate device replaces the fifth virtual channel identifier with the virtual channel identifier of the next virtual channel in the virtual path and then forwards the path removal request.
[0032] For example, the intermediate device queries the third outbound port number and the fourth virtual channel identifier based on the inbound port and the fifth virtual channel identifier of the path demolition request, and then sends the path demolition request through the third outbound port corresponding to the third outbound port number, and the path demolition request includes the fourth virtual channel identifier.
[0033] Optionally, before sending the path teardown response, the intermediate device receives a path teardown response including the fourth virtual channel identifier. The intermediate device replaces the fourth virtual channel identifier with the virtual channel identifier of the upper-level virtual channel in the virtual path and then forwards the path teardown response.
[0034] For example, the intermediate device queries the second inbound port and the fifth virtual channel identifier based on the inbound port number and the fourth virtual channel identifier of the path demolition response, and then forwards the bandwidth release response through the second inbound port corresponding to the second inbound port, where the bandwidth release response includes the fifth virtual channel identifier.
[0035] In a fourth aspect, the present application provides a virtual path removal method, which is applied to a target device. First, the target device responds to a path removal request and returns a path removal response, where the path removal response includes a sixth virtual channel identifier.
[0036] Based on the above implementation, when the port of an intermediate device in a virtual path communicating with the initiating device is disconnected, the target device can also address the virtual path based on the virtual channel identifier and return a path teardown response to the intermediate device, indicating the teardown of the virtual path. This enables teardown of the virtual path even when the port is disconnected, avoiding the inability to release bandwidth for the failed virtual path and improving bandwidth utilization.
[0037] As a possible implementation manner, before returning the path teardown response, the target device receives a path teardown request, where the path teardown request includes the fourth outbound port number and the sixth virtual channel identifier.
[0038] Optionally, the path teardown response further includes a third multicast count value. The third multicast count value is used to indicate the number of devices receiving the audio and video service streams at the outbound port of the target device.
[0039] In a fifth aspect, the present application provides a virtual path removal device, comprising a transceiver module and a processing module. The transceiver module is configured to receive a bandwidth release response; the bandwidth release response includes a first virtual channel identifier; the virtual path includes multiple virtual channels cascaded between a source adapter of an initiating device of an audio or video service flow and a sink adapter among multiple adapters of a target device of the audio or video service flow, the virtual channels being used to transmit the audio or video service flow on a link between two ports; and the processing module is configured to remove a first virtual channel corresponding to the first virtual channel identifier in response to the bandwidth release response.
[0040] As a possible implementation manner, the virtual path removal apparatus may further include other modules that execute the operation steps of the virtual path removal method described in the first aspect.
[0041] In a sixth aspect, the present application provides a virtual path removal device, comprising a transceiver module, wherein the transceiver module is configured to send a bandwidth release response, wherein the bandwidth release response includes a third virtual channel identifier.
[0042] As a possible implementation manner, the virtual path removal apparatus may further include other modules for executing the operation steps of the virtual path removal method described in the second aspect.
[0043] In a seventh aspect, the present application provides a virtual path removal device, comprising a transceiver module and a processing module. The transceiver module is configured to receive a path removal response, wherein the path removal response includes a fourth virtual channel identifier; and the processing module is configured to remove a fourth virtual channel corresponding to the fourth virtual channel identifier in response to the path removal response.
[0044] As a possible implementation manner, the virtual path removal apparatus may further include other modules for executing the operation steps of the virtual path removal method described in the third aspect.
[0045] In an eighth aspect, the present application provides a virtual path removal device, comprising a transceiver module, wherein the transceiver module is configured to return a path removal request, wherein the path removal response includes a sixth virtual channel identifier.
[0046] As a possible implementation manner, the virtual path removal apparatus may further include other modules for executing the operation steps of the virtual path removal method described in the fourth aspect.
[0047] In a ninth aspect, the present application provides a multimedia device comprising a transceiver and a processor; the processor is configured to process audio and video service flows; and the processor is configured to transmit and receive the audio and video service flows. The memory, the transceiver, and the processor are configured to collaboratively execute the steps of the virtual path removal method described in the first or third aspect.
[0048] In a tenth aspect, the present application provides a multimedia device comprising a transceiver and a processor; the processor is configured to process audio and video service streams; and the processor is configured to transmit and receive the audio and video service streams. The memory, the transceiver, and the processor are configured to collaboratively execute the steps of the virtual path removal method described in the second aspect or the fourth aspect.
[0049] In an eleventh aspect, a computer program product is provided, which includes a computer program or instructions, and when the computer program or instructions are executed on a computer, the computer executes the virtual path removal method described in any possible implementation of the first aspect.
[0050] In a twelfth aspect, a computer program product is provided, which includes a computer program or instructions, and when the computer program or instructions are run on a computer, the computer is caused to execute the virtual path removal method described in any possible implementation of the second aspect.
[0051] In a thirteenth aspect, a computer program product is provided, which includes a computer program or instructions, and when the computer program or instructions are run on a computer, the computer is caused to execute the virtual path removal method described in any possible implementation of the third aspect.
[0052] In a fourteenth aspect, a computer program product is provided, which includes a computer program or instructions, and when the computer program or instructions are executed on a computer, the computer is caused to execute the virtual path removal method described in any possible implementation of the fourth aspect.
[0053] In a fifteenth aspect, a computer-readable storage medium is provided, which includes a computer program or instructions that, when executed on a computer, causes the computer to execute the virtual path removal method described in any possible implementation of the first aspect.
[0054] In a sixteenth aspect, a computer-readable storage medium is provided, wherein the computer-readable storage medium includes a computer program or instructions, which, when executed on a computer, causes the computer to execute the virtual path removal method described in any possible embodiment of the second aspect.
[0055] In a seventeenth aspect, a computer-readable storage medium is provided, wherein the computer-readable storage medium includes a computer program or instructions, which, when executed on a computer, causes the computer to execute the virtual path removal method described in any possible implementation of the third aspect.
[0056] In an eighteenth aspect, a computer-readable storage medium is provided, wherein the computer-readable storage medium includes a computer program or instructions, which, when executed on a computer, causes the computer to execute the virtual path removal method described in any possible implementation of the fourth aspect. BRIEF DESCRIPTION OF THE DRAWINGS
[0057] FIG1 is a schematic diagram of a video transmission system provided by the present application;
[0058] FIG2 is a schematic diagram of an audio and video encoding and decoding system provided by the present application;
[0059] FIG3 is a schematic diagram of a virtual path provided by the present application;
[0060] FIG4 is a schematic diagram of multicast of a virtual channel provided by the present application;
[0061] FIG5 is a flow chart of a method for removing a virtual path provided by the present application;
[0062] FIG6 is a schematic diagram of a port disconnection scenario of an intermediate device provided by the present application;
[0063] FIG7 is a second flow chart of a virtual path removal method provided by the present application;
[0064] FIG8a is a third flow chart of a virtual path removal method provided by the present application;
[0065] FIG8 b is a fourth flow chart of a virtual path removal method provided by the present application;
[0066] FIG9 is a schematic structural diagram of a virtual passage removal device provided by the present application;
[0067] FIG10 is a schematic structural diagram of a multimedia device provided in this application. DETAILED DESCRIPTION
[0068] The present application provides a method for dismantling a virtual path, wherein an initiating device or an intermediate device receives a bandwidth release response and dismantles a first virtual channel according to a first virtual channel identifier in the bandwidth release response. In this way, the initiating device or the intermediate device can, through the virtual channel identifier, dismantle the virtual channel corresponding to the specified virtual path without changing the physical connection relationship between the devices, thereby improving the flexibility of dismantling the transmission path of audio and video service flows, facilitating path switching of audio and video service flows, and thereby improving the overall networking flexibility of audio and video service flows.
[0069] The technical solutions involved in this application may be applied not only to current audio and video transmission technologies or audio and video standards, but also to future audio and video transmission technologies or audio and video standards. The terms used in the embodiments of this application are only used to explain the specific embodiments of this application and are not intended to limit this application. The following is a brief introduction to some concepts that may be involved in this application.
[0070] Audio and video service flows include audio streams and / or video streams. An audio stream is a data stream used to transmit audio data in real time. A video stream is the transmission of video data. For example, a video stream can be processed as a stable and continuous flow over a network. A video stream consists of multiple video frames, each of which corresponds to an image.
[0071] In this embodiment, "video" is a general term that refers to a sequence of multiple consecutive frames, with one frame corresponding to one image. "Audio and video" is an information application technology term that refers to video, audio, or multimedia content that includes both video and audio. Furthermore, this application does not limit the type of service flow. For example, the service flow in this application can be an audio and video service flow or a USB service flow. The following description will primarily use audio and video service flows as an example.
[0072] A router's forwarding table, also known as a forwarding table or forwarding information base (FIB), is a table located on the router's data plane. The entries in the router's forwarding table are called forwarding entries or forwarding entries. Each forwarding entry specifies a destination, the outgoing interface to be reached, the next-hop IP address, and other information.
[0073] In order to make the description of the following embodiments clear and concise, the video transmission system to which the virtual path removal method of the present application is applicable is first introduced.
[0074] Figure 1 is a schematic diagram of a video transmission system provided by the present application. The video processing process may include but is not limited to: video acquisition, video encoding, video transmission, video decoding and playback.
[0075] The video transmission system in Figure 1 includes a set-top box 110, a smart TV 120, multiple audio and video playback devices, and a server 130. The set-top box 110 is connected to the operator's network via a network cable and can receive audio and video streams from the server 130. The network can implement the function of audio and video transmission, and the network can include one or more network devices, such as a network device 131, which can be a router or a switch. In some optional implementations, the set-top box 110 and the server 130 can also communicate via wireless communication, which is not limited in this application.
[0076] The video transmission system in Figure 1 includes a set-top box 110, a smart TV 120, multiple audio and video playback devices, and a server 130. The set-top box 110 is connected to the operator's network via a network cable and can receive audio and video streams from the server 130. The network can implement the function of audio and video transmission, and the network can include one or more network devices, such as a network device 131, which can be a router or a switch. In some optional implementations, the set-top box 110 and the server 130 can also communicate via wireless communication, which is not limited in this application.
[0077] Smart TV 120 is a display device with audio and video processing capabilities that implements functions such as receiving, processing, pushing, and playing video streams or audio and video streams. In some possible scenarios, the smart TV 120 may refer to an audio and video device such as a conference tablet, a smart TV, or a projector, but this application is not limited to this.
[0078] The plurality of audio and video playback devices include audio and video playback devices 121 to 124. For example, these audio and video playback devices may include, but are not limited to, multimedia control platforms or other devices supporting audio and video playback functions, such as virtual reality (VR) terminal devices or augmented reality (AR) terminal devices.
[0079] In this embodiment, the set-top box 110 and the smart TV 120 can be connected via a bus 125. The set-top box 110 and various audio and video playback devices can also be connected via the bus 125. The smart TV 120 and various audio and video playback devices can also be connected via the bus 125. Exemplarily, the bus 125 can be a data bus that supports video and audio and video transmission. For example, the bus 125 is a unified multimedia interconnection (UMI) bus. A UMI bus is a bus connected based on the UMI interface provided by the source device and the sink device. The UMI bus can be used to connect a charger to charge an electronic device (such as the smart TV, set-top box, or audio and video playback device described above), and can also be used to transmit data between the electronic device and peripheral devices. It can also be used to connect headphones to play audio through the headphones. This interface can also be used to connect other electronic devices, such as augmented reality devices. When the UMI bus is used to implement data communication between devices, it can support both uncompressed and compressed video transmission, as well as various advanced features such as Quick Video Transport (QVT), Auto Low Latency Mode (ALLM), and Dynamic Frame Rate Refresh (DFR). Furthermore, the UMI bus can support LPCM audio and video formats defined by IEC 60958, as well as various HDR protocols, such as HDR Vivid (HDR Vivid) specified in T / UWA005.1-2022. The UMI also supports encryption control and protection for data transmission, such as audio and video. In some optional implementations, the bus 125 can also refer to other types of buses that can implement the functions supported by the aforementioned UMI bus.
[0080] Server 130 can be an application server or an authentication and authorization server. Server 130 can provide video services, game services, messaging services, music services, authentication and authorization services, and the like. In one example, the functions of multiple services can be integrated on server 130. For example, a game service and a music service can be deployed on server 130. In another example, the functions of some services can be integrated on server 130. For example, server 130 can deploy some game services and some video services. Server 130 can also utilize virtualization technology to provide multiple virtual machines, which provide various services. The embodiments of this application do not limit the deployment of the server. Network device 131 is connected to server 130 via wireless or wired connections. Figure 1 is merely a schematic diagram; the network may also include other devices, not shown in Figure 1. It will be understood that the aforementioned audio and video is a general term. Audio and video include multiple video frames, each of which corresponds to a group of packets carrying the audio and video data to be parsed and played. Figure 1 is merely a schematic diagram; the video transmission system may also include other devices, not shown in Figure 1. The embodiments of the present application do not limit the number and type of each device included in the system.
[0081] Based on the video transmission system shown in FIG1 , FIG2 is a schematic diagram of an audio and video codec system provided by the present application. The audio and video codec system includes a source device 210 and a sink device 220. The source device 210 establishes a communication connection with the sink device 220 via a UMI bus.
[0082] The above-mentioned source device 210 can implement the function of audio and video encoding. As shown in Figure 1, the source device 210 can be a set-top box 110 or a smart TV 120. The source device 210 can also be an audio and video control center with audio and video encoding capabilities. For example, the audio and video control center includes one or more servers.
[0083] The source device 210 may include a data source 211 , a pre-processing module 212 , an audio and video transmission adapter 213 , and a communication interface 214 .
[0084] The data source 211 may include or may be any type of electronic device for collecting audio and video, and / or any type of source audio and video generating device, such as a computer graphics processor for generating computer animation scenes or any type of device for obtaining and / or providing source audio and video, or computer-generated source audio and video. The data source 211 may be any type of memory or storage for storing the above-mentioned source audio and video. The above-mentioned source audio and video may include multiple audio and video streams or images obtained by multiple audio and video acquisition devices (such as cameras), such as ultra high definition (UHD) video, high definition (HD) video, 4K video, etc.
[0085] The pre-processing module 212 is configured to receive source audio and video and pre-process the source audio and video to obtain audio and video or multiple frames of images. For example, the pre-processing performed by the pre-processing module 212 may include color format conversion (e.g., from RGB to YCbCr), octree structuring, audio and video splicing, audio track merging and deletion, or channel number adjustment.
[0086] The audio and video transmission adapter 213 is also referred to as a source adapter in this application, and is used to receive audio and video or images, and encode the audio and video, images or images to obtain coded data. In some optional situations, the code stream (coded data) obtained by encoding can also be called a bit stream. If the coded data is obtained by encoding audio and video data, then the bit stream refers to the audio and video stream.
[0087] The communication interface 214 in the source device 210 may be configured to receive encoded data (e.g., a video stream or an audio / video stream) and send the encoded data (or a version of the encoded data after any other processing) to another device such as the sink device 220 or any other device via a UMI bus for storage, display, playback, or image reconstruction.
[0088] Optionally, the source device 210 includes a bitstream buffer, which is used to store bitstreams corresponding to one or more coding units.
[0089] The sink device 220 can implement the audio and video decoding function. As shown in FIG1 , the sink device 220 can be any one of the smart TV 120 or the audio and video playback device shown in FIG1 .
[0090] The sink device 220 may include an audio and video playback unit 221 , a post-processing module 222 , an audio and video receiving adapter 223 , and a communication interface 224 .
[0091] The communication interface 224 in the sink device 220 is configured to receive the encoded data (or a version of the encoded data after any other processing has been performed on the encoded data) from the source device 210 or any other source device such as a storage device.
[0092] Communication interface 214 and communication interface 224 may be used to communicate via a direct communication link between source device 210 and sink device 220, such as a direct wired connection, as shown in the UMI bus in FIG2 . For details about the UMI bus, please refer to the description of FIG1 , and will not be repeated here.
[0093] The communication interface 224 corresponds to the communication interface 214 and can be used, for example, to receive transmission data and process the transmission data using any type of corresponding transmission decoding or processing and / or decapsulation to obtain encoded data (such as a video stream or an audio and video stream).
[0094] Both the communication interface 224 and the communication interface 214 may be configured as a unidirectional communication interface, as indicated by the arrow pointing from the source device 210 to the corresponding UMI bus of the sink device 220 in FIG2 , or a bidirectional communication interface, and may be used to send and receive messages, etc., to establish a connection, confirm and exchange any other information related to the communication link or data transmission, such as encoded compressed data transmission, etc.
[0095] The audio and video receiving adapter 223 is also referred to as a sink adapter in this application, and is used to receive encoded data and decode the encoded data to obtain decoded data (video or audio and video, etc.).
[0096] The post-processing module 222 is used to post-process the decoded data to obtain post-processed data (such as an image to be displayed or audio and video to be played). The post-processing performed by the post-processing module 222 may include, for example, color format conversion (such as from YCbCr to RGB), octree reconstruction, audio and video splitting and fusion, or any other processing for generating data for output by the audio and video playback unit 221.
[0097] The audio and video playback unit 221 is used to receive post-processed data for display or playback to a user or viewer. The audio and video playback unit 221 can be or include any type of display for representing the reconstructed image, such as an integrated or external display screen or display. For example, the display screen may include a liquid crystal display (LCD), an organic light emitting diode (OLED) display, a plasma display, a projector, a micro LED display, a liquid crystal on silicon (LCoS) display, a digital light processor (DLP), or any other type of display screen. The audio and video playback unit 221 can also include one or more audio and video playback modules, each of which can refer to a speaker, a smart speaker, an amplifier, or the like.
[0098] As an optional implementation, the source device 210 and the sink device 220 may transmit the encoded data via a data forwarding device. For example, the data forwarding device may be a router or a switch. It is worth noting that the data forwarding device must support the UMI interface.
[0099] Based on the video transmission system shown in FIG1 and the audio and video encoding and decoding system shown in FIG2 , FIG3 is a schematic diagram of a virtual path provided by the present application.
[0100] The communication link between communication interface 214 and communication interface 224, through multiple communication links between intermediate devices, forms the communication link between source device 210 and sink device 220. For example, taking source device 210 as device A, sink device 220 as device D, and intermediate devices including devices B and C, a virtual path is formed by cascading multiple virtual channels between adapter 4 of device A and adapter 5 of device D. This virtual path includes three virtual channels: a virtual channel with a virtual channel ID (shuttle ID) of 7 from device A to device B, a virtual channel with a virtual channel ID of 4 from device B to device C, and a virtual channel with a virtual channel ID of 13 between devices C and D. Port 2 of each device is a main downstream port (MDP), and port 1 of each device is a main upstream port (MUP). The downstream and upstream ports are connected via connectors and cables.
[0101] A virtual path can be represented by a quadruple. For example, the virtual path shown in FIG3 can be represented by (device A, adapter 4, device D, adapter 5).
[0102] The UMI bus supports multicast functionality. Data, audio and video streams, etc. generated by the same adapter can be transmitted to multiple adapters. As shown in Figure 4, the stream sent by adapter 4 of device A is received by adapter 7 of device B, adapter 6 of device C, and adapter 5 of device D at the same time. The corresponding three virtual paths are (device A, adapter 4, device B, adapter 7), (device A, adapter 4, device C, adapter 6), and (device A, adapter 4, device D, adapter 5).
[0103] The implementation of the virtual path removal method provided in the embodiment of the present application will be described in detail below with reference to the accompanying drawings.
[0104] Here, the virtual path removal method of the present application is described as being executed by the initiator device 210 and the target device 220 shown in FIG. 2 . FIG. 5 is a flow chart illustrating a first embodiment of the virtual path removal method provided by the present application. In this embodiment, the initiator device 51 is used to implement the functions of the source device 210, and the target device 52 is used to implement the functions of the sink device 220. In this embodiment, the initiator device 51 may also be referred to as a source device, an audio and video transmitter, or an audio and video transmitter, and the target device 52 may also be referred to as a sink device, a display device, an audio and video receiver, or an audio and video player. In this embodiment, the initiator device 51 and the target device 52 are connected via one or more intermediate devices 53 (only one intermediate device 53 is shown in FIG. 5 , but the number of intermediate devices is not limited). The initiator device 51, the intermediate device 53, and the target device 52 are connected via a bus 54, which may be a UMI bus. The virtual channels between the initiator device 51 and the intermediate device 53, and the virtual channels between the intermediate device 53 and the target device 52 constitute the virtual path.
[0105] In a first possible application scenario, the initiating device 51 may be the set-top box 110 in Figure 1, and the target device 52 may be the smart TV 120 in Figure 1. For example, the set-top box pushes audio and video data to the smart TV.
[0106] In a second possible application scenario, the initiating device 51 may be the set-top box 110 in FIG1 , and the target device 52 may be any audio and video playback device in FIG1 , such as any one of the audio and video playback devices 121 to 124. For example, the set-top box pushes audio and video data to the audio and video playback device.
[0107] In a third possible application scenario, the initiating device 51 may be the smart TV 120 in FIG1 , and the target device 52 may be any audio and video playback device in FIG1 , such as any one of the audio and video playback devices 121 to 124. For example, the smart TV pushes audio and video data to the audio and video playback device.
[0108] The above three possible application scenarios are merely examples provided in this embodiment and should not be construed as limiting the present application. In other possible examples, the initiating device 51 may be any of the audio and video playback devices in FIG1 (e.g., audio and video playback device 121), and the target device 52 may be another audio and video playback device different from the aforementioned audio and video playback device (e.g., audio and video playback device 122).
[0109] Referring to FIG. 5 , the virtual path removal method provided in this embodiment includes the following steps 501 to 518 .
[0110] Step 501: The initiating device 51 generates a bandwidth release request.
[0111] The initiating device 51 generates a bandwidth release request based on changes in the audio and video service flow. For example, if the audio and video service stops, or if a device on the virtual path used to transmit the audio and video service flow is detected to be lost, the bandwidth release request message must be initiated by the source device of the corresponding flow. For example, an audio and video service flow must be initiated by the device containing the audio and video transmission adapter that transmits the video, and a USB service flow must be initiated by the device containing the USB tunnel adapter connected to the USB host.
[0112] The bandwidth release request includes a second virtual channel identifier, which is used to indicate the upper-level virtual channel of the first virtual channel. The bandwidth release request may also include a second outbound port number, etc.
[0113] As a possible implementation manner, the message structure of the bandwidth release request is shown in Table 1.
[0114] Table 1
[0115] Optionally, the message structure of the message header is as shown in Table 2.
[0116] Table 2
[0117] In the message header of the bandwidth release request, the Type value is 7, indicating that the message type is bandwidth release. The Response value is 0, indicating that it is a request message.
[0118] Optionally, the message structure of the general field is as shown in Table 3.
[0119] Table 3
[0120] In the general field of the bandwidth release request, Channel ShuttleID is assigned as the second virtual channel identifier.
[0121] Optionally, the addressing information requested by the bandwidth device is forwarding list addressing information, or referred to as forwarding list addressing, or addressing information. The message structure of the forwarding list addressing information is shown in Table 4.
[0122] Table 4
[0123] The Forwarding List Level of the bandwidth release request is used to indicate the current level, and the corresponding port number in the port number of the level is the port number for the current device to send the bandwidth release request, that is, the second outbound port number.
[0124] In a possible embodiment, the forwarding list addressing information does not include the port number from which the initiating device 51 sends the bandwidth release request. The initiating device 51 can determine the port number from which the bandwidth release request is sent, i.e., the second outbound port number, based on internal device addressing. For example, the initiating device 51 maintains service flow information, which includes the input port number, source device address, source adapter identifier, output port number, destination device address, destination adapter identifier, bandwidth value, and priority. The initiating device 51 uses the source device address and destination device address of the bandwidth release request to query the service flow information for the output port number, i.e., the second outbound port number.
[0125] Step 502: The initiating device 51 configures an identifier of a forwarding entry of an outgoing flow node.
[0126] As a possible implementation method, when the second outgoing port number is in the router forwarding table corresponding to the audio and video service flow, the initiating device 51 reduces the first multicast count value of the outgoing node by one, and sets the identifier of the forwarding entry corresponding to the second virtual channel identifier in the router forwarding table to the first identifier.
[0127] Alternatively, a router forwarding table is used to indicate the forwarding rule of message between different virtual channels in this device, and a router forwarding table comprises one or more forwarding entries (or router forwarding table items). As shown in Table 5, the router forwarding table is composed of inflow information and outflow information, and a router forwarding table item can be represented by {inflow information|outflow information}. Wherein the inflow information is composed of the information of a single inflow node, and the outflow information is composed of the information of one or more outflow nodes. The information of the inflow node mainly describes the port and the virtual channel (such as port number and virtual channel mark) corresponding to the inflow, and the information of the outflow node mainly describes the relevant information such as the target port and the target virtual channel (such as port number and virtual channel mark) of the forwarding of the message. For example, the first router forwarding entry in Table 5 can be represented as {[0,4]|[2,4]}. The inbound flow information contains only one inbound node, [0,4], indicating that the flow receives packets from the receive buffer of adapter 4 on this router. The outbound flow information contains one outbound node, [2,4], indicating that the flow packet needs to be forwarded to virtual channel 4 on port 2. The virtual channel ID in the inbound node information of the inbound flow information is equivalent to the adapter ID (AdapterID). An inbound node can also be called an inbound node, and an outbound node can also be called an outbound node.
[0128] Table 5
[0129] In a multicast scenario, if one or more devices on the same destination port receive the stream corresponding to the same virtual channel, a multicast count (ReceiverCount) is added to the outbound node to facilitate router forwarding table management. The outbound node is represented by a triplet of [port number (Port), virtual channel identifier (ShuttleID), multicast count (ReceiverCount)]. The multicast count indicates the number of destination devices receiving the audio and video service stream on the output port (also called the outbound port).
[0130] For example, based on the router forwarding table shown in Table 5 above, after the initiating device 51 determines the second outgoing port number 2, it queries the output port number in the router forwarding table according to the virtual channel identifier 4 of the audio and video service flow, that is, the second virtual channel identifier, and obtains the information that the outgoing node corresponding to the virtual channel identifier 4 is forwarded by port 2, then determines that the initiating device 51 is in the router forwarding table corresponding to the audio and video service flow in the second outgoing port number.
[0131] Optionally, the forwarding entry corresponding to the second virtual channel identifier in the router forwarding table refers to the forwarding entry containing the information of the outgoing node of the second virtual channel identifier. For example, if the second virtual channel identifier is virtual channel identifier 4, the corresponding forwarding entry is a forwarding entry consisting of the inbound information [0, 4] and the outbound information [2, 4]. The identifier of the forwarding entry can refer to the domain identifier (FwVID) of the forwarding entry, which is used to indicate the validity of the forwarding entry. For example, if the identifier of the forwarding entry is the first identifier, it indicates that the forwarding entry is invalid. The first identifier can be any character such as 0 or 1.
[0132] As another possible implementation method, when the second outgoing port number is in the router forwarding table corresponding to the audio and video service flow, the initiating device 51 subtracts one from the first multicast count value of the outgoing node, and when the first multicast count value is equal to zero, sets the service flow identifier (VID) of the audio and video service flow to the second identifier.
[0133] Optionally, the service flow identifier of the audio or video service flow is a second identifier, indicating that the identifiers of all forwarding entries corresponding to the audio or video service flow are the second identifier. For example, when the service flow identifier of the audio or video service flow is the second identifier, it indicates that all forwarding entries corresponding to the audio or video service flow are invalid. The second identifier can be any character such as 0 or 1. The first identifier and the second identifier can be the same or different.
[0134] Step 503: The initiating device 51 sends the configuration information to the transport layer.
[0135] The configuration information may be as shown in Table 6 below.
[0136] Table 6
[0137] Step 504: The initiating device 51 sends a bandwidth release request.
[0138] As a possible implementation manner, the initiating device 51 forwards the bandwidth release request according to the forwarding list addressing information of the bandwidth release request.
[0139] Step 505: The intermediate device 53 receives a bandwidth release request.
[0140] The bandwidth release request includes the second virtual channel identifier.
[0141] Step 506: The intermediate device 53 configures the identifier of the forwarding entry of the outgoing flow node.
[0142] As a possible implementation method, the intermediate device 53 determines the output port number based on the forwarding list addressing information carried by the bandwidth release request, and determines whether the output port number is in the router forwarding table of the audio and video service flow based on the second virtual channel identifier in the router forwarding table. The subsequent processing method is as shown in step 502 and will not be repeated here.
[0143] Step 507: The intermediate device 53 sends the configuration information to the transport layer.
[0144] As a possible implementation manner, the processing manner in which the intermediate device 53 sends the configuration information to the transport layer is shown in step 503 and will not be repeated here.
[0145] Step 508: The intermediate device 53 sends a bandwidth release request.
[0146] As a possible implementation, the intermediate device 53 replaces the virtual channel identifier in the general field of the bandwidth release request with the virtual channel identifier of the next virtual channel in the virtual path, that is, replaces the second virtual channel identifier with the first virtual channel identifier, and then sends the bandwidth release request.
[0147] Optionally, the intermediate device 53 updates the forwarding list addressing information, and sends a bandwidth release request according to the updated forwarding list addressing information.
[0148] Step 509: The target device 52 receives the bandwidth release request.
[0149] The bandwidth release request includes a third virtual channel identifier. When the target device 52 receives the bandwidth release request from the initiating device 51 through one intermediate device 53, the third virtual channel identifier is the same as the first virtual channel identifier. When the target device 52 receives the bandwidth release request from the initiating device 51 through multiple intermediate devices 53, the third virtual channel identifier is the virtual channel identifier of the virtual channel between the target device 52 and the upper-level device in the virtual path.
[0150] Step 510: The target device 52 configures the identifier of the forwarding entry of the outgoing flow node.
[0151] As a possible implementation manner, the processing manner of configuring the identifier of the forwarding entry of the outgoing flow node by the target device 52 is as shown in step 506, which will not be repeated here.
[0152] Step 511: The target device 52 sends the configuration information to the transport layer.
[0153] As a possible implementation manner, the processing manner in which the target device 52 sends the configuration information to the transport layer is shown in step 503 and will not be repeated here.
[0154] Step 512: The target device 52 refreshes the adapter binding information.
[0155] Adapter binding information is used to indicate that two adapters have been bound (or paired). The bound adapters lock some resources (such as bandwidth) between them to establish a virtual path. For example, the adapter binding information of the target device 52 includes the identifier of the audio and video transmission adapter 213, which is used to indicate that the audio and video receiving adapter 223 of the target device is bound to the audio and video transmission adapter 213.
[0156] Step 513: The target device 52 sends a bandwidth release response.
[0157] The bandwidth release response includes the third virtual channel identifier.
[0158] As a possible implementation, the message structure of the bandwidth release response is shown in Table 7 below.
[0159] Table 7
[0160] The structures of the fields in Table 7 are similar to those in the bandwidth release request. The differences are that in the bandwidth release response header, the value of Response is 1, indicating that it is a request message; and the value of Channel ShuttleID in the general field is assigned to the third virtual channel identifier. These are adaptive content adjustments between the request and response and are not further described here.
[0161] Optionally, the bandwidth release response also includes a message identifier (tag). For the same management message, the tags of the request and response are consistent. Therefore, when the bandwidth release response is forwarded in the virtual path, the device can perform path identification based on the virtual channel identifier and message identifier carried by the bandwidth release response to determine the output port of the bandwidth release response.
[0162] Step 514: The intermediate device 53 receives a bandwidth release response.
[0163] The bandwidth release response includes a third virtual channel identifier. In this embodiment, when the target device 52 receives the bandwidth release request from the initiating device 51 through an intermediate device 53, the third virtual channel identifier is the same as the first virtual channel identifier. In another possible embodiment, when the target device 52 receives the bandwidth release request from the initiating device 51 through multiple intermediate devices 53, and the bandwidth release response is forwarded by another intermediate device 53, the third virtual channel identifier is the virtual channel identifier of the virtual channel between the intermediate device 53 and the next-level device in the virtual path.
[0164] Step 515 : In response to the bandwidth release response, the intermediate device 53 removes the third virtual channel corresponding to the third virtual channel identifier.
[0165] As a possible implementation method, the intermediate device 53 determines whether the first multicast count value of the flow node is equal to zero. If so, the third virtual channel corresponding to the third virtual channel identifier is dismantled, including: starting to release the transport layer flow control cache, and waiting for the release to complete the bandwidth value release.
[0166] Optionally, the bandwidth value release completed by the intermediate device 53 is to release the bandwidth value allocated to the third virtual channel corresponding to the third virtual channel identifier, that is, to release the outbound bandwidth value on the output port corresponding to the third virtual channel identifier.
[0167] As a possible implementation, when the first multicast count value of the outgoing node is not zero (greater than zero), the intermediate device removes the third virtual channel corresponding to the third virtual channel identifier, including clearing adapter binding information.
[0168] Optionally, the adapter binding information cleared by the intermediate device 53 is binding information between the adapter of the intermediate device and the adapter of the next-level device in the virtual path, or binding information between the adapter of the target device 52 and the adapter of the initiator device 51 .
[0169] In a possible embodiment of the present application, if the audio and video service flow is a bidirectional service flow, or for a USB service flow, it is necessary to release both the outgoing and incoming bandwidths at the same time. In addition to releasing the outgoing bandwidth for the output port, the intermediate device also needs to release the outgoing bandwidth for the input port. The rules and procedures for bandwidth release are the same as above.
[0170] Step 516: The intermediate device 53 sends a bandwidth release response.
[0171] As a possible implementation, the intermediate device 53 replaces the third virtual channel identifier with the virtual channel identifier of the upper-level virtual channel of the third virtual channel in the virtual path, updates the message identifier, and then sends the updated bandwidth release response.
[0172] In this embodiment, when the target device 52 receives the bandwidth release request from the initiating device 51 through an intermediate device 53, the virtual channel identifier of the upper-level virtual channel of the third virtual channel is the identifier of the virtual channel between the initiating device 51 and the intermediate device 53, that is, the second virtual channel identifier.
[0173] Step 517: The initiating device 51 receives a bandwidth release response.
[0174] Step 518: In response to the bandwidth release response, the initiating device 51 removes the second virtual channel corresponding to the second virtual channel identifier.
[0175] As a possible implementation manner, the processing manner of the initiating device 51 to remove the second virtual channel is shown in step 515, which will not be described in detail here.
[0176] Based on the above steps 501 to 518, in the audio and video transmission network, each device uses the virtual channel identifier to identify the path and specify the virtual channel. Without changing the physical connection relationship between the devices, the virtual channel corresponding to the specified virtual path can be dismantled, thereby improving the flexibility of dismantling the transmission path of the audio and video business flow, facilitating the path switching of the audio and video business flow, and thus improving the overall networking flexibility for the audio and video business flow.
[0177] The above description of the virtual path removal method is generally described in conjunction with FIG5 , and is applicable to scenarios where the communication function of the virtual path between the initiating device and the target device is normal. In a scenario that may occur in reality, as shown in FIG6 , a virtual path exists between the initiating device, intermediate device A, intermediate device B, intermediate device C, and the target device. When the port between intermediate device A and intermediate device B is disconnected (for example, the port is unplugged), the initiating device recognizes the topology change and needs to send a bandwidth release request to intermediate device A to remove the virtual path between the initiating device and intermediate device A. Intermediate device B needs to send a path removal request to the target device to remove the virtual path between intermediate device B and the target device.
[0178] The above-mentioned process of the initiating device sending a bandwidth release request to intermediate device A to remove the virtual channel between the initiating device and intermediate device A is similar to the processing principle of the bandwidth release request and bandwidth release response in steps 501 to 518 shown in Figure 5, and will not be repeated here. The overall process of the intermediate device B sending a path disconnect request to the target device to disconnect the virtual channel between intermediate device B and the target device will be described below with reference to Figure 7.
[0179] Initiating device 71 implements the functions of intermediate device B, and target device 72 implements the functions of sink device 220. In this embodiment, target device 72 may also be referred to as a sink device, a display device, an audio / video receiving device, or an audio / video playback device. In this embodiment, initiating device 71 and target device 72 are connected via one or more intermediate devices 53 (Figure 5 shows only one intermediate device 53, intermediate device C, but the number of intermediate devices is not limited). Initiating device 71, intermediate device 73, and target device 72 are connected via bus 74, which may be a UMI bus. The virtual channels between initiating device 71 and intermediate device 73, and the virtual channels between intermediate device 73 and target device 72 constitute a virtual path.
[0180] Referring to FIG. 7 , the virtual path removal method provided in this embodiment includes the following steps 701 to 712 .
[0181] Step 701: When the initiator 71 detects a port disconnection event, it extracts the forward flow passing through the disconnected port.
[0182] The forward flow refers to the flow in which the port receives bandwidth request messages.
[0183] Step 702: The initiating device 71 generates a path teardown request according to the forward flow.
[0184] The initiating device 71 queries the outgoing port number (OutPortID) and the virtual channel identifier of the forward flow according to the incoming port number (InportID) and the virtual channel identifier, and generates a path removal request including the retrieved virtual channel identifier.
[0185] The path removal request is used to remove the service virtual path, complete bandwidth release and service virtual path destruction.
[0186] As a possible implementation, initiating device 71 uses the inbound port number of the forward flow as the port number in the inbound node information in the router forwarding table, and uses the virtual channel identifier of the forward flow as the virtual channel identifier in the inbound node information in the router forwarding table. It then searches the router forwarding table for the corresponding outbound flow information to obtain the port number and virtual channel identifier in the outbound node information. The retrieved port number and virtual channel identifier are used as the outbound port number and virtual channel identifier for the path teardown request. In a possible embodiment of the present application, the retrieved virtual channel identifier can be referred to as a fifth virtual channel identifier.
[0187] As a possible implementation, the message structure of the bandwidth release request is shown in Table 8.
[0188] Table 8
[0189] The message structure of the message header in Table 8 is similar to that in Table 2, and the message structure of the general field is similar to that in Table 3, which will not be repeated here.
[0190] In the message header of the Channel Shuttle Request, the Type field is set to 8, indicating that the message type is a Channel Shuttle. The Response field is set to 0, indicating that it is a request message. In the general field of the Channel Shuttle Response, the Channel ShuttleID field is assigned the fifth virtual channel identifier.
[0191] Step 703: The initiating device 71 sends a path removal request.
[0192] As a possible implementation, if the device is a multicast point, a path removal request needs to be sent to all multicast output ports. If the outgoing port is disconnected, the path removal request is processed within the management adapter of the device.
[0193] Optionally, the initiating device 71 sends the path teardown request using a virtual path addressing method. This virtual path addressing method means that upon receiving a path teardown request, each device on the virtual path searches the router forwarding table for information about the corresponding outbound node, namely, the outbound port number and virtual channel identifier, based on the inbound port and virtual channel identifier of the path teardown request. The device then replaces the virtual channel identifier carried in the path teardown request with the retrieved virtual channel identifier and sends the path teardown request using the outbound port number.
[0194] Step 704: The intermediate device 73 receives a path removal request.
[0195] The path teardown request includes the fifth virtual path identifier. The fifth virtual path identifier is used for the virtual path between the intermediate device 73 and the upper-level device in the virtual path.
[0196] When receiving the path removal request, the intermediate device 73 records the inflow port number of the path removal request.
[0197] Step 705: The intermediate device 73 sends a path removal request.
[0198] As a possible implementation, the intermediate device 73 searches the router forwarding table for the outbound port number and virtual channel identifier of the received path teardown request based on the inbound port number and the fifth virtual channel identifier, obtains the third outbound port number and the fourth virtual channel identifier, and sends the path teardown request through the third outbound port corresponding to the third outbound port number. The sent path teardown request includes the fourth virtual channel identifier.
[0199] In another possible embodiment, when a certain outbound port is unplugged, the intermediate device 73 carries the anchor count value in the information of the outbound node corresponding to the outbound port, assigns the ErrorCode in the message body to 0x4 (invalid path), and directly returns a path dismantling response.
[0200] Step 706: The target device 72 receives the path teardown request.
[0201] The path teardown request includes a sixth virtual channel identifier. When target device 72 receives the path teardown request from initiating device 71 via one intermediate device 73, the sixth virtual channel identifier is the same as the fourth virtual channel identifier. When target device 72 receives bandwidth release requests from initiating device 71 via multiple intermediate devices 73, the sixth virtual channel identifier is the virtual channel identifier of the virtual channel between target device 72 and the upper-level device in the virtual path.
[0202] When receiving the path teardown request, the target device 72 records the inflow port number of the path teardown request.
[0203] Step 707: The target device 72 sends a path teardown response.
[0204] The target device 72 queries its outbound port number and virtual channel identifier in the router forwarding table based on the inbound port number and the sixth virtual channel identifier of the received path demolition request, and obtains the information of the outbound node corresponding to the outbound port. The information of the outbound node includes the third multicast count value of the outbound node.
[0205] In this embodiment, when the target device 72 receives the path teardown request from the initiating device 71 through an intermediate device 73, the virtual channel identifier of the upper-level virtual channel of the sixth virtual channel is the identifier of the virtual channel between the initiating device 71 and the intermediate device 73, that is, the fifth virtual channel identifier.
[0206] The target device 72 uses the inbound port number of the received path teardown request as the outbound port number of the path teardown response and sends the path teardown response. The path teardown response sent by the target device 72 includes the sixth virtual channel identifier and the third multicast count value.
[0207] As a possible implementation, the message structure of the path teardown response is shown in Table 9 below.
[0208] Table 9
[0209] The message structure of the message header in Table 9 is similar to that in Table 2, and the message structure of the general field is similar to that in Table 3, which will not be repeated here.
[0210] In the message header of the Channel Dismantle Response, the Type field is set to 8, indicating that the message type is a Channel Dismantle message. The Response field is set to 1, indicating that it is a response message. In the general field of the Channel Dismantle Response, the Channel ShuttleID field is assigned the sixth virtual channel identifier.
[0211] Step 708: The intermediate device 73 receives the path teardown response.
[0212] Step 709 : The intermediate device 73 removes the sixth virtual channel corresponding to the sixth virtual channel identifier in response to the path removal response.
[0213] As a possible implementation, the third multicast count value carried in the path teardown response is subtracted from the multicast count value of the audio and video service flow corresponding to the current port (i.e., the outbound port of the current device). When the multicast count value corresponding to the audio and video service flow of the current port of the current device reaches zero, the sixth virtual channel corresponding to the sixth virtual channel identifier is torn down. This includes initiating the release of the transport layer flow control buffer, waiting for the release to complete before releasing the bandwidth value, and sending configuration information to the transport layer. This configuration information can be found in Table 6 and is not further described here.
[0214] Optionally, the bandwidth value release performed by the intermediate device 73 is to release the bandwidth value allocated to the sixth virtual channel corresponding to the sixth virtual channel identifier, that is, to release the outbound bandwidth value on the output port corresponding to the sixth virtual channel identifier.
[0215] Optionally, when the next-level device of the intermediate device 73 in the virtual path is another intermediate device, the second multicast count value carried in the path demolition response is used to indicate the multicast count value of the audio and video service flow corresponding to the outgoing port of the next-level device, which may be different from the third multicast count value.
[0216] As another possible implementation, when the multicast count value of the audio and video service flow corresponding to the outgoing port of the device has not decreased to zero, the sixth virtual channel is not removed.
[0217] In a possible embodiment of the present application, if the audio and video service flow is a bidirectional service flow, or for a USB service flow, it is necessary to release both the outgoing and incoming bandwidths at the same time. In addition to releasing the outgoing bandwidth for the output port, the intermediate device also needs to release the outgoing bandwidth for the input port. The rules and procedures for bandwidth release are the same as above.
[0218] Step 710: The intermediate device 73 sends a path teardown response.
[0219] Intermediate device 73 searches the router forwarding table for the outbound port number and virtual channel identifier based on the inbound port and the sixth virtual channel identifier of the path teardown response, obtains the second inbound port number and the fifth virtual channel identifier, and sends the path teardown response through the second inbound port corresponding to the second inbound port number. The sent path teardown response includes the fifth virtual channel identifier.
[0220] In a possible embodiment of the present application, the second inflow port number refers to the outflow port in the reverse flow in the opposite direction of the forward flow. For the same port, the inflow port of the forward flow can be the outflow port of the reverse flow, and the outflow port of the forward flow can be the inflow port of the reverse flow. The reverse flow is the flow for which this port receives a bandwidth request response.
[0221] Step 711: The initiating device 71 receives a path teardown response.
[0222] Step 712: In response to the path removal response, the initiating device 71 removes the fifth virtual channel corresponding to the fifth virtual channel identifier.
[0223] As a possible implementation manner, the processing manner of the initiating device 71 to remove the fifth virtual channel is shown in step 709 and will not be repeated here.
[0224] Steps 701-712 above describe a scenario where a port between two intermediate devices is disconnected. In a possible embodiment of the present application, when source device 210 is disconnected from a port of a lower-level device in a virtual path, the service flow identifier of the audio and video service flow corresponding to the virtual channel identifier output through the disconnected port is set to the second identifier, the forwarding entry identifier is set to the first identifier, and this information is sent to the transport layer, initiating bandwidth release for the corresponding service flow and waiting for the transport layer to release the flow control buffer. When sink device 220 is disconnected from a port of a higher-level device in a virtual path, the processing is similar to the processing for disconnecting a port between source device 210 and a lower-level device in the virtual path, and will not be further described here.
[0225] Based on the above steps 701 to 712, when a port of a device in a virtual path is disconnected and the intermediate device is unable to forward a bandwidth release request to the target device, a path removal response can also be forwarded to the intermediate device through virtual path addressing using the virtual channel identifier to instruct the intermediate device to remove the virtual channel, thereby realizing virtual path removal in the scenario where a port of the virtual path is disconnected, avoiding the inability to release the bandwidth of the invalid virtual path, and improving bandwidth utilization.
[0226] The above describes the overall process of the virtual path removal method in detail. Next, the sending and receiving of bandwidth release requests and bandwidth release responses in the virtual path removal method will be described with the initiating device, intermediate device, and target device as the execution entities.
[0227] The virtual path removal method shown in FIG8 a includes the following steps 801 to 806 .
[0228] Step 801: The target device sends a bandwidth release response.
[0229] Please refer to step 513 for the specific processing method of this step, which will not be repeated here.
[0230] Step 802: The intermediate device receives a bandwidth release response.
[0231] Please refer to step 514 for the specific processing method of this step, which will not be repeated here.
[0232] Step 803: The intermediate device removes the virtual channel in response to the bandwidth release response. The specific processing method of this step is referred to step 515 and will not be described in detail here.
[0233] Step 804: The intermediate device sends a bandwidth release response.
[0234] Please refer to step 516 for the specific processing method of this step, which will not be repeated here.
[0235] Step 805: The initiating device receives a bandwidth release response.
[0236] For the specific processing method of this step, please refer to step 517 and will not be repeated here.
[0237] Step 806: The initiating device removes the virtual channel in response to the bandwidth release response.
[0238] Please refer to step 518 for the specific processing method of this step, which will not be repeated here.
[0239] Before the above steps 801 to 806 , the virtual path removal method may further include the following steps 807 to 812 .
[0240] Step 807: The initiating device sends a bandwidth release request.
[0241] For the specific processing method of this step, please refer to step 504.
[0242] Step 808: The intermediate device receives the bandwidth release request.
[0243] Please refer to step 505 for the specific processing method of this step, which will not be repeated here.
[0244] Step 809: The intermediate device performs configuration in response to the bandwidth release request.
[0245] For the specific processing method of this step, please refer to steps 506 and 507, which will not be repeated here.
[0246] Step 810: The intermediate device sends a bandwidth release request.
[0247] Please refer to step 508 for the specific processing method of this step, which will not be repeated here.
[0248] Step 811: The target device receives a bandwidth release request.
[0249] Please refer to step 509 for the specific processing method of this step, which will not be repeated here.
[0250] Step 812: The target device performs configuration in response to the bandwidth release request.
[0251] For the specific processing method of this step, please refer to steps 510 to 512, which will not be repeated here.
[0252] Next, the sending and receiving of the path teardown request and the path teardown response in the virtual path teardown method will be described with the intermediate device and the target device as the execution subjects.
[0253] The virtual path removal method shown in FIG8 b includes the following steps 901 to 906 .
[0254] Step 901: The target device sends a path teardown response.
[0255] Please refer to step 707 for the specific processing method of this step, which will not be repeated here.
[0256] Step 902: The intermediate device receives a path teardown response.
[0257] Please refer to step 708 for the specific processing method of this step, which will not be repeated here.
[0258] Step 903: The intermediate device removes the virtual channel in response to the path removal response.
[0259] Please refer to step 709 for the specific processing method of this step, which will not be repeated here.
[0260] Step 904: The intermediate device sends a path teardown response.
[0261] Please refer to step 710 for the specific processing method of this step, which will not be repeated here.
[0262] Step 905: The initiating device receives a path removal response.
[0263] Please refer to step 711 for the specific processing method of this step, which will not be repeated here.
[0264] Step 906: The initiating device removes the virtual channel in response to the path removal response.
[0265] Please refer to step 712 for the specific processing method of this step, which will not be repeated here.
[0266] Before the above steps 901 to 906 , the virtual path removal method may further include the following steps 907 to 910 .
[0267] Step 907: The initiating device sends a path removal request.
[0268] Please refer to step 703 for the specific processing method of this step, which will not be repeated here.
[0269] Step 908: The intermediate device receives the path teardown request.
[0270] Please refer to step 704 for the specific processing method of this step, which will not be repeated here.
[0271] Step 909: The intermediate device sends a path teardown request.
[0272] Please refer to step 705 for the specific processing method of this step, which will not be repeated here.
[0273] Step 910: The target device receives a path teardown request.
[0274] Please refer to step 706 for the specific processing method of this step, which will not be repeated here.
[0275] It is understood that in order to implement the functions in the above embodiments, the source device and the sink device include hardware structures and / or software modules corresponding to the execution of each function. Those skilled in the art should readily appreciate that, in combination with the units and method steps of the various examples described in the embodiments disclosed in this application, this application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a function is executed in hardware or in a manner driven by computer software depends on the specific application scenario and design constraints of the technical solution.
[0276] The above description describes in detail the virtual path removal method provided in accordance with the present embodiment in conjunction with FIG. 1 to FIG. 7 , and FIG. 8 a and FIG. 8 b . The following description will describe the virtual path removal device provided in accordance with the present embodiment in conjunction with FIG. 9 .
[0277] Fig. 9 is a schematic structural diagram of a virtual path removal device provided by the present application. The virtual path removal device 900 can be used to implement the function of any one of the devices in the above-mentioned method embodiment, and therefore can also achieve the beneficial effects possessed by the above-mentioned method embodiment. In the present embodiment, the virtual path removal device 900 can be a set-top box 110, a smart TV 120 or any display device as shown in Figure 1, or it can be a source device 210 or a sink device 220 as shown in Figure 2, or it can be a multimedia device or a display device provided by subsequent embodiments. It should be understood that the virtual path removal device 900 can also be a module (such as a chip) applied to any of the aforementioned devices.
[0278] As shown in Figure 9, the virtual path removal device 900 includes a transceiver module 910 and a processing module 920. Transceiver module 910 and processing module 920 can collaboratively implement the various steps in the aforementioned method embodiment. A more detailed description of transceiver module 910 and processing module 920 can be directly obtained by referring to the relevant description of the device in the method embodiment shown in the aforementioned figures, and will not be repeated here.
[0279] When the virtual path removal device 900 implements any of the virtual path removal methods shown in the aforementioned figures through software, the virtual path removal device 900 and its various units may also be software modules. The aforementioned virtual path removal method is implemented by invoking the software module via a processor. The processor may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or a programmable logic device (PLD). The PLD may be a complex programmable logical device (CPLD), a field programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof.
[0280] It can be understood that the virtual path removal device shown in FIG9 is only an example provided in this embodiment. The virtual path removal device may include more or fewer units according to different audio and video service flow transmission processes, and this application does not limit this.
[0281] When the virtual path removal device 900 is implemented via hardware, the hardware can be implemented via a processor or a chip system. The chip system includes one or more chips, each of which includes an interface circuit and a control circuit. The interface circuit is used to receive data from other devices outside the chip and transmit it to the control circuit, or to send data from the control circuit to other devices outside the chip. The control circuit and the interface circuit are used to implement the method of any possible implementation method in the above-mentioned embodiments through logic circuits or execution code instructions. The beneficial effects can be found in the description of any aspect of the above-mentioned embodiments and will not be repeated here.
[0282] It is understood that the processor in the embodiments of the present application may be a CPU, or other general-purpose processor, digital signal processor (DSP), ASIC, FPGA or other programmable logic device, transistor logic device, hardware component or any combination thereof. The general-purpose processor may be a microprocessor or any conventional processor.
[0283] In addition, the virtual path removal device 900 shown in FIG9 can also be implemented by a multimedia device, as shown in FIG10, which is a schematic structural diagram of the multimedia device provided by the present application. The multimedia device includes: a processor 1010, an external memory interface 1020, an internal memory 1021, a universal serial bus (USB) interface 1030, a UMI interface 1031, antenna 1, antenna 2, a mobile communication module 1050, a wireless communication module 1060, an audio module 1070, a speaker 1070A, a receiver 1070B, a microphone 1070C, a sensor module 1080, a button 1090, an indicator 1092, a camera 1093, a display screen 1094, and subscriber identification module (SIM) card interfaces 1-N 1095.
[0284] Among them, the above-mentioned sensor module 1080 may include sensors such as pressure sensor, gyroscope sensor, air pressure sensor, magnetic sensor, acceleration sensor, distance sensor, proximity light sensor, fingerprint sensor, temperature sensor, touch sensor, ambient light sensor and bone conduction sensor.
[0285] It is understood that the structure illustrated in this embodiment does not constitute a specific limitation on the multimedia device. In other embodiments, the multimedia device may include more or fewer components than shown, or combine or separate certain components, or arrange the components differently. The components shown in the figure may be implemented in hardware, software, or a combination of software and hardware.
[0286] The multimedia device shown in FIG10 may be any device in FIG1 , or a source device or a sink device in subsequent embodiments.
[0287] The processor 1010 may include one or more processing units. For example, the processor 1010 may include an application processor (AP), a modem processor, a graphics processing unit (GPU), an image signal processor (ISP), a controller, a memory, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural-network processing unit (NPU). The different processing units may be independent devices or integrated into one or more processors.
[0288] The controller can be the nerve center and command center of the multimedia device. The controller can generate operation control signals based on instruction opcodes and timing signals to complete the control of instruction fetching and execution.
[0289] Processor 1010 may also include a memory for storing instructions and data. In some embodiments, the memory in processor 1010 is a cache memory. This memory can store instructions or data that have just been used or are being recycled by processor 1010. If processor 1010 needs to use the same instruction or data again, it can directly access the memory. This avoids duplicate accesses, reduces processor 1010 latency, and thus improves system efficiency.
[0290] In some embodiments, the processor 1010 may include one or more interfaces. The interfaces may include an inter-integrated circuit (I2C) interface, an inter-integrated circuit sound (I2S) interface, a pulse code modulation (PCM) interface, a universal asynchronous receiver / transmitter (UART) interface, a mobile industry processor interface (MIPI), a general-purpose input / output (GPIO) interface, a subscriber identity module (SIM) interface, and / or a USB interface, a UMI interface, etc.
[0291] It is understood that the interface connection relationship between the modules illustrated in this embodiment is merely a schematic illustration and does not constitute a structural limitation on the multimedia device. In other embodiments, the multimedia device may also adopt a different interface connection method from the above embodiment, or a combination of multiple interface connection methods.
[0292] The wireless communication function of the multimedia device can be implemented through antenna 1, antenna 2, mobile communication module 1050, wireless communication module 1060, modem processor, and baseband processor. In some embodiments, antenna 1 of the multimedia device is coupled to mobile communication module 1050, and antenna 2 is coupled to wireless communication module 1060, so that the multimedia device can communicate with the network and other devices through wireless communication technology.
[0293] The wired communication function of the multimedia device can be implemented through the USB interface 1030 or the UMI interface 1031. For example, the multimedia device receives or sends video streams and AVP messages through the bus connected to the UMI interface 1031.
[0294] The multimedia device implements display functions through a GPU, display screen 1094, and an application processor. A GPU is a microprocessor for image processing that connects display screen 1094 and the application processor. The GPU is used to perform mathematical and geometric calculations for graphics rendering. Processor 1010 may include one or more GPUs that execute program instructions to generate or modify display information.
[0295] The display screen 1094 is used to display images, videos, etc. The display screen 1094 includes a display panel.
[0296] The multimedia device can implement a camera function through an ISP, a camera 1093, a video codec, a GPU, a display 1094, and an application processor. The ISP processes data fed back by the camera 1093. The camera 1093 is used to capture still images or videos. In some embodiments, the multimedia device may include one or N cameras 1093, where N is a positive integer greater than 1.
[0297] In this embodiment, the above display screen 1094, video codec, GPU, display screen 1094 and application processor can also be collectively referred to as the display unit of the multimedia device, which is used to process and display the received multimedia data stream (such as video stream).
[0298] External memory interface 1020 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the multimedia device. The external memory card communicates with processor 1010 via external memory interface 1020 to implement data storage functions. For example, files such as music and videos can be stored on the external memory card.
[0299] The internal memory 1021 can be used to store computer executable program code, which includes instructions. The processor 1010 executes various functional applications and data processing of the multimedia device by running the instructions stored in the internal memory 10101. For example, in an embodiment of the present application, the processor 210 can execute instructions stored in the internal memory 1021, and the internal memory 1021 can include a program storage area and a data storage area.
[0300] The program storage area may store an operating system and at least one application required for a function (such as a sound playback function, an image playback function, etc.). The data storage area may store data created during the use of the multimedia device (such as audio and video data, a phone book, etc.). In addition, the internal memory 1021 may include high-speed random access memory and non-volatile memory, such as at least one disk storage device, a flash memory device, or a universal flash storage (UFS).
[0301] The multimedia device can implement audio functions such as music playback and recording through the audio module 1070, the speaker 1070A, the receiver 1070B, the microphone 1070C, and the application processor.
[0302] Buttons 1090 include a power button, a volume button, and the like. Buttons 1090 may be mechanical buttons or touch buttons. Indicator 1092 may be an indicator light that can be used to indicate charging status, battery level changes, messages, missed calls, notifications, and the like.
[0303] The method steps in the embodiments of the present application can also be implemented by a processor executing software instructions. The software instructions can be composed of corresponding software modules, which can be stored in random access memory (RAM), flash memory, read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), registers, hard disks, mobile hard disks, CD-ROMs, or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor so that the processor can read information from the storage medium and write information to the storage medium. Of course, the storage medium can also be an integral part of the processor. The processor and storage medium can be located in an ASIC. In addition, the ASIC can be located in a network device or a terminal device. Of course, the processor and storage medium can also exist as discrete components in a video processing device and a multimedia device.
[0304] In the above embodiments, all or part of the embodiments can be implemented by software, hardware, firmware or any combination thereof. When implemented using software, all or part of the embodiments can be implemented in the form of a computer program product. The computer program product includes one or more computer programs or instructions. When the computer program or instructions are loaded and executed on a computer, the process or function described in the embodiments of the present application is performed in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, a network device, a user device or other programmable device. The computer program or instruction can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer program or instruction can be transmitted from one website, computer, server or data center to another website, computer, server or data center via wired or wireless means. The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium, such as a floppy disk, a hard disk, or a tape; it can also be an optical medium, such as a digital video disc (DVD); it can also be a semiconductor medium, such as a solid state drive (SSD).
[0305] The above description is merely a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in the present application, and such modifications or substitutions should be included in the scope of protection of the present application. Therefore, the scope of protection of the present application should be based on the scope of protection of the claims.
Claims
1. A method for tearing down a virtual path, characterized in that, the method comprises: receiving a bandwidth release response; the bandwidth release response includes a first virtual channel identifier; the virtual path includes a plurality of virtual channels cascaded between a source adapter of an originating device of an audio - video service flow and a sink adapter among a plurality of adapters of a destination device of the audio - video service flow, and the virtual channels are used to transmit the audio - video service flow on a link between two ports; tearing down the first virtual channel corresponding to the first virtual channel identifier in response to the bandwidth release response.
2. The method according to claim 1, characterized in that, the method further comprises: sending a bandwidth release request; the bandwidth release request includes a first outgoing flow port number and the first virtual channel identifier.
3. The method according to claim 2, characterized in that, the method further comprises: when the first outgoing flow port number is in a router forwarding table corresponding to the audio - video service flow, decrementing a first multicast count value of an outgoing flow node by one, and setting an identifier of a forwarding entry corresponding to the first virtual channel identifier in the router forwarding table to a first identifier; the router forwarding table is used to indicate forwarding rules of packets within the device between different virtual channels, the outgoing flow node corresponds to the first outgoing flow port number, the first multicast count value is used to represent the number of destination devices receiving the audio - video service flow under the first outgoing flow port, and the first identifier is used to indicate that the forwarding entry has become invalid.
4. The method according to claim 3, characterized in that, when the first multicast count value is equal to zero, setting a service flow identifier of the audio - video service flow to a second identifier; the second identifier is used to indicate that the forwarding entry has become invalid.
5. The method according to any one of claims 1 - 4, characterized in that, the tearing down the first virtual channel corresponding to the first virtual channel identifier in response to the bandwidth release response includes: when the first multicast count value of the outgoing flow node is equal to zero, releasing the bandwidth of the first outgoing flow port; the outgoing flow node corresponds to the first outgoing flow port number.
6. The method according to any one of claims 1 - 5, characterized in that, the tearing down the first virtual channel corresponding to the first virtual channel identifier in response to the bandwidth release response includes: when the first multicast count value of the outgoing flow node is greater than zero, clearing adapter binding information.
7. The method according to claim 2, characterized in that, the sending the bandwidth release request includes: when receiving a tearing - down instruction or a disconnection of a port of an intermediate device, sending the bandwidth release request; the intermediate device is used to forward the audio - video service flow.
8. The method according to claim 7, characterized in that, applied to the intermediate device or a processor of the intermediate device, before the sending the bandwidth release request, the method further comprises: receiving the bandwidth release request; the bandwidth release request includes a second virtual channel identifier, and the second virtual channel identifier is used to indicate a virtual channel at a level above the first virtual channel.
9. The method according to claim 8, characterized in that, After the receiving bandwidth release response, the method further includes: Identifying a path according to a virtual channel identifier in the bandwidth release response; Forwarding the bandwidth release response based on the path; the bandwidth release response includes the second virtual channel identifier.
10. A virtual path tearing-down method, characterized in that being applied to a target device or a processor of the target device, the method includes: Sending a bandwidth release response; the bandwidth release response includes a third virtual channel identifier.
11. The method according to claim 10, characterized in that the method further includes: Receiving a bandwidth release request; the bandwidth release request includes a second outgoing flow port number and the third virtual channel identifier, the virtual path includes a plurality of cascaded virtual channels between a source adapter of an initiating device of an audio-visual service flow and a sink adapter among a plurality of adapters of a target device of the audio-visual service flow, and the virtual channel is used to transmit the audio-visual service flow on a link between two ports.
12. A virtual path tearing-down method, characterized in that being applied to an intermediate device or a processor of the intermediate device, the method includes: Receiving a path tearing-down response; the path tearing-down response includes a fourth virtual channel identifier; Tearing down a fourth virtual channel corresponding to the fourth virtual channel identifier in response to the path tearing-down response.
13. The method according to claim 12, characterized in that the method further includes: Sending a path tearing-down request; the path tearing-down request includes a third outgoing flow port number and the fourth virtual channel identifier.
14. The method according to claim 13, characterized in that the path tearing-down response further includes a second multicast count value, and the second multicast count value is used to indicate the number of target devices that receive the audio-visual service flow under a third outgoing flow port corresponding to the third outgoing flow port number; The tearing down the fourth virtual channel corresponding to the fourth virtual channel identifier in response to the path tearing-down response includes: When a multicast count value of an outgoing flow node is equal to the second multicast count value, releasing the bandwidth of the third outgoing flow port; The outgoing flow node corresponds to the third outgoing flow port number.
15. The method according to claim 13, characterized in that the path tearing-down response further includes a second multicast count value, and the second multicast count value is used to indicate the number of target devices that receive the audio-visual service flow under a third outgoing flow port corresponding to the third outgoing flow port number; The tearing down the fourth virtual channel corresponding to the fourth virtual channel identifier in response to the path tearing-down response includes: When a multicast count value of an outgoing flow node is equal to the second multicast count value, releasing the bandwidth of the third outgoing flow port; The outgoing flow node corresponds to the third outgoing flow port number.
16. The method according to any one of claims 12-15, characterized in that before the sending the path tearing-down request, the method further includes: Receiving the path tearing-down request; the path tearing-down request includes a fifth virtual channel identifier; after the tearing down the fourth virtual channel corresponding to the fourth virtual channel identifier in response to the path tearing-down response, the method further includes: Forward the path removal response; the path removal response includes the fifth virtual channel identifier.
17. The method according to claim 16, wherein, the sending of the path removal request includes: querying the third out-flow port number and the fourth virtual channel identifier according to the in-flow port of the path removal request and the fifth virtual channel identifier; sending the path removal request through the third out-flow port corresponding to the third out-flow port number; the path removal request includes the fourth virtual channel identifier.
18. The method according to claim 16, wherein, the forwarding of the path removal response includes: querying the second in-flow port number and the fifth virtual channel identifier according to the in-flow port number of the path removal response and the fourth virtual channel identifier; forwarding the bandwidth release response through the second in-flow port corresponding to the second in-flow port; the bandwidth release response includes the fifth virtual channel identifier.
19. A virtual path removal method, wherein, applied to a target device or a processor of the target device, the method includes: returning a path removal response; the path removal response includes a sixth virtual channel identifier.
20. The method according to claim 19, wherein, the method further includes: receiving a path removal request; the path removal request includes a fourth out-flow port number and the sixth virtual channel identifier.
21. The method according to claim 19 or 20, wherein, the path removal response further includes a third multicast count value, and the third multicast count value is used to indicate the number of devices receiving the audio-visual service flow under the out-flow port of the target device.
22. A virtual path removal device, wherein, comprising: a transceiver module, configured to receive a bandwidth release response; the bandwidth release response includes a first virtual channel identifier; the virtual path includes a plurality of virtual channels cascaded between a source adapter of an initiating device of an audio-visual service flow and a destination adapter among a plurality of adapters of a destination device of the audio-visual service flow, and the virtual channels are used to transmit the audio-visual service flow on a link between two ports; a processing module, configured to remove the first virtual channel corresponding to the first virtual channel identifier in response to the bandwidth release response.
23. An audio-visual path removal device, wherein, comprising: a transceiver module, configured to send a bandwidth release response; the bandwidth release response includes a third virtual channel identifier.
24. A virtual path removal device, wherein, comprising: a transceiver module, configured to receive a path removal response; the path removal response includes a fourth virtual channel identifier; a processing module, configured to remove the fourth virtual channel corresponding to the fourth virtual channel identifier in response to the path removal response.
25. An audio-visual path removal device, wherein, comprising: a transceiver module, configured to return a path removal request; the path removal response includes a sixth virtual channel identifier.
26. A multimedia device, wherein, comprising: a processor and a transceiver; the transceiver is configured to send and receive an audio-visual service flow; The processor is used to process audio - video service streams; The transceiver and the processor are used to cooperate to execute the method described in any one of claims 1 - 9, or the method described in any one of claims 12 - 18.
27. A multimedia device, Characterized in that, Comprising: A processor and a transceiver; The transceiver is used to transmit and receive audio - video service streams; The processor is used to process audio - video service streams; The transceiver and the processor are used to cooperate to execute the method described in any one of claims 10 - 11, or the method described in any one of claims 19 - 21.
28. A readable storage medium, Characterized in that, The readable storage medium includes a computer program or instruction. When the computer program or instruction runs on a computer, the computer is caused to execute the operation steps of the method described in any one of claims 1 - 9, or the operation steps of the method described in any one of claims 10 - 11, or the operation steps of the method described in any one of claims 12 - 18, or the operation steps of the method described in any one of claims 19 - 21.
29. A computer program product, Characterized in that, The computer program product includes a computer program or instruction. When the computer program or instruction runs on a computer, the computer is caused to execute the operation steps of the method described in any one of claims 1 - 9, or the operation steps of the method described in any one of claims 10 - 11, or the operation steps of the method described in any one of claims 12 - 18, or the operation steps of the method described in any one of claims 19 - 21.
Citation Information
Patent Citations
Method, apparatus and system for determining fusion path of IP network and optical transport network
CN108092733A
Link-physical layer interface adapter
CN109661658A
An anchor point-based virtual network damagement-resistant mapping method in an elastic optical network
CN109831379A
Audio playing method, device and equipment
CN115314584A
Device, system and method for communication with heterogeneous physical layers
US20160267048A1