Methods, devices, computer-readable media, and electronic devices that signal multiple audio mixing gains
By synchronously managing the gain of multiple audio streams through the RTCP feedback mechanism, the problem of poor audio mixing in omnidirectional media streams is solved, improving user experience and audio quality.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- TENCENT AMERICA LLC
- Filing Date
- 2022-03-25
- Publication Date
- 2026-05-01
AI Technical Summary
In omnidirectional media streaming, existing technologies struggle to effectively manage and mix the gains of multiple audio streams, resulting in a poor user experience.
By using the Real-Time Transmission Control Protocol (RTCP) feedback mechanism, multiple audio mixing gains, including the mixing gains of 360-degree streams and overlay streams, are notified in real time. The synchronization and management of audio mixing gains are achieved using a single RTP header extension.
It enables precise control of the gain of multiple audio streams in remote conferencing, improving user experience and audio quality.
Smart Images

Figure CN116636201B_ABST
Abstract
Description
Methods, devices, computer-readable media, and electronic devices for signaling multiple audio mixing gains
[0001] Cross-references to related applications
[0002] This application is based on and claims priority to U.S. Provisional Patent Application No. 63 / 276,433, filed November 11, 2021, the disclosure of which is incorporated herein by reference in its entirety. Technical Field
[0003] This application relates to video encoding and decoding, and in particular to a method, apparatus, storage medium, and electronic device for signaling multiple audio mixing gains. Background Technology
[0004] When using omnidirectional media streaming, only a portion of the content corresponding to the user's viewport is presented when using a head-mounted display (HMD), thus providing the user with a realistic view of the media stream.
[0005] Figure 1 illustrates a relevant technical scenario (Scenario 1) for an immersive remote conferencing call, where the call is organized between room A (101), user B (102), and user C (103). As shown in Figure 1, room A (101) represents a conference room with an omnidirectional / 360-degree camera (104), and users B (102) and C (103) are remote participants using an HMD and a mobile device, respectively. In this scenario, participants user B (102) and user C (103) send their viewport orientations to room A (101), and room A (101) then sends viewport-related streams to users B (102) and C (103).
[0006] Figure 2A illustrates an extended scenario (Scenario 2) comprising multiple meeting rooms (2a01, 2a02, 2a03, 2a04). User B (2a06) uses an HMD to view a video stream from a 360-degree camera (104), and user C (2a07) uses a mobile device to view the video stream. Users B (2a06) and C (2a07) send their viewport orientations to at least one of the meeting rooms (2a01, 2a02, 2a03, 2a04), and at least one of the meeting rooms (2a01, 2a02, 2a03, 2a04) in turn sends viewport-related streams to users B (2a06) and C (2a07).
[0007] As shown in Figure 2B, another example scenario (Scenario 3) is when a call is established using the MRF / MCU (2b05), where the Media Resource Function (MRF) and Media Control Unit (MCU) are multimedia servers used to provide media-related functions for terminals bridging multi-party conference calls. Conference rooms can send their respective videos to the MRF / MCU (2b05). These videos are viewport-independent; that is, the entire 360-degree video is sent to the media server (i.e., the MRF / MCU), independent of the user's viewport for streaming a specific video. The media server receives the viewport orientation of the users (User B (2b06) and User C (2b07)) and sends the viewport-related streams to the users accordingly.
[0008] Further, for scenario 3, remote users can choose to watch one of the available 360-degree videos from conference rooms (2a01 to 2a04, 2b01 to 2b04). In this case, the user sends information about the video they want to stream and its viewport orientation to the conference room or the MRF / MCU (2b05). Users can also trigger a switch from one conference room to another based on active speakers. The media server can pause receiving video streams from any conference room without active users.
[0009] ISO 23090-2 defines overlay as "visual media presented on or over an omnidirectional video or image project or viewport". When any participant in conference room A is sharing any presentation, in addition to being displayed in conference room A, the presentation is also streamed to other users (conference rooms 2a02 to 2a04, 2b02 to 2b04, user B (2b06), and / or user C (2b07)). This stream can be overlaid on 360-degree video. Overlay can also be used for 2D streams. The default audio mixing gain for the different audio streams is for 360-degree video (a0) and overlaid video (a1, a2, ..., a...). N The audio gain (r0, r1, ..., r) N The audio output is equal to r0*a0 + r1*a1 + ... + rn*an, where r0 + r 1+ …+r N =1. The receiver or MRF / MCU mixes the audio source proportionally to its mixing gain. Summary of the Invention
[0010] One or more exemplary embodiments of this disclosure provide a system and method for simultaneously signaling overlay and 360-degree streaming audio mixing gain in a single RTP header extension.
[0011] According to an embodiment, a method is provided for signaling multiple audio mixing gains in a remote conference using Real-Time Transmission Control Protocol (RTCP) feedback. The method may include: receiving an input audio stream from a 360-degree stream, the input audio stream including the mixing gains; declaring an RTCP feedback rate for receiving the mixing gains based on allocated bandwidth; and signaling the mixing gains using the declared RTCP feedback rate.
[0012] According to an embodiment, an apparatus is provided for signaling multiple audio mixing gains in a remote conference using Real-Time Transmission Control Protocol (RTCP) feedback. The apparatus may include: one or more memories configured to store program code, and one or more processors configured to read the program code and operate as instructed by the program code. The program code includes: receive code configured to cause at least one processor to receive an input audio stream from a 360-degree stream, the input audio stream including the mixing gains; declaration code configured to cause at least one processor to declare an RTCP feedback rate for receiving the mixing gains based on allocated bandwidth; and signaling code configured to cause at least one processor to signal the mixing gains using the declared RTCP feedback rate.
[0013] According to an embodiment, a non-volatile computer-readable medium is provided for signaling multiple audio mixing gains in a remote conference using Real-Time Transmission Control Protocol (RTCP) feedback. The computer-readable medium may be connected to one or more processors and may be configured to store instructions that, when executed by at least one processor of a device, cause at least one or more processors to receive an input audio stream including the mixing gains from a 360-degree stream, declare an RTCP feedback rate for receiving the mixing gains based on allocated bandwidth, and signal the mixing gains using the declared RTCP feedback rate.
[0014] Additional aspects will be set forth in part in the description which follows, and in part will be apparent from the description, or may be learned by practice of the embodiments of this disclosure presented. Attached Figure Description
[0015] The above and other aspects, features and aspects of embodiments of the present disclosure will become more apparent from the following description taken in conjunction with the accompanying drawings.
[0016] Figure 1 is a schematic diagram of the ecosystem for immersive remote conferencing.
[0017] Figure 2A is a schematic diagram of a multi-party, multi-meeting room remote conference.
[0018] Figure 2B is a schematic diagram of a multi-party, multi-meeting room remote conference using MRF / MCU.
[0019] Figure 3 is a simplified block diagram of a communication system according to one or more embodiments.
[0020] Figure 4 is a simplified example illustration of a streaming environment according to one or more embodiments.
[0021] Figure 5 is a flowchart of a method for signaling multiple audio mixing gains using RTCP feedback, according to one or more embodiments.
[0022] Figure 6 is a schematic diagram of a computer system according to one or more embodiments. Detailed Implementation
[0023] This disclosure relates to a method and apparatus for audio mixing gain using RTCP feedback to simultaneously send signal notifications and superimpose 360-degree streams.
[0024] As shown in Figures 2A and 2B, multiple conference rooms with omnidirectional cameras are in a remote conference. The user selects a video / audio stream to be displayed as an immersive stream from one of the conference rooms (2a01, 2a02, 2a03, 2a04). Any additional audio or video streams used simultaneously with the 360-degree immersive stream are sent as an overlay (i.e., as separate streams). Upon receiving multiple audio streams, the terminal device decodes them and mixes them to present to the user. The sending conference room provides the mixing gain level for all the different audio streams. The sending conference room can also update the mixing gain level for the different audio streams during the remote conference session. The audio mixing gain can be defined for each audio stream. Therefore, it is necessary to use a single header extension to send / receive all audio gains (r0, r1, ..., r) as detailed in the embodiments of this disclosure. N ) and overlay videos (a1, a2, ..., a N The method.
[0025] Embodiments of this disclosure are described in full below with reference to the accompanying drawings. However, examples of embodiments can be implemented in a variety of forms, and this disclosure should not be construed as limited to the examples described herein. Rather, examples of embodiments are provided to make the technical solutions of this disclosure more comprehensive and complete, and to fully convey the concept of the examples of embodiments to those skilled in the art. The drawings are merely illustrative of this disclosure and are not necessarily drawn to scale. The same reference numerals in the drawings denote the same or similar parts, and therefore repeated descriptions of these parts are omitted.
[0026] The features discussed below can be used individually or in any combination in any order. Some block diagrams shown in the accompanying drawings are functional entities and do not necessarily correspond to physically or logically independent entities. Furthermore, embodiments can be implemented by processing circuitry (e.g., one or more processors or one or more integrated circuits), or in software, or in different network and / or processor devices and / or microcontroller devices. In one example, one or more processors execute a program stored on a non-volatile computer-readable medium.
[0027] Figure 3 is a simplified block diagram of a communication system (300) according to an embodiment of the present disclosure. The communication system (300) may include at least two terminals (302, 303) interconnected via a network (305). For unidirectional data transmission, the first terminal (303) may encode video data locally for transmission to the other terminal (302) via the network (305). The second terminal (302) may receive the encoded video data from the other terminal from the network (305), decode the encoded data, and display the recovered video data. Unidirectional data transmission may be common in media service applications such as teleconferencing.
[0028] Figure 3 illustrates a second pair of terminals (301, 304) provided to support bidirectional transmission of encoded video, for example, during video conferencing. For bidirectional data transmission, each terminal (301, 304) can encode video data acquired at a local location for transmission to the other terminal via a network (305). Each terminal (301, 304) can also receive encoded video data transmitted from the other terminal, decode and mix the encoded data, and display the recovered video data on a local display device.
[0029] In Figure 3, terminals (301, 302, 303, 304) may be illustrated as servers, personal computers, and mobile devices, but the principles of this disclosure are not limited thereto. Embodiments of this disclosure are applicable to laptop computers, tablet computers, head-mounted displays (HMDs), other media players, and / or dedicated video conferencing equipment. Network (305) refers to any number of networks that transmit encoded video data between terminals (301, 302, 303, 304), including, for example, wired and / or wireless communication networks. Communication network 305 may exchange data in circuit-switched and / or packet-switched channels. Representative networks include telecommunications networks, local area networks (LANs), wide area networks (WANs), and / or the Internet. The hybrid gain discussed in embodiments of this disclosure can be transmitted and received via network (305), etc., using network protocols explained below.
[0030] Figure 4 illustrates an example streaming environment for an application using the disclosed topics. The disclosed topics can be equivalently applied to other video-enabled applications, including, for example, immersive remote conferencing calls, video conferencing, and telepresence.
[0031] A streaming environment may include one or more conference rooms (403), which may include a video source (401) (e.g., a camera) and one or more participants (402) in the conference. The video source (401) illustrated in Figure 4 is, for example, a 360-degree camera that can create a sample video stream. The sample video stream may be sent to and / or stored thereon on a streaming server (404) for future use. One or more streaming clients (405, 406) may also send their respective viewport information to the streaming server (404). Based on the viewport information, the streaming server (404) may send the viewport-related stream to the corresponding streaming client (405, 406). In another example embodiment, the streaming client (405, 406) may access the streaming server (404) to retrieve the viewport-related stream. The streaming server (404) and / or the streaming clients (405, 406) may include hardware, software, or a combination thereof to support or implement aspects of the disclosed subject matter as described in more detail below.
[0032] In an immersive remote conferencing call, multiple audio streams can be sent from a sender (e.g., 403) to a streaming client (e.g., 405 and / or 406). These streams may include audio streams for 360-degree video and one or more audio streams for overlay. The streaming client (405, 406) may include mixing components (407a, 407b). The mixing components can decode and mix the 360-degree video and the overlay viewport-related streams, and create an output video sample stream that can be presented on a display 408 or other presentation devices such as an HDM, speaker, mobile device, etc. The embodiment is not limited to this configuration; one or more conference rooms (403) may communicate with the streaming client (405, 406) via a network (e.g., network 305).
[0033] The following description, based on an embodiment, will now describe how multiple audio mixing gains are signaled from the server to the streaming client via RTCP feedback packets.
[0034] A streaming client (hereinafter referred to as the "receiver") can indicate its ability to receive audio gain using the following Session Description Protocol (SDP) attributes:
[0035] a = rtcp-fb:*audio-mix-gain
[0036] The receiver can define the RTCP feedback frequency capability using SDP. In the same or another embodiment, the RTCP feedback can be sent by the server at a constant or variable rate. When sending RTCP feedback at a constant rate, the RTCP feedback may also include other information, such as viewport orientation information and general RTCP reporting. In this case, the server follows the standard 5% bandwidth allocated for RTCP traffic (without the 5-second minimum RTCP transmission interval allowed by the RTP / AVPF profile). Table 1 shows the RTCP feedback frequency sufficient to send audio gain, assuming an RTCP packet size of 96 bytes, including audio and RTCP feedback bit rate requirements.
[0037] Table 1
[0038]
[0039]
[0040] In the same or another example embodiment, the audio gain transmitted (via RTCP feedback) can be sent by the server based on event-based feedback (i.e., sending RTCP feedback at a variable rate). In this case, RTCP feedback on the audio gain can be given immediately in the event of any change in audio mix gain. In the same or another example embodiment, the receiver can define a bandwidth different from the standard 5%.
[0041] The receiver can send instant event-based feedback provided the following conditions are met:
[0042] The number of events per interval is less than or equal to the bandwidth allocated to RTCP / the average RTCP packet size (1).
[0043] Events per interval = Average number of reported events / Time interval (2)
[0044] For audio, event-based feedback intervals can be sent whenever the audio mixing gain changes. Therefore, to adhere to the standard 5% bandwidth allocation for permitted RTCP traffic, the server will only send data at intervals less than T. E The interval does not trigger immediate event-based feedback, where:
[0045] T E => Average RTCP packet size / RTCP allocated bandwidth (3)
[0046] Figure 5 is a flowchart of a method 500 for signaling multiple audio mixing gains using RTCP feedback according to one or more embodiments.
[0047] As shown in Figure 5, in operation 510, method 500 includes receiving an input audio stream from a 360-degree stream, the input audio stream including a mixing gain. The mixing gain includes an audio gain from the input audio stream and an audio gain from the superimposed audio stream.
[0048] In operation 520, method 500 includes declaring an RTCP feedback rate for receiving mixed gain based on the allocated bandwidth. The RTCP feedback rate can be a constant feedback rate or an event-based feedback rate. The event-based rate is triggered only for event intervals based on the average RTCP packet size and the allocated bandwidth.
[0049] In operation 530, method 500 includes signaling the hybrid gain using the declared RTCP feedback rate.
[0050] Although Figure 5 shows example blocks of the method, in some implementations, the method may include additional blocks, fewer blocks, different blocks, or blocks arranged differently compared to those depicted in Figure 5. Additionally or alternatively, two or more blocks of the method may be performed in parallel.
[0051] The aforementioned technique of using RTCP feedback signaling to notify multiple audio mixing gains for remote conferencing and telepresence can be implemented as computer software using computer-readable instructions and physically stored in one or more computer-readable media. For example, Figure 6 illustrates a computer system 600 suitable for implementing certain embodiments of the disclosed subject matter.
[0052] The computer software can be encoded using any suitable machine code or computer language, which can be assembled, compiled, linked, or similar mechanisms to create code comprising instructions that can be executed directly or by a computer's central processing unit (CPU), graphics processing unit (GPU), etc., through interpretation, microcode execution, etc. The instructions can be executed on various types of computers or computer components, including, for example, personal computers, tablets, servers, smartphones, gaming devices, Internet of Things (IoT) devices, etc.
[0053] The components for computer system 600 shown in Figure 6 are exemplary in nature and are not intended to imply any limitation on the scope of use or functionality of the computer software implementing embodiments of this application. Nor should the configuration of the components be construed as having any dependency or requirement on any one or combination of components shown in the exemplary embodiments of computer system 600.
[0054] Computer system 600 may include certain human-machine interface input devices. Such human-machine interface input devices may respond to input from one or more human users via, for example, tactile input (e.g., key presses, swiping, data glove movement), audio input (e.g., voice, tapping), visual input (e.g., gestures), or olfactory input. The human-machine interface device may also be used to capture certain media that are not necessarily directly related to conscious human input, such as audio (e.g., speech, music, ambient sound), images (e.g., scanned images, photographic images obtained from a still image camera), and video (e.g., two-dimensional video, three-dimensional video including stereoscopic video).
[0055] The input human-machine interface device may include one or more of the following (only one of each is depicted): keyboard 601, trackpad 602, mouse 603, touch screen 609, data glove, joystick 604, microphone 605, camera 606, scanner 607.
[0056] Computer system 600 may also include certain human-machine interface (HMI) output devices. Such HMI output devices can stimulate the senses of one or more human users through, for example, tactile output, sound, light, and smell / taste. These HMI output devices may include tactile output devices (e.g., tactile feedback from a touchscreen 609, a data glove, or a joystick 604, but may also include tactile feedback devices that do not function as input devices), audio output devices (e.g., speakers 608, headphones), visual output devices (e.g., screens 609, including cathode ray tube (CRT) screens, liquid crystal display (LCD) screens, plasma screens, organic light-emitting diode (OLED) screens, each with or without touchscreen input capability, each with or without tactile feedback capability—some of which can output two-dimensional or greater than three-dimensional visual outputs, such as stereoscopic flat image outputs; virtual reality glasses, holographic displays, and smoke boxes; and printers).
[0057] The computer system 600 may also include human-accessible storage devices and associated media of the storage devices, such as optical media, including CD / DVD ROM / RW 611 with media such as CD / DVD 610, thumb drives 612, removable hard disk drives or solid-state drives 613, legacy magnetic media such as magnetic tapes and floppy disks, dedicated devices based on ROM / Application-Specific Integrated Circuits (ASICs) / Programmable Logic Devices (PLDs), such as security protection devices, etc.
[0058] Those skilled in the art should also understand that the term "computer-readable medium" used in connection with the currently disclosed subject matter does not cover transmission media, carrier waves, or other transient signals.
[0059] The computer system (600) may also include an interface 615 to one or more communication networks 614. Network 614 may be, for example, wireless, wired, or optical. Network 614 may also be local, wide area, metropolitan area, vehicular and industrial, real-time, latency-tolerant, etc. Examples of network 614 include, for example, local area networks such as Ethernet and wireless LANs; cellular networks including Global System for Mobile Communications (GSM), 3G, 4G, 5G, and LTE; wired or wireless wide area digital TV networks including cable TV, satellite TV, and terrestrial broadcast TV; and vehicular and industrial networks including Controller Area Network Bus (CANBus). Some networks 614 typically require an external network interface adapter (e.g., graphics adapter 625) attached to certain general-purpose data ports or peripheral buses 616 (e.g., the Universal Serial Bus (USB) port of computer system 600); other networks are typically integrated into the core of computer system 600 by attaching to system buses as described below (e.g., integrated into a PC computer system via an Ethernet interface, or integrated into a smartphone computer system via a cellular network interface). By using any of these networks 614, computer system 600 can communicate with other entities. Such communication can be one-way receiving (e.g., broadcasting TV), one-way transmitting (e.g., a CANBus connected to a CANBus device), or bidirectional, such as connecting to other computer systems using a local area digital network or a wide area digital network. Certain protocols and protocol stacks can be used on each of those networks and network interfaces described above.
[0060] The aforementioned human-machine interface device, human-accessible storage device, and network interface can be attached to the core 617 of the computer system 600.
[0061] Core 617 may include one or more central processing units (CPUs) 618, graphics processing units (GPUs) 619, dedicated programmable processing units in the form of field-programmable gate areas (FPGAs) 620, hardware accelerators 621 for certain tasks, and so on. These devices, along with read-only memory (ROM) 623, random access memory 624, and internal high-capacity storage devices 622 such as internal non-user-accessible hard disk drives and solid-state drives (SSDs), can be connected via system bus 626. In some computer systems, system bus 626 can be accessed via one or more physical connectors to allow expansion through additional CPUs, GPUs, etc. Peripheral devices can be attached directly or via peripheral bus 616 to the core's system bus 626. Architectures for the peripheral bus include peripheral device interconnect (PCI), USB, and so on.
[0062] The CPU 618, GPU 619, FPGA 620, and accelerator 621 can execute certain instructions, which, when combined, constitute the aforementioned computer code. The computer code can be stored in ROM 623 or RAM 624. Transient data can also be stored in RAM 624, while permanent data can be stored, for example, in an internal mass storage device 622. Fast storage and retrieval of any memory device can be achieved using a cache memory, which can be closely associated with one or more CPUs 618, GPU 619, mass storage device 622, ROM 623, RAM 624, etc.
[0063] The computer-readable medium may contain computer code for performing various computer-implemented operations. The medium and computer code may be designed and constructed specifically for the purposes of this application, or may belong to a class well-known and available to those skilled in the art of computer software.
[0064] For example, but not as a limitation, a computer system having architecture 600, and in particular core 617, can provide functionality resulting from the execution of software embodied in one or more tangible computer-readable media by a processor (including CPU, GPU, FPGA, accelerator, etc.). Such computer-readable media can be media associated with certain non-transitory storage devices (e.g., internal core storage device 622 or ROM 623) of the core 617, as described above. Software implementing various embodiments of this application can be stored in such devices and executed by core 617. Depending on specific needs, the computer-readable medium may include one or more memory devices or chips. The software can cause core 617, and specifically the processor therein (including CPU, GPU, FPGA, etc.), to perform specific processes or specific portions of specific processes described herein, including defining data structures stored in RAM 624 and modifying such data structures according to processes defined by the software. Alternatively or as an alternative, the computer system may provide functionality generated by logic hardwired or otherwise embodied in circuitry (e.g., accelerator 621), which may operate in place of or in conjunction with software to perform a particular process or a particular portion of a particular process described herein. Where appropriate, references to software may cover logic, and vice versa. Where appropriate, references to computer-readable media may cover circuitry storing software for execution (e.g., integrated circuits (ICs)), circuitry embodying logic for execution, or both. This application covers any suitable combination of hardware and software.
[0065] Although this application describes several exemplary embodiments, various modifications, arrangements, and alternative equivalents are possible within the scope of this application. Therefore, it should be understood that those skilled in the art can design various systems and methods, though not expressly shown or described herein, that embody the principles of this application, within the spirit and scope of the application.
Claims
1. A method for signaling multiple audio mixing gains in a remote conference using Real-time Transmission Control Protocol (RTCP) feedback, characterized in that, The method includes: receiving an input audio stream from a 360-degree stream, the input audio stream including a mixing gain; declaring an RTCP feedback rate for receiving the mixing gain based on an allocated bandwidth; and signaling the mixing gain using the declared RTCP feedback rate, wherein the receiver of the input audio stream indicates its ability to receive the audio mixing gain using Session Description Protocol (SDP) attributes. The receiver is configured to send event-based immediate feedback when the event in each interval is determined to be at least one of the following: less than or equal to the ratio of the bandwidth allocated to RTCP to the average RTCP packet size; equal to the average number of events reported in each time interval; and for intervals less than one that is equal to or greater than the ratio of the average RTCP packet size to the bandwidth allocated to RTCP, event-based immediate feedback is not triggered.
2. The method according to claim 1, characterized in that, The mixed gain includes a first audio gain from the input audio stream and a second audio gain from the superimposed audio stream.
3. The method according to claim 1, characterized in that, The RTCP feedback rate is a constant rate.
4. The method according to claim 1, characterized in that, The RTCP feedback rate is based on the rate of events.
5. The method according to claim 4, characterized in that, The event-based rate is triggered only when the event interval is greater than or equal to T, where T is based on the average RTCP packet size and the allocated bandwidth.
6. The method according to claim 4, characterized in that, It further includes signaling the mixed gain using the event-based rate based on the change in the mixed gain.
7. A device for signaling multiple audio mixing gains in a remote conference using Real-Time Transmission Control Protocol (RTCP) feedback, characterized in that, The device includes: a receiving module for enabling the at least one processor to receive an input audio stream from a 360-degree stream, the input audio stream including a mixing gain; a declaration module for enabling the at least one processor to declare an RTCP feedback rate for receiving the mixing gain based on an allocated bandwidth; and a signaling module for enabling the at least one processor to signal the mixing gain using the declared RTCP feedback rate, wherein the receiver of the input audio stream indicates the ability to receive the audio mixing gain using Session Description Protocol (SDP) attributes. The receiver is configured to send event-based immediate feedback when the event in each interval is determined to be at least one of the following: less than or equal to the ratio of the bandwidth allocated to RTCP to the average RTCP packet size; equal to the average number of events reported in each time interval; and for intervals less than one that is equal to or greater than the ratio of the average RTCP packet size to the bandwidth allocated to RTCP, event-based immediate feedback is not triggered.
8. The device according to claim 7, characterized in that, The mixed gain includes the audio gain from the input audio stream and the audio gain from the superimposed audio stream.
9. The device according to claim 7, characterized in that, The RTCP feedback rate is a constant rate.
10. The device according to claim 7, characterized in that, The RTCP feedback rate is based on the rate of events.
11. The device according to claim 10, characterized in that, The event-based rate is triggered only when the event interval is greater than or equal to T, where T is based on the average RTCP packet size and the allocated bandwidth.
12. The device according to claim 10, characterized in that, The signaling module is further configured to enable the at least one processor to signal the hybrid gain at the event-based rate based on the change in the hybrid gain.
13. A non-volatile computer-readable medium storing instructions, characterized in that, The instructions include: one or more instructions that, when executed by at least one processor of a device for multiple audio mixing gains in a remote conference, via feedback from stored instructions using the Real-time Transmission Control Protocol (RTCP), cause the at least one processor to perform the method of any one of claims 1 to 6.
14. An electronic device, characterized in that, The method includes a memory for storing computer-readable instructions; and a processor for reading the computer-readable instructions and executing the method according to any one of claims 1 to 6 as instructed by the computer-readable instructions.
Citation Information
Patent Citations
Method and device for video signaling and readable storage medium
CN113542209A