CN111585776A - 数据传输方法、装置、设备及计算机可读存储介质 - Google Patents

数据传输方法、装置、设备及计算机可读存储介质 Download PDF

Info

Publication number
CN111585776A
CN111585776A CN202010454618.0A CN202010454618A CN111585776A CN 111585776 A CN111585776 A CN 111585776A CN 202010454618 A CN202010454618 A CN 202010454618A CN 111585776 A CN111585776 A CN 111585776A
Authority
CN
China
Prior art keywords
terminal
mixing
value
smoothing
audio
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN202010454618.0A
Other languages
English (en)
Other versions
CN111585776B (zh
Inventor
梁俊斌
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Tencent Technology Shenzhen Co Ltd
Original Assignee
Tencent Technology Shenzhen Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Tencent Technology Shenzhen Co Ltd filed Critical Tencent Technology Shenzhen Co Ltd
Priority to CN202010454618.0A priority Critical patent/CN111585776B/zh
Publication of CN111585776A publication Critical patent/CN111585776A/zh
Application granted granted Critical
Publication of CN111585776B publication Critical patent/CN111585776B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/02Details
    • H04L12/16Arrangements for providing special services to substations
    • H04L12/18Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1863Arrangements for providing special services to substations for broadcast or conference, e.g. multicast comprising mechanisms for improved reliability, e.g. status reports
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1829Arrangements specially adapted for the receiver end
    • H04L1/1858Transmission or retransmission of more than one copy of acknowledgement message
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1829Arrangements specially adapted for the receiver end
    • H04L1/1864ARQ related signaling
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1867Arrangements specially adapted for the transmitter end
    • H04L1/189Transmission or retransmission of more than one copy of a message
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1867Arrangements specially adapted for the transmitter end
    • H04L1/1896ARQ related signaling

Abstract

本申请实施例提供一种数据传输方法、装置、设备及计算机可读存储介质,其中,方法包括:对终端集合中的每一终端在预设历史时间段内发送的音频信号进行平滑处理,得到平滑处理结果;根据每一终端的所述平滑处理结果,确定对应终端被选中为混音终端的概率值;根据每一终端的所述概率值,在所述终端集合中选择预设数量的终端作为所述混音终端;根据每一所述混音终端的当前网络状态,确定对应混音终端的当前丢包率;根据所述当前丢包率,对每一所述混音终端进行丢包重传控制。通过本申请实施例,能够提高丢包重传效率,节省网络带宽,节约用户和运营商成本。

Description

数据传输方法、装置、设备及计算机可读存储介质
技术领域
本申请实施例涉及通信技术领域,涉及但不限于一种数据传输方法、装置、设备及计算机可读存储介质。
背景技术
多人通话的通话质量主要受网络丢包影响,由于传输网络的不稳定性导致传输过程出现丢包现象,会造成接收端声音的卡顿和不连贯,使收听者体验很不好。且目前基于服务器的多人通话方案主要有两种:多人服务器混音方案和多人服务器选路方案。
目前,有多种方法来抵抗网络丢包,包括:前向纠错(FEC,Forward ErrorCorrection)、丢包隐藏(PLC,Packet Loss Concealment)和自动重传请求(ARQ,AutomaticRepeat Request)等,其中ARQ丢包重传是一种解决丢包的有效技术。相关技术中,对于多人通话的场景,通常是采用多人混音方案或多人选路方案的发送方ARQ丢包重传方式来抵抗网络丢包。
但是,相关技术中对发送方ARQ丢包重传方式的触发,均是基于服务器实际的接收丢包状态来执行的。然而有些声音源是不会被收听者最终听到的,但为了确保接收到该通道的数据包,就需要多次反复触发ARQ丢包重传,这样会降低ARQ丢包重传效率,并造成大量的带宽消耗,降低通话质量和用户体验。
发明内容
本申请实施例提供一种数据传输方法、装置、设备及计算机可读存储介质,根据每一终端的音频信号的平滑处理结果,确定终端被选中为混音终端的概率值,根据概率值选择混音终端,并根据混音终端的当前丢包率对混音终端进行数据包丢包重传控制,如此,有针对性地控制丢包重传,让被选中的混音终端触发丢包重传,能够提高丢包重传效率,并节省网络带宽,提高通话质量和用户体验。
本申请实施例的技术方案是这样实现的:
本申请实施例提供一种数据传输方法,包括:
对终端集合中的每一终端在预设历史时间段内发送的音频信号进行平滑处理,得到平滑处理结果;
根据每一终端的所述平滑处理结果,确定对应终端被选中为混音终端的概率值;
根据每一终端的所述概率值,在所述终端集合中选择预设数量的终端作为所述混音终端;
根据每一所述混音终端的当前网络状态,确定对应混音终端的当前丢包率;
根据所述当前丢包率,对每一所述混音终端进行丢包重传控制。
本申请实施例提供一种数据传输方法,包括:
终端获取在预设历史时间段内向服务器发送的音频信号;
对所述音频信号进行平滑处理,得到平滑处理结果;
根据所述平滑处理结果,确定所述终端被选中为混音终端的概率值;
当所述概率值大于阈值时,将所述终端确定为所述混音终端,并向所述服务器发送数据包;
当接收到所述服务器返回的与所述数据包对应的否定应答消息时,对所述数据包进行重传。
本申请实施例提供一种数据传输装置,包括:
第一平滑处理模块,用于对终端集合中的每一终端在预设历史时间段内发送的音频信号进行平滑处理,得到平滑处理结果;
第一确定模块,用于根据每一终端的所述平滑处理结果,确定对应终端被选中为混音终端的概率值;
选择模块,用于根据每一终端的所述概率值,在所述终端集合中选择预设数量的终端作为所述混音终端;
第二确定模块,用于根据每一所述混音终端的当前网络状态,确定对应混音终端的当前丢包率;
控制模块,用于根据所述当前丢包率,对每一所述混音终端进行丢包重传控制。
本申请实施例提供一种数据传输装置,包括:
获取模块,用于确定在预设历史时间段内向服务器发送的音频信号;
第二平滑处理模块,用于对所述音频信号进行平滑处理,得到平滑处理结果;
第三确定模块,用于根据所述平滑处理结果,确定所述终端被选中为混音终端的概率值;
发送模块,用于当所述概率值大于阈值时,将所述终端确定为所述混音终端,并向所述服务器发送数据包;
重传模块,用于当接收到所述服务器返回的与所述数据包对应的否定应答消息时,对所述数据包进行重传。
本申请实施例提供一种数据传输设备,包括:
存储器,用于存储可执行指令;处理器,用于执行所述存储器中存储的可执行指令时,实现上述的方法。
本申请实施例提供一种计算机可读存储介质,存储有可执行指令,用于引起处理器执行时,实现上述的方法。
本申请实施例具有以下有益效果:根据对每一终端在预设历史时间段内发送的音频信号进行平滑处理所得到的平滑处理结果,确定对应终端被选中为混音终端的概率值,根据概率值在终端集合中选择预设数量的终端作为混音终端,并根据混音终端的当前丢包率对混音终端进行数据包丢包重传控制。如此,有针对性地控制丢包重传,让被选中的混音终端触发丢包重传,即对于处于参与到最终多人混音通话的混音终端的数据包给予丢包重传控制,确保混音终端的音频信号的质量,避免作为发言方的混音终端由于上行网络丢包,而影响所有收听者体验的问题,同时也提高了丢包重传效率,节省了网络带宽,节约用户和运营商成本。
附图说明
图1是本申请实施例提供的数据传输系统10的一个可选的架构示意图;
图2A是本申请实施例提供的数据传输系统10应用于区块链系统的一个可选的结构示意图;
图2B是本申请实施例提供的区块结构的一个可选的示意图;
图3是本申请实施例提供的服务器300的结构示意图;
图4是本申请实施例提供的数据传输方法的一个可选的流程示意图;
图5是本申请实施例提供的数据传输方法的一个可选的流程示意图;
图6是本申请实施例提供的数据传输方法的一个可选的流程示意图;
图7是本申请实施例提供的数据传输方法的一个可选的流程示意图;
图8是本申请实施例提供的数据传输方法的一个可选的流程示意图;
图9A是相关技术中提供的多人服务器混音方案的实现流程示意图;
图9B是相关技术中提供的多人服务器选路方案的实现流程示意图;
图10A是本申请实施例提供的多人服务器混音方案的实现流程示意图;
图10B是本申请实施例提供的多人服务器选路方案的实现流程示意图。
具体实施方式
为了使本申请的目的、技术方案和优点更加清楚,下面将结合附图对本申请作进一步地详细描述,所描述的实施例不应视为对本申请的限制,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例,都属于本申请保护的范围。
在以下的描述中,涉及到“一些实施例”,其描述了所有可能实施例的子集,但是可以理解,“一些实施例”可以是所有可能实施例的相同子集或不同子集,并且可以在不冲突的情况下相互结合。除非另有定义,本申请实施例所使用的所有的技术和科学术语与属于本申请实施例的技术领域的技术人员通常理解的含义相同。本申请实施例所使用的术语只是为了描述本申请实施例的目的,不是旨在限制本申请。
为了更好地理解本申请实施例中提供的数据传输方法,首先对相关技术中的数据传输方法进行说明:
由于人耳对同一时间来自不同声源的混合信号的有效辨识能力比较有限,通常情况下人耳只能识别4人以下的同时说话声,当同一时刻说话人达到或超过4人,则混音后的声音人耳难以辨别,感觉声音杂乱而听不清楚。为了解决这个问题,多人通话的混音算法或者选路混音算法会对来自不同与会方的声音信号做加权处理或选路筛选处理,其结果将突出有限的几路声音,避免一些非主要的或者干扰的声音信号混入进而影响人耳收听效果。例如选路方案中,50人通话,其中有10人有发声,如果预设最大选路方数为3,则每一时刻只有3方的声音最终被选中,其余未被选中的47方通话数据将不被服务器转发到接收客户端。
在实际应用中,多人通话的通话质量主要受网络丢包影响,由于传输网络的不稳定性导致传输过程出现丢包现象,造成接收端声音的卡顿和不连贯,使收听者体验很不好。其中,多人通话是指参与通话的多方通过不同的设备(终端)进行音频信号采集及各种音频处理,然后经过语音编码及网络传输打包,经过网络发送到音频混音设备,混音设备将语音编码数据解码后做声音的混合叠加处理,最后各与会方的终端根据相应的混音结果信号进行声音播放。
为了抵抗网络丢包,有很多种方法,包括:FEC、PLC和ARQ等,其中ARQ丢包重传是一种解决丢包的有效技术,即当接收方检测目标数据包超时仍未接收到或者发现接收包出错,则向发送方发出请求包,请求发送方重传出错的数据或连续多个相关数据包的一种技术手段。但是,丢包重传技术需要发送方和接收方发送更多的交互数据包,即如果第一次ARQ重发包出现丢失后可能触发第二次ARQ请求执行第二次丢失包重发,而第二次重发包可能继续丢失就会触发第三次ARQ重发。如此下去网络带宽被持续消耗,对于网络能力较弱的情况也会增大网络负荷,在网络负荷较重的情况下效果不理想,另外ARQ不可避免地要额外增加重传数据包接收等待时间,减小重发的数据包到达接收端时已无效的概率,势必导致通话端到端时延的增加,影响语音交互通话的体验效果。
相关技术中的基于服务器的多人通话方案框架主要有两种:多人服务器混音方案和多人服务器选路方案,其中,多人服务器混音方案中发送端的ARQ触发是基于服务器的NACK包,通过重发丢失的数据包以抵抗网络丢包;多人服务器选路方案中发送端的ARQ也是基于服务器的检测到数据包丢失后反馈的NACK包,通过重复丢失数据包以抵抗网络丢包。
相关技术中的ARQ技术方案主要是以下几种方式:
停等式丢包重传方式:数据报文发送完成后,发送方等待接收方的状态报告,如果状态报告报文表示发送成功才发送后续的数据报文,如果状态报告报文表示发送失败则重传该报文。停等式重传方式下,发送方每发一帧后必须停下来等接收方的确认,等收到确认报文后才可能发下一帧,所以其缺点是信道利用率很低。
回退N帧丢包重传方式:在回退N帧重传方式中,当发送方接收到接收方的状态报文指示报文出错后,发送方将重传过去N个报文。回退N帧重传与停等式丢包重传不同的地方在于该方式不需要在接收到上一个数据报文的状态确认报文才发送下一个数据报文,而可以连续发送数据报文,在发送方发送数据报文过程中,如果接收到对应已发的某个数据报文的失败状态确认报文则发送方需要将该状态报文对应的数据报文及后续N帧报文进行重发。但这种重发方式对于报文乱序情况就会导致误判为丢包,导致N个成功报文被重发,影响了效率。
选择性重传方式:在选择性重传方式中,当发送方接收到接收方的状态报文指示报文出错后,发送方只需发送发生错误的报文。选择性重传与回退N帧重传方式差别在于只对没有成功收到状态确认报文的数据报文进行重发,不需要对后续N帧都要重发,其效率有所提升。
但是,相关技术中,不管是多人服务器混音的ARQ触发方案,还是多人服务器选路的ARQ触发方案,发送方ARQ的触发均是基于服务器实际的接收丢包状态来执行的,与最终通过混音或选路方式送入收听者耳朵的有效声音信号无关,也就是说,有些声音源是不会被收听者最终听到的,但可能为了确保接收到该通道的数据包,则需要多次反复ARQ的重发(因为ARQ的重发包如果继续丢失,可能需要触发第二次、第三次的ARQ)。那么,即便丢包重传解决了上行的网络丢包,但如果该通道的最终混音贡献度小或者未必选路被选中,不会被最终收听者收听到,则ARQ的执行也是无效的且消耗网络带宽资源。另外,当多人通话的与会方数较多时,例如数百上千方的超大型语音会议,这种网络带宽的消耗对于业务成本运营而言是非常可观的。
基于相关技术所存在的上述至少一个问题,本申请实施例提供一种数据传输方法,用于实现在多人语音通过过程中的丢包重传控制,以显著提升发送端的ARQ效率,在一定网络带宽下尽可能提升整体多人通话质量和体验。首先,确定终端集合中的每一终端在预设历史时间段内发送的音频信号;然后,根据对每一终端的音频信号进行平滑处理所得到的平滑处理结果,确定对应终端被选中为混音终端的概率值;并根据每一终端的概率值,在终端集合中选择预设数量的终端作为混音终端;最后,当任一混音终端发送的数据包接收失败或者任一混音终端发送的数据包发送错误时,向对应混音终端发送否定应答消息,以触发对应混音终端对所述数据包进行重传控制。如此,有针对性地控制丢包重传,能够避免作为发言方的混音终端由于上行网络丢包,而影响所有收听者体验的问题,同时也提高了丢包重传效率,节省了网络带宽,节约用户和运营商成本。
下面说明本申请实施例提供的数据传输设备的示例性应用,本申请实施例提供的数据传输设备可以实施为笔记本电脑,平板电脑,台式计算机,移动设备(例如,移动电话,便携式音乐播放器,个人数字助理,专用消息设备,便携式游戏设备)、智能机器人等任意的终端,也可以实施为服务器。下面,将说明数据传输设备实施为服务器时的示例性应用。
参见图1,图1是本申请实施例提供的数据传输系统10的一个可选的架构示意图。为支撑任意一种数据传输应用(例如多人语音通话应用),以实现对通话的数据包进行有效传输,数据传输系统10中包括终端集合100(其中,终端集合100中包括终端100a、终端100b和终端100c)、网络200和服务器300。其中,每个终端上均运行有多人语音通话应用,在实现本申请实施例的数据传输方法时,每一终端对应的用户通过在自身的终端进行多人语音通话输入语音,形成音频信号,触发终端通过网络200向服务器300发送音频信号。为了保证在多人语音通过过程中的丢包重传控制,以显著提升发送端的丢包重传效率,在一定网络带宽下尽可能提升整体多人通话质量和体验,服务器300可以确定终端集合100中的每一终端在预设历史时间段内发送的音频信号;根据对每一终端的音频信号进行平滑处理所得到的平滑处理结果,确定对应终端被选中为混音终端的概率值;根据每一终端的概率值,在终端集合100中选择预设数量的终端作为混音终端,例如,可以选择出终端100a和终端100b为混音终端。那么,在后续的多人语音通话过程中,当任一混音终端发送的数据包接收失败或者任一混音终端发送的数据包发送错误时,服务器向对应混音终端发送否定应答消息,以触发对应混音终端对数据包进行重传,例如,当终端100a发送的数据包接收失败时,服务器300向终端100a发送否定应答消息,则终端100a对数据包进行重传,向服务器300发送重传数据包,以保证音频信号的有效传输,并且在服务器接收到重传数据包之后,对音频信号进行混音处理,得到混音信号,并将混音信号发送给终端100b和终端100c。
本申请实施例涉及的数据传输系统10也可以是区块链系统的分布式系统201,参见图2A,图2A是本申请实施例提供的数据传输系统10应用于区块链系统的一个可选的结构示意图,其中,所述分布式系统201可以是由多个节点202(接入网络中的任意形式的计算设备,如服务器、用户终端)和客户端203形成的分布式节点,节点之间形成组成的点对点(P2P,Peer To Peer)网络,P2P协议是一个运行在传输控制协议(TCP,TransmissionControl Protocol)协议之上的应用层协议。在分布式系统中,任何机器如服务器、终端都可以加入而成为节点,节点包括硬件层、中间层、操作系统层和应用层。
需要说明的是,在分布式系统201中,每一节点202对应一终端100,在每一用户的终端100上,会收集该终端100的音频信号,例如,收集该终端100在预设历史时间段内发送的音频信号,从而可以在后续数据传输过程中需要进行丢包重传控制时,能够获取到每一终端的音频信号,并对音频信号进行平滑处理得到的平滑处理结果,根据平滑处理结果确定对应终端被选中为混音终端的概率值。本申请实施例中,通过收集这些音频信号,并将音频信号上链存储,能够保证在后续语音通话过程中,从区块链系统中直接获取到准确的预设历史时间段内发送的音频信号,并根据预设历史时间段内发送的音频信号直接确定出每一终端被选中为混音终端的概率值,实现对后续需要丢包重传控制的终端进行准确的定位。
本申请实施例中,在该区块链系统中,每一用户的音频信号均会被记录下来,且不可更改,并且,随着终端100进一步获取到用户的语音,会产生新的语音数据包和音频信号,因此会存在音频信号的更新,那么,区块链中所存储的数据也会发生更新,因此,能够及时地对音频信号进行更新,从而使得发送端能够根据准确的音频信号选择出准确的混音终端,以进一步对语音数据包进行高效准确的重传。
参见图2A示出的区块链系统中各节点的功能,下面对区块链系统中各节点涉及的功能进行详细介绍:
1)路由,节点具有的基本功能,用于支持节点之间的通信。节点除具有路由功能外,还可以具有以下功能:
2)应用,用于部署在区块链中,根据实际业务需求而实现特定业务,记录实现功能相关的数据形成记录数据,在记录数据中携带数字签名以表示任务数据的来源,将记录数据发送到区块链系统中的其他节点,供其他节点在验证记录数据来源以及完整性成功时,将记录数据添加到临时区块中。例如,应用实现的业务包括:2.1)钱包,用于提供进行电子货币的交易的功能,包括发起交易(即,将当前交易的交易记录发送给区块链系统中的其他节点,其他节点验证成功后,作为承认交易有效的响应,将交易的记录数据存入区块链的临时区块中;当然,钱包还支持查询电子货币地址中剩余的电子货币。2.2)共享账本,用于提供账目数据的存储、查询和修改等操作的功能,将对账目数据的操作的记录数据发送到区块链系统中的其他节点,其他节点验证有效后,作为承认账目数据有效的响应,将记录数据存入临时区块中,还可以向发起操作的节点发送确认。2.3)智能合约,计算机化的协议,可以执行某个合约的条款,通过部署在共享账本上的用于在满足一定条件时而执行的代码实现,根据实际的业务需求代码用于完成自动化的交易,例如查询买家所购买商品的物流状态,在买家签收货物后将买家的电子货币转移到商户的地址;当然,智能合约不仅限于执行用于交易的合约,还可以执行对接收的信息进行处理的合约。
3)区块链,包括一系列按照产生的先后时间顺序相互接续的区块(Block),新区块一旦加入到区块链中就不会再被移除,区块中记录了区块链系统中节点提交的记录数据。
4)共识(Consensus),是区块链网络中的一个过程,用于在涉及的多个节点之间对区块中的交易达成一致,达成一致的区块将被追加到区块链的尾部,实现共识的机制包括工作量证明(PoW,Proof of Work)、权益证明(PoS,Proof of Stake)、股份授权证明(DPoS,Delegated Proof-of-Stake)、消逝时间量证明(PoET,Proof of Elapsed Time)等。
参见图2B,图2B是本申请实施例提供的区块结构(Block Structure)的一个可选的示意图,每个区块中包括本区块存储交易记录的哈希值(本区块的哈希值)、以及前一区块的哈希值,各区块通过哈希值连接形成区块链。另外,区块中还可以包括有区块生成时的时间戳等信息。区块链(Blockchain),本质上是一个去中心化的数据库,是一串使用密码学方法相关联产生的数据块,每一个数据块中包含了相关的信息,用于验证其信息的有效性(防伪)和生成下一个区块。
参见图3,图3是本申请实施例提供的服务器300的结构示意图,图3所示的服务器300包括:至少一个处理器310、存储器350、至少一个网络接口320和用户接口330。服务器300中的各个组件通过总线系统340耦合在一起。可理解,总线系统340用于实现这些组件之间的连接通信。总线系统340除包括数据总线之外,还包括电源总线、控制总线和状态信号总线。但是为了清楚说明起见,在图3中将各种总线都标为总线系统340。
处理器310可以是一种集成电路芯片,具有信号的处理能力,例如通用处理器、数字信号处理器(DSP,Digital Signal Processor),或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等,其中,通用处理器可以是微处理器或者任何常规的处理器等。
用户接口330包括使得能够呈现媒体内容的一个或多个输出装置331,包括一个或多个扬声器和/或一个或多个视觉显示屏。用户接口330还包括一个或多个输入装置332,包括有助于用户输入的用户接口部件,比如键盘、鼠标、麦克风、触屏显示屏、摄像头、其他输入按钮和控件。
存储器350可以是可移除的,不可移除的或其组合。示例性的硬件设备包括固态存储器,硬盘驱动器,光盘驱动器等。存储器350可选地包括在物理位置上远离处理器310的一个或多个存储设备。存储器350包括易失性存储器或非易失性存储器,也可包括易失性和非易失性存储器两者。非易失性存储器可以是只读存储器(ROM,Read Only Memory),易失性存储器可以是随机存取存储器(RAM,Random Access Memory)。本申请实施例描述的存储器350旨在包括任意适合类型的存储器。在一些实施例中,存储器350能够存储数据以支持各种操作,这些数据的示例包括程序、模块和数据结构或者其子集或超集,下面示例性说明。
操作系统351,包括用于处理各种基本系统服务和执行硬件相关任务的系统程序,例如框架层、核心库层、驱动层等,用于实现各种基础业务以及处理基于硬件的任务;
网络通信模块352,用于经由一个或多个(有线或无线)网络接口320到达其他计算设备,示例性的网络接口320包括:蓝牙、无线相容性认证(WiFi)、和通用串行总线(USB,Universal Serial Bus)等;
输入处理模块353,用于对一个或多个来自一个或多个输入装置332之一的一个或多个用户输入或互动进行检测以及翻译所检测的输入或互动。
在一些实施例中,本申请实施例提供的装置可以采用软件方式实现,图3示出了存储在存储器350中的一种数据传输装置354,该数据传输装置354可以是服务器300中的一种数据传输装置,其可以是程序和插件等形式的软件,包括以下软件模块:第一平滑处理模块3541、第一确定模块3542、选择模块3543、第二确定模块3544和控制模块3545,这些模块是逻辑上的,因此根据所实现的功能可以进行任意的组合或进一步拆分。将在下文中说明各个模块的功能。
在另一些实施例中,存储在存储器350中的另一种数据传输装置,该数据传输装置可以是服务器中的另一种数据传输装置,其也可以是程序和插件等形式的软件,包括以下软件模块(图中未示出):获取模块、第二平滑处理模块、第三确定模块、发送模块和重传模块,这些模块也是逻辑上的,因此根据所实现的功能可以进行任意的组合或进一步拆分。
在再一些实施例中,本申请实施例提供的装置可以采用硬件方式实现,作为示例,本申请实施例提供的装置可以是采用硬件译码处理器形式的处理器,其被编程以执行本申请实施例提供的数据传输方法,例如,硬件译码处理器形式的处理器可以采用一个或多个应用专用集成电路(ASIC,Application Specific Integrated Circuit)、DSP、可编程逻辑器件(PLD,Programmable Logic Device)、复杂可编程逻辑器件(CPLD,ComplexProgrammable Logic Device)、现场可编程门阵列(FPGA,Field-Programmable GateArray)或其他电子元件。
下面将结合本申请实施例提供的服务器300的示例性应用和实施,说明本申请实施例提供的数据传输方法。参见图4,图4是本申请实施例提供的数据传输方法的一个可选的流程示意图,将结合图4示出的步骤进行说明。
步骤S401,服务器对终端集合中的每一终端在预设历史时间段内发送的音频信号进行平滑处理,得到平滑处理结果。
这里,终端集合中包括至少两个终端,终端集合中的每一终端均参与到多人语音通过过程中,在多人语音通话过程中,任一终端可以向服务器发送音频信号,也可以不发送音频信号。
本申请实施例中,音频信号可以是终端在预设历史时间段内发送的音频信号,预设历史时间段内发送的音频信号是用于对对应终端是否参与到当前混音处理的预判参数,通过预设历史时间段内发送的音频信号,预测对应终端当前的音频信号是否要进行混音处理。
平滑处理是指对预设历史时间段内的音频信号进行处理,以保证信号的连续性,从而使得根据平滑处理后的连续信号,能够计算出对应终端被选中为混音终端的概率值的处理方法。
步骤S402,根据每一终端的平滑处理结果,确定对应终端被选中为混音终端的概率值。
本申请实施例中,在对每一终端的音频信号进行平滑处理之后,得到平滑处理结果,然后根据平滑处理结果计算得到对应终端被选中作为混音终端的概率值。
步骤S403,根据每一终端的概率值,在终端集合中选择预设数量的终端作为混音终端。
这里,对于每一终端来说,当概率值大于阈值时,将对应终端确定为混音终端,当概率值小于阈值时,将对应终端确定为不是混音终端。本申请实施例中,可以选择预设数量的混音终端,因此,可以根据选取混音终端的预设数量和全部终端的概率值确定该阈值,或者,可以按照概率值由大到小的顺序,依次选取预设数量的混音终端。
步骤S404,根据每一混音终端的当前网络状态,确定对应混音终端的当前丢包率。
丢包率是指接收端在预设时间段内的丢包数量与接收的总数据包数量之间的比值,总数据包数量既包括成功接收到的数据包的数量,还包括未成功接收到的数据包的数量,即总数据包数量是发送端向接收端发送的数据包的总量。
这里,可以确定出当前网络状态,以及与当前网络状态相同的历史网络状态,将该历史网络状态下的丢包率确定为当前网络状态对应的当前丢包率。本申请实施例中,可以根据历史时间段内的丢包数量和接收的数据包的总数量,计算该在历史时间段内的丢包率,即计算历史网络状态下的丢包率。
步骤S405,根据当前丢包率,对每一混音终端进行丢包重传控制。
这里,当当前丢包率大于或等于丢包率阈值时,表明当前的网络状态不好,因此,需要进行丢包重传控制;当当前丢包率小于丢包率阈值时,表明当前的网络状态比较好,丢包的可能性不大,因此,也可以不进行丢包重传控制,即对于终端来说,不用重传数据包。
在一些实施例中,丢包重传控制是指,当任一混音终端发送的数据包接收失败或者任一混音终端发送的数据包发送错误时,向对应混音终端发送否定应答消息,以触发对应混音终端对数据包进行重传。或者,也可以是指当任一混音终端的当前丢包率小于丢包率阈值,且对应混音终端发送的数据包接收失败时,向对应混音终端发送否定应答消息,以触发对应混音终端对数据包进行重传。或者,当任一混音终端的当前丢包率小于丢包率阈值,且对应混音终端发送的数据包发送错误时,向对应混音终端发送否定应答消息,以触发对应混音终端对数据包进行重传。
数据接收失败是指服务器未成功接收到数据包,数据包发送错误是指所发送的数据包与服务器所请求的数据包不同。服务器在接收到数据包之后,会对数据包进行解析,确定数据包中的数据格式、数据内容等信息是否正确,如果正确的话,对数据包对应的音频信号进行混音处理,并且,向混音终端反馈确认应答消息;如果确定数据包中的数据格式、数据内容等任一信息不正确的话,则会向混音终端反馈否定应答消息。
否定应答消息是指服务器在未收到数据包或者收到错误数据包之后所反馈的消息,否定应答消息可以是“告知没有收到”或者“没有告知收到”消息(NACK,Non-Acknowledge Character)。当混音终端接收到否定应答消息时,表明服务器未接收到或者接收到错误的数据包,所以需要混音终端向服务器重发数据包。混音终端发送的数据包可以是混音终端的音频信号,当多个混音终端同时发送数据包时,服务器对多个混音终端的数据包进行解析,并进行混音处理,将多路声音信号混合成一路信号形成混音信号,并将混音信号发送至每一终端。
需要说明的是,在数据传输系统中,对于每一终端来说,接收到的是其他混音终端发送的声音信号,对于混音终端来说,接收到的也是其他混音终端发送的声音信号。对多个混音终端的声音信号进行混音处理,既可以由服务器来进行混音处理,也可以由作为每一混音信号的接收方的终端来进行混音处理。当由服务器进行混音处理时,服务器将除了接收端的音频信号之外的其他混音终端的音频信号进行混合,发送至对应的接收端;当由终端自己进行混音处理时,终端接收服务器发送的多路混音终端的音频信号,并对接收到的音频信号进行混音处理。
本申请实施例提供的数据传输方法,根据对每一终端的音频信号进行平滑处理所得到的平滑处理结果,确定对应终端被选中为混音终端的概率值,根据概率值在终端集合中选择预设数量的终端作为混音终端,并对混音终端进行数据包丢包重传控制。如此,有针对性地控制丢包重传,让被选中的混音终端触发丢包重传,即对于处于参与到最终多人混音通话的混音终端的数据包给予丢包重传控制,确保混音终端的音频信号的质量,避免作为发言方的混音终端由于上行网络丢包,而影响所有收听者体验的问题,同时也提高了丢包重传效率,节省了网络带宽,节约用户和运营商成本。
在一些实施例中,数据传输系统中包括作为混音处理方的服务器和作为音频信号发送方的终端集合,且终端集合中的终端不仅可以作为音频信号的发送端,还可以作为混音处理后的混音信号的接收端,即在用于实现多人通话的数据传输系统中,包括至少两个终端和服务器。本申请实施例以终端集合中有三个终端为例(其中两个终端为音频信号的发送方,一个终端为混音信号的接收方,当然,三个终端中的每一个终端也既可以作为混音信号的接收方,又可以作为音频信号的发送方),对本申请实施例提供的数据传输方法进行说明。图5是本申请实施例提供的数据传输方法的一个可选的流程示意图,如图5所示,方法包括以下步骤:
步骤S501,终端A获取自身在预设历史时间段内发送的音频信号A1。
步骤S502,终端A将音频信号A1发送给服务器。
步骤S503,服务器根据对音频信号A1进行平滑处理所得到的平滑处理结果,确定终端A被选中为混音终端的概率值A11。
步骤S504,服务器根据概率值A11,确定终端A为混音终端。
在上述步骤S501至步骤S504中,终端A通过向服务器发送自身在预设历史时间段内的音频信号A1,使得服务器根据音频信号A1确定终端A被选中作为混音终端的概率值A11,并根据概率至A11确定出终端A为混音终端,即确定出终端A在当前语音通过过程中,终端A的用户是作为发言方,终端A的用户的语音需要被其他终端的用户听到。
步骤S505,终端B获取自身在预设历史时间段内发送的音频信号B1。
步骤S506,终端B将音频信号B1发送给服务器。
步骤S507,服务器根据对音频信号B1进行平滑处理所得到的平滑处理结果,确定终端B被选中为混音终端的概率值B11;
步骤S508,服务器根据概率值B11,确定终端B为混音终端。
在上述步骤S505至步骤S508中,终端B的用户也是作为发言方,终端B的用户的语音也需要被其他终端的用户听到。
步骤S509,终端C获取自身在预设历史时间段内发送的音频信号C1。
步骤S510,终端C将音频信号C1发送给服务器。
步骤S511,服务器根据对音频信号C1进行平滑处理所得到的平滑处理结果,确定终端C被选中为混音终端的概率值C11。
步骤S512,服务器根据概率值C11,确定终端C不是混音终端。
在上述步骤S509至步骤S512中,终端C通过向服务器发送自身在预设历史时间段内的音频信号C1,使得服务器根据音频信号C1确定终端C被选中作为混音终端的概率值C11,并根据概率至C11确定出终端C不是混音终端,即确定出终端C在当前语音通过过程中,终端C的用户不是作为发言方或者终端C的语音为干扰语音需要被屏蔽,终端C采集的语音不需要被其他终端的用户听到。
步骤S513,服务器获取终端A发送的第一数据包和终端B发送的第二数据包。这里,在确定出混音终端之后,服务器仅接收混音终端发送的数据包。
步骤S514,服务器对第一数据包对应的音频信号和第二数据包对应的音频信号进行混音处理,得到混音信号。
这里,服务器对第一数据包进行解析得到第一音频信号,对第二数据包进行解析得到第二音频信号,并对第一音频信号和第二音频信号进行混合,形成混音信号。举例来说,第一音频信号是终端A的用户的语音,第二音频信号是终端B的用户的语音。
步骤S515,服务器将混音信号发送给终端C、将第一数据包对应的音频信号发送给终端B、将第二数据包对应的音频信号发送给终端A。
步骤S516,当终端A发送的第一数据包接收失败或者终端A发送的第一数据包发送错误时,向终端A发送否定应答消息。
这里,数据接收失败是指服务器未成功接收到数据包,数据包发送错误是指所发送的数据包与数据发送请求所请求的数据包不同。服务器在接收到数据包之后,会对数据包进行解析,确定数据包中的数据格式、数据内容等信息是否正确,如果正确的话,对混音终端发送的数据包解析后得到的音频信号进行混音处理。
步骤S517,终端A对数据包进行重传。
这里,由于终端A是混音终端,因此,服务器对终端A进行丢包重传控制,本申请实施例中,可以采用ARQ丢包重传控制,当终端A接收到服务器发送的NACK包时,即触发对数据包的重传。
步骤S518,当终端B发送的第二数据包接收失败或者终端B发送的第二数据包发送错误时,向终端B发送否定应答消息。
步骤S519,终端B对数据包进行重传。
本申请实施例提供的数据传输方法,对数据传输系统中的终端集合中的每一终端分别计算被选中作为混音终端的概率值,并根据概率值确定出特定的几个终端为混音终端,且仅对确定出的混音终端的音频信号进行混音处理,并且,仅对确定出的混音终端进行丢包重传控制,如此,可以有针对性地控制丢包重传,让被选中的混音终端触发丢包重传,避免作为发言方的混音终端由于上行网络丢包,而影响所有收听者体验的问题,同时也提高了丢包重传效率,节省了网络带宽,节约用户和运营商成本。
图6是本申请实施例提供的数据传输方法的一个可选的流程示意图,在一些实施例中,平滑处理包括累计平滑处理,如图6所示,步骤S402可以通过以下步骤实现:
步骤S601,获取每一终端在预设历史时间段内接收到的混音信号、和对应终端发送的音频信号对终端集合中的每一其他终端的混音信号的贡献值;其中,混音信号是对音频信号进行混音处理之后所得到的。
这里,依次获取每一终端接收到的混音信号,获取每一终端的音频信号对终端集合中的每一其他终端的混音信号的贡献值。
步骤S602,对混音信号和贡献值分别进行累计平滑处理,对应得到混音累计平滑值和贡献累计平滑值。
在一些实施例中,步骤S602可以通过以下步骤实现:步骤S6021,对终端集合中的至少两个终端的混音信号进行所述累计平滑处理,得到与至少两个终端对应的混音累计平滑值。步骤S6022,对对应终端对至少两个其他终端的贡献值进行累计平滑处理,得到对应终端的贡献累计平滑值。
步骤S603,根据混音累计平滑值和贡献累计平滑值,确定对应终端被选中为混音终端的概率值。
在一些实施例中,步骤S603可以通过以下步骤实现:步骤S6031,确定对应终端的贡献累计平滑值,与至少两个终端对应的混音累计平滑值之间的比值。步骤S6032,将比值确定为对应终端被选中为混音终端的概率值。
请继续参照图6,在另一些实施例中,平滑处理包括状态平滑处理;步骤S402可以通过以下步骤实现:
步骤S611,确定每一终端的音频信号的信号参数。
这里,信号参数包括以下至少之一:音频信号的能量和音频信号的信噪比。
步骤S612,根据信号参数确定对应终端被选中为混音终端的预判值。
在一些实施例中,步骤S612可以通过以下步骤实现:步骤S6121,当信号参数满足以下条件中的至少之一时:音频信号的能量大于或等于能量阈值时、和音频信号的信噪比大于或等于信噪比阈值时,确定对应终端被选中为混音终端的预判值为1;步骤S6122,当信号参数不满足所述条件中的至少之一时,确定对应终端被选中为混音终端的预判值为0。
步骤S613,根据预判值,对对应终端进行状态平滑处理,得到状态平滑值。
在一些实施例中,步骤S613可以通过以下方式实现:
当所述预判值为1时,采用以下公式(1-1)确定所述状态平滑值:
Figure BDA0002508759710000191
其中,
Figure BDA0002508759710000192
表示第i个终端的状态平滑值;α表示第一状态平滑系数,取值为[0,1];
Figure BDA0002508759710000193
表示第i-1个终端的状态平滑值;
当所述预判值为0时,采用以下公式(1-2)确定所述状态平滑值:
Figure BDA0002508759710000194
其中,η表示第二状态平滑系数,取值为[0,1]。
步骤S614,根据状态平滑值,确定对应终端被选中为混音终端的概率值。
这里,在计算出状态平滑值后,将状态平滑值对应的数值确定为对应终端被选中为混音终端的概率值。当状态平滑值较大时,对应终端被选中为混音终端的概率较高;当状态平滑值较小时,对应终端被选中为混音终端的概率较低。
图7是本申请实施例提供的数据传输方法的一个可选的流程示意图,如图7所示,在一些实施例中,步骤S403可以通过以下步骤实现:
步骤S701,按照概率值由大到小的顺序,对终端集合中的终端进行排序,形成终端序列。
步骤S702,在终端序列中选择预设数量的终端作为混音终端。
请继续参照图7,在另一些实施例中,步骤S403还可以通过以下步骤实现:
步骤S703,当任一终端的概率值大于阈值时,将对应终端确定为混音终端。
请继续参照图7,在一些实施例中,方法还可以包括以下步骤:
步骤S704,禁止接收除混音终端之外的其他终端发送的数据包。
在一种实现方式中,可以禁止接收除混音终端之外的其他终端发送的数据包,即不接收其他终端发送的数据包;或者,当任一终端被确定为不是混音终端时,服务器向不是混音终端的终端发送提醒消息,以提醒不是混音终端的终端不向服务器发送数据包,即对于其他终端来说,在被确定为不是混音终端之后,不主动向服务器发送数据包,或者不采集用户的语音。
步骤S705,对其他终端发送的数据包不进行混音处理。
在一种实现方式中,即使接收到不是混音终端的其他终端发送的数据包,也不对数据包进行混音处理,即不将其他终端的音频信号发送给每一终端。
步骤S706,对预设数量的混音终端发送的数据包进行混音处理。
本申请实施例中,在确定出混音终端之后,接收混音终端发送的数据包,并对数据包进行解析,得到每一混音终端的音频信号,然后,对音频信号进行混音处理,得到混音信号,并将混音信号输出给每一终端。需要说明的是,对于不是混音终端的终端,也正常接收混音信号,只是该终端自己的音频信号不被混音处理至任一终端的混音信号中。
在一些实施例中,对于被确定为不是混音终端的其他终端,不触发ARQ丢包重传控制或者不反复触发ARQ丢包重传控制,其中,不触发ARQ丢包重传控制是指,对于不是混音终端的其他终端,即使该终端的数据包丢失或者发送错误,服务器也不向该终端发送否定应答消息;不反复触发ARQ丢包重传控制是指对于不是混音终端的其他终端,若该终端的数据包丢失或者发送错误,服务器仅向该终端发送特定次数的否定应答消息,或者每隔预设时长向该终端反馈一次接收状态(即反馈否定应答消息或者肯定应答消息),服务器不会循环反复的发送否定应答消息直至服务器接收到该终端发送的数据包为止。
在一些实施例中,还可以由终端实现确定终端自身是否是混音终端的步骤,即终端判断自身是否为混音终端,当终端判断出自身是混音终端之后,控制自身接收服务器的否定应答消息,实现服务器对终端自身的丢包重传控制。如图8所示,是本申请实施例提供的数据传输方法的一个可选的流程示意图,方法包括以下步骤:
步骤S801,终端获取在预设历史时间段内向服务器发送的音频信号。
步骤S802,终端对音频信号进行平滑处理,得到平滑处理结果。
这里,平滑处理是指对预设历史时间段内的音频信号进行处理,以保证信号的连续性,从而使得根据平滑处理后的连续信号,能够计算出对应终端被选中为混音终端的概率值的处理方法。
步骤S803,终端根据平滑处理结果,确定终端自身被选中为混音终端的概率值。
步骤S804,当概率值大于阈值时,终端确定自身为混音终端。
步骤S805,在终端确定自身为混音终端之后,终端向服务器发送数据包。
步骤S806,当终端发送的数据包接收失败或者终端发送的数据包发送错误时,服务器向终端发送否定应答消息。
步骤S807,当接收到服务器返回的与数据包对应的否定应答消息时,终端对数据包进行重传。
本申请实施例中,由终端判断自身是否是当前多人通话的混音终端,如果是混音终端的话,终端向服务器发送数据包,并接收服务器在进行丢包重传控制时发送的否定应答消息;如果不是混音终端的话,终端不向服务器发送数据包,并且,不接收服务器在进行丢包重传控制时发送的否定应答消息。如此,由每个终端自己进行是否是混音终端的判断步骤,避免服务器对大量的终端进行判断,从而将服务器的数量处理量分散于多个终端上,提高服务器的数据处理能力,节省语音通话时的网络带宽消耗。并且,由于当确定出终端不是混音终端的话,终端不向服务器发送数据包,从而能够进一步减小服务器与终端之间传输的数据量而降低带宽消耗,保证作为发言方的混音终端由于具有较充足的带宽资源而避免上行网络丢包。
下面,将说明本申请实施例在一个实际的应用场景中的示例性应用。
本申请实施例提供一种数据传输方法,针对多人通话的特殊应用场景提出的一种有效利用丢包重传技术的方法。考虑到实际的多人通话的混音或选路方案中对声音音源的控制权,本申请实施例提供的据传输方法可以显著提升发送端的ARQ效率,在一定网络带宽下尽可能提升整体多人通话质量和体验。
本申请实施例提供一种基于多人通话混音贡献、选入状态跟踪预测调控发送端ARQ的方法,该方法根据多人通话的特性,有针对性地控制ARQ,让处于不活跃的通道不需要触发ARQ或者避免反复触发ARQ的过程,而对于处于参与到最终多人混音的通道给予合理的ARQ处理,确保其声音的质量,避免发言方由于上行网络丢包影响所有收听者体验的问题,同时也节省了网络带宽,节约用户和运营商成本。
本申请实施例的数据传输方法针对于基于服务器的多人通话方案,其中,在相关技术中,基于服务器的多人通话方案主要有两种:多人服务器混音方案和多人服务器选路方案。
图9A是相关技术中提供的多人服务器混音方案的实现流程示意图,如图9A所示,各与会方通过声音采集设备获取数字声音信号,即对各通道音频信号采集处理901,并对采集到的音频信号进行语音编码处理902,编码后的数据进行网络打包后传输到服务器90。服务器90接收相关数据包并进行丢包检测903,当检测到数据包丢失则返回NACK包(即返回丢包状态904)给发送方,实现ARQ控制905,如果在ARQ过程中接收到数据包则返回ACK包给发送方,发送方收到NACK包则重发丢失的数据包。
当服务器接收到相应数据包后进行语音解码906,得到脉冲编码调制(PCM,PulseCode Modulation)线性声音信号,根据混音算法进行多路声音混音处理907,其中,在混音处理过程中,各通道的混音信号会把自身信号排除在外的其它信号进行混音,得到混音结果。各通道对应的混音结果经过服务器的二次语音编码网络进行二次语音编码908,并将二次语音编码后得到的数据打包发送到各与会方(将各终端设备)。各与会方设备收到服务器发来的语音二次编码信号后进行语音解码909,并在语音解码后对各通道音频信号进行播放910。
在多人服务器混音方案中,发送端的ARQ触发是基于服务器的NACK包,通过重发丢失的数据包以抵抗网络丢包。
多人服务器混音方案中都是基于时域上的处理,其混音算法基本处理如以下公式(2-1):
Figure BDA0002508759710000231
其中,M表示参与多人通话的有效语音方数;ai(t)是第i方在t时刻的输入信号;bj(t)是向第j方在t时刻的混音输出信号;Wij(t)为第i方输入信号对第j方的混音权重,各语音输入方的混音权重Wij(t)有不同的方法进行计算。
混音权重Wij(t)的计算方法包括平均权重法和对齐权重法。
在平均权重法中,是将各路PCM线性信号叠加后取平均,即混音权重Wij(t)=1/M;
在对齐权重法中,分别计算各通道音频信号采样值的各自最大绝对值,以及,计算各通道线性叠加后的最大绝对值,其中,各通道音频信号采样值的各自最大绝对值通过以下公式(2-2)计算:
Figure BDA0002508759710000232
其中,TotalMaxj表示第j方(即第j通道)音频信号采样值的最大绝对值;T表示第j通道混音信号的起始时刻,Δt表示混音信号的长度。
各通道线性叠加后的最大绝对值通过以下公式(2-3)计算:
Figure BDA0002508759710000233
其中,MixedMaxj表示第j方(即第j通道)线性叠加后的最大绝对值。
在通过上述公式(2-2)和(2-3)分别计算出TotalMaxj和MixedMaxj之后,通过以下公式(2-4)计算各通道的混音权重:
Figure BDA0002508759710000241
其中,Lj∈[1,MixedMaxj/TotalMaxj],Lj用于调整最终输出混音结果的值。
经过混音算法可以根据需要对各通道信号的幅值进行放大或衰减,为解决多通道同时发声导致最终用户听不清楚的问题,混音算法可以对判为干扰或者可被忽视的通道信号进行信号衰减处理,使最终混音后用户听到的是有限通道的有效声音信号。
图9B是相关技术中提供的多人服务器选路方案的实现流程示意图,如图9B所示,各与会方通过声音采集设备获取数字声音信号,即对各通道音频信号采集处理和特征提取911,并对采集到的音频信号进行语音编码处理912,编码后的数据进行网络打包后传输到服务器90。服务器90接收相关数据包并进行丢包检测913,当检测到数据包丢失则返回NACK包(即返回丢包状态914)给发送方,实现ARQ控制915,如果在ARQ过程中接收到数据包则返回ACK包给发送方,发送方收到NACK包则重发丢失的数据包。
当服务器接收到相应数据包后进行音频选路916,被选中的通道语音码流将转发至接收客户端,在接收客户端对多个被选中的通道编码信号经过语音解码917后进行混音处理918,得到混音结果,然后,对各通道音频信号进行播放919。
多人服务器选路方案与多人服务器混音方案不同的是,选路方案不需要对各与会方发来的声音编码数据进行解码和二次编码,并且在发送方提取一些选路所需的语音特征,语音特征和语音码流打包发送到服务器,服务器根据各通道的语音特征判决哪些通道将最终参与本次的通话,即被选路算法选中,哪些通道将最终不参与本次的通话,即未被选路算法选中。被选中的通道语音码流将转发至接收客户端,在接收客户端对多个被选中的通道编码信号经过语音解码后进行混音处理,最终的混音信号进行播放。
在多人服务器选路方案中,发送端的ARQ触发是基于服务器检测到数据包丢失后反馈的NACK包,通过重发丢失数据包以抵抗网络丢包。
选路方案的选路算法主要是基于能量或信噪比等语音特征信息进行判决,例如低能量或者低信噪比的通道会大概率不被选中,而能量较大且信噪比较高的通道信号将被选中。通过选路算法能有效地降低干扰或可被忽视的通道信号最终不会出现在客户端混音信号里面,使最终混音后用户听到的是有限通道的有效声音信号。
本申请实施例考虑到实际的多人通话的混音方案或选路方案中对声音音源的控制权,提出一种能明显提升ARQ效率的多人通话ARQ控制方法,该方法可以显著提升发送端的ARQ效率,在一定网络带宽下尽可能提升整体多人通话质量和体验。
图10A是本申请实施例提供的多人服务器混音方案的实现流程示意图,如图10A所示,与图9A中的方法不同的是,发送方的上行ARQ并不仅由服务器接收丢包状态控制,ARQ控制策略在多人服务器混音方案中还会受混音信号跟踪预测值1001来协同控制,当某一通道(与会方)信号在最终混音信号的能量的占比较高时,则ARQ会根据图9A中的丢包状态执行;相反,当某一通道信号在混音信号的能量占比较低时,则ARQ控制可以关闭以减少不必要的消耗。
图10B是本申请实施例提供的多人服务器选路方案的实现流程示意图,如图10B所示,ARQ控制策略是受丢包状态和选路状态跟踪预测值1002综合来决定,当某一通道(与会方)信号选路状态跟踪预测值(即选入概率预测值)大于某阈值时,则ARQ根据图9B中基于丢包状态执行;相反,当某一通道信号选入概率预测值小于某阈值时,ARQ可以关闭以减少不必要的消耗。通过这种方法,可以有效避免某些通道混音参与度低或者不被选入的情况下仍采用消耗资源的ARQ策略。
下面对本申请实施例的服务器混音方案和服务器选路方案进行进一步说明。
在服务器混音方案中,由于服务器混音方案的混音算法,如前面公式(2-1)所述,第j通道(即第j方)混音结果为bj(t),而其中第i通道(即第i方)的混音贡献cij(t)可以通过以下公式(3-1)计算:
cij(t)=Wij(t)*ai(t) (3-1);
其中,cij(t)对应上述实施例中的终端对至少两个其他终端的贡献值。
图10A中的通过混音信号跟踪预测值1001来调控ARQ的思路如下,这里以第i通道为例:
首先,通过以下公式(3-2),计算所有通道在t时刻的混音结果的累计平滑值ball(t):
Figure BDA0002508759710000261
其中,ball(t-1)表示在t-1时刻的混音结果的累计平滑值;β表示用于将历史值和当前计算值进行平滑处理的平滑系数。ball(t)对应上述的混音累计平滑值。
然后,通过以下公式(3-3),计算第i通道在t时刻在各通道混音中的贡献累计平滑值
Figure BDA0002508759710000262
Figure BDA0002508759710000263
其中,
Figure BDA0002508759710000264
表示第i通道在t-1时刻在各通道混音中的贡献累计平滑值。
再然后,通过以下公式(3-4),计算第i通道的混音贡献比例值ri(t):
Figure BDA0002508759710000265
最后,发送方上行ARQ控制策略如下公式(3-5):
Figure BDA0002508759710000266
其中,ArqEnable表示ARQ使能开关,当ArqEnable=1时,ARQ使能开关打开;当ArqEnable=0时,ARQ使能开关关闭;R为一个(0,1)范围的阈值。
在服务器选路方案中,服务器选路方案的选路算法会输出第i通道是否被选入的判断结果,被选入定义结果si(t)=1,不被选入定义结果si(t)=0。其中,定义结果si(t)对应上述实施例中的预判值。
图10B中的通过选路状态跟踪预测来调控ARQ的思路如下,这里以第i通道为例:
首先,计算第i通道的选入状态平滑值(即状态平滑值)
Figure BDA0002508759710000271
如果si(t)=1,则通过以下公式(4-1)计算
Figure BDA0002508759710000272
Figure BDA0002508759710000273
如果si(t)=0,则通过以下公式(4-2)计算
Figure BDA0002508759710000274
Figure BDA0002508759710000275
其中,
Figure BDA0002508759710000276
表示第t-1时刻的第i通道的选入状态平滑值(即状态平滑值);α是可以设置为0到1的一个系数,对应上述第一状态平滑系数,例如α=0.1;η也是可以设置为0到1的一个系数,对应上述第二状态平滑系数,例如,η=0.98。
最后,发送方上行ARQ控制策略如下公式(4-3):
Figure BDA0002508759710000277
其中,ArqEnable表示ARQ使能开关,当ArqEnable=1时,ARQ使能开关打开;当ArqEnable=0时,ARQ使能开关关闭;C为一个(0,1)范围的阈值。
本申请实施例提供的数据传输方法,考虑到实际的多人通话的混音方案或选路方案中对声音音源的控制权,该方法根据多人通话的特性,有针对性地控制ARQ,让处于不活跃的通道不需要触发ARQ或者避免反复触发ARQ的过程,而对于处于参与到最终多人混音的通道给予合理的ARQ处理,确保其声音的质量,避免发言方由于上行网络丢包影响所有收听者体验的问题,同时也节省了网络带宽,节约用户和运营商成本,并能够显著提升发送端的ARQ效率,在一定网络带宽下尽可能提升整体多人通话质量和体验。
下面继续说明本申请实施例提供的数据传输装置354实施为软件模块的示例性结构,在一些实施例中,如图3所示,存储在存储器350的数据传输装置354中的软件模块可以是服务器300中的数据传输装置,包括:
第一平滑处理模块3541,用于对终端集合中的每一终端在预设历史时间段内发送的音频信号进行平滑处理,得到平滑处理结果;
第一确定模块3542,用于根据每一终端的所述平滑处理结果,确定对应终端被选中为混音终端的概率值;
选择模块3543,用于根据每一终端的所述概率值,在所述终端集合中选择预设数量的终端作为所述混音终端;
第二确定模块3544,用于根据每一所述混音终端的当前网络状态,确定对应混音终端的当前丢包率;
控制模块3545,用于根据所述当前丢包率,对每一所述混音终端进行丢包重传控制。
在一些实施例中,所述控制模块还用于当任一所述混音终端的所述当前丢包率小于丢包括阈值,且对应混音终端发送的数据包接收失败时,或者,当任一所述混音终端的所述当前丢包率小于丢包括阈值,且对应混音终端发送的数据包发送错误时,向对应混音终端发送否定应答消息,以触发所述对应混音终端对所述数据包进行重传。
在一些实施例中,所述平滑处理包括累计平滑处理;所述装置还包括:混音信号获取模块,用于获取每一终端接收到的混音信号,其中,所述混音信号是对所述音频信号进行混音处理之后所得到的信号;累计平滑处理模块,用于对所述终端集合中的至少两个终端的所述混音信号,进行累计平滑处理,得到混音累计平滑值;对应地,所述第一确定模块还用于:对于所述终端集合中的每一终端,确定出对应终端的所述音频信号对所述终端集合中的每一其他终端的所述混音信号的贡献值;对所述对应终端对至少两个所述其他终端的所述贡献值,进行所述累计平滑处理,得到所述对应终端的贡献累计平滑值;根据所述混音累计平滑值和所述贡献累计平滑值,确定所述对应终端被选中为所述混音终端的所述概率值。
在一些实施例中,所述第一确定模块还用于:确定所述对应终端的贡献累计平滑值,与所述至少两个终端对应的所述混音累计平滑值之间的比值;将所述比值,确定为所述对应终端被选中为混音终端的概率值。
在一些实施例中,所述平滑处理包括状态平滑处理;所述第一确定模块还用于:确定每一终端的所述音频信号的信号参数;根据所述信号参数确定对应终端被选中为混音终端的预判值;根据所述预判值,对所述对应终端进行状态平滑处理,得到状态平滑值;根据所述状态平滑值,确定所述对应终端被选中为所述混音终端的所述概率值。
在一些实施例中,所述信号参数包括以下至少之一:所述音频信号的能量和所述音频信号的信噪比;所述第一确定模块还用于:当所述信号参数满足以下条件中的至少之一时:所述音频信号的能量大于或等于能量阈值时、和所述音频信号的信噪比大于或等于信噪比阈值时,确定对应终端被选中为混音终端的预判值为1;当所述信号参数不满足所述条件中的至少之一时,确定对应终端被选中为混音终端的预判值为0。
在一些实施例中,所述第一确定模块还用于:当所述预判值为1时,采用以下公式确定所述状态平滑值:
Figure BDA0002508759710000291
其中,
Figure BDA0002508759710000292
表示第i个终端的状态平滑值;α表示第一状态平滑系数,取值为[0,1];
Figure BDA0002508759710000293
表示第i-1个终端的状态平滑值;当所述预判值为0时,采用以下公式确定所述状态平滑值:
Figure BDA0002508759710000294
其中,η表示第二状态平滑系数,取值为[0,1]。
在一些实施例中,所述选择模块还用于:按照所述概率值由大到小的顺序,对所述终端集合中的终端进行排序,形成终端序列,并在所述终端序列中选择所述预设数量的终端作为所述混音终端;或者,当任一终端的所述概率值大于阈值时,将对应终端确定为所述混音终端。
在一些实施例中,所述装置还包括:处理模块,用于禁止接收除所述混音终端之外的其他终端发送的数据包;或者,对所述其他终端发送的数据包不进行混音处理;或者,对所述预设数量的所述混音终端发送的所述数据包进行混音处理。
在另一些实施例中,存储在存储器350的数据传输装置354中的软件模块还可以是服务器300中的另一种数据传输装置(图中未示出),包括:获取模块,用于确定在预设历史时间段内向服务器发送的音频信号;第二平滑处理模块,用于对所述音频信号进行平滑处理,得到平滑处理结果;第三确定模块,用于根据所述平滑处理结果,确定所述终端被选中为混音终端的概率值;发送模块,用于当所述概率值大于阈值时,将所述终端确定为所述混音终端,并向所述服务器发送数据包;重传模块,用于当接收到所述服务器返回的与所述数据包对应的否定应答消息时,对所述数据包进行重传。
需要说明的是,本申请实施例装置的描述,与上述方法实施例的描述是类似的,具有同方法实施例相似的有益效果,因此不做赘述。对于本装置实施例中未披露的技术细节,请参照本申请方法实施例的描述而理解。
本申请实施例提供一种存储有可执行指令的存储介质,其中存储有可执行指令,当可执行指令被处理器执行时,将引起处理器执行本申请实施例提供的方法,例如,如图4示出的方法。
在一些实施例中,存储介质可以是计算机可读存储介质,例如,铁电存储器(FRAM,Ferromagnetic Random Access Memory)、只读存储器(ROM,Read Only Memory)、可编程只读存储器(PROM,Programmable Read Only Memory)、可擦除可编程只读存储器(EPROM,Erasable Programmable Read Only Memory)、带电可擦可编程只读存储器(EEPROM,Electrically Erasable Programmable Read Only Memory)、闪存、磁表面存储器、光盘、或光盘只读存储器(CD-ROM,Compact Disk-Read Only Memory)等存储器;也可以是包括上述存储器之一或任意组合的各种设备。
在一些实施例中,可执行指令可以采用程序、软件、软件模块、脚本或代码的形式,按任意形式的编程语言(包括编译或解释语言,或者声明性或过程性语言)来编写,并且其可按任意形式部署,包括被部署为独立的程序或者被部署为模块、组件、子例程或者适合在计算环境中使用的其它单元。
作为示例,可执行指令可以但不一定对应于文件系统中的文件,可以可被存储在保存其它程序或数据的文件的一部分,例如,存储在超文本标记语言(HTML,Hyper TextMarkup Language)文档中的一个或多个脚本中,存储在专用于所讨论的程序的单个文件中,或者,存储在多个协同文件(例如,存储一个或多个模块、子程序或代码部分的文件)中。作为示例,可执行指令可被部署为在一个计算设备上执行,或者在位于一个地点的多个计算设备上执行,又或者,在分布在多个地点且通过通信网络互连的多个计算设备上执行。
以上所述,仅为本申请的实施例而已,并非用于限定本申请的保护范围。凡在本申请的精神和范围之内所作的任何修改、等同替换和改进等,均包含在本申请的保护范围之内。

