Bandwidth negotiation method and apparatus

Abstract

Disclosed are a bandwidth negotiation method and apparatus, which relate to the technical field of multimedia. An initiating device in an audio / video transmission network may perform bandwidth negotiation with a target device by means of sending a bandwidth negotiation request to the target device. Moreover, the bandwidth negotiation request comprises a first egress bandwidth value and / or a first ingress bandwidth value, which enables the target device to sense a target egress bandwidth value which requires negotiation and a target ingress bandwidth value which requires negotiation, and the target device then determines, on the basis of a service flow condition thereof, whether to agree to perform bandwidth negotiation, and then returns the bandwidth negotiation request, such that the initiating device and the target device can perform collaborative management on bandwidth resources, and resources of the target device, such as an idle bandwidth, can thus be used, thereby increasing the bandwidth utilization rate of the audio / video transmission network.

Description

Bandwidth negotiation method and device Technical Field

[0001] The present application relates to the field of multimedia technology, and in particular to a bandwidth negotiation method and device. Background Art

[0002] Existing audio and video transmission networks are typically organized in a tree-like structure, managed by a root node. Because the root node independently manages its own child nodes, different root nodes cannot collaboratively manage resources like bandwidth. Consequently, devices managed by a single root node may have a significant amount of idle bandwidth, resulting in low bandwidth utilization.

[0003] Summary of the Invention

[0004] The present application provides a bandwidth negotiation method and device, which solves the problem of low bandwidth utilization in audio and video transmission networks.

[0005] In a first aspect, the present application provides a bandwidth negotiation method. The bandwidth negotiation method is applied to an initiating device or a processor of an initiating device, and the initiating device is connected to an intermediate device or a target device via a unified multimedia interconnection interface (UMI) bus. First, the initiating device sends a bandwidth negotiation request, which includes the device address of the target device, and a first outbound bandwidth value and / or a first inbound bandwidth value. The first outbound bandwidth value is used to indicate a target outbound bandwidth value that needs to be negotiated, and the first inbound bandwidth value is used to indicate a target inbound bandwidth value that needs to be negotiated. Then, the initiating device receives a bandwidth negotiation response, which is used to indicate whether the target device agrees to the bandwidth negotiation.

[0006] In a second aspect, the present application provides a bandwidth negotiation method. This bandwidth negotiation method is applied to a target device or a processor of the target device, also referred to as a target device. The target device is connected to an intermediate device or target device via a UMI bus. First, the target device receives a bandwidth negotiation request. The bandwidth negotiation request includes the device address of the target device, and a first outbound bandwidth value and / or a first inbound bandwidth value. The first outbound bandwidth value indicates a target outbound bandwidth value to be negotiated, and the first inbound bandwidth value indicates a target inbound bandwidth value to be negotiated. The target device then sends a bandwidth negotiation response, indicating whether the target device agrees to the bandwidth negotiation.

[0007] Based on the bandwidth negotiation method of the first or second aspect above, an initiating device in an audio and video transmission network can conduct bandwidth negotiation with a target device by sending a bandwidth negotiation request to the target device. At the same time, the bandwidth negotiation request includes a first outbound bandwidth value and / or a first inbound bandwidth value, so that the target device can perceive the outbound bandwidth target value and the inbound bandwidth target value that need to be negotiated, thereby determining whether to agree to the bandwidth negotiation based on its own business flow situation, and then returning the bandwidth negotiation request, so that the initiating device and the target device can collaboratively manage bandwidth resources, thereby utilizing the idle bandwidth and other resources of the target device and improving the bandwidth utilization rate of the audio and video transmission network.

[0008] In conjunction with the bandwidth negotiation methods provided in the first and second aspects, as a possible implementation, after sending a bandwidth negotiation response, the target device further adjusts or releases bandwidth based on the first outbound bandwidth value and / or the first inbound bandwidth value, and sends a negotiation notification request. The negotiation notification request includes the second outbound bandwidth value and / or the second inbound bandwidth value, where the second outbound bandwidth value indicates the actual value of the outbound bandwidth after the negotiation adjustment, and the second inbound bandwidth value indicates the actual value of the inbound bandwidth after the negotiation adjustment. The target device then receives the negotiation notification response.

[0009] In combination with the bandwidth negotiation method provided in the first aspect and the second aspect, as a possible implementation manner, after receiving the bandwidth negotiation response, the initiating device also receives a negotiation notification request, and in response to the negotiation notification request, establishes or adjusts the service according to the second outbound bandwidth value and / or the second inbound bandwidth value, and then sends a negotiation notification response.

[0010] In combination with the bandwidth negotiation method provided in the first aspect and the second aspect, as a possible implementation method, the initiating device also needs to determine the negotiation target port before sending the bandwidth negotiation request, and determine the target device based on the business flow information of at least one business flow passing through the negotiation target port.

[0011] Optionally, the initiating device uses a bandwidth query request to determine a negotiation target port. The initiating device sends a bandwidth query request. The initiating device then receives a bandwidth query response, which includes the available outbound bandwidth value and / or inbound bandwidth value of each port on the virtual path. Finally, the initiating device determines the negotiation target port as a port whose available outbound bandwidth value is less than the first outbound bandwidth value, or whose available inbound bandwidth value is less than the first inbound bandwidth value.

