CN112738642A - 一种实现多网卡聚合推流的方法 - Google Patents
一种实现多网卡聚合推流的方法 Download PDFInfo
- Publication number
- CN112738642A CN112738642A CN202011579694.0A CN202011579694A CN112738642A CN 112738642 A CN112738642 A CN 112738642A CN 202011579694 A CN202011579694 A CN 202011579694A CN 112738642 A CN112738642 A CN 112738642A
- Authority
- CN
- China
- Prior art keywords
- data
- network
- link
- sent
- links
- 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
- 238000000034 method Methods 0.000 title claims abstract description 36
- 230000002776 aggregation Effects 0.000 title claims abstract description 20
- 238000004220 aggregation Methods 0.000 title claims abstract description 20
- 230000008569 process Effects 0.000 claims description 10
- 230000006870 function Effects 0.000 claims description 9
- 238000012544 monitoring process Methods 0.000 claims description 6
- 230000008859 change Effects 0.000 claims description 5
- 230000007246 mechanism Effects 0.000 claims description 3
- 238000012545 processing Methods 0.000 claims description 3
- 230000002159 abnormal effect Effects 0.000 abstract description 5
- 238000011084 recovery Methods 0.000 abstract description 5
- 230000000903 blocking effect Effects 0.000 abstract description 3
- 230000008447 perception Effects 0.000 description 4
- 238000005516 engineering process Methods 0.000 description 2
- 239000012634 fragment Substances 0.000 description 2
- 238000011161 development Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000012856 packing Methods 0.000 description 1
- 230000002194 synthesizing effect Effects 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client
- H04N21/61—Network physical structure; Signal processing
- H04N21/6106—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/24—Multipath
- H04L45/245—Link aggregation, e.g. trunking
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client
- H04N21/61—Network physical structure; Signal processing
- H04N21/6156—Network physical structure; Signal processing specially adapted to the upstream path of the transmission network
Abstract
本发明提供了一种实现多网卡聚合推流的方法，通过客户端进行多网卡的绑定；客户端把流数据打包，通过多个链路发送；服务器把从多个链路收到的数据，进行排序合成一份正常的流输出。(1)本发明适用性高，该方案可在移动端(包括Android，iOS)，PC端(Windows，Linux)上运行；(2)本发明使网络更稳定，因为流量分流在多个链路上，每个链路所需要承载的流量更小，发生网络丢包，阻塞的概率变小，从而提高稳定性；(3)本发明使网络的容错性更高，在单一网络中，网络发生了丢包或者阻塞，那么接下要发送的数据只能异常恢复后才能继续发送，但在多路聚合网中，某路网络发生异常，数据可以通过其他链路进行发送，不用等待该链路的恢复，大大提高了容错性。
Description
技术领域
本发明涉及网络直播技术领域，特别涉及一种实现多网卡聚合推流的方法。
背景技术
随着互联网的飞速发展，网络直播越来越流行。但是直播行业中一个普遍存在的问题就是开播端的网络问题，尤其是一些户外或者室内直播的用户。市面的推流软件采用单一链路进行推流，比如4G或者WIFI或者有线。当用户同时拥有多个网络，却不能同时使用时，这就造成了网络的浪费。
基于此，现急需一种能够同时利用多个网络、获得更大网络带宽的实现多网卡聚合推流的方法。
发明内容
为解决上述问题，本发明旨在提出一种实现多网卡聚合推流的方法，利用多个链路聚合成一个稳定，带宽更大的网络，从而解决主播开播的网络问题。
为达到上述目的，本发明的技术方案是这样实现的：
一种实现多网卡聚合推流的方法，包括以下步骤：
S1、通过客户端进行多网卡的绑定；
S2、客户端把流数据打包，通过多个链路发送；
S3、服务器把从多个链路收到的数据，进行排序合成一份正常的流输出。
进一步的，当平台为iOS，Windows，Linux时，所述S1通过客户端进行多网卡的绑定流程具体为：当监听iOS，Windows，Linux系统的设备接口有新的网卡增加时，此时增加一个socket，并调用socket的绑定函数bind，把网卡设备与socket进行绑定，再通过该socket发送数据，即可通过该网卡发出。
进一步的，当平台为Android时，所述S1通过客户端进行多网卡的绑定流程具体为：当监听Android系统的设备接口有新的网卡增加时，那么会增加一个socket，并调用socket的绑定函数bind，进行绑定到该网卡；根据Android的接口：ConnectivityManager.getAIlNetworks获取所有的Network，并根据网卡的ip找到对应的Network；调用Network.bindSocket函数对socket进行绑定操作；最后通过该socket发送数据，即可通过该网卡发出。
进一步的，所述S2中客户端把流数据打包，通过多个链路发送的具体流程为：
S21、把每一帧数据(Frame)分成N个1350字节大小的分片(Segment)，并把数据增加″头部数据(SegmentHeader)″；
S22、根据每个链路的实时状况计算链路的优先级别(Priority)；
S23、当有数据需要发送时，先根据链路优先级排序，然后优先级高的链路进行发送，发送前，需要检查该链路的带宽(bandwidth)和当前链路上的缓存是否满足发送数据，如果满足，则进行发送，如果不满足，则选择下一个链路，进行发送；当所有链路都不足以发送数据时，需要把数据保存起来，等待有链路空闲了，再进行发送；
S24、当数据通过某个链路发送后，发现数据丢失了，那么，该系统会选择其他链路重传该数据。
进一步的，所述S21中的头部数据包含：Sequence，DataType，segmentCount，segmentIndex，timestamp，data。
进一步的，所述Sequence为递增序列号，DataType为数据类型：视频、音频、是否为关键帧，segmentCount为一帧数据总的Segment数量，segmentIndex为该Segment在该帧所有Segment中的索引，timestamp为发送时的时间戳，data为Segment数据。
进一步的，所述S22中根据每个链路的实时状况计算链路的优先级别(Priority)的具体方法为：
S221、根据rtt(网络往返时延)范围计算：rrt在0-200ms认为是较好的链路，201-400ms认为是一般的链路，401-800ms认为是差的网络，801-1000ms认为是非常差的网络，1000ms认为是极差的网络；
S222、根据rtt在5秒时间的波动情况计算；
S223、最后根据rtt范围和rtt波动情况，计算一个优先级，优先级越高，表示网络越好。
进一步的，S3中服务器把从多个链路收到的数据，进行排序合成一份正常的流输出的具体流程为：
S31、聚合服务器接收到从每个链路发送过来的乱序Segment后，会存入缓冲区，根据Segment的segmentIndex，segmentCount判断每一帧数据是否已经接收完成；
S32、当发现Segment丢失时，那么服务器会要求客户端重传；
S33、当一帧数据超过1秒都不能接收完整时，那么会主动丢弃该帧数据，不让整个链路阻塞，继续处理下面的帧数据；
S34、帧接收完整后，会根据Sequence进行帧的排序；
S35、完整，有序的帧还需要进行一些容错处理：当视频中的某个GOP里面的关键帧丢失了，那么后面的P、B帧需要丢弃；
S36、把完整，有序的帧，组合成rtmp协议，发送出去。
进一步的，当所述S2中的多个链路被删除某个链路时，或者切换时，客户端记录该变动，并立刻把本来由该链路发送的数据在其他链路上进行重传，使该行为完全不感知；所述S3中的服务器设有服务端动态缓存区：服务器会根据所有链路的最大的rtt，并计算一个rrt抖动值，两者得出JitterBuffer的长度；使JitterBuffer的长度尽可能小，并且稳定。
进一步的，所述客户端与服务器均设有数据重传机制：
客户端主动重传：如果某个链路上发送的某个Segment在服务器的JitterBuffer的长度的一半时间内还没有被Ack，那么会通过其他通道重传；
服务器主动向客户端要求重传：当某个重要的数据，比如视频关键帧不完整时，并超出JitterBuffer的1/3时间时，会主动发送请求向客户端要求重传该数据；
所述流数据设有不同发送优先级别：
把流数据，分成4个不同优先级别：第一种是控制数据(优先级最高)，第二种是音频数据，第三种是视频关键帧，第四种是视频非关键帧；在链路发送时，会根据高优先级数据先发送，低优先级后发送的策略进行发送，以保证流的流畅度。
有益效果：(1)本发明适用性高，该方案可在移动端(包括Android，iOS)，PC端(Windows，Linux)上运行；(2)本发明使网络更稳定，因为流量分流在多个链路上，每个链路所需要承载的流量更小，发生网络丢包，阻塞的概率变小，从而提高稳定性；(3)本发明使网络带宽更大，因为使用多个链路同时上传，总的的带宽理论可以认为是多个单一网络之和；(4)本发明使网络的容错性更高，在单一网络中，网络发生了丢包或者阻塞，那么接下要发送的数据只能异常恢复后才能继续发送，但在多路聚合网中，某路网络发生异常，数据可以通过其他链路进行发送，不用等待该链路的恢复，大大提高了容错性；(5)本发明使网络的可靠性更高，当在某些链路因基站故障，人为移动导致移动网络没有信号等原因掉线，聚合服务可以利用链路变动无感知技术，使数据快速恢复，完全无感知。
附图说明
构成本发明的一部分的附图用来提供对本发明的进一步理解，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：
图1为本发明实施例所述的实现多网卡聚合推流的方法的客户端流程图；
图2为本发明实施例所述的实现多网卡聚合推流的方法的服务器端的流程图。
具体实施方式
需要说明的是，在不冲突的情况下，本发明中的实施例及实施例中的特征可以相互组合。
英文单词注解：
Frame：帧数据，表示一个完整的视频或者音频数据
Segment：分片，表示把一个帧数据切割成多个1350字节大小的分片
SegmentHeader：分片的头部，用来携带每个分片的信息，比如：Sequence，DataType，segmentCount，segmentIndex，timestamp
Sequence：分片的序列号，该序列号是全局递增
DataType：分片的类型，表示该分配的类型：视频，音频，是否为关键帧
segmentCount：分片的总个数，表示一帧数据的分片的总个数
segmentIndex：分片的索引，表示该分片在帧数据中的索引
timestamp：分片的时间戳
data：分片的数据
Priority：网络优先级
bandwidth：网络的带宽
JitterBuffer：网络抖动缓冲区
Ack(Acknowledge)：网络确认包
rtt(Round Trip Time)：表示网络往返时间
GOP(GroupofPictures)：全称：，表示一组连续有关联的视频帧画面
rtmp(Real Time Messaging Protocol)：实时消息传输协议
下面将参考附图并结合实施例来详细说明本发明。
实施例1
参见图1-2：一种实现多网卡聚合推流的方法，包括以下步骤：
S1、通过客户端进行多网卡的绑定；
S2、客户端把流数据打包，通过多个链路发送；
S3、服务器把从多个链路收到的数据，进行排序合成一份正常的流输出。
本实施例利用在推流端所有能用的网络，比如：4G，WIFI，有线网络，把它们根据一定的算法，把流量分到这些链路上，使整个网络的稳定性，带宽，容错性都大大提升。
在一具体的实例中，当平台为iOS，Windows，Linux时，所述S1通过客户端进行多网卡的绑定流程具体为：当监听iOS，Windows，Linux系统的设备接口有新的网卡增加时，此时增加一个socket，并调用socket的绑定函数bind，把网卡设备与socket进行绑定，再通过该socket发送数据，即可通过该网卡发出；
当平台为Android时，所述S1通过客户端进行多网卡的绑定流程具体为：当监听Android系统的设备接口有新的网卡增加时，那么会增加一个socket，并调用socket的绑定函数bind，进行绑定到该网卡；根据Android的接口：ConnectivityManager.getAIlNetworks获取所有的Network，并根据网卡的ip找到对应的Network；调用Network.bindSocket函数对socket进行绑定操作；最后通过该socket发送数据，即可通过该网卡发出。
本实施例可在移动端(包括Android，iOS)，PC端(Windows，Linux)上运行，适用性高。
在一具体的实例中，所述S2中客户端把流数据打包，通过多个链路发送的具体流程为：
S21、把每一帧数据(Frame)分成N个1350字节大小的分片(Segment)，并把数据增加″头部数据(SegmentHeader)″；
S22、根据每个链路的实时状况计算链路的优先级别(Priority)；
S23、当有数据需要发送时，先根据链路优先级排序，然后优先级高的链路进行发送，发送前，需要检查该链路的带宽(bandwidth)和当前链路上的缓存是否满足发送数据，如果满足，则进行发送，如果不满足，则选择下一个链路，进行发送；当所有链路都不足以发送数据时，需要把数据保存起来，等待有链路空闲了，再进行发送；
S24、当数据通过某个链路发送后，发现数据丢失了，那么，该系统会选择其他链路重传该数据。
本实施例使网络更稳定，因为流量分流在多个链路上，每个链路所需要承载的流量更小，发生网络丢包，阻塞的概率变小，从而提高稳定性；本实施例使网络带宽更大，因为使用多个链路同时上传，总的的带宽理论可以认为是多个单一网络之和。
在一具体的实例中，所述S21中的头部数据包含：Sequence，DataType，segmentCount，segmentIndex，timestamp，data，其中，所述Sequence为递增序列号，DataType为数据类型：视频、音频、是否为关键帧，segmentCount为一帧数据总的Segment数量，segmentIndex为该Segment在该帧所有Segment中的索引，timestamp为发送时的时间戳，data为Segment数据。
在一具体的实例中，所述S22中根据每个链路的实时状况计算链路的优先级别(Priority)的具体方法为：
S221、根据rtt(网络往返时延)范围计算：rrt在0-200ms认为是较好的链路，201-400ms认为是一般的链路，401-800ms认为是差的网络，801-1000ms认为是非常差的网络，1000ms认为是极差的网络；
S222、根据rtt在5秒时间的波动情况计算；
S223、最后根据rtt范围和rtt波动情况，计算一个优先级，优先级越高，表示网络越好。
在一具体的实例中，S3中服务器把从多个链路收到的数据，进行排序合成一份正常的流输出的具体流程为：
S31、聚合服务器接收到从每个链路发送过来的乱序Segment后，会存入缓冲区，根据Segment的segmentIndex，segmentCount判断每一帧数据是否已经接收完成；
S32、当发现Segment丢失时，那么服务器会要求客户端重传；
S33、当一帧数据超过1秒都不能接收完整时，那么会主动丢弃该帧数据，不让整个链路阻塞，继续处理下面的帧数据；
S34、帧接收完整后，会根据Sequence进行帧的排序；
S35、完整，有序的帧还需要进行一些容错处理：当视频中的某个GOP里面的关键帧丢失了，那么后面的P、B帧需要丢弃；
S36、把完整，有序的帧，组合成rtmp协议，发送出去。
本实施例的服务器能够充分利用各个网络，对每个链路的网络进行充分整合、容错处理，从而使得客户端接收到的带宽稳定性、容错性都大大提升。
在一具体的实例中，当所述S2中的多个链路被删除某个链路时，或者切换时，客户端记录该变动，并立刻把本来由该链路发送的数据在其他链路上进行重传，使该行为完全不感知；所述S3中的服务器设有服务端动态缓存区：服务器会根据所有链路的最大的rtt，并计算一个rrt抖动值，两者得出JitterBuffer的长度；使JitterBuffer的长度尽可能小，并且稳定。
本实施例使网络的可靠性更高，当在某些链路因基站故障，人为移动导致移动网络没有信号等原因掉线，聚合服务可以利用链路变动无感知技术，使数据快速恢复，完全无感知。
在一具体的实例中，所述客户端与服务器均设有数据重传机制：
客户端主动重传：如果某个链路上发送的某个Segment在服务器的JitterBuffer的长度的一半时间内还没有被Ack，那么会通过其他通道重传；
服务器主动向客户端要求重传：当某个重要的数据，比如视频关键帧不完整时，并超出JitterBuffer的1/3时间时，会主动发送请求向客户端要求重传该数据；
所述流数据设有不同发送优先级别：
把流数据，分成4个不同优先级别：第一种是控制数据(优先级最高)，第二种是音频数据，第三种是视频关键帧，第四种是视频非关键帧；在链路发送时，会根据高优先级数据先发送，低优先级后发送的策略进行发送，以保证流的流畅度。
本实施例的网络的容错性更高，在单一网络中，网络发生了丢包或者阻塞，那么接下要发送的数据只能异常恢复后才能继续发送，但在多路聚合网中，某路网络发生异常，数据可以通过其他链路进行发送，不用等待该链路的恢复，大大提高了容错性。
以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。
Claims (10)
1.一种实现多网卡聚合推流的方法，其特征在于，包括以下步骤：
S1、通过客户端进行多网卡的绑定；
S2、客户端把流数据打包，通过多个链路发送；
S3、服务器把从多个链路收到的数据，进行排序合成一份正常的流输出。
2.根据权利要求1所述的实现多网卡聚合推流的方法，其特征在于，当平台为iOS，Windows，Linux时，所述S1通过客户端进行多网卡的绑定流程具体为：当监听iOS，Windows，Linux系统的设备接口有新的网卡增加时，此时增加一个socket，并调用socket的绑定函数bind，把网卡设备与socket进行绑定，再通过该socket发送数据，即可通过该网卡发出。
3.根据权利要求1所述的实现多网卡聚合推流的方法，其特征在于，当平台为Android时，所述S1通过客户端进行多网卡的绑定流程具体为：当监听Android系统的设备接口有新的网卡增加时，那么会增加一个socket，并调用socket的绑定函数bind，进行绑定到该网卡；根据Android的接口：ConnectivityManager.getAllNetworks获取所有的Network，并根据网卡的ip找到对应的Network；调用Network.bindSocket函数对socket进行绑定操作；最后通过该socket发送数据，即可通过该网卡发出。
4.根据权利要求1所述的实现多网卡聚合推流的方法，其特征在于，所述S2中客户端把流数据打包，通过多个链路发送的具体流程为：
S21、把每一帧数据分成N个1350字节大小的分片，并把数据增加″头部数据″；
S22、根据每个链路的实时状况计算链路的优先级别；
S23、当有数据需要发送时，先根据链路优先级排序，然后优先级高的链路进行发送，发送前，需要检查该链路的带宽和当前链路上的缓存是否满足发送数据，如果满足，则进行发送，如果不满足，则选择下一个链路，进行发送；当所有链路都不足以发送数据时，需要把数据保存起来，等待有链路空闲了，再进行发送；
S24、当数据通过某个链路发送后，发现数据丢失了，那么，该系统会选择其他链路重传该数据。
5.根据权利要求4所述的实现多网卡聚合推流的方法，其特征在于，所述S21中的头部数据包含：Sequence，DataType，segmentCount，segmentIndex，timestamp，data。
6.根据权利要求5所述的实现多网卡聚合推流的方法，其特征在于，所述Sequence为递增序列号，DataType为数据类型：视频、音频、是否为关键帧，segmentCount为一帧数据总的Segment数量，segmentIndex为该Segment在该帧所有Segment中的索引，timestamp为发送时的时间戳，data为Segment数据。
7.根据权利要求4所述的实现多网卡聚合推流的方法，其特征在于，所述S22中根据每个链路的实时状况计算链路的优先级别的具体方法为：
S221、根据rtt范围计算：rrt在0-200ms认为是较好的链路，201-400ms认为是一般的链路，401-800ms认为是差的网络，801-1000ms认为是非常差的网络，1000ms认为是极差的网络；
S222、根据rtt在5秒时间的波动情况计算；
S223、最后根据rtt范围和rtt波动情况，计算一个优先级，优先级越高，表示网络越好。
8.根据权利要求1所述的实现多网卡聚合推流的方法，其特征在于，S3中服务器把从多个链路收到的数据，进行排序合成一份正常的流输出的具体流程为：
S31、聚合服务器接收到从每个链路发送过来的乱序Segment后，会存入缓冲区，根据Segment的segmentIndex，segmentCount判断每一帧数据是否已经接收完成；
S32、当发现Segment丢失时，那么服务器会要求客户端重传；
S33、当一帧数据超过1秒都不能接收完整时，那么会主动丢弃该帧数据，不让整个链路阻塞，继续处理下面的帧数据；
S34、帧接收完整后，会根据Sequence进行帧的排序；
S35、完整，有序的帧还需要进行一些容错处理：当视频中的某个GOP里面的关键帧丢失了，那么后面的P、B帧需要丢弃；
S36、把完整，有序的帧，组合成rtmp协议，发送出去。
9.根据权利要求1所述的实现多网卡聚合推流的方法，其特征在于，当所述S2中的多个链路被删除某个链路时，或者切换时，客户端记录该变动，并立刻把本来由该链路发送的数据在其他链路上进行重传，使该行为完全不感知；所述S3中的服务器设有服务端动态缓存区：服务器会根据所有链路的最大的rtt，并计算一个rrt抖动值，两者得出JitterBuffer的长度；使JitterBuffer的长度尽可能小，并且稳定。
10.根据权利要求1所述的实现多网卡聚合推流的方法，其特征在于，所述客户端与服务器均设有数据重传机制：
客户端主动重传：如果某个链路上发送的某个Segment在服务器的JitterBuffer的长度的一半时间内还没有被Ack，那么会通过其他通道重传；
服务器主动向客户端要求重传：当某个重要的数据，比如视频关键帧不完整时，并超出JitterBuffer的1/3时间时，会主动发送请求向客户端要求重传该数据；
所述流数据设有不同发送优先级别：
把流数据，分成4个不同优先级别：第一种是控制数据，第二种是音频数据，第三种是视频关键帧，第四种是视频非关键帧；在链路发送时，会根据高优先级数据先发送，低优先级后发送的策略进行发送，以保证流的流畅度。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011579694.0A CN112738642A (zh) | 2020-12-28 | 2020-12-28 | 一种实现多网卡聚合推流的方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011579694.0A CN112738642A (zh) | 2020-12-28 | 2020-12-28 | 一种实现多网卡聚合推流的方法 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN112738642A true CN112738642A (zh) | 2021-04-30 |
Family
ID=75606502
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202011579694.0A Pending CN112738642A (zh) | 2020-12-28 | 2020-12-28 | 一种实现多网卡聚合推流的方法 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112738642A (zh) |
Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20020087716A1 (en) * | 2000-07-25 | 2002-07-04 | Shakeel Mustafa | System and method for transmitting customized multi priority services on a single or multiple links over data link layer frames |
| CN1536820A (zh) * | 2003-04-09 | 2004-10-13 | 华为技术有限公司 | 提高网络拥塞时数据传输性能的方法 |
| CN102104468A (zh) * | 2011-02-18 | 2011-06-22 | 中兴通讯股份有限公司 | 一种基于路由代理的媒体感知arq控制方法及系统 |
| CN104702518A (zh) * | 2015-03-05 | 2015-06-10 | 安徽清新互联信息科技有限公司 | 一种基于无线网络的多卡路由器装置及其数据传输方法 |
| CN108322773A (zh) * | 2018-02-01 | 2018-07-24 | 安徽创世科技股份有限公司 | 一种基于多卡绑定的自适应网络带宽实时数据流传输方法 |
| CN108781139A (zh) * | 2016-02-26 | 2018-11-09 | 网络洞察力知识产权公司 | 分组网络中的数据重传 |
| CN110022297A (zh) * | 2019-03-01 | 2019-07-16 | 广东工业大学 | 一种高清视频直播系统 |
| CN111901075A (zh) * | 2020-07-16 | 2020-11-06 | 华中科技大学 | 多网络融合传输方法、传输系统及计算机可读存储介质 |
-
2020
- 2020-12-28 CN CN202011579694.0A patent/CN112738642A/zh active Pending
Patent Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20020087716A1 (en) * | 2000-07-25 | 2002-07-04 | Shakeel Mustafa | System and method for transmitting customized multi priority services on a single or multiple links over data link layer frames |
| CN1536820A (zh) * | 2003-04-09 | 2004-10-13 | 华为技术有限公司 | 提高网络拥塞时数据传输性能的方法 |
| CN102104468A (zh) * | 2011-02-18 | 2011-06-22 | 中兴通讯股份有限公司 | 一种基于路由代理的媒体感知arq控制方法及系统 |
| CN104702518A (zh) * | 2015-03-05 | 2015-06-10 | 安徽清新互联信息科技有限公司 | 一种基于无线网络的多卡路由器装置及其数据传输方法 |
| CN108781139A (zh) * | 2016-02-26 | 2018-11-09 | 网络洞察力知识产权公司 | 分组网络中的数据重传 |
| CN108322773A (zh) * | 2018-02-01 | 2018-07-24 | 安徽创世科技股份有限公司 | 一种基于多卡绑定的自适应网络带宽实时数据流传输方法 |
| CN110022297A (zh) * | 2019-03-01 | 2019-07-16 | 广东工业大学 | 一种高清视频直播系统 |
| CN111901075A (zh) * | 2020-07-16 | 2020-11-06 | 华中科技大学 | 多网络融合传输方法、传输系统及计算机可读存储介质 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP2421190B1 (en) | Medium streaming distribution system | |
| US20220014312A1 (en) | Data transmission method and apparatus | |
| US7124333B2 (en) | Retransmission packet structure having multiple sequence numbers | |
| JP3912091B2 (ja) | データ通信システム、データ送信装置、データ受信装置、および方法、並びにコンピュータ・プログラム | |
| EP1929681B1 (en) | Synchronization of data transmission over wireless networks | |
| US9585062B2 (en) | System and method for implementation of dynamic encoding rates for mobile devices | |
| US20130003579A1 (en) | Method and apparatus for parsing a network abstraction-layer for reliable data communication | |
| US20060251105A1 (en) | Method and apparatus for requesting/transmitting status report of a mobile communication system | |
| US20120300663A1 (en) | Method and apparatus for retransmission decision making | |
| JP2003338841A (ja) | プロトコル、情報処理システムおよび方法、情報処理装置および方法、記録媒体、並びにプログラム | |
| CN101861709A (zh) | 用于具有合并的自动重复请求的自适应前向纠错以在无线局域网中进行可靠多播的方法和装置 | |
| CN1513252A (zh) | 在流式传输应用中的实时分组化和重发 | |
| JP2001045098A (ja) | データ通信システム、データ通信装置、データ通信方法及び記憶媒体 | |
| KR20080052042A (ko) | 데이터를 멀티캐스팅하는 방법 및 장치 | |
| KR101177454B1 (ko) | 영상 데이터의 전송에 따른 에러 복원 결정을 위한 서버 및클라이언트와, 영상 데이터의 전송에 따른 에러 복원결정방법 | |
| EP1770893B1 (en) | Method and apparatus for initiating a storage window in a wireless communications system | |
| CN101421965A (zh) | 使用传输窗口的通信系统中的优化分组数据传输协议 | |
| CN112738642A (zh) | 一种实现多网卡聚合推流的方法 | |
| JP3927486B2 (ja) | ストリーミング配信装置、ストリーミング配信システム、及びストリーミング配信方法 | |
| CN111052650A (zh) | 用于操作网络实体的方法、网络实体、用于操作用户设备的方法以及用户设备 | |
| KR101058687B1 (ko) | 멀티미디어 방송/멀티캐스트 서비스에서 일련번호를이용한 제어 메시지의 수신 방법 및 장치 | |
| CN113542685B (zh) | 一种基于可靠udp的实时超高清视频传输方法 | |
| Teyeb et al. | The impact of RLC delivery sequence on FTP performance in UMTS | |
| Gotta et al. | On Cloud-Based Multisource Reliable Multicast Transport in Broadband Multimedia Satellite Networks | |
| KR20050020305A (ko) | 다중 고속 데이터 전송장치 |
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: 20210430 |
|
| RJ01 | Rejection of invention patent application after publication |