Claims (14)

1.一种数据传输方法,其特征在于,包括:
对终端集合中的每一终端在预设历史时间段内发送的音频信号进行平滑处理,得到平滑处理结果;
根据每一终端的所述平滑处理结果,确定对应终端被选中为混音终端的概率值;
根据每一终端的所述概率值,在所述终端集合中选择预设数量的终端作为所述混音终端;
根据每一所述混音终端的当前网络状态,确定对应混音终端的当前丢包率;
根据所述当前丢包率,对每一所述混音终端进行丢包重传控制。
2.根据权利要求1所述的方法,其特征在于,所述根据所述当前丢包率,对每一所述混音终端进行丢包重传控制,包括:
当任一所述混音终端的所述当前丢包率小于丢包括阈值,且对应混音终端发送的数据包接收失败时,或者,当任一所述混音终端的所述当前丢包率小于丢包括阈值,且对应混音终端发送的数据包发送错误时,
向对应混音终端发送否定应答消息,以触发所述对应混音终端对所述数据包进行重传。
3.根据权利要求1所述的方法,其特征在于,所述平滑处理包括累计平滑处理;所述方法还包括:
获取每一终端接收到的混音信号,其中,所述混音信号是对所述音频信号进行混音处理之后所得到的信号;
对所述终端集合中的至少两个终端的所述混音信号,进行累计平滑处理,得到混音累计平滑值;
对应地,所述根据每一终端的所述平滑处理结果,确定对应终端被选中为混音终端的概率值,包括:
对于所述终端集合中的每一终端,确定出对应终端的所述音频信号对所述终端集合中的每一其他终端的所述混音信号的贡献值;
对所述对应终端对至少两个所述其他终端的所述贡献值,进行所述累计平滑处理,得到所述对应终端的贡献累计平滑值;
根据所述混音累计平滑值和所述贡献累计平滑值,确定所述对应终端被选中为所述混音终端的所述概率值。
4.根据权利要求3所述的方法,其特征在于,所述根据所述混音累计平滑值和所述贡献累计平滑值,确定所述对应终端被选中为所述混音终端的所述概率值,包括:
确定所述对应终端的贡献累计平滑值,与所述至少两个终端对应的所述混音累计平滑值之间的比值;
将所述比值,确定为所述对应终端被选中为混音终端的概率值。
5.根据权利要求1所述的方法,其特征在于,所述平滑处理包括状态平滑处理;所述根据每一终端的所述平滑处理结果,确定对应终端被选中为混音终端的概率值,包括:
确定每一终端的所述音频信号的信号参数;
根据所述信号参数确定对应终端被选中为混音终端的预判值;
根据所述预判值对所述对应终端进行状态平滑处理,得到状态平滑值;
根据所述状态平滑值,确定所述对应终端被选中为所述混音终端的所述概率值。
6.根据权利要求5所述的方法,其特征在于,所述信号参数包括以下至少之一:所述音频信号的能量和所述音频信号的信噪比;
所述根据所述信号参数确定对应终端被选中为混音终端的预判值,包括:
当所述信号参数满足以下条件中的至少之一时:所述音频信号的能量大于或等于能量阈值时、和所述音频信号的信噪比大于或等于信噪比阈值时,确定对应终端被选中为混音终端的预判值为1;
当所述信号参数不满足所述条件中的至少之一时,确定对应终端被选中为混音终端的预判值为0。
7.根据权利要求6所述的方法,其特征在于,所述根据所述预判值,对所述对应终端进行状态平滑处理,得到状态平滑值,包括:
当所述预判值为1时,采用以下公式确定所述状态平滑值:
Figure FDA0002508759700000031
其中,
Figure FDA0002508759700000032
表示第i个终端的状态平滑值;α表示第一状态平滑系数,取值为[0,1];
Figure FDA0002508759700000033
表示第i-1个终端的状态平滑值;
当所述预判值为0时,采用以下公式确定所述状态平滑值:
Figure FDA0002508759700000034
其中,η表示第二状态平滑系数,取值为[0,1]。
8.根据权利要求1所述的方法,其特征在于,所述根据每一终端的所述概率值,在所述终端集合中选择预设数量的终端作为所述混音终端,包括:
按照所述概率值由大到小的顺序,对所述终端集合中的终端进行排序,形成终端序列,并在所述终端序列中选择所述预设数量的终端作为所述混音终端;
或者,
当任一终端的所述概率值大于阈值时,将对应终端确定为所述混音终端。
9.根据权利要求1至8任一项所述的方法,其特征在于,所述方法还包括:
禁止接收除所述混音终端之外的其他终端发送的数据包;或者,
对所述其他终端发送的数据包不进行混音处理;或者,
对所述预设数量的所述混音终端发送的所述数据包进行混音处理。
10.一种数据传输方法,其特征在于,包括:
终端获取在预设历史时间段内向服务器发送的音频信号;
对所述音频信号进行平滑处理,得到平滑处理结果;
根据所述平滑处理结果,确定所述终端被选中为混音终端的概率值;
当所述概率值大于阈值时,将所述终端确定为所述混音终端,并向所述服务器发送数据包;
当接收到所述服务器返回的与所述数据包对应的否定应答消息时,对所述数据包进行重传。
11.一种数据传输装置,其特征在于,包括:
第一平滑处理模块,用于对终端集合中的每一终端在预设历史时间段内发送的音频信号进行平滑处理,得到平滑处理结果;
第一确定模块,用于根据每一终端的所述平滑处理结果,确定对应终端被选中为混音终端的概率值;
选择模块,用于根据每一终端的所述概率值,在所述终端集合中选择预设数量的终端作为所述混音终端;
第二确定模块,用于根据每一所述混音终端的当前网络状态,确定对应混音终端的当前丢包率;
控制模块,用于根据所述当前丢包率,对每一所述混音终端进行丢包重传控制。
12.一种数据传输装置,其特征在于,包括:
获取模块,用于确定在预设历史时间段内向服务器发送的音频信号;
第二平滑处理模块,用于对所述音频信号进行平滑处理,得到平滑处理结果;
第三确定模块,用于根据所述平滑处理结果,确定所述终端被选中为混音终端的概率值;
发送模块,用于当所述概率值大于阈值时,将所述终端确定为所述混音终端,并向所述服务器发送数据包;
重传模块,用于当接收到所述服务器返回的与所述数据包对应的否定应答消息时,对所述数据包进行重传。
13.一种数据传输设备,其特征在于,包括:
存储器,用于存储可执行指令;处理器,用于执行所述存储器中存储的可执行指令时,实现权利要求1至9任一项所述的方法,或者,实现权利要求10所述的方法。
14.一种计算机可读存储介质,其特征在于,存储有可执行指令,用于引起处理器执行时,实现权利要求1至9任一项所述的方法,或者,实现权利要求10所述的方法。
CN202010454618.0A 2020-05-26 2020-05-26 数据传输方法、装置、设备及计算机可读存储介质 Active CN111585776B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202010454618.0A CN111585776B (zh) 2020-05-26 2020-05-26 数据传输方法、装置、设备及计算机可读存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202010454618.0A CN111585776B (zh) 2020-05-26 2020-05-26 数据传输方法、装置、设备及计算机可读存储介质