[0012] Optionally, the initiating device uses a port bandwidth query request to determine the target device. The initiating device sends a port bandwidth query request that includes the port number of the negotiated target port. The initiating device then receives a port bandwidth query response that includes service flow information for at least one service flow. Each service flow information includes a source device address, service priority, a third outbound bandwidth value, and / or a third inbound bandwidth value. Finally, the initiating device determines the target device from the source devices corresponding to the at least one service flow.

[0013] In a third aspect, the present application provides a bandwidth negotiation device, which includes a module for executing the method of any one of the implementations of the first aspect or the second aspect.

[0014] In a fourth aspect, the present application provides a multimedia device. The multimedia device includes a processor and a transceiver. Exemplarily, the processor is configured to process a service flow, and the transceiver is configured to transmit and receive the service flow. The processor and the transceiver collaborate to perform the method of any optional implementation of the first aspect or the second aspect.

[0015] In a fifth aspect, the present application provides a multimedia data transmission system. This multimedia data transmission system includes multiple multimedia devices provided in the fourth aspect, wherein the multimedia device used to send a service flow is an initiating device, the multimedia device used to receive a service flow is a target device, and the multimedia device used to forward a service flow is an intermediate device. The initiating device can be used to implement the functions of the initiating device in the first aspect, the intermediate device can be used to implement the functions of the intermediate device in the first aspect, and the target device can be used to implement the functions of the target device in the second aspect. Therefore, this multimedia data transmission system can also achieve the beneficial effects of the methods described in the first or second aspects above, which will not be elaborated here.

[0016] In a sixth aspect, the present application provides a computer-readable storage medium. The computer-readable storage medium includes computer software instructions. When the computer software instructions are executed in a computing device, the computing device executes the operating steps of the method described in the first aspect or any possible implementation of the first aspect, as well as the operating steps of the method described in the second aspect or any possible implementation of the second aspect. For example, the computing device is the aforementioned initiating device, intermediate device, or target device.

[0017] In a seventh aspect, the present application provides a computer program product. When the computer program product is executed on a computer, the computer program product causes the computing device to perform the steps of the method described in the first aspect or any possible implementation of the first aspect, as well as the steps of the method described in the second aspect or any possible implementation of the second aspect. For example, the computer is the aforementioned initiating device, intermediate device, or target device.

[0018] Regarding the beneficial effects of the third to seventh aspects, reference may be made to the description of any implementation in the first or second aspects, and no further details will be given here. Based on the implementations provided in the above aspects, this application can also be further combined to provide more implementations. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] FIG1 is a schematic diagram of a video transmission system provided by the present application;

[0020] FIG2 is a schematic diagram of an audio and video encoding and decoding system provided by the present application;

[0021] FIG3 is a schematic diagram of a virtual path provided by the present application;

[0022] FIG4 is a schematic diagram of a virtual path provided by the present application;

[0023] FIG5 is a flow chart of a bandwidth negotiation method provided by the present application;

[0024] FIG6 is a flow chart of a bandwidth negotiation notification operation provided by the present application;

[0025] FIG7 is a schematic diagram of a flow chart of a bandwidth query operation provided by the present application;

[0026] FIG8 is a schematic diagram of a flow chart of a bandwidth query operation provided by this application;

[0027] FIG9 is a schematic structural diagram of a bandwidth negotiation device provided by the present application;

[0028] FIG10 is a schematic structural diagram of a multimedia device provided by this application. DETAILED DESCRIPTION

[0029] The present application provides a bandwidth negotiation method, in which an initiating device sends a bandwidth negotiation request, the bandwidth negotiation request includes the device address of the target device, and a first outbound bandwidth value and / or a first inbound bandwidth value, the first outbound bandwidth value is used to indicate the outbound bandwidth target value that needs to be negotiated, and the first inbound bandwidth value is used to indicate the inbound bandwidth target value that needs to be negotiated. The target device receives the bandwidth negotiation request and returns a bandwidth negotiation response. The initiating device receives the bandwidth negotiation response, and the bandwidth negotiation response is used to indicate that the target device agrees to the bandwidth negotiation. In this way, the initiating device and the target device can collaboratively manage bandwidth resources based on the interaction of the bandwidth negotiation request and response, thereby being able to utilize the idle bandwidth and other resources of the target device to improve the bandwidth utilization rate of the audio and video transmission network.

[0030] 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.

[0031] 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.

[0032] 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.

[0033] In order to make the description of the following embodiments clear and concise, the video transmission system to which the bandwidth negotiation method of the present application is applicable is first introduced.

[0034] 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.

[0035] 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.

[0036] 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.

[0037] 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.

[0038] 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.

[0039] 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 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.

[0040] 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.

[0041] 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.

[0042] 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.

[0043] 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 .

[0044] 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.

[0045] 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.

[0046] 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.

[0047] 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.

[0048] Optionally, the source device 210 includes a bitstream buffer, which is used to store bitstreams corresponding to one or more coding units.

[0049] 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 .

[0050] 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 .

[0051] 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.

[0052] 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.

[0053] 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).

[0054] 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.

[0055] 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.).

[0056] 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.

[0057] The audio and video playback unit 221 is used to receive post-processed data for display or playback to a user or viewer, etc. 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, etc.

[0058] 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.

