CN113315823A - 一种低延迟音视频传输方法 - Google Patents
一种低延迟音视频传输方法 Download PDFInfo
- Publication number
- CN113315823A CN113315823A CN202110557973.5A CN202110557973A CN113315823A CN 113315823 A CN113315823 A CN 113315823A CN 202110557973 A CN202110557973 A CN 202110557973A CN 113315823 A CN113315823 A CN 113315823A
- Authority
- CN
- China
- Prior art keywords
- address
- network
- candidate
- transmission
- video
- 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.)
- Pending
Links
- 230000005540 biological transmission Effects 0.000 title claims abstract description 82
- 238000000034 method Methods 0.000 title claims abstract description 30
- 230000011664 signaling Effects 0.000 claims abstract description 24
- 238000012546 transfer Methods 0.000 claims abstract description 7
- 239000000872 buffer Substances 0.000 claims description 14
- 101000741965 Homo sapiens Inactive tyrosine-protein kinase PRAG1 Proteins 0.000 claims description 9
- 102100038659 Inactive tyrosine-protein kinase PRAG1 Human genes 0.000 claims description 9
- 238000004364 calculation method Methods 0.000 claims description 9
- 238000012937 correction Methods 0.000 claims description 8
- 230000003044 adaptive effect Effects 0.000 claims description 5
- 238000004891 communication Methods 0.000 claims description 4
- 230000008713 feedback mechanism Effects 0.000 claims description 4
- 230000005577 local transmission Effects 0.000 claims description 3
- 238000010187 selection method Methods 0.000 claims description 3
- 230000008901 benefit Effects 0.000 description 2
- 230000003993 interaction Effects 0.000 description 2
- 230000008569 process Effects 0.000 description 2
- 101100465000 Mus musculus Prag1 gene Proteins 0.000 description 1
- 230000006399 behavior Effects 0.000 description 1
- 238000010586 diagram Methods 0.000 description 1
- 230000002452 interceptive effect Effects 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000009467 reduction Effects 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
- H04L69/162—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields involving adaptations of sockets based mechanisms
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/1066—Session management
- H04L65/1101—Session protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/104—Peer-to-peer [P2P] networks
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Business, Economics & Management (AREA)
- General Business, Economics & Management (AREA)
- Computer Security & Cryptography (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明提供了一种低延迟音视频传输方法,包括:S1、客户端通过Websocket连接到信令服务器,用于交换信令信息;S2、客户端通过最优网络传输链路自适应选择算法,结合信令服务器、stun服务器、turn服务器以及SDP信令协商,建立相应的流媒体传输通道;S3、通过流媒体传输通道进行相应的流媒体数据传输。本发明利用最优网络传输链路自适应选择算法识别用户与用户间的网络连通性,如果两个用户在同个局域网,那么就会优先使用局域网络进行传输;如果两者能直接点对点连接,那么就直接进行点对点连接;最后如果上面2种网络方式都连接不通,则通过中转服务器进行中转;本发明具有传输速率高,延迟低,稳定好的特点,更适合音视频的低延迟,高分辨率传输。
Description
技术领域
本发明涉及网络数据传输技术领域,特别涉及一种低延迟音视频传输方法。
背景技术
随着网络质量不断发展,低延迟视频互动已经越来越普及。但是目前低延迟互动普遍存在的问题是低分辨率,和低码率。原因是一般的互动方案的数据传输是通过公网进行传输,为了数据的稳定性和实时性,只能减少传输带宽,从而牺牲了分辨率和码率。
发明内容
为解决上述问题,本发明旨在提出一种低延迟音视频传输方法,客户端与客户端之间通过最优网络传输链路自适应选择算法结合信令服务器、stun服务器、turn服务器以及SDP信令协商构建相应的流媒体传输通道,通过流媒体传输通道进行相应的流媒体数据传输。
为达到上述目的,本发明的技术方案是这样实现的:
一种低延迟音视频传输方法,包括以下步骤:
S1、客户端通过Websocket连接到信令服务器,用于交换信令信息;
S2、客户端通过最优网络传输链路自适应选择算法,结合信令服务器、stun服务器、turn服务器以及SDP信令协商,建立相应的流媒体传输通道;
S3、通过上述流媒体传输通道进行相应的流媒体数据传输。
进一步的,所述信令信息包括candidate信息、SDP信息以及应用层控制协议。
进一步的,所述最优网络传输链路自适应选择算法为ICE算法。
进一步的,所述ICE算法的具体流程为:
A、从本机获取host地址,从stun服务器获取srvflx地址,从turn服务器获取relay地址;
B、使用ICE的offer和answer方式,通过信令服务使用SDP协商交换各自的candidate信息;
C、本端收到对端的candidate后,生成candidate pairs;
D、双方根据candidate pairs进行连通性性检查;
E、将连通性检查成功的candidate pair按照优先级排序进入连通列表中;
F、ICE在连通列表中,根据优先级最高选择最终传输地址。
进一步的,所述ICE算法具体为RFC5245ICE,网络地址的选择方法包括:
A、媒体传输的候选地址(candidate):
候选地址用于组成candidate pair做点对点连通性检查确定传输路径;
B、候选地址分成4种类型:
host:从网卡中获取的本地传输地址
srvflx:从stun服务器获取的srvflx地址
relay:从turn服务器获取的relay地址
prflx:从对端发送Stun Binding请求获取的传输地址;
C、4种类型的网络地址优先级如下:
host>prflx>srvflx>relay。
进一步的,所述网络地址的选择方法还包括:
D、候选地址优先级(candidate priority)计算方法:
priority=(2∧24)*(type preference)+(2∧8)*(local preference)+(2∧0)*(256-component ID)
type preference:取值范围为0-126,126优先级最高,0最低;host地址为126,prflx地址为100,srvflx地址为80,reply地址为60;
local preference:取值范围为0-65535;
component ID:取值范围为:1-256;
E、候选地址对(Candidate pair priority):
由本端和远端的候选地址组成的pair,有自己的优先级;
pair优先级的计算取决candidate的priority;
F、优先地址对(candidate pair)优先级计算方法:
priority=2∧32*MIN(G,D)+2*MAX(G,D)+(G>D?1:0)
G:controlling candidate优先级
D:controlled candidate优先级。
进一步的,所述流媒体数据传输采用RTP over UDP、NACK、FEC、JitterBuffer、VBR以及VFR用于降低延迟。
进一步的,所述RTP over UDP,通过在应用层传输数据时,对无用数据进行丢失用于保证音视频的实时性以及降低延迟;所述NACK丢包反馈机制,通过在接收方定时把所有未收到的包序号通过反馈报文通知到发送方进行重传;所述FEC前向纠错,发送端将多媒体数据加上一定的冗余纠错码一起发送,在接收端根据FEC数据包和已接收数据包恢复丢失的数据包;所述JitterBuffer抖动缓冲器,当网络不稳定时,增加buffer的长度,多缓存一些数据,以应对将来可能发生的抖动;当网络稳定下来时,减小buffer的长度,少缓存一些数据,降低视频端到端的延迟,用于提高实时性;所述VBR以及VFR动态码率以及动态帧率,视频发送端会根据当前的网络情况,估算出发送的码率值,当网络比较好时,码率值会比较大,当网络比较差时,码率值会比较低;发送帧率根据当前的码率进行动态调整。
进一步的,所述流媒体数据传输采用h265视频编码,通过使用x265编码器在发送端把视频编码成h265编码,在解码端使用ffmpeg的hevc解码器解出相应的视频数据。
进一步的,当所述流媒体传输通道为p2p链路时,且客户端之间处于同一个局域网内,带宽为50Mbps-100Mbps,用于实现4K视频的传输。
有益效果:本发明利用了最优网络传输链路自适应选择算法,可以识别用户与用户间的网络连通性,如果两个用户在同个局域网,那么就会优先使用局域网络进行传输;如果两者能直接点对点连接,那么就直接进行点对点连接(P2P);最后如果上面2种网络方式都连接不通,则通过中转服务器进行中转;在本发明的应用场景下,用户与用户如果在同一个局域网内,那么他们的数据将通过内部网络进行传输,不在公网内,由于内部网络具有传输速率高,延迟低,稳定好的特点,更适合音视频的低延迟,高分辨率传输。。
附图说明
构成本发明的一部分的附图用来提供对本发明的进一步理解,本发明的示意性实施例及其说明用于解释本发明,并不构成对本发明的不当限定。在附图中:
图1为本发明实施例所述的低延迟音视频传输方法的实现架构图;
图2为本发明实施例所述的低延迟音视频传输方法的ICE算法流程图。
具体实施方式
需要说明的是,在不冲突的情况下,本发明中的实施例及实施例中的特征可以相互组合。
下面将参考附图并结合实施例来详细说明本发明。
实施例1
参见图1-2:一种低延迟音视频传输方法,包括以下步骤:
S1、客户端通过Websocket连接到信令服务器,用于交换信令信息;
S2、客户端通过最优网络传输链路自适应选择算法,结合信令服务器、stun服务器、turn服务器以及SDP信令协商,建立相应的流媒体传输通道;
S3、通过上述流媒体传输通道进行相应的流媒体数据传输。
本实施例利用了智能网络发现(最优网络传输链路自适应选择算法),可以识别用户与用户间的网络连通性,如果两个用户在同个局域网,那么就会优先使用局域网络进行传输;如果两者能直接点对点连接,那么就直接进行点对点连接(P2P);最后如果上面2种网络方式都连接不通,则通过中转服务器进行中转;在本实施例的应用场景下,用户与用户如果在同一个局域网内,那么他们的数据将通过内部网络进行传输,不在公网内,由于内部网络具有传输速率高,延迟低,稳定好的特点,更适合音视频的低延迟,高分辨率传输。
具体的,所述信令信息包括candidate信息、SDP信息以及应用层控制协议。
在一具体的实例中,所述最优网络传输链路自适应选择算法为ICE算法,所述ICE算法的具体流程为:
A、从本机获取host地址,从stun服务器获取srvflx地址,从turn服务器获取relay地址;
B、使用ICE的offer和answer方式,通过信令服务使用SDP协商交换各自的candidate信息;
C、本端收到对端的candidate后,生成candidate pairs;
D、双方根据candidate pairs进行连通性性检查;
E、将连通性检查成功的candidate pair按照优先级排序进入连通列表中;
F、ICE在连通列表中,根据优先级最高选择最终传输地址。
本实施例可以应用在不同的场景,例如:当使用场景正常是几个摄像头在同一个地方(比如同一个酒店,同一栋楼)的不同地方拍摄,客户端与客户端之间的链接都是可以通过p2p方式进行流媒体数据的传输,并且可以在同一个局域网内,既少了一层服务器转发层,又可以直接点对点通过局域网传输,大大降低了延迟;需要说明的是,本实施例在不处于同一个局域网、p2p网络连接不通的情况下,流数据传输会通过turn服务器进行中转,保证了网络的可用性。
在一具体的实例中,所述ICE算法具体为RFC5245 ICE,网络地址的选择方法包括:
A、媒体传输的候选地址(candidate):
候选地址用于组成candidate pair做点对点连通性检查,确定传输路径;
B、候选地址分成4种类型:
host:从网卡中获取的本地传输地址
srvflx:从stun服务器获取的srvflx地址
relay:从turn服务器获取的relay地址
prflx:从对端发送Stun Binding请求获取的传输地址;
C、4种类型的网络地址优先级如下:
host>prflx>srvflx>relay。
进一步的,所述网络地址的选择方法还包括:
D、候选地址优先级(candidate priority)计算方法:
priority=(2∧24)*(type preference)+(2∧8)*(local preference)+(2∧0)*(256-component ID)
type preference:取值范围为0-126,126优先级最高,0最低;host地址为126,prflx地址为100,srvflx地址为80,reply地址为60;
local preference:取值范围为0-65535,本实施例可以设定为65535;
component ID:取值范围为:1-256,本实施例可以设定为1;
E、候选地址对(candidate pair priority):
由本端和远端的候选地址组成的pair,有自己的优先级;
pair优先级的计算取决candidate的priority;
F、优先地址对(candidate pair)优先级计算方法:
priority=2∧32*MIN(G,D)+2*MAX(G,D)+(G>D?1:0)
G:controlling candidate优先级
D:controlled candidate优先级。
需要说明的是,ICE中的角色:
SDP发送Offer一方为controlling角色
SDP发送answer一方为controlled角色。
在一具体的实例中,所述流媒体数据传输采用RTP over UDP、NACK、FEC、JitterBuffer、VBR以及VFR用于降低延迟,所述RTP over UDP,通过在应用层传输数据时,对无用数据进行丢失用于保证音视频的实时性以及降低延迟;所述NACK丢包反馈机制,通过在接收方定时把所有未收到的包序号通过反馈报文通知到发送方进行重传;所述FEC前向纠错,发送端将多媒体数据加上一定的冗余纠错码一起发送,在接收端根据FEC数据包和已接收数据包恢复丢失的数据包;所述JitterBuffer抖动缓冲器,当网络不稳定时,增加buffer的长度,多缓存一些数据,以应对将来可能发生的抖动;当网络稳定下来时,减小buffer的长度,少缓存一些数据,降低视频端到端的延迟,用于提高实时性;所述VBR以及VFR动态码率以及动态帧率,视频发送端会根据当前的网络情况,估算出发送的码率值,当网络比较好时,码率值会比较大,当网络比较差时,码率值会比较低;发送帧率根据当前的码率进行动态调整。
需要说明的是,在低延迟的实现方法中,本实施例使用了RTP over UDP,NACK,FEC,JitterBuffer,VBR和VFR等技术来实现低延迟。
RTP over UDP:一般的流媒体传输是通过TCP传输协议进行数据传输,而TCP相对于流媒体传输的一个缺点是它的传输的″可靠性″:不能对已过时的数据进行丢弃。而UDP是不可靠传输,在应用层传输数据时,可以做更多的策略性行为,比如对已经过时的数据进行丢弃,这样保证了音视频的实时性。
NACK(Negative Acknowledgement):本实施例使用NACK丢包反馈机制,在接收方定时把所有未收到的包序号通过反馈报文通知到发送方进行重传。相对于TCP的ACK机制,带来的好处是:减少反馈包的频率和带宽占用,同时也能比较及时地通知发送方进行丢包重传。
FEC(前向纠错):在基于IP网络的多媒体传输系统中,网络丢包对多媒体通信质量有非常严重的影响,例如造成视频的马赛克,图像模糊等问题。在本发明中,对抗网络丢包除了上面的NACK技术外,还使用FEC技术。发送端将多媒体数据加上一定的冗余纠错码一起发送,在接收端根据FEC数据包和已接收数据包恢复丢失的数据包。
JitterBuffer(抖动缓冲器):本实施例的JitterBuffer的实现原理是,当网络不稳定时(抖动发生),增加buffer的长度,多缓存一些数据,以应对将来可能发生的抖动;当网络稳定下来时,减小buffer的长度,少缓存一些数据,降低视频端到端的延迟,提高实时性。
VBR和VFR(动态码率和动态帧率):本实施例中,视频发送端会根据当前的网络情况,估算出发送的码率值。当网络比较好时,码率值会比较大,当网络比较差时,码率值会比较低。发送帧率也会根据当前的码率进行动态调整。如果不调整帧率,当网络条件比较好的时候,仅仅提升了视频质量,没有充分利用网络条件,提升实时性。当网络条件比较差的时候,码率降的比较低,若不降低帧率,视频质量会大幅度下降。
在一具体的实例中,所述流媒体数据传输采用h265视频编码,通过使用x265编码器在发送端把视频编码成h265编码,在解码端使用ffmpeg的hevc解码器解出相应的视频数据。
本实施例支持h265视频编码,在同样的码率和分辨率情况下,支持更高清晰的视频,同时本实施例的音频支持:opus。
在一具体的实例中,当所述流媒体传输通道为p2p链路时,且客户端之间处于同一个局域网内,带宽为50Mbps-100Mbps,用于实现4K视频的传输。
本实施例的流媒体传输在正常情况下可以通过客户端与客户端之间的p2p链路进行数据传输,这样减少服务器之间中转数据所带来的带宽消耗;并且如果两者之间在同一个局域网内的话,带宽可达到50M bps,甚至100M bps以上,可以轻松实现4K高分辨率视频的传输。
以上所述仅为本发明的较佳实施例而已,并不用以限制本发明,凡在本发明的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。
Claims (10)
1.一种低延迟音视频传输方法,其特征在于,包括以下步骤:
S1、客户端通过Websocket连接到信令服务器,用于交换信令信息;
S2、客户端通过最优网络传输链路自适应选择算法,结合信令服务器、stun服务器、turn服务器以及SDP信令协商,建立相应的流媒体传输通道;
S3、通过上述流媒体传输通道进行相应的流媒体数据传输。
2.根据权利要求1所述的低延迟音视频传输方法,其特征在于,所述信令信息包括candidate信息、SDP信息以及应用层控制协议。
3.根据权利要求1所述的低延迟音视频传输方法,其特征在于,所述最优网络传输链路自适应选择算法为ICE算法。
4.根据权利要求3所述的低延迟音视频传输方法,其特征在于,所述ICE算法的具体流程为:
A、从本机获取host地址,从stun服务器获取srvflx地址,从turn服务器获取relay地址;
B、使用ICE的offer和answer方式,通过信令服务使用SDP协商交换各自的candidate信息;
C、本端收到对端的candidate后,生成candidate pairs;
D、双方根据candidate pairs进行连通性性检查;
E、将连通性检查成功的candidate pair按照优先级排序进入连通列表中;
F、ICE在连通列表中,根据优先级最高选择最终传输地址。
5.根据权利要求3所述的低延迟音视频传输方法,其特征在于,所述ICE算法具体为RFC5245 ICE,网络地址的选择方法包括:
A、媒体传输的候选地址:
候选地址用于组成candidate pair做点对点连通性检查确定传输路径;
B、候选地址分成4种类型:
host:从网卡中获取的本地传输地址
srvflx:从stun服务器获取的srvflx地址
relay:从turn服务器获取的relay地址
prflx:从对端发送Stun Binding请求获取的传输地址;
C、4种类型的网络地址优先级如下:
host>prflx>srvflx>relay。
6.根据权利要求5所述的低延迟音视频传输方法,其特征在于,所述网络地址的选择方法还包括:
D、候选地址优先级计算方法:
priority=(2∧24)*(type preference)+(2∧8)*(local preference)+(2∧0)*(256-componentID)
type preference:取值范围为0-126,126优先级最高,0最低;
host地址为126,prflx地址为100,srvflx地址为80,reply地址为60;
local preference:取值范围为0-65535;
component ID:取值范围为:1-256;
E、候选地址对:
由本端和远端的候选地址组成的pair,有自己的优先级;
pair优先级的计算取决candidate的priority;
F、优先地址对优先级计算方法:
priority=2∧32*MIN(G,D)+2*MAX(G,D)+(G>D?1:0)
G:controlling candidate优先级
D:controlled candidate优先级。
7.根据权利要求1所述的低延迟音视频传输方法,其特征在于,所述流媒体数据传输采用RTP over UDP、NACK、FEC、JitterBuffer、VBR以及VFR用于降低延迟。
8.根据权利要求7所述的低延迟音视频传输方法,其特征在于,所述RTP over UDP,通过在应用层传输数据时,对无用数据进行丢失用于保证音视频的实时性以及降低延迟;所述NACK丢包反馈机制,通过在接收方定时把所有未收到的包序号通过反馈报文通知到发送方进行重传;所述FEC前向纠错,发送端将多媒体数据加上一定的冗余纠错码一起发送,在接收端根据FEC数据包和已接收数据包恢复丢失的数据包;所述JitterBuffer抖动缓冲器,当网络不稳定时,增加buffer的长度,多缓存一些数据,以应对将来可能发生的抖动;当网络稳定下来时,减小buffer的长度,少缓存一些数据,降低视频端到端的延迟,用于提高实时性;所述VBR以及VFR动态码率以及动态帧率,视频发送端会根据当前的网络情况,估算出发送的码率值,当网络比较好时,码率值会比较大,当网络比较差时,码率值会比较低;发送帧率根据当前的码率进行动态调整。
9.根据权利要求1所述的低延迟音视频传输方法,其特征在于,所述流媒体数据传输采用h265视频编码,通过使用x265编码器在发送端把视频编码成h265编码,在解码端使用ffmpeg的hevc解码器解出相应的视频数据。
10.根据权利要求1所述的低延迟音视频传输方法,其特征在于,当所述流媒体传输通道为p2p链路时,且客户端之间处于同一个局域网内,带宽为50Mbps-100Mbps,用于实现4K视频的传输。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202110557973.5A CN113315823A (zh) | 2021-05-21 | 2021-05-21 | 一种低延迟音视频传输方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202110557973.5A CN113315823A (zh) | 2021-05-21 | 2021-05-21 | 一种低延迟音视频传输方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN113315823A true CN113315823A (zh) | 2021-08-27 |
Family
ID=77373943
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202110557973.5A Pending CN113315823A (zh) | 2021-05-21 | 2021-05-21 | 一种低延迟音视频传输方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN113315823A (zh) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN114339116A (zh) * | 2021-12-31 | 2022-04-12 | 四川科瑞软件有限责任公司 | 基于WebRtc的音视频通话方法和系统 |
CN114900508A (zh) * | 2022-05-16 | 2022-08-12 | 深圳市瑞云科技有限公司 | 一种基于webrtc传输VR应用数据的方法 |
WO2024032102A1 (zh) * | 2022-08-09 | 2024-02-15 | 腾讯科技(深圳)有限公司 | 数据传输方法、装置、设备、存储介质和计算机程序产品 |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20130185440A1 (en) * | 2012-01-17 | 2013-07-18 | Telefonaktiebolaget L M Ericsson (Publ) | Ice Based Nat Traversal |
US20160094589A1 (en) * | 2014-09-25 | 2016-03-31 | Microsoft Corporation | Media Session Between Network Endpoints |
CN105721570A (zh) * | 2016-02-04 | 2016-06-29 | 福建星网锐捷通讯股份有限公司 | 数据点对点传输方法及装置 |
CN108141409A (zh) * | 2015-10-14 | 2018-06-08 | Ntt通信公司 | 通信系统、地址通知装置、通信控制装置、终端、通信方法以及程序 |
CN109274634A (zh) * | 2017-07-18 | 2019-01-25 | 腾讯科技(深圳)有限公司 | 多媒体通信方法及装置、存储介质 |
-
2021
- 2021-05-21 CN CN202110557973.5A patent/CN113315823A/zh active Pending
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20130185440A1 (en) * | 2012-01-17 | 2013-07-18 | Telefonaktiebolaget L M Ericsson (Publ) | Ice Based Nat Traversal |
US20160094589A1 (en) * | 2014-09-25 | 2016-03-31 | Microsoft Corporation | Media Session Between Network Endpoints |
CN108141409A (zh) * | 2015-10-14 | 2018-06-08 | Ntt通信公司 | 通信系统、地址通知装置、通信控制装置、终端、通信方法以及程序 |
CN105721570A (zh) * | 2016-02-04 | 2016-06-29 | 福建星网锐捷通讯股份有限公司 | 数据点对点传输方法及装置 |
CN109274634A (zh) * | 2017-07-18 | 2019-01-25 | 腾讯科技(深圳)有限公司 | 多媒体通信方法及装置、存储介质 |
Non-Patent Citations (5)
Title |
---|
J. ROSENBERG等: "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", 《IETF RFC5245》 * |
畅巨峥等: "利用ICE实现VOIP媒体流穿越", 《现代电子技术》 * |
艾伦 B•约翰斯顿等: "《WebRTC权威指南(3版)》", 30 September 2016 * |
陈恒勋等: "NAT穿越技术研究", 《现代信息科技》 * |
魏立峰等: "一种媒体流穿越NAT的算法设计与实现", 《计算机工程》 * |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN114339116A (zh) * | 2021-12-31 | 2022-04-12 | 四川科瑞软件有限责任公司 | 基于WebRtc的音视频通话方法和系统 |
CN114900508A (zh) * | 2022-05-16 | 2022-08-12 | 深圳市瑞云科技有限公司 | 一种基于webrtc传输VR应用数据的方法 |
CN114900508B (zh) * | 2022-05-16 | 2023-08-29 | 深圳市瑞云科技有限公司 | 一种基于webrtc传输VR应用数据的方法 |
WO2024032102A1 (zh) * | 2022-08-09 | 2024-02-15 | 腾讯科技(深圳)有限公司 | 数据传输方法、装置、设备、存储介质和计算机程序产品 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN105357592B (zh) | 一种流媒体自适应传输选择性丢帧方法 | |
CN113315823A (zh) | 一种低延迟音视频传输方法 | |
KR101644215B1 (ko) | 신뢰성 있는 데이터 통신을 위한 네트워크 추상화 계층을 파싱하는 방법 및 장치 | |
US8989185B2 (en) | Method and apparatus for converting a multicast session to a unicast session | |
US9306708B2 (en) | Method and apparatus for retransmission decision making | |
US8699522B2 (en) | System and method for low delay, interactive communication using multiple TCP connections and scalable coding | |
KR101242663B1 (ko) | 패킷 송신 장치, 통신 시스템 및 컴퓨터 판독가능한 기록매체 | |
KR100680671B1 (ko) | 에러 정정용 데이터의 생성 방법 및 생성 장치와 생성 프로그램을 저장한 컴퓨터 판독가능한 기록 매체 | |
JP4116470B2 (ja) | メディア・ストリーミング配信システム | |
US8499212B2 (en) | Method and apparatus for adaptive forward error correction with merged automatic repeat request for reliable multicast in wireless local area networks | |
US10944973B2 (en) | Estimation of video quality of experience on media servers | |
US20150103885A1 (en) | Real time ip video transmission with high resilience to network errors | |
KR20110108366A (ko) | 신뢰성 있는 멀티캐스트 스트리밍을 위한 방법 및 장치 | |
JP2010519789A (ja) | 逆方向リンクおよび順方向リンクのビデオデータエラーを区別するエラーフィルタ | |
US10491651B2 (en) | Method and system for streaming low-delay high-definition video with partially reliable transmission | |
CN104104924A (zh) | 一种基于3g网络的视频监控系统带宽自适应传输方法 | |
WO2010108416A1 (zh) | 转发可伸缩视频编码数据报文的方法、设备和通信系统 | |
JP2006304138A (ja) | 選択再送型通信装置 | |
Cheng et al. | Improving transmission quality of MPEG video stream by SCTP multi-streaming and differential RED mechanisms | |
JP5523163B2 (ja) | 送信装置、送信方法、プログラム | |
CN114866523A (zh) | 一种基于udp的视频快速传输方法及系统 | |
CN115842900A (zh) | 一种无线信道下的音视频通信优化方法 | |
Panahi et al. | A novel schema for multipath video transferring over ad hoc networks | |
CN118214897A (zh) | 一种面向svc视频流的网络传输方法 | |
WO2018157352A1 (zh) | 一种基于流媒体纠偏算法的无线传输技术 |
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 | ||
RJ01 | Rejection of invention patent application after publication |
Application publication date: 20210827 |
|
RJ01 | Rejection of invention patent application after publication |