Publications (2)

Publication Number Publication Date
CN111585776A true CN111585776A (zh) 2020-08-25
CN111585776B CN111585776B (zh) 2021-06-11

Family

ID=72127060

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202010454618.0A Active CN111585776B (zh) 2020-05-26 2020-05-26 数据传输方法、装置、设备及计算机可读存储介质

Country Status (1)

Country Link
CN (1) CN111585776B (zh)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114448588A (zh) * 2022-01-14 2022-05-06 杭州网易智企科技有限公司 音频传输方法、装置、电子设备及计算机可读存储介质
TWI785511B (zh) * 2021-02-26 2022-12-01 圓展科技股份有限公司 應用於視訊傳輸的目標追蹤方法
CN115765934A (zh) * 2021-09-03 2023-03-07 中国移动通信集团山东有限公司 一种数据传输方法和装置

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101252452A (zh) * 2007-03-31 2008-08-27 红杉树(杭州)信息技术有限公司 一种多媒体会议中分布式混音系统
CN102075312A (zh) * 2011-01-10 2011-05-25 西安电子科技大学 基于视频服务质量的混合选择重传方法
CN102436818A (zh) * 2011-10-25 2012-05-02 浙江万朋网络技术有限公司 一种基于能量优先的服务器端选路混音方法
CN104486518A (zh) * 2014-12-03 2015-04-01 中国电子科技集团公司第三十研究所 一种带宽受限网络环境下的电话会议分布式混音方法
CN104539816A (zh) * 2014-12-25 2015-04-22 广州华多网络科技有限公司 一种多方语音通话的智能混音方法及装置
CN107979507A (zh) * 2017-11-21 2018-05-01 广州视源电子科技股份有限公司 一种数据传输方法、装置、设备及存储介质
CN109474897A (zh) * 2019-01-10 2019-03-15 厦门大学 基于隐马尔可夫模型的车联网安全消息单跳协作广播方法
CN110336645A (zh) * 2019-07-17 2019-10-15 广州市百果园信息技术有限公司 数据传输方法、装置、系统、设备和存储介质

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101252452A (zh) * 2007-03-31 2008-08-27 红杉树(杭州)信息技术有限公司 一种多媒体会议中分布式混音系统
CN102075312A (zh) * 2011-01-10 2011-05-25 西安电子科技大学 基于视频服务质量的混合选择重传方法
CN102436818A (zh) * 2011-10-25 2012-05-02 浙江万朋网络技术有限公司 一种基于能量优先的服务器端选路混音方法
CN104486518A (zh) * 2014-12-03 2015-04-01 中国电子科技集团公司第三十研究所 一种带宽受限网络环境下的电话会议分布式混音方法
CN104539816A (zh) * 2014-12-25 2015-04-22 广州华多网络科技有限公司 一种多方语音通话的智能混音方法及装置
CN107979507A (zh) * 2017-11-21 2018-05-01 广州视源电子科技股份有限公司 一种数据传输方法、装置、设备及存储介质
CN109474897A (zh) * 2019-01-10 2019-03-15 厦门大学 基于隐马尔可夫模型的车联网安全消息单跳协作广播方法
CN110336645A (zh) * 2019-07-17 2019-10-15 广州市百果园信息技术有限公司 数据传输方法、装置、系统、设备和存储介质

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
TWI785511B (zh) * 2021-02-26 2022-12-01 圓展科技股份有限公司 應用於視訊傳輸的目標追蹤方法
CN115765934A (zh) * 2021-09-03 2023-03-07 中国移动通信集团山东有限公司 一种数据传输方法和装置
CN114448588A (zh) * 2022-01-14 2022-05-06 杭州网易智企科技有限公司 音频传输方法、装置、电子设备及计算机可读存储介质
CN114448588B (zh) * 2022-01-14 2024-01-23 杭州网易智企科技有限公司 音频传输方法、装置、电子设备及计算机可读存储介质