[0059] The bandwidth negotiation method of the present application is that when a source device 210 needs to start or adjust an audio or video service flow, it negotiates bandwidth with another source device 210. When the other source device 210 agrees to the bandwidth negotiation, it releases the bandwidth value on the virtual path of its own audio or video service flow to meet the bandwidth requirement of the source device 210 for starting or adjusting the audio or video service flow. Next, the virtual path is explained with reference to Figure 3. Based on the video transmission system shown in Figure 1 and the audio and video codec system shown in Figure 2, Figure 3 is a schematic diagram of a virtual path provided by the present application.

[0060] 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.

[0061] 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).

[0062] 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).

[0063] The implementation of the bandwidth negotiation method provided in the embodiment of the present application will be described in detail below with reference to the accompanying drawings.

[0064] Bandwidth negotiation messages, including bandwidth negotiation requests and bandwidth negotiation responses, are used for bandwidth negotiation between two devices in a UMI network. This allows for bandwidth negotiation between different devices, enabling bandwidth sharing and full utilization. Bandwidth negotiation requests must be initiated by the source device of the audio and video stream. For example, a video stream must be initiated by the device that contains the audio and video adapter that sends the video, and a USB service stream must be initiated by the device that contains the USB tunnel adapter connected to the USB host.

[0065] Here, the bandwidth negotiation method of an embodiment of the present application is described as being executed by the initiating device 210 and the target device 220 shown in FIG2 . FIG5 is a flow chart illustrating a bandwidth negotiation method provided by the present application. In this embodiment, the initiating 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 source device 210. In this embodiment, the initiating device 51 and the target device 52 may also be referred to as source devices, audio and video transmitters, or audio and video transmitters. In this embodiment, the initiating device 51 and the target device 52 are connected via one or more intermediate devices 53 (only one intermediate device 53 is shown in FIG5 , but the number of intermediate devices is not limited). The initiating device 51, the intermediate device 53, and the target device 52 are connected via a bus 54, which may be a UMI bus.

[0066] In a possible application scenario, the initiating device 51 may be the set-top box 110 in FIG. 1 , and the target device 52 may be the smart TV 120 in FIG. 1 .

[0067] The above 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).

[0068] Referring to FIG. 5 , the bandwidth negotiation method provided in this embodiment includes the following steps 501 to 509 .

[0069] Step 501: The initiating device 51 generates a bandwidth negotiation request.

[0070] The initiating device 51 selects a target device for negotiation according to the needs of the audio and video service flow and generates a bandwidth negotiation request.

[0071] As a possible implementation, the initiating device 51 first determines the negotiation target port on the virtual path of the audio and video service flow, and then determines the negotiation target device based on service flow information of at least one service flow passing through the negotiation target port.

[0072] Optionally, the negotiation target port is a port whose available bandwidth is less than the bandwidth required by the audio and video service flow. For example, if the available outbound bandwidth of port 1 on the virtual channel is less than the outbound bandwidth required by the audio and video service flow, port 1 can be used as the negotiation target port. For another example, if the available inbound bandwidth of port 2 on the virtual channel is less than the inbound bandwidth required by the audio and video service flow, port 2 can be used as the negotiation target port.

[0073] In a possible embodiment of the present application, the initiating device 51 determines the negotiation target port through a bandwidth query operation. For specific steps, please refer to steps 701 to 710 shown in FIG. 7 , which will not be described in detail here.

[0074] In a possible embodiment of the present application, the initiating device 51 determines the target device for negotiation through a port bandwidth query operation. For specific steps, please refer to steps 801 to 809 shown in FIG. 8 , which will not be described in detail here.

[0075] As a possible implementation manner, the message structure of the bandwidth negotiation request is shown in Table 1.

[0076] Table 1

[0077] Optionally, the message fields of the bandwidth negotiation request are described as shown in Table 2.

[0078] Table 2

[0079] When generating a bandwidth negotiation request, the initiating device 51 assigns OutStreamBW to the outgoing bandwidth value to be negotiated, i.e., the first outgoing bandwidth value, and assigns InStreamBW to the ingoing bandwidth value to be negotiated, i.e., the first ingoing bandwidth value. The target address included in the device addressing information is the device address of the target device.

[0080] Optionally, the message structure of the message header is as shown in Table 3.

[0081] Table 3

[0082] Optionally, the message structure of the general field is as shown in Table 4.

[0083] Table 4

[0084] Step 502: The initiating device 51 sends a bandwidth negotiation request.

[0085] The initiating device 51 sends a bandwidth negotiation request according to the device addressing information.

[0086] As a possible implementation method, the addressing information of the bandwidth negotiation request is device address addressing information, or device address addressing, or addressing information. Each device in the UMI network has a unique 8-byte (64-bit) identifier that can uniquely identify a device, so this identifier is called a device address. The device address consists of a vendor identifier (Vendor ID) and a device identifier (Device ID). The Vendor ID consists of 16 bits and must be registered with the UMI organization. The Device ID is assigned by the device manufacturer when manufacturing the UMI device and must be guaranteed to be unique.

[0087] The message structure of the device address addressing information is shown in Table 5.

[0088] Table 5

[0089] The destination address is the device address of the device that the message is intended to receive, and the source address is the device address of the device that sends the message.

