Media file transmission method and equipment
In Bluetooth audio transmission, the adaptive encoding protocol allows the sender and receiver to negotiate supported codec formats, directly sending media files with different codec formats. This solves the power consumption and latency issues of the sender and improves the sound quality and user experience of the receiver.
Patent Information
- Application Number
- CN202511686671.2
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2021-12-31
- Publication Date
- 2026-03-17
AI Technical Summary
In Bluetooth audio transmission, the power consumption and latency of the transmitting end are relatively high, and the audio quality transcoding results in poor playback effect and user experience on the receiving end.
An adaptive encoding protocol is adopted, in which the sending end and the receiving end negotiate the supported encoding and decoding formats, and media files with different encoding and decoding formats are sent directly via Bluetooth. The encoding and decoding format indication is carried in the media data, and the receiving end adaptively adjusts the decoding method.
Reduce power consumption and transmission latency at the transmitting end, maintain sound quality without degradation, and improve playback effect and user experience at the receiving end.
Smart Images

Figure CN121691302A_ABST
Abstract
Description
[0001] This application is a divisional application. The original application has the application number 202111679593.5 and the original application date is December 31, 2021. The entire contents of the original application are incorporated herein by reference. Technical Field
[0002] This application relates to the field of chip technology, and in particular to a method and device for transmitting media files. Background Technology
[0003] In audio transmission protocols that transmit audio data from the sending end to the receiving end via Bluetooth, when playing audio data based on the Advanced Audio Distribution Profile (A2DP), the sending end supports a variety of codec formats, such as Moving Picture Experts Group (Moving Picture Experts Group) Audio Layer III (mp3), Advanced Audio Coding (AAC), M4A (MPEG-4), and Opus. The receiving end typically uses proprietary formats such as Sub-band coding (SBC), AAC, and vendor codes according to Bluetooth codec formats.
[0004] Before sending audio data to the receiver, the sender needs to negotiate a fixed codec format with the receiver. The sender needs to decode the audio data and then encode it into the codec format negotiated via Bluetooth before sending it to the receiver. For example, the sender can support four codec formats: mp3, AAC, M4A, and opus. The receiver, supporting both network and local playback, also supports these four codec formats. The codec format negotiated between the sender and receiver via Bluetooth is SBC. When the audio data to be played by the sender is in mp3 format, the sender first decodes the mp3 audio data, then encodes the decoded data into SBC format to obtain SBC audio data, and then outputs the SBC audio data to the receiver, which then plays the SBC audio data.
[0005] However, for the sending end, this method of transcoding audio—that is, decoding before encoding—results in higher power consumption and greater latency in transmitting audio data. Furthermore, this decoding-then-encoding transcoding degrades audio quality, affecting playback and user experience at the receiving end. Summary of the Invention
[0006] This application provides a method and device for transmitting media files, which can reduce power consumption and latency when the sending end transmits media files via Bluetooth, and improve the playback effect and user experience of the receiving end without the need for transcoding.
[0007] To achieve the above objectives, the embodiments of this application adopt the following technical solutions:
[0008] In a first aspect, a method for transmitting media files is provided. The method includes: a sending end and a receiving end negotiating Bluetooth capabilities to determine that the sending end and the receiving end support an adaptive encoding protocol, wherein the adaptive encoding protocol is used by the sending end to transmit media files with different codec formats to the receiving end via Bluetooth; the sending end determining at least one codec format of the media file supported by the receiving end; the sending end and the receiving end establishing an Advanced Audio Distribution Protocol (A2DP) Bluetooth connection; the sending end determining a first codec format of a first media file to be transmitted, wherein when the receiving end supports at least one codec format including the first codec format, the sending end transmits the first media file to the receiving end, wherein media data in the first media file includes a first indication, wherein the first indication is used to indicate the first codec format.
[0009] In this way, with both the sending and receiving ends supporting adaptive encoding protocols, the sending end does not need to negotiate a fixed codec format with the receiving end for media file transmission, nor does it need to perform transcoding according to a fixed codec format. If the codec format of the media file to be sent by the sending end is within the range of codec formats supported by the receiving end, the sending end can adaptively send media files with multiple different codec formats to the receiving end, and carry a first indication of the codec format in the media data of the media file. The receiving end can adaptively adjust the decoding method according to the first indication, so that the receiving end can play media files with different codec formats when the sending and receiving ends transmit media files via Bluetooth. For the sending end, without transcoding, it can save power consumption and transmission latency. Moreover, for the receiving end, without audio quality transcoding by the sending end, the audio quality at the receiving end is not compromised, improving the playback effect and user experience.
[0010] In one possible design, the method further includes: the sending end determining a second codec format of the second media file to be sent; when the receiving end supports at least one codec format including the second codec format, the sending end sends the second media file to the receiving end; the media data in the second media file includes a second indication, which is used to indicate the second codec format; wherein the second codec format is different from the first codec format. That is, when the codec format of a second media file sent by the sending end is different from that of a first media file sent by the sending end, if the second codec format of the second media file is supported by the receiving end, the sending end only needs to carry the indication of the second codec format in the media data of the second media file. The sending end does not need to perform transcoding processing, which saves power consumption and latency, and also avoids audio quality transcoding, preventing audio quality degradation and improving the playback effect and user experience of the receiving end.
[0011] In one possible design, if the receiver supports at least one codec format, but not the first codec format, the sender transcodes the first media file in the first codec format to obtain a first media file in the second codec format. The receiver supports at least one codec format for media files, including the second codec format. The sender then sends the first media file in the second codec format to the receiver. The media data in the first media file includes a second indication, which indicates the second codec format. In other words, if the first codec format of the first media file to be sent by the sender is not supported by the receiver, transcoding is required so that the receiver can successfully play the transcoded first media file.
[0012] In one possible design, the transmitting end and receiving end negotiate Bluetooth capabilities to determine if they support an adaptive coding protocol. This includes: establishing a Bluetooth connection between the transmitting end and the receiving end; the transmitting end sending a first request to the receiving end, the first request inquiring whether the receiving end supports the adaptive coding protocol; and the transmitting end receiving a first response from the receiving end, the first response including an indication that the receiving end supports the adaptive coding protocol, and also including at least one codec format supported by the receiving end. This adaptive coding protocol allows the transmitting end to directly transmit media files with different codec formats to the receiving end without transcoding, saving power consumption on the transmitting end and improving the sound quality on the receiving end.
[0013] In one possible design, the sending end determines at least one codec format of the media file supported by the receiving end, including: the sending end determining at least one codec format of the media file supported by the receiving end, and at least one codec format locally supported by the sending end; the sending end determines a set of codec formats, where each codec format in the set is at least one codec format of the media file supported by both the sending end and the receiving end. Thus, for a media file to be sent by the sending end, if the codec format of the media file is in the set, it means that both the sending end and the receiving end support this codec format. The sending end does not need to perform transcoding processing; it only needs to carry the corresponding codec format indication in the media data when sending the media file to the receiving end.
[0014] Secondly, a method for transmitting media files is provided. The method includes: a receiving end and a sending end negotiating Bluetooth capabilities to determine that the receiving end and the sending end support an adaptive encoding protocol, wherein the adaptive encoding protocol is used by the sending end to transmit media files with different codec formats to the receiving end via Bluetooth; the receiving end transmitting at least one codec format supported by the receiving end to the sending end; the receiving end and the sending end establishing an Advanced Audio Distribution Protocol (A2DP) Bluetooth connection; the receiving end receiving a first media file transmitted by the sending end, wherein media data in the first media file includes a first indication, the first indication being used to indicate a first codec format, and the at least one codec format supported by the receiving end including the first codec format.
[0015] In this way, with both the sending and receiving ends supporting adaptive encoding protocols, the sending end does not need to negotiate a fixed codec format with the receiving end for media file transmission, nor does it need to perform transcoding according to a fixed codec format. If the codec format of the media file to be sent by the sending end is within the range of codec formats supported by the receiving end, the sending end can adaptively send media files with multiple different codec formats to the receiving end, and carry a first indication of the codec format in the media data of the media file. The receiving end can adaptively adjust the decoding method according to the first indication, so that the receiving end can play media files with different codec formats when the sending and receiving ends transmit media files via Bluetooth. For the sending end, without transcoding, it can save power consumption and transmission latency. Moreover, for the receiving end, without audio quality transcoding by the sending end, the audio quality at the receiving end is not compromised, improving the playback effect and user experience.
[0016] In one possible design, the method further includes: a receiving end receiving a second media file, the media data in the second media file including a second indication, the second indication being used to indicate a second codec format of the second media file; wherein the second codec format is different from the first codec format, and the receiving end supports at least one codec format including the second codec format.
[0017] The benefits of this design can be found in the explanation in the first aspect.
[0018] In one possible design, the receiver and transmitter negotiate Bluetooth capabilities to determine whether they support the adaptive encoding protocol, including: the receiver and transmitter establishing a Bluetooth connection; the receiver receiving a first request from the transmitter, the first request being used to inquire whether the receiver supports the adaptive encoding protocol; and the receiver sending a first response to the transmitter, the first response including an indication that the receiver supports the adaptive encoding protocol, and also including at least one encoding / decoding format supported by the receiver.
[0019] The benefits of this design can be found in the explanation in the first aspect.
[0020] Thirdly, a transmitter is provided, comprising: a negotiation unit for negotiating Bluetooth capabilities with a receiver to determine that the transmitter and receiver support an adaptive encoding protocol, wherein the adaptive encoding protocol is used by the transmitter to send media files with different codec formats to the receiver via Bluetooth; a determination unit for determining at least one codec format of the media file supported by the receiver; a connection unit for establishing an Advanced Audio Distribution Protocol (A2DP) Bluetooth connection between the transmitter and the receiver; the determination unit is further configured to determine a first codec format of a first media file to be sent; and a sending unit for sending the first media file to the receiver when the receiver supports at least one codec format including the first codec format, wherein media data in the first media file includes a first indication, the first indication being used to indicate the first codec format.
[0021] In one possible design, the determining unit is further configured to determine a second codec format of the second media file to be sent; the sending unit is further configured to send the second media file to the receiving end when the receiving end supports at least one codec format including the second codec format, wherein the media data in the second media file includes a second indication, the second indication being used to indicate the second codec format; wherein the second codec format is different from the first codec format.
[0022] In one possible design, a transcoding unit is further included, configured to: transcode the first media file in the first codec format to obtain the first media file in the second codec format when the at least one codec format supported by the receiving end does not include the first codec format; the at least one codec format of the media file supported by the receiving end includes the second codec format; and a sending unit is further configured to send the first media file in the second codec format to the receiving end, wherein the media data in the first media file includes a second indication, the second indication being used to indicate the second codec format.
[0023] In one possible design, the negotiation unit is used to: establish a Bluetooth connection with the receiver; send a first request to the receiver, the first request being used to inquire whether the receiver supports an adaptive encoding protocol; and receive a first response from the receiver, the first response including an indication that the receiver supports the adaptive encoding protocol, and also including at least one encoding / decoding format supported by the receiver.
[0024] In one possible design, the determining unit is used to: determine at least one codec format of a media file supported by the receiving end and at least one codec format locally supported by the sending end; determine a set of codec formats, wherein each codec format in the set is at least one codec format of a media file supported by both the sending end and the receiving end.
[0025] Fourthly, a receiving end is provided, comprising: a negotiation unit for negotiating Bluetooth capabilities with a sending end, determining that the receiving end and the sending end support an adaptive encoding protocol, the adaptive encoding protocol being used by the sending end to send media files with different codec formats to the receiving end via Bluetooth; a sending unit for sending at least one codec format supported by the receiving end to the sending end; a connection unit for establishing an Advanced Audio Distribution Protocol (A2DP) Bluetooth connection with the sending end; and a receiving unit for receiving a first media file sent by the sending end, the media data in the first media file including a first indication, the first indication being used to indicate a first codec format, and the at least one codec format supported by the receiving end including the first codec format.
[0026] In one possible design, the receiving unit is further configured to: receive a second media file, wherein the media data in the second media file includes a second indication, the second indication being used to indicate a second codec format of the second media file; wherein the second codec format is different from the first codec format, and at least one codec format supported by the receiving end includes the second codec format.
[0027] In one possible design, the negotiation unit is used to: establish a Bluetooth connection with the transmitter; receive a first request sent by the transmitter, the first request being used to inquire whether the receiver supports an adaptive encoding protocol; and send a first response to the transmitter, the first response including an indication that the receiver supports the adaptive encoding protocol, and also including at least one encoding / decoding format supported by the receiver.
[0028] Fifthly, a communication device is provided, comprising at least one processor connected to a memory, the at least one processor being configured to read and execute a program stored in the memory, such that the device performs a method as described in the first aspect or any possible design of the first aspect, and / or a method as described in the second aspect or any possible design of the second aspect.
[0029] In a sixth aspect, a chip, such as a Bluetooth chip, coupled to a memory, is provided for reading and executing program instructions stored in the memory to implement the method as described in the first aspect or any possible design of the first aspect, and / or the method as described in the second aspect or any possible design of the second aspect.
[0030] A seventh aspect provides a Bluetooth device comprising: a memory and a processor. The memory and processor are coupled. The memory stores computer program code, including computer instructions. The transceiver receives and transmits data. When the processor executes the computer instructions, it causes the Bluetooth device to perform any of the media file transmission methods provided by the first aspect or its corresponding possible designs.
[0031] Eighthly, embodiments of this application provide a terminal device, including an antenna, one or more processors, and one or more memories. The one or more memories are coupled to the one or more processors, and the one or more memories are used to store computer program code, including computer instructions. When the one or more processors execute the computer instructions, the electronic device performs the media file transmission method described in any of the above aspects and any possible implementations.
[0032] Ninthly, embodiments of this application provide a computer-readable storage medium including computer instructions that, when executed on an electronic device, cause the electronic device to perform the media file transmission method in any of the above aspects and any possible implementations.
[0033] In a tenth aspect, embodiments of this application provide a computer program product that, when run on a computer or processor, causes the computer or processor to execute the media file transmission method in any of the above aspects and any possible implementations.
[0034] Eleventhly, embodiments of this application provide a computer-readable storage medium including computer instructions that, when executed on an electronic device, cause the electronic device to perform the media file transmission method in any of the above aspects and any possible implementations.
[0035] In a twelfth aspect, embodiments of this application provide a computer program product that, when run on a computer or processor, causes the computer or processor to execute the media file transmission method in any of the above aspects and any possible implementations.
[0036] In a thirteenth aspect, embodiments of this application provide a system that may include a sender and a receiver as described in any of the possible implementations of any of the foregoing aspects. The sender and receiver may execute the media file transmission method described in any of the foregoing aspects and any of the possible implementations.
[0037] It is understood that any of the transmitters, receivers, chips, computer-readable storage media, or computer program products provided above can be applied to the corresponding methods provided above. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects in the corresponding methods, and will not be repeated here.
[0038] These or other aspects of this application will become more readily apparent in the following description. Attached Figure Description
[0039] Figure 1 A schematic diagram illustrating the process of transmitting audio files between a Bluetooth audio transmitter and receiver, provided in an embodiment of this application;
[0040] Figure 2 A schematic diagram of a network architecture provided for an embodiment of this application;
[0041] Figure 3 A schematic diagram illustrating the encapsulation and transmission process of an audio data packet format in an audio file, provided for an embodiment of this application;
[0042] Figure 4 This application provides a schematic flowchart of a media file transmission method according to an embodiment of the present application.
[0043] Figure 5 This application provides a schematic flowchart of a media file transmission method according to an embodiment of the present application.
[0044] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application;
[0045] Figure 7 This is a schematic diagram of the structure of a terminal device provided in an embodiment of this application;
[0046] Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation
[0047] For ease of understanding, the examples provide explanations of some concepts related to the embodiments of this application for reference. As shown below:
[0048] A2DP is a Bluetooth audio transmission protocol that defines the protocol and process for distributing high-quality mono or stereo audio content over an asynchronous connectionless link (ACL) channel. It can be applied to playback devices such as Bluetooth headsets, Bluetooth speakers, and car speakers. This protocol specifies the protocol stack software and usage methods for transmitting high-quality audio data using Bluetooth asynchronous transmission channels. Based on this protocol, the sender can transmit high-quality stereo music via Bluetooth. A typical use case is for the sender to stream music content from a stereo music player to headphones or speakers. The audio data is compressed in an appropriate format to effectively utilize limited bandwidth. A2DP focuses on audio streaming, enabling users to distribute high-quality audio content.
[0049] Codec Support Formats: A2DP defines the mandatory and optional codecs supported in the configuration file, as shown in Table 1.
[0050] Table 1
[0051] Codec type Support SBC M MPEG-1, 2Audio O MPEG-2, 4AAC O ATRAC family O
[0052] SBC is the encoding method that both the transmitter and receiver must support, as specified in A2DP. Motion Picture Expert Group (MPEG)-1, 2Audio, MPEG-2, 4AAC, and the Adaptive Transform Acoustic Coding (ATRAC) family are optional encoding methods.
[0053] Vendor-specific A2DP codecs: These include codec types not listed in Table 1, codec formats assigned via Bluetooth, or mandatory or optional codec types used inconsistently by the sender and receiver. For example, mp3 and opus are not among the encoding types defined in Table 1, and mp3 and opus can be understood as vendor-specific A2DP codecs or vendor-specific encoding methods.
[0054] The suppliers here can be understood as suppliers of Bluetooth chips.
[0055] Codec-specific information elements: As shown in Table 2, Table 2 shows the specific codec information elements of the vendor-specific A2DP codec used in the transmission of signaling between the sender and receiver.
[0056] Table 2
[0057] Supplier ID Vendor-Specific Codec ID Vendor-Specific Value
[0058] Media packet format: As shown in Table 3, this refers to the media packet format transmitted from the sending end to the receiving end when establishing a Bluetooth connection, such as the format of audio data.
[0059] Table 3
[0060]
[0061]
[0062] Here, Time Stamp represents the timestamp of the transmitted media packet, and Synchronization Source (SSRC) is used to indicate a source of audio data to avoid dependence on network addresses. All packets sent within the same SSRC have the same timing and sequence number intervals, allowing the receiver to group and sort received data packets using the SSRC. An SSRC may change over time, altering the audio encoding data format. CSRC 1…CSRC n represent contributor sources; each CSRC identifies all contributor sources in the payload contained within the audio data. MediaPayload represents the audio content of the audio data.
[0063] Among them, Time Stamp and SSRC are mandatory formats in the media packet format, while CSRC 1...CSRCn are extension formats in the media packet format. Both mandatory and extension formats are formats in the media packet header (MP) of the media packet format.
[0064] The technical solutions of the embodiments of this application will be described below with reference to the accompanying drawings. In the description of the embodiments of this application, unless otherwise stated, " / " means "or," for example, A / B can mean A or B; "and / or" in this text is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Furthermore, in the description of the embodiments of this application, "multiple" refers to two or more than two.
[0065] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this embodiment, unless otherwise stated, "a plurality of" means two or more.
[0066] The Bluetooth audio transmitter typically selects high-quality audio data (high-quality audio codec) by comparing the audio codec format of its local audio file with the audio codec format supported by the Bluetooth audio receiver. This high-quality audio data is then transmitted from the transmitter to the receiver in A2DP audio codec format. If the Bluetooth audio receiver supports an audio codec format that includes the transmitter's local audio file, the transmitter selects the local audio file's audio codec format as the A2DP transmission audio codec format and adds an audio playback module to the Bluetooth audio transmitter. In this way, the Bluetooth audio transmitter does not need to acquire high-quality audio data through the operating system's sound card, nor does it need to perform audio codec format conversion; it can directly transmit high-quality audio data to the Bluetooth audio receiver via the A2DP link in the local audio file's audio codec format.
[0067] Specifically, such as Figure 1 The diagram illustrates the process of transmitting audio files between the Bluetooth audio transmitter and receiver. This process includes:
[0068] (1) The sending end can first obtain the audio codec format of the local audio file;
[0069] (2) The transmitter and receiver establish a Bluetooth connection;
[0070] (3) The sending end queries the receiving end for the audio codec formats supported;
[0071] (4) The receiving end returns the audio codec formats supported by the receiving end;
[0072] (5) The sending end determines whether the audio codec formats supported by the receiving end include the audio codec formats of the sending end's local audio files;
[0073] (6) The transmitting end selects one of the audio codec formats supported by the receiving end as the A2DP transmission audio codec format;
[0074] (7) The sending end and the receiving end establish an A2DP connection;
[0075] (8) The sending end converts the audio codec format of the local audio file to the A2DP transmission audio codec format;
[0076] (9) The sending end transmits high-quality audio data in A2DP transmission audio codec format.
[0077] It is known that once the sending and receiving ends agree on an audio codec format for A2DP transmission, the sending end needs to transcode all audio files to be sent into the selected A2DP transmission audio codec format. This involves decoding and encoding processes, resulting in significant power consumption and latency for the sending end. Furthermore, audio quality is degraded during transcoding, affecting the playback effect and user experience at the receiving end.
[0078] For example, in current Bluetooth audio file transmission processes, the negotiation of Bluetooth audio formats is rather rigid. Assuming the receiving end's Bluetooth audio format supports SBC and AAC, and the currently negotiated A2DP transmission audio codec format is AAC, when the sending end transmits the next audio file in MP3 codec format, the sending end must convert the MP3 audio file to AAC.
[0079] Furthermore, if the sending and receiving ends renegotiate a new audio codec format for A2DP transmission, it will result in a longer processing time and affect the playback experience for the receiving end user.
[0080] In response, this application proposes a method for transmitting media files, which can be applied to scenarios involving A2DP transmission of audio codec formats. The media file can be, for example, an audio file or a video file.
[0081] This application utilizes Bluetooth A2DP adaptive transmission for various media file encoding / decoding formats, eliminating the need for transcoding and reducing power consumption and transmission latency at the transmitting end. Without transcoding, high-quality audio playback is supported, enhancing audio playback effects and user experience. Specifically, based on the adaptive encoding protocol, when the transmitting end learns that the receiving end supports multiple encoding / decoding formats, it can avoid transcoding the media file to be transmitted. Instead, it can include indication information in the media data of the media file to indicate its encoding / decoding format. Thus, when the receiving end receives the media file, it can adjust the decoding method accordingly based on the indication information, enabling playback of different media file formats via Bluetooth connection.
[0082] The network architecture used in the media file transmission method of this application can be as follows: Figure 2 As shown, it includes a transmitter and a receiver. The transmitter and receiver can establish a Bluetooth connection. The transmitter can send media files using A2DP transmission to the receiver. This media file can be, for example, an audio file or a video file.
[0083] The sending end can be a terminal device, such as a mobile phone or smartwatch.
[0084] The receiving end can be, for example, a Bluetooth headset, a Bluetooth speaker, or a car speaker.
[0085] Both the sending and receiving ends are devices that support Bluetooth transmission.
[0086] In some embodiments, the transmitting end can be understood as a Bluetooth chip that transmits media files, and the receiving end can be understood as a Bluetooth chip that receives media files.
[0087] Before introducing the media file transmission method of this application, the encapsulation and transmission process of audio data packets in audio files will be described first. For example... Figure 3 As shown, for the sending end of an audio file, the audio data to be sent must first be encoded to obtain the media payload. Then, the media payload can be encrypted (encryption is optional) to obtain the content protection header (CP). Next, it can be encapsulated using the Audio / Video Distribution Transport Protocol (AVDTP) to obtain the media packet header (MP). Finally, it can be encapsulated using the Logical Link Control and Adaptation Layer Protocol (L2CAP) to obtain the encapsulated media data, which is then sent to the receiving end.
[0088] Correspondingly, for the receiving end, the media file can be decapsulated through the L2CAP and AVDTP protocol layers, and then the decapsulated media file can be decrypted (the decryption process is optional) and decoded to obtain the decoded media data.
[0089] AVDTP defines the parameter negotiation, establishment, and transmission process of data stream handles between Bluetooth devices, as well as the signaling entity forms they exchange. This protocol is the foundational protocol of the A2DP framework. L2CAP is the multiplexing layer for Bluetooth Low Energy, which defines two basic concepts: L2CAP channel and L2CAP signaling.
[0090] This application essentially extends the extension format in MP during the media file encapsulation process by adding indication information to specify the encoding / decoding format of the media data. For example, this indication information could be a VendorSpecial Codec ID, used to indicate a vendor-specific encoding / decoding identifier.
[0091] Applying this network architecture, this application provides a method for transmitting media files, such as... Figure 4 As shown, the method includes the following steps.
[0092] 401. The sending end and the receiving end negotiate Bluetooth capabilities to determine whether the sending end and the receiving end support the adaptive encoding protocol. The adaptive encoding protocol is used by the sending end to send media files with different encoding and decoding formats to the receiving end via Bluetooth.
[0093] Accordingly, the receiver and transmitter negotiate Bluetooth capabilities to determine whether they support the adaptive coding protocol.
[0094] Taking audio files as an example, when a sender wants to transmit an audio file to a receiver via Bluetooth, if the sender sends the audio file to the receiver using different codec formats, the sender needs to negotiate with the receiver after establishing a Bluetooth connection whether both support an adaptive encoding protocol. In this case, the adaptive encoding protocol can be understood as follows: when the sender transmits an audio file to the receiver, as long as the format of the sender's local audio file is within the range of codec formats supported by the receiver, the sender can send audio files in different codec formats. For example, if the receiver supports codec formats such as SBC, AAC, and mp3, and the sender's previous audio file to be sent was in SBC codec format, the sender can directly send that SBC codec format audio file; if the sender's next audio file to be sent is in AAC codec format, the sender can directly send that AAC codec format audio file.
[0095] 402. The sending end determines at least one encoding / decoding format of the media file supported by the receiving end.
[0096] Accordingly, the receiving end sends at least one encoding / decoding format supported by the receiving end to the sending end.
[0097] In this way, when the sending end determines its local codec format, it can find the intersection of this intersection with the codec formats supported by the receiving end. If the codec format of the media file to be sent is within the intersection, the sending end can directly send the media file to the receiving end.
[0098] 403. The sending and receiving ends establish an Advanced Audio Distribution Protocol (A2DP) Bluetooth connection.
[0099] Accordingly, the receiving end and the sending end establish an Advanced Audio Distribution Protocol (A2DP) Bluetooth connection.
[0100] When the sending end wants to send a media file to the receiving end, the sending end first establishes an A2DP Bluetooth connection with the receiving end so that the sending end can send the media file to the receiving end via A2DP.
[0101] 404. When the sending end determines the first codec format of the first media file to be sent, and the receiving end supports at least one codec format including the first codec format, the sending end sends the first media file to the receiving end. The media data in the first media file includes a first indication, which is used to indicate the first codec format.
[0102] Accordingly, the receiving end receives the first media file sent by the sending end.
[0103] When the first codec format of the first media file sent by the sending end is a codec format supported by the receiving end, the sending end can directly send the first media file to the receiving end and carry a first indication in the first media file to indicate that the codec format of the first media file is the first codec format.
[0104] In this way, with both the sending and receiving ends supporting adaptive encoding protocols, the sending end does not need to negotiate a fixed codec format with the receiving end for media file transmission, nor does it need to perform transcoding according to a fixed codec format. If the codec format of the media file to be sent by the sending end is within the range of codec formats supported by the receiving end, the sending end can adaptively send media files with multiple different codec formats to the receiving end, and carry a first indication of the codec format in the media data of the media file. The receiving end can adaptively adjust the decoding method according to the first indication, so that the receiving end can play media files with different codec formats when the sending and receiving ends transmit media files via Bluetooth. For the sending end, without transcoding, it can save power consumption and transmission latency. Moreover, for the receiving end, without audio quality transcoding by the sending end, the audio quality at the receiving end is not compromised, improving the playback effect and user experience.
[0105] The method for transmitting media files according to this application will be further described below. For example... Figure 5 As shown, the method includes the following steps.
[0106] 501. The sending end and the receiving end establish a Bluetooth connection.
[0107] For example, if the sending end is a Bluetooth-enabled mobile phone and the receiving end is a Bluetooth headset, the user can control the mobile phone to establish a Bluetooth connection with the Bluetooth headset when the Bluetooth function of the mobile phone is turned on.
[0108] 502. The sending end sends a first request to the receiving end, which inquires whether the receiving end supports the adaptive encoding protocol. The adaptive encoding protocol is used by the sending end to send media files with different encoding / decoding formats to the receiving end via Bluetooth.
[0109] Accordingly, the receiving end receives the first request sent by the sending end.
[0110] The adaptive coding protocol in this application can be referred to as the ADPC (adaptive codec) protocol. The ADPC protocol can be understood as a virtual codec format capable of adaptively adapting to different codec formats. This ADPC protocol information can contain multiple codec format capabilities. When both the sender and receiver supporting A2DP support the ADPC protocol, they can negotiate the codec format capabilities they support through the ADPC protocol information. In this case, ADPC is similar to a container; this application can describe the actual audio format in the extension format of the ADPC media packet header (ADPC MP), while the frame data of the media file can still follow the standards of different codec formats of the media file.
[0111] 503. The receiving end sends a first response to the sending end. The first response includes an indication that the receiving end supports an adaptive coding protocol, and also includes at least one codec format supported by the receiving end.
[0112] The sending end receives the first response from the receiving end. When the receiving end supports the adaptive coding protocol, both the sending and receiving ends can preferentially select the adaptive coding protocol as the default Bluetooth initial format.
[0113] In some embodiments, in the current A2DP protocol, when the receiver and sender negotiate the codec format of an audio file, the receiver may carry protocol information as shown in Table 4 in its response when returning the codec format supported by the receiver to the sender.
[0114] Table 4
[0115]
[0116] Here, the sampling frequency is the sampling frequency of the audio files supported by the receiving end, and the Company ID is the identifier of the receiving end's supplier. This Company ID can be, for example, 0xXXXD or 0xYYYF, used to distinguish different Bluetooth chip suppliers for the receiving end. The Bluetooth chip can be understood as a playback device used to support the playback of audio files transmitted via Bluetooth.
[0117] In this application, the first response from the receiving end can indicate at least one codec format supported by the receiving end through at least one Vendor Special Codec ID. For example, the receiving end can send a first response to the sending end according to the rules of Vendor Special Codec IDs shown in Table 5. Of course, the sending end will store the rules shown in Table 5 so that it can determine the at least one codec format supported by the receiving end based on the rules and the first response.
[0118] Table 5
[0119]
[0120]
[0121] In this context, "Position" indicates the bit position in the first response that indicates the codec format or Vendor Special Codec ID using 16 bits. For example, if the value of bit 0 (b0) in Octet 4 of the first response is 1, it indicates that the receiver supports the SBC codec format. If the value of bit 1 (b1) in Octet 4 of the first response is 1, it indicates that the receiver supports the MPEG-1,2Audio codec format. Similarly, the receiver can use 16 bits to indicate multiple Vendor Special Codec IDs, i.e., at least one codec format supported by the receiver. For example, codec formats supported by the receiver include SBC, MPEG-1,2Audio, MPEG-2,4AAC, Adaptive Transform Acoustic Coding (ATRAC family), Free Lossless Audio Codec (FLAC), Opus, Vorbis, and Monkey's Audio (.ape) in Table 5. Of course, this application is not limited to these codec formats and may include other codec formats. RFA in Table 5 indicates reservation, meaning other codec formats may also be included. SRC (Source) can represent the sending end, and Support in SRC indicates the codec formats supported by the sending end and optional supported codec formats. SNK (sink) can represent the receiving end, and Support in SNK indicates the codec formats that the receiving end should support and optional supported codec formats.
[0122] In some embodiments, in addition to the protocol content in Table 4, this application may further extend the ADPC protocol according to the protocol information in Table 4 to indicate the file format when the receiver receives audio files via Bluetooth, as shown in Table 6 as Vendor Specific Value. The parameter values in the Vendor Specific Value returned by different receivers may be different.
[0123] Table 6
[0124]
[0125] Here, Sampling Frequency represents the sampling rate of audio data supported by the receiver. The meanings of the other parameters can be found in the descriptions of the information elements in the Vendor Specific Value in Table 7, as well as the bit length that each information element can occupy.
[0126] Table 7
[0127]
[0128]
[0129] 504. The sending end determines at least one codec format of the media file supported by the receiving end, and at least one codec format locally supported by the sending end, and determines the codec format set.
[0130] Each codec format in the codec format set is at least one codec format for media files that is supported by both the sender and receiver.
[0131] In other words, when the sending end obtains the audio file capabilities supported by the receiving end through the ADPC Vendor Special Codec ID, such as the rules in Table 5, i.e., at least one codec format supported by the receiving end, the sending end can determine at least one codec format locally supported by the sending end. Then, the sending end can obtain the intersection of the at least one codec format supported by the sending end and the codec formats supported by the receiving end, which is the codec format set.
[0132] For example, if the first response from the receiver indicates that the receiver supports codec formats including SBC, mp3, opus, M4A, and FALC, and the sender locally supports codec formats including SBC, mp3, M4A, and Vorbis, then the codec format set is SBC, mp3, and M4A.
[0133] 505. The transmitting end and the receiving end establish an A2DP Bluetooth connection.
[0134] When the sending end decides to send media files, such as audio files, via an A2DP Bluetooth connection, the sending end can first establish an A2DP Bluetooth connection with the receiving end.
[0135] 506. The sending end determines the first encoding / decoding format of the first media file to be sent. Then, it executes step 507 or step 509.
[0136] 507. When the receiving end supports at least one codec format including a first codec format, the sending end sends a first media file to the receiving end, and the media data in the first media file includes a first indication, which is used to indicate the first codec format.
[0137] Accordingly, the receiving end receives the first media file.
[0138] For example, following the example in step 504, if the first media file is a first audio file, if the sending end wants to send the first audio file via Bluetooth, the sending end can first obtain the first codec format of the first audio file. If the receiving end also supports the first codec format, the sending end can carry the first indication in the extension format of the ADPC MP of the first audio file. For example, the first indication is represented by the Vendor Special Codec ID occupying 16 bits in Table 5, and the first indication is used to indicate the first codec format.
[0139] For example, the first codec format is SBC, which is one of the codec formats supported by the receiver. The transmitter can carry a 16-bit Vendor Special Codec ID in each audio data packet of the first audio file, and the value of bit b0 in the Vendor Special Codec ID is 1, while the value of the remaining bits is 0.
[0140] 508. When the sending end determines the second codec format of the second media file to be sent, and the receiving end supports at least one codec format including the second codec format, the sending end sends the second media file to the receiving end. The media data in the second media file includes a second indication, which is used to indicate the second codec format.
[0141] The second codec format is different from the first codec format.
[0142] Accordingly, the receiving end receives the second media file.
[0143] For example, if step 507 continues to transmit a second media file to the receiving end after transmitting the first media file, and the second codec format of the second media file is M4A, since the receiving end also supports the M4A codec format, the sending end can directly send the second media file and carry a second indication in each media data in the second media file. The second indication is used to indicate M4A. In this case, the sending end can carry a 16-bit Vendor Special Codec ID in each media data packet of the second media file, and the value of bit b2 in the Vendor Special Codec ID is 1, while the values of the remaining bits are 0.
[0144] For example, if the sending end transmits an audio file of a song to the receiving end, and after sending the first song in the SBC codec format (supported by both the sending and receiving ends), the next song will also use the M4A codec format (supported by both the sending and receiving ends). In this case, the sending end does not need to renegotiate the codec format with the receiving end; it can directly send the next song's audio file to the receiving end. Each audio data point in each song's audio file carries an indication of the audio file's codec format.
[0145] In other words, when playing audio files with different codec formats, the sending end only needs to update the Vendor Special Codec ID information in the extension field of the Media packet header in the audio data packet. When the receiving end detects a change in the codec format, it can switch the codec format and play the audio.
[0146] 509. When the receiving end supports at least one codec format, which does not include the first codec format, the sending end transcodes the first media file in the first codec format to obtain the first media file in the second codec format. The receiving end supports at least one codec format for media files, which includes the second codec format.
[0147] According to the example in step 504, if the first codec format of the first media file to be sent by the sending end is Vorbis, but the codec format supported by the receiving end does not include Vorbis, the sending end can convert the Vorbis codec format to a codec format supported by the receiving end, namely the second codec format, for example, the second codec format is mp3.
[0148] In this way, the sending end can transmit the first media file in MP3 encoding / decoding format to the receiving end.
[0149] Therefore, even if the format of the first media file to be sent by the sending end is not supported by the receiving end, the sending end can flexibly transcode the encoding and decoding format of the media file to be sent, and carry an indication of the transcoded encoding and decoding format in the first media file.
[0150] 510. The sending end sends a first media file in a second codec format to the receiving end. The media data in the first media file includes a second indication, which is used to indicate the second codec format.
[0151] Accordingly, the receiving end receives the first media file.
[0152] Following the example in step 509, the second instruction, namely the Vendor Special Codec ID, is used to indicate mp3.
[0153] In this way, with both the sending and receiving ends supporting adaptive encoding protocols, the sending end does not need to negotiate a fixed codec format with the receiving end for media file transmission, nor does it need to perform transcoding according to a fixed codec format. If the codec format of the media file to be sent by the sending end is within the range of codec formats supported by the receiving end, the sending end can adaptively send media files with multiple different codec formats to the receiving end, and carry a first indication of the codec format in the media data of the media file. The receiving end can adaptively adjust the decoding method according to the first indication, so that the receiving end can play media files with different codec formats when the sending and receiving ends transmit media files via Bluetooth. For the sending end, without transcoding, it can save power consumption and transmission latency. Moreover, for the receiving end, without audio quality transcoding by the sending end, the audio quality at the receiving end is not compromised, improving the playback effect and user experience.
[0154] It is understood that, in order to achieve the above functions, electronic devices, such as the aforementioned transmitting or receiving end, include hardware and / or software modules corresponding to perform each function. Based on the algorithmic steps of the various examples described in conjunction with the embodiments disclosed herein, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in a hardware or software-driven manner depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application in conjunction with the embodiments, but such implementations should not be considered beyond the scope of this application.
[0155] This embodiment can divide the electronic device into functional modules according to the above method example. For example, each function can be divided into its own functional modules, or two or more functions can be integrated into one processing module. The integrated modules can be implemented in hardware. It should be noted that the module division in this embodiment is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods.
[0156] When dividing each function into modules according to its corresponding function. Figure 6 A schematic diagram of a possible configuration of the electronic device 60 involved in the above embodiments is shown. This electronic device can be the aforementioned transmitting end, such as... Figure 6 As shown, the electronic device 60 may include: a negotiation unit 601, a determination unit 602, a connection unit 603, a transmission unit 604, and a transcoding unit 605.
[0157] The negotiation unit 601 can be used to support the electronic device 60 in performing the above steps 401, etc., and / or other processes used in the technology described herein.
[0158] The determining unit 602 can be used to support the electronic device 60 in performing the above steps 402, 504, 506, etc., and / or other processes used in the technology described herein.
[0159] The connection unit 603 can be used to support the electronic device 60 in performing the above steps 403, 501, 505, etc., and / or other processes used in the technology described herein.
[0160] The transmitting unit 604 can be used to support the electronic device 60 in performing the above steps 404, 502, 507, 508, 509, 510, etc., and / or other processes used in the technology described herein.
[0161] It should be noted that all relevant content of each step involved in the above method embodiments can be referenced from the functional description of the corresponding functional module, and will not be repeated here.
[0162] The electronic device 60 provided in this embodiment is used to execute the above-described media file transmission method, and thus can achieve the same effect as the above-described implementation method.
[0163] When using integrated units, the electronic device 60 may include a processing module, a storage module, and a communication module. The processing module can be used to control and manage the operations of the electronic device 60; for example, it can support the electronic device 60 in executing the steps performed by the negotiation unit 601, the determination unit 602, and the transcoding unit 605. The storage module can be used to support the electronic device 60 in storing program code and data. The communication module can be used to support communication between the electronic device 60 and other devices, such as communication with a Bluetooth device.
[0164] The processing module can be a processor or a controller. It can implement or execute various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. The processor can also be a combination of functions that implement computing capabilities, such as a combination of one or more microprocessors, a combination of digital signal processing (DSP) and a microprocessor, etc. The storage module can be a memory. The communication module can specifically be a radio frequency circuit, a Bluetooth chip, a Wi-Fi chip, or other devices that interact with other electronic devices.
[0165] In one embodiment, when the processing module is a processor, the storage module is a memory, and the communication module is a transceiver, the electronic device 60 involved in this embodiment can be a device having... Figure 7 The terminal device with the structure shown.
[0166] When dividing each function into modules according to its corresponding function. Figure 8 A schematic diagram of a possible composition of the electronic device 80 involved in the above embodiments is shown. This electronic device can be the aforementioned receiver, such as... Figure 8 As shown, the electronic device 80 may include: a negotiation unit 801, a sending unit 802, a connection unit 803, and a receiving unit 804.
[0167] The negotiation unit 801 can be used to support the electronic device 80 in performing the above-described steps 401, and / or other processes used in the technology described herein.
[0168] The transmitting unit 802 can be used to support the electronic device 80 in performing the corresponding process of step 402 described above, and / or other processes used in the technology described herein.
[0169] The connection unit 803 can be used to support the electronic device 80 in performing the above steps 403, 501, 505, etc., and / or other processes used in the technology described herein.
[0170] The receiving unit 804 can be used to support the electronic device 80 in performing the corresponding processes of step 402, step 404, step 502, step 503, step 507, step 508 and step 510, and / or other processes used in the technology described herein.
[0171] It should be noted that all relevant content of each step involved in the above method embodiments can be referenced from the functional description of the corresponding functional module, and will not be repeated here.
[0172] The electronic device 80 provided in this embodiment is used to execute the above-described media file transmission method, and thus can achieve the same effect as the above-described implementation method.
[0173] When using integrated units, the electronic device 80 may include a processing module, a storage module, and a communication module. The processing module can be used to control and manage the operations of the electronic device 80; for example, it can support the electronic device 80 in executing the steps performed by the negotiation unit 801. The storage module can support the electronic device 80 in storing program code and data. The communication module can support communication between the electronic device 80 and other devices, such as communication with a Bluetooth device, and can support the electronic device 80 in executing the processes of the sending unit 802, the connecting unit 803, and the receiving unit 804.
[0174] The processing module can be a processor or a controller. It can implement or execute various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. The processor can also be a combination that implements computing functions, such as a combination of one or more microprocessors, a digital signal processing unit (DSP), and a microprocessor, etc. The storage module can be a memory. The communication module can specifically be a radio frequency circuit, a Bluetooth chip, a Wi-Fi chip, or other devices that interact with other electronic devices.
[0175] In one embodiment, when the processing module is a processor, the storage module is a memory, and the communication module is a transceiver, the electronic device 80 involved in this embodiment can be a device having... Figure 7 The terminal device with the structure shown.
[0176] This application also provides an electronic device, including one or more processors and one or more memories. The one or more memories are coupled to the one or more processors, and the one or more memories are used to store computer program code, including computer instructions. When the one or more processors execute the computer instructions, the electronic device performs the aforementioned method steps to implement the media file transmission method in the above embodiments.
[0177] Embodiments of this application also provide a computer storage medium storing computer instructions. When the computer instructions are executed on an electronic device, the electronic device performs the aforementioned method steps to implement the media file transmission method in the above embodiments.
[0178] Embodiments of this application also provide a computer program product that, when run on a computer, causes the computer to perform the aforementioned related steps to implement the media file transmission method executed by the electronic device in the above embodiments.
[0179] In addition, embodiments of this application also provide an apparatus, which may specifically be a chip or Bluetooth chip, component or module. The apparatus may include a connected processor and a memory; wherein, the memory is used to store computer execution instructions, and when the apparatus is running, the processor may execute the computer execution instructions stored in the memory to cause the chip to execute the media file transmission method executed by the electronic device in the above method embodiments.
[0180] In this embodiment, the electronic device, computer storage medium, computer program product or chip are all used to execute the corresponding method provided above. Therefore, the beneficial effects that can be achieved can be referred to the beneficial effects of the corresponding method provided above, and will not be repeated here.
[0181] Another embodiment of this application provides a system that may include the aforementioned sending end and receiving end, and can be used to implement the aforementioned media file transmission method.
[0182] Through the above description of the embodiments, those skilled in the art will understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.
[0183] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.
[0184] The units described as separate components may or may not be physically separate. A component shown as a unit can be one or more physical units; that is, it can be located in one place or distributed in multiple different locations. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.
[0185] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.
[0186] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, essentially or in other words, the parts that contribute to the prior art, or all or part of the technical solutions, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.
[0187] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.
Claims
1. A method of transmitting a media file, characterized by, The method comprises: The sending end and the receiving end perform Bluetooth capability negotiation to determine that the sending end and the receiving end support an adaptive coding protocol, and the adaptive coding protocol is used for the sending end to send media files in different coding formats to the receiving end through Bluetooth; The sending end determines a coding format set, and each coding format in the coding format set is a plurality of coding formats of media files supported by the sending end and the receiving end; The sending end and the receiving end establish a Bluetooth connection; The sending end adaptively sends a plurality of media files to the receiving end, the coding formats of the plurality of media files are different, the coding formats of the plurality of media files belong to the coding format set, and the media data of the plurality of media files all comprise first indications, and the first indications are used to indicate the coding formats corresponding to each of the plurality of media files.
2. The method of claim 1, wherein, The sending end adaptively sends a plurality of media files to the receiving end, the coding formats of the plurality of media files are different, the coding formats of the plurality of media files belong to the coding format set, and the media data of the plurality of media files all comprise first indications, and the first indications are used to indicate the coding formats corresponding to each of the plurality of media files. The sending end sends a first media file in a first coding format to the receiving end, wherein the first coding format belongs to the coding format set; The sending end sends a second media file in a second coding format to the receiving end, wherein the second coding format belongs to the coding format set, and the second coding format is different from the first coding format; Before the sending end sends the second media file in the second coding format to the receiving end, the sending end does not need to re-perform coding format negotiation with the receiving end.
3. The method of claim 2, wherein, Before the sending end sends the second media file in the second coding format to the receiving end, the method further comprises: The sending end updates second indication information of the media data in the second media file according to the second coding format, and the second indication information is used to indicate the second coding format.
4. The method according to claim 2 or 3, characterized in that, The media data in the first media file comprises first indication information, and the first indication information is used to indicate the first coding format.
5. The method according to any one of claims 2 to 4, characterized in that, The first indication information is located in an extension field of a media packet header of the first media file, and the second indication information is located in an extension field of a media packet header of the second media file.
6. A method of transmitting a media file, characterized by, The method comprises: The receiving end and the sending end perform Bluetooth capability negotiation to determine that the receiving end and the sending end support an adaptive coding protocol, and the adaptive coding protocol is used for the sending end to send media files in different coding formats to the receiving end through Bluetooth; The receiving end determines a coding format set, and each coding format in the coding format set is a plurality of coding formats of media files supported by the sending end and the receiving end; The receiving end and the sending end establish a Bluetooth connection; The receiving end receives a plurality of media files adaptively sent by the sending end, the coding formats of the plurality of media files are different, the coding formats of the plurality of media files belong to the coding format set, and the media data of the plurality of media files all comprise first indications, and the first indications are used to indicate the coding formats corresponding to each of the plurality of media files.
7. The method of claim 6, wherein, The receiving end receives a plurality of media files adaptively transmitted by the sending end, including: The receiving end receives a first media file in a first codec format, wherein the first codec format belongs to the set of codec formats; The receiving end receives a second media file in a second codec format, wherein the second codec format belongs to the set of codec formats, and the second codec format is different from the first codec format; Before the receiving end receives the second media file in the second codec format, the receiving end does not need to re-negotiate the codec format with the sending end.
8. The method of claim 7, wherein, The media data in the second media file includes second indication information, which is used to indicate the second codec format.
9. The method according to claim 7 or 8, characterized in that, The media data in the first media file includes first indication information, which is used to indicate the first codec format.
10. The method according to any one of claims 7 to 9, characterized in that, The first indication information is located in an extension field of a media packet header of the first media file, and the second indication information is located in an extension field of a media packet header of the second media file.
11. A transmitting end, characterized by, including: The negotiation unit is configured to perform Bluetooth capability negotiation with the receiving end, and determine that the sending end and the receiving end support an adaptive coding protocol, wherein the adaptive coding protocol is used for the sending end to transmit media files in different codec formats to the receiving end through Bluetooth; The determination unit is configured to determine a set of codec formats, wherein each codec format in the set of codec formats is a plurality of codec formats of media files that are supported by the sending end and the receiving end; The connection unit is configured to establish Bluetooth connection between the sending end and the receiving end; The sending unit is configured to adaptively transmit a plurality of media files to the receiving end, wherein the codec formats of the plurality of media files are different, the codec formats of the plurality of media files belong to the set of codec formats, and the media data of the plurality of media files all include first indication, which is used to indicate the codec format corresponding to each media file in the plurality of media files.
12. The sending end according to claim 11, wherein: The sending unit is specifically configured to: transmit a first media file in a first codec format to the receiving end, wherein the first codec format belongs to the set of codec formats; transmit a second media file in a second codec format to the receiving end, wherein the second codec format belongs to the set of codec formats, and the second codec format is different from the first codec format; Before the sending unit transmits the second media file in the second codec format to the receiving end, the sending end does not need to re-negotiate the codec format with the receiving end.
13. The transmitter of claim 12, wherein, The determination unit is further configured to: before the sending unit transmits the second media file in the second codec format to the receiving end, update second indication information of the media data in the second media file according to the second codec format, wherein the second indication information is used to indicate the second codec format.
14. The transmitter of claim 12 or 13, wherein, The media data in the first media file includes first indication information, which is used to indicate the first codec format.
15. The sender of any of claims 12 to 14, wherein, The first indication information is located in an extension field of a media packet header of the first media file, and the second indication information is located in an extension field of a media packet header of the second media file.
16. A receiving end, characterized by The method comprises the following steps: The negotiation unit is configured to perform Bluetooth capability negotiation with the sending terminal, and determine that the receiving terminal and the sending terminal support an adaptive coding protocol, wherein the adaptive coding protocol is used for the sending terminal to send media files in different codec formats to the receiving terminal through Bluetooth. The determination unit is configured to determine a codec format set, wherein each codec format in the codec format set is a plurality of codec formats of media files that are supported by the sending terminal and the receiving terminal. The connection unit is configured to establish Bluetooth connection with the sending terminal. The receiving unit is configured to receive a plurality of media files adaptively sent by the sending terminal, wherein the media files are in different codec formats, the codec formats belong to the codec format set, and media data of the media files each comprises first indication information, wherein the first indication information is used for indicating a corresponding codec format of each media file.
17. The receiving end of claim 16, characterized in that The receiving unit is specifically configured to: receive a first media file in a first codec format, wherein the first codec format belongs to the codec format set; receive a second media file in a second codec format, wherein the second codec format belongs to the codec format set, and the second codec format is different from the first codec format; Before the receiving unit receives the second media file in the second codec format, the receiving terminal does not need to perform codec format negotiation with the sending terminal again.
18. The receiving end of claim 17, characterized in that, Media data in the second media file comprises second indication information, wherein the second indication information is used for indicating the second codec format.
19. The receiving end according to claim 17 or 18, c h a r a c t e r i z e d b y Media data in the first media file comprises first indication information, wherein the first indication information is used for indicating the first codec format.
20. The receiving end according to any one of claims 17 to 19, characterized by, The first indication information is located in an extension field of a media packet header of the first media file, and the second indication information is located in an extension field of a media packet header of the second media file.
21. A computer-readable storage medium, characterized in that, The computer program product comprises computer instructions, and when the computer instructions run on an electronic device, the electronic device performs the method in any one of claims 1-5.
22. A computer-readable storage medium, characterized in that, The computer program product comprises computer instructions, and when the computer instructions run on an electronic device, the electronic device performs the method in any one of claims 6-10.