Also Published As

Publication number Publication date
CN111585776B (zh) 2021-06-11

Similar Documents

Publication Publication Date Title
CN111585776B (zh) 数据传输方法、装置、设备及计算机可读存储介质
KR101298342B1 (ko) 분산된 다자간 회의를 제어하기 위한 메카니즘
US8958326B2 (en) Voice over internet protocol (VOIP) session quality
US20100228824A1 (en) Distributed server selection for online collaborative computing sessions
US8121880B2 (en) Method for calendar driven decisions in web conferences
CN111371957B (zh) 一种冗余度控制方法、装置、电子设备和存储介质
CN113676605A (zh) 数据传输方法、装置、设备及计算机可读存储介质
US10680742B2 (en) Systems and methods for improved communication packet delivery over a public network
CN111583942B (zh) 语音会话的编码码率控制方法、装置和计算机设备
US20100223320A1 (en) Data distribution efficiency for online collaborative computing sessions
CN113037440A (zh) 数据重传处理方法、装置、计算机设备和存储介质
CN106973253A (zh) 一种调整媒体流传输的方法及装置
US8161113B2 (en) Rich signaling feedback mechanism for group communication
Radenkovic et al. Multi-party distributed audio service with TCP fairness
CN111628992B (zh) 一种多人通话控制方法、装置、电子设备及存储介质
CN101553801B (zh) 用于处理多个设备使用的音频流的方法和装置
CN115550459A (zh) 语音数据的发送和接收方法以及相关设备
CN114448588B (zh) 音频传输方法、装置、电子设备及计算机可读存储介质
Aguirre et al. Darkcube: A k-Hypercube based P2P VoIP protocol
JP4476898B2 (ja) 通信システム、通信端末装置及びデータ要求方法
CN113541872B (zh) 实时通信方法和实时通信装置
Kausar et al. End to end reliable multicast transport protocol requirements for collaborative multimedia systems
Orvalho et al. State Transmission Mechanisms for a Collaborative Virtual Environment Middleware Platform
Radenkovic et al. A scaleable and adaptive audio service to support large scale collaborative work and entertainment
EP3308487B1 (en) Systems and methods for improved communication packet delivery over a public network

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
REG Reference to a national code

Ref country code: HK

Ref legal event code: DE

Ref document number: 40027361

Country of ref document: HK

GR01 Patent grant
GR01 Patent grant