[0090] In the present application, the addressing method based on the above-mentioned device address addressing information includes: when a device receives a message carrying device address addressing information, if the target address of the message is its own device address, then the device is the target device of the message. Otherwise, it is necessary to query the address table based on the target address of the message and process it according to the query result: (1) If the target address of the message is in the address table, and the corresponding port is different from the port receiving the message, then the message is forwarded from the corresponding port. The address table includes the correspondence between the device address and the forwarding port. (2) If the target address of the message is in the address table, but the corresponding port is the same as the port receiving the message. It is considered that the target address of the message is in the device connected to the port, so the target device should have received the message, and the device should discard the message. (3) If the target address of the message is not found in the address table, then the device does not know whether there is a port connected to the target device, and the device should flood the message from all ports except the receiving port.

[0091] Step 503: The intermediate device 53 receives a bandwidth negotiation request.

[0092] Step 504: The intermediate device 53 sends a bandwidth negotiation request.

[0093] In the above steps 503 and 504 , the manner in which the intermediate device 53 forwards the bandwidth negotiation request can be found in the addressing manner corresponding to the above device address information, which will not be described in detail here.

[0094] Step 505: The target device 52 receives the bandwidth negotiation request.

[0095] When receiving the bandwidth negotiation request, the target device 52 decides whether to agree to the bandwidth negotiation based on the current bandwidth and service conditions of the target device 52 , and starts the bandwidth adjustment or bandwidth release process when agreeing to the bandwidth negotiation.

[0096] In one possible implementation, target device 52 is the source device initiating another audio or video service flow. Target device 52 decides whether to agree to bandwidth negotiation based on the bandwidth allocated on the virtual path for the audio or video service flow it initiates and the bandwidth required for the audio or video service flow it initiates. The audio or video service flow initiated by target device 52 is different from the audio or video service flow initiated by initiating device 51.

[0097] Optionally, if the bandwidth value allocated to the target device 52 on the virtual path is greater than the bandwidth value required by the audio and video service flow, and the absolute value of the difference between the two is greater than the first outgoing flow bandwidth value, the target device 52 agrees to conduct bandwidth negotiation. Otherwise, the target device 52 does not agree to conduct bandwidth negotiation.

[0098] As a possible implementation manner, the target device 52 initiates a bandwidth adjustment or bandwidth release process to adjust or release the bandwidth value allocated on the virtual path of the audio and video service flow initiated by itself.

[0099] Step 506: The target device 52 sends a bandwidth negotiation response.

[0100] The target device 52 sends a bandwidth negotiation response according to the device address addressing mode.

[0101] In a possible embodiment of the present application, when the target device 52 disagrees with the bandwidth negotiation, the ErrorCode in the message body of the bandwidth negotiation response is set to 0x5.

[0102] As a possible implementation, the message structure of the bandwidth negotiation response is shown in Table 6.

[0103] Table 6

[0104] Optionally, the message fields of the bandwidth negotiation response are described as shown in Table 7.

[0105] Table 7

[0106] Step 507: The intermediate device 53 receives the bandwidth negotiation response.

[0107] Step 508: The intermediate device 53 sends a bandwidth negotiation response.

[0108] In the above steps 507 and 508 , the manner in which the intermediate device 53 forwards the bandwidth negotiation request can be found in the addressing manner corresponding to the above device address information, which will not be described in detail here.

[0109] Step 509: The initiating device 51 receives the bandwidth negotiation response.

[0110] After receiving the bandwidth negotiation response, the initiating device 51 confirms that the target device 52 agrees with the bandwidth negotiation and is adjusting or releasing the bandwidth.

[0111] After confirming that the target device 52 agrees to the bandwidth negotiation, the initiating device 51 can also wait for the bandwidth negotiation notification request (bandwidth negotiation notification message) from the target device 52 to confirm that the target device 52 has completed the bandwidth adjustment or bandwidth release process, and then decide the next step based on the bandwidth negotiation notification request.

[0112] Therefore, the bandwidth negotiation method provided in this application may also include a bandwidth negotiation notification operation. This bandwidth negotiation notification operation (including a bandwidth negotiation notification request and a bandwidth negotiation notification response) is used to generate a bandwidth notification request and send it to the device that initiated the bandwidth negotiation request after the device completes bandwidth adjustment or release, in a scenario where the device has received a bandwidth negotiation request from another device and agrees to conduct bandwidth negotiation.

[0113] The bandwidth negotiation notification operation must be initiated by the source device of the corresponding service flow. For example, the video stream must be initiated by the device where the audio and video sending adapter that sends the video is located, and the USB service stream must be initiated by the device where the USB tunnel adapter connected to the USB host is located.

[0114] Here, the bandwidth negotiation notification operation of an embodiment of the present application is performed by the initiating device 210 and the target device 220 shown in Figure 2 as an example for explanation, and Figure 6 is a flow chart of a bandwidth negotiation notification operation provided by the present application. Among them, the initiating device 61 is used to implement the function of the source device 210, and the target device 62 is used to implement the function of the source device 210. In this embodiment, the initiating device 61 and the target device 62 can also be referred to as source devices, audio and video sending terminals or audio and video sending devices. For example, after returning a bandwidth negotiation response and completing the process of adjusting the bandwidth or releasing the bandwidth, the target device 52 in Figure 5 sends a bandwidth negotiation notification request to the initiating device 51, that is, the initiating device 61 can be the target device 52 in Figure 5, and the target device 62 can be the initiating device 61 in Figure 5.

[0115] In this embodiment, an initiator device 61 and a target device 62 are connected via one or more intermediate devices 63 ( FIG. 6 shows only one intermediate device 63 , but the number of intermediate devices is not limited). The initiator device 61, the intermediate device 63, and the target device 62 are connected via a bus 64, which may be a UMI bus.

[0116] Referring to FIG. 6 , the bandwidth negotiation notification operation provided in this embodiment includes the following steps 601 to 610 .

[0117] Step 601: The initiating device 61 generates a bandwidth negotiation notification request.

[0118] The initiating device 61 generates a bandwidth negotiation notification request when the bandwidth adjustment or bandwidth release process ends.

[0119] As a possible implementation manner, the message structure of the bandwidth negotiation notification request is shown in Table 8.

[0120] Table 8

[0121] Optionally, the field description of the bandwidth negotiation notification request is as shown in Table 9.

[0122] Table 9

[0123] When generating a bandwidth negotiation request, the initiating device 61 assigns OutStreamBW to the actual value of the outbound bandwidth adjusted after negotiation, i.e., the second outbound bandwidth value, and assigns InStreamBW to the actual value of the inbound bandwidth adjusted after negotiation, i.e., the second inbound bandwidth value. The target address included in the device address information is the device address of the target device.

[0124] Step 602: The initiating device 61 sends a bandwidth negotiation notification request.

[0125] The initiating device 61 sends a bandwidth negotiation notification request according to the device addressing information.

[0126] Step 603: The intermediate device 63 receives the bandwidth negotiation notification request.

[0127] Step 604: The intermediate device 63 sends a bandwidth negotiation notification request.

[0128] In the above steps 603 and 604 , the manner in which the intermediate device 63 forwards the bandwidth negotiation notification request can be found in the addressing manner corresponding to the above device address information, which will not be described in detail here.

[0129] Step 605: The target device 62 receives the bandwidth negotiation notification request.

[0130] Step 606: The target device 62 sends a bandwidth negotiation notification response.

[0131] The target device 62 returns a bandwidth negotiation notification response using the device address in the bandwidth negotiation notification response.

[0132] As a possible implementation manner, the message structure of the bandwidth negotiation notification response is shown in Table 10.

[0133] Table 10

[0134] Optionally, the message fields of the bandwidth negotiation notification response are described as shown in Table 11.

[0135] Table 11

[0136] Step 607: The target device 62 establishes or adjusts a service according to the second outbound bandwidth value and / or the second inbound bandwidth value in response to the bandwidth negotiation notification request.

[0137] In response to the negotiation notification request, the target device 62 decides on the next operation based on the second outbound bandwidth value and / or the second inbound bandwidth value carried in the negotiation notification. The decision strategy may be as follows:

[0138] 1) If the bandwidth value in the negotiation notification request (i.e., OutStreamBW is assigned, the second outbound bandwidth value) is consistent with the service application value (i.e., the outbound bandwidth value required for the audio and video service flow initiated by the target device 62), the target device 62 initiates the audio and video service flow transmission.

[0139] 2) If the bandwidth value in the negotiation notification request is less than the service application value and the service is acceptable, for example, the service requirements can be continued to be met by adjusting the resolution, color space, bit depth, etc., then the target device 62 initiates audio and video service stream transmission.

[0140] 3) If the bandwidth value in the negotiation notification request is smaller than the service application value, but the service is unacceptable, the target device 62 initiates a bandwidth release process, selects the next shortest path, and then starts the bandwidth application process.

[0141] 4) If no path in the UMI network can meet the bandwidth requirements of the current audio and video service flow, an exception is reported.

[0142] Step 608: The intermediate device 63 receives the bandwidth negotiation notification response.

[0143] Step 609: The intermediate device 63 sends a bandwidth negotiation notification response.

[0144] In the above steps 608 and 609 , the manner in which the intermediate device 63 forwards the bandwidth negotiation notification response can be found in the addressing manner corresponding to the above device address information, which will not be described in detail here.

[0145] Step 610: The target device 62 receives a bandwidth negotiation notification response.

[0146] The overall process of the bandwidth negotiation method of the present application is described above with reference to FIG5 and FIG6 . Next, the bandwidth query operation that may be included in the bandwidth negotiation method will be described with reference to FIG7 .

[0147] The bandwidth query operation includes a bandwidth query request and a bandwidth query response, which are used to query the available bandwidth value of each port on the virtual path between two devices in the UMI network.

[0148] The bandwidth query message must be initiated by the source device of the corresponding audio and video service flow. For example, the video stream must be initiated by the device where the audio and video sending adapter that sends the video is located, and the USB service flow must be initiated by the device where the USB tunnel adapter connected to the USB host is located.

[0149] Here, the bandwidth query operation performed by the initiating device 210 and the target device 220 shown in Figure 2 is used as an example to illustrate an embodiment of the present application. Figure 7 is a schematic flow chart of a bandwidth query operation provided by the present application. In this embodiment, the initiating device 71 is used to implement the functions of the source device 210, and the target device 72 is used to implement the functions of the source device 210. In this embodiment, the initiating device 71 may also be referred to as a source device, an audio and video transmitter, or an audio and video transmitter, and the target device 72 may also be referred to as a sink device, an audio and video receiver, or an audio and video receiver. In this embodiment, the initiating device 71 and the target device 72 are connected via one or more intermediate devices 73 (only one intermediate device 73 is shown in Figure 7, but the number of intermediate devices is not limited). The initiating device 71, the intermediate device 73, and the target device 72 are connected via a bus 74, which may be a UMI bus.

[0150] For example, the initiating device 71 is the initiating device 51 in FIG. 5 , and the target device 72 is the sink device of the audio and video service flow initiated by the initiating device 71 .

[0151] Referring to FIG. 7 , the bandwidth query operation provided in this embodiment includes the following steps 701 to 710 .

[0152] Step 701: The initiating device 71 generates a bandwidth query request.

[0153] The initiating device 71 sets Channel to 1, sets L0_OutStreamBW to the available outbound bandwidth value of the output port, sets L1~n_OutStreamBW and L0~n_InStreamBW to 0xFFFFFFFF (n=FL Length), and generates a bandwidth query request message.

[0154] As a possible implementation, the message structure of the bandwidth query request is shown in Table 12.

[0155] Table 12

[0156] Optionally, the message fields of the bandwidth query request are described as shown in Table 13.

[0157] Table 13

[0158] Step 702: The initiating device 71 sends a bandwidth query request.

[0159] As a possible implementation manner, the initiating device 71 sends the bandwidth query request through a forwarding list addressing manner.

[0160] Optionally, the addressing information of the bandwidth query request 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 14.

[0161] Table 14

[0162] The Forwarding List Level of the bandwidth query request is used to indicate the current level, and the corresponding port number in the port number of the level is the port number through which the current device sends the bandwidth query request.

[0163] Step 703: The intermediate device 73 receives a bandwidth query request.

[0164] As a possible implementation, after receiving the bandwidth query request, the intermediate device 73 executes the following steps S1-S3 to update the bandwidth query request.

[0165] S1. The intermediate device 73 updates the available outbound bandwidth value of the input port to the Ln-1_InStremBW field in the message body.

[0166] The input port refers to the port through which the intermediate device 73 receives the bandwidth query request.

[0167] S2. The intermediate device 73 extracts the corresponding output port number from the forwarding list addressing information.

[0168] The intermediate device 73 extracts the corresponding output port number Ln_PortID from the forwarding list addressing information according to the FL Level value, where FL Level represents the level of the current device with the source device as the origin.

[0169] S3. The intermediate device 73 updates the available outbound bandwidth value of the output port to the OutStremBW field in the message body.

[0170] In a possible embodiment of the present application, when the intermediate device 73 receives a bandwidth query request, if the port is in the link configuration or link training state, it should set ErrCode to 0x1 (Busy) and directly return a bandwidth query response.

[0171] Step 704: The intermediate device 73 sends a bandwidth query request.

[0172] As a possible implementation manner, the intermediate device 73 forwards the bandwidth query request according to a forwarding list addressing manner.

[0173] Step 705: The target device 72 receives the bandwidth query request.

[0174] As a possible implementation, after receiving the bandwidth query request, the target device 72 executes the following steps S1-S3.

[0175] S1. The target device 72 updates the available outbound bandwidth value of the input port to the Ln_InStremBW field in the message body.

[0176] S2. The target device 72 determines that the device is the target device according to FL Level=FL Length+1.

[0177] S3. The target device 72 uses the bandwidth query request as an output port of the bandwidth query response.

[0178] In a possible embodiment of the present application, when the target device 72 receives a bandwidth query request, if the port is in the link configuration or link training state, it should set ErrCode to 0x1 (Busy) and directly return a bandwidth query response.

[0179] Step 706: The target device 72 sends a bandwidth query response.

[0180] As a possible implementation, the message structure of the bandwidth query response is shown in Table 15.

[0181] Table 15

[0182] Optionally, for a description of each field in the bandwidth query response, please refer to Table 16.

[0183] Table 16

[0184] Step 707: The intermediate device 73 receives the bandwidth query response.

[0185] Step 708: The intermediate device 73 sends a bandwidth query response.

[0186] As a possible implementation manner, the intermediate device 73 forwards the bandwidth query request according to a forwarding list addressing manner.

[0187] Step 709: The initiating device 71 receives the bandwidth query response.

[0188] Step 710: The initiating device 71 determines that the negotiation target port is a port whose available outbound bandwidth value is smaller than the first outbound bandwidth value, or whose available inbound bandwidth value is smaller than the first inbound bandwidth value.

[0189] The overall process of the bandwidth negotiation method of the present application is described above with reference to FIG5 and FIG6 . Next, the port bandwidth query operation that may be included in the bandwidth negotiation method will be described with reference to FIG8 .

[0190] The bandwidth query operation includes port bandwidth query request and port bandwidth query response, which are used to query the bandwidth of a specific port in a specified device in the UMI network so that bandwidth negotiation can be carried out between different devices to achieve bandwidth sharing and full utilization.

[0191] The bandwidth query operation must be initiated by the source device of the corresponding audio and video service flow. For example, the video stream must be initiated by the device where the audio and video sending adapter that sends the video is located, and the USB service flow must be initiated by the device where the USB tunnel adapter connected to the USB host is located.

[0192] Here, we use the bandwidth query operation performed by the initiating device 210 and the target device 220 shown in Figure 2 as an example. Figure 8 is a schematic flow chart of a bandwidth query operation provided by this application. Initiating device 81 is used to implement the functions of source device 210. In this embodiment, initiating device 81 may also be referred to as a source device, an audio and video transmitter, or an audio and video transmitter. In this embodiment, initiating device 81 and target device 82 are connected via one or more intermediate devices 83 (only one intermediate device 83 is shown in Figure 8, but the number of intermediate devices is not limited). The initiating device 81, intermediate device 83, and target device 82 are connected via a bus 84, which may be a UMI bus.

[0193] For example, the initiating device 81 is the initiating device 51 in FIG. 5 or the initiating device 71 in FIG. 7 , and the target device 82 is the device where the negotiation target port determined in step 710 is located.

[0194] Referring to FIG. 8 , the port bandwidth query operation provided by this embodiment includes the following steps 801 to 809 .

[0195] Step 801: The initiating device 81 generates a port bandwidth query request.

[0196] The initiating device 81 selects the target device 82 to be queried and the port number of the negotiated target port, assigns the port number of the negotiated target port to the PortID field of the port bandwidth query request, and generates a port bandwidth query request.

[0197] As a possible implementation, the message structure of the port bandwidth query request is shown in Table 17.

[0198] Table 17

[0199] Optionally, the message field description of the port bandwidth query request is as shown in Table 18.

[0200] Table 18

[0201] Step 802: The initiating device 81 sends a port bandwidth query request.

[0202] As a possible implementation manner, the initiating device 81 sends the port bandwidth query request through a forwarding list addressing manner.

[0203] Step 803: The intermediate device 83 receives a port bandwidth query request.

[0204] Step 804: The intermediate device 83 sends a port bandwidth query request.

[0205] In the above steps 803 and 804 , the manner in which the intermediate device 83 forwards the port bandwidth query request can be found in the addressing manner corresponding to the above forwarding list addressing information, which will not be described in detail here.

[0206] Step 805: The target device 82 receives the port bandwidth query request.

[0207] Step 806: The target device 83 sends a port bandwidth query response.

[0208] The target device 82 summarizes the source adapter ID, priority, source device address, outbound bandwidth value and inbound bandwidth value corresponding to all flows passing through the port, fills them into the port bandwidth query response, and sends the port bandwidth query response based on the addressing method corresponding to the forwarding list addressing information.

[0209] As a possible implementation, the message structure of the port bandwidth query response is shown in Table 19.

[0210] Table 19

[0211] Optionally, the message fields of the port bandwidth query response are described as shown in Table 20.

[0212] Table 20

[0213] The OutStreamBW field of the port bandwidth query response is assigned the third outbound bandwidth value, and the InStreamBW field is assigned the third inbound bandwidth value.

[0214] Step 807: The intermediate device 83 receives the port bandwidth query response.

[0215] Step 808: The intermediate device 83 sends a port bandwidth query response.

[0216] For the manner in which the intermediate device 83 forwards the port bandwidth query response in the above steps 807 and 807, please refer to the addressing manner corresponding to the above forwarding list addressing information, which will not be described in detail here.

[0217] Step 809: The initiating device 81 receives the port bandwidth query response.

[0218] The initiating device 81 extracts the source device address, priority, outbound bandwidth value, and inbound bandwidth value from the port bandwidth query response, and selects a target source device for negotiation, ie, the target device 52 in FIG. 5 , according to the following recommended policy.

[0219] Recommended strategy: Select a source device with a low priority and expected bandwidth. If multiple source devices meet the requirements, the one with the shorter path is preferred for negotiation.

[0220] 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.

[0221] The bandwidth negotiation method provided in accordance with this embodiment is described in detail above with reference to FIG. 1 to FIG. 8 . The bandwidth negotiation apparatus provided in accordance with this embodiment will be described below with reference to FIG. 9 .

[0222] Figure 9 is a schematic diagram of the structure of a bandwidth negotiation device provided by the present application. The bandwidth negotiation device 900 can be used to implement the functions of any one of the devices in the above-mentioned method embodiments, and thus can also achieve the beneficial effects of the above-mentioned method embodiments. In this embodiment, the bandwidth negotiation device 900 can be the set-top box 110, smart TV 120, or any display device as shown in Figure 1, or the source device 210 or sink device 220 as shown in Figure 2, or the multimedia device or display device provided in subsequent embodiments. It should be understood that the bandwidth negotiation device 900 can also be a module (such as a chip) applied to any of the aforementioned devices.

[0223] As shown in Figure 9 , bandwidth negotiation apparatus 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 description of the devices in the method embodiment shown in the aforementioned figures, and is not further elaborated here.

[0224] When bandwidth negotiation device 900 implements any of the bandwidth negotiation methods shown in the aforementioned figures through software, bandwidth negotiation device 900 and its various units may also be software modules. The bandwidth negotiation method described above 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.

[0225] It can be understood that the bandwidth negotiation device shown in Figure 9 is only an example provided in this embodiment. Depending on the different audio and video service flow transmission processes, the bandwidth negotiation device may include more or fewer units, and this application does not limit this.

[0226] When bandwidth negotiation device 900 is implemented via hardware, the hardware may 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 devices outside the chip and transmit it to the control circuit, or to send data from the control circuit to devices outside the chip. The control circuit and the interface circuit implement the method of any possible implementation method in the above embodiments through logic circuits or executing code instructions. The beneficial effects can be found in the description of any aspect of the above embodiments and will not be repeated here.

[0227] 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.

[0228] In addition, the bandwidth negotiation apparatus 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 in 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.

[0229] 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.

[0230] 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.

[0231] The multimedia device shown in FIG10 may be any device in FIG1 , or a source device or a sink device in subsequent embodiments.

[0232] 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.

[0233] 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.

[0234] 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.

[0235] 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.

[0236] 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.

[0237] 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.

[0238] 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.

[0239] 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.

[0240] The display screen 1094 is used to display images, videos, etc. The display screen 1094 includes a display panel.

[0241] 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.

[0242] 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).

[0243] 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.

[0244] 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 1021. For example, in an embodiment of the present application, the processor 1010 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.

[0245] 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).

[0246] 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.

[0247] 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.

[0248] 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.

[0249] 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).

[0250] 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 bandwidth negotiation method, characterized in that, it includes: Sending a bandwidth negotiation request; The bandwidth negotiation request includes the device address of the target device, and a first outbound bandwidth value and / or a first inbound bandwidth value. The first outbound bandwidth value is used to indicate the target value of the outbound bandwidth to be negotiated, and the first inbound bandwidth value is used to indicate the target value of the inbound bandwidth to be negotiated; Receiving a bandwidth negotiation response; the bandwidth negotiation response is used to indicate whether the target device agrees to conduct bandwidth negotiation.

2. The method according to claim 1, characterized in that, the method further includes: Receiving a negotiation notification request; the negotiation notification request includes a second outbound bandwidth value and / or a second inbound bandwidth value; the second outbound bandwidth value is used to indicate the actual value of the outbound bandwidth after negotiation adjustment, and the second inbound bandwidth value is used to indicate the actual value of the inbound bandwidth after negotiation adjustment; In response to the negotiation notification request, establishing or adjusting services according to the second outbound bandwidth value and / or the second inbound bandwidth value; Sending a negotiation notification response.

3. The method according to claim 1 or 2, characterized in that, the method further includes: Determining a negotiation target port; Determining the target device according to the service flow information of at least one service flow passing through the negotiation target port.

4. The method according to claim 2, characterized in that, the determination of the negotiation target port includes: Sending a bandwidth query request; Receiving a bandwidth query response; the bandwidth query response includes the available outbound bandwidth value and / or outbound bandwidth value of each port on the virtual path; Determining the negotiation target port as a port whose available outbound bandwidth value is less than the first outbound bandwidth value, or whose available inbound bandwidth value is less than the first inbound bandwidth value.

5. The method according to claim 3 or 4, characterized in that, the determination of the target device according to the service flow information of at least one service flow passing through the negotiation target port includes: Sending a port bandwidth query request; the port bandwidth query request includes the port number of the negotiation target port; Receiving a port bandwidth query response; the port bandwidth query response includes the service flow information of the at least one service flow, and each service flow information includes the source device address, service priority, third outbound bandwidth value and / or third inbound bandwidth value; Determining the target device among the source devices corresponding to the at least one service flow.

6. A bandwidth negotiation method, characterized in that, it includes: Receiving a bandwidth negotiation request; The bandwidth negotiation request includes the device address of the target device, and a first outbound bandwidth value and / or a first inbound bandwidth value. The first outbound bandwidth value is used to indicate the target value of the outbound bandwidth to be negotiated, and the first inbound bandwidth value is used to indicate the target value of the inbound bandwidth to be negotiated; Sending a bandwidth negotiation response; the bandwidth negotiation response is used to indicate whether the target device agrees to conduct bandwidth negotiation.

7. The method according to claim 6, characterized in that, the method further includes: Adjusting or releasing the bandwidth according to the first outbound bandwidth value and / or the first inbound bandwidth value; Send a negotiation notification request; the negotiation notification request includes a second outgoing bandwidth value and / or a second incoming bandwidth value, where the second outgoing bandwidth value is used to indicate the actual value of the outgoing bandwidth after negotiation adjustment, and the second incoming bandwidth value is used to indicate the actual value of the incoming bandwidth after negotiation adjustment; Receive a negotiation notification response.

8. A bandwidth negotiation device, characterized in that, it includes: A transceiver module, configured to send a bandwidth negotiation request; The bandwidth negotiation request includes the device address of the target device, and a first outgoing bandwidth value and / or a first incoming bandwidth value, where the first outgoing bandwidth value is used to indicate the target value of the outgoing bandwidth to be negotiated, and the first incoming bandwidth value is used to indicate the target value of the incoming bandwidth to be negotiated; The transceiver module is further configured to receive a bandwidth negotiation response; the bandwidth negotiation response is used to indicate whether the target device agrees to perform bandwidth negotiation.

9. A bandwidth negotiation device, characterized in that, it includes: A transceiver module, configured to receive a bandwidth negotiation request; The bandwidth negotiation request includes the device address of the target device, and a first outgoing bandwidth value and / or a first incoming bandwidth value, where the first outgoing bandwidth value is used to indicate the target value of the outgoing bandwidth to be negotiated, and the first incoming bandwidth value is used to indicate the target value of the incoming bandwidth to be negotiated; The transceiver module is further configured to send a bandwidth negotiation response; the bandwidth negotiation response is used to indicate whether the target device agrees to perform bandwidth negotiation.

10. A multimedia device, characterized in that, it includes: A transceiver and a processor; The processor is configured to process traffic flows; The transceiver is configured to transmit and receive the traffic flows; The transceiver and the processor are configured to cooperate to execute the method according to any one of claims 1-5, or the method according to any one of claims 6-7.

Images