CN101222311A - 实时报文丢包恢复方法、系统及接收端单元 - Google Patents
实时报文丢包恢复方法、系统及接收端单元 Download PDFInfo
- Publication number
- CN101222311A CN101222311A CNA2008100570616A CN200810057061A CN101222311A CN 101222311 A CN101222311 A CN 101222311A CN A2008100570616 A CNA2008100570616 A CN A2008100570616A CN 200810057061 A CN200810057061 A CN 200810057061A CN 101222311 A CN101222311 A CN 101222311A
- Authority
- CN
- China
- Prior art keywords
- buffering
- data
- framing
- receiving terminal
- time window
- 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
Links
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
- Communication Control (AREA)
Abstract
本发明公开了实时报文丢包恢复方法、系统及接收端单元。方法包括：接收端统计包重传所消耗的时长即重传消耗，把将一个非重传包放入组帧缓冲到将该包送往解码器所消耗的时长作为重传时间窗口；发送端将数据打包成实时报文发送给接收端，同时保存数据；接收端发现丢包，若确定重传消耗不大于重传时间窗口，则向发送端发送重传请求，同时确定当前时刻为重传时间窗口开始时刻，发送端将保存的需重传的数据打包成报文发送给接收端；接收端在重传时间窗口结束时刻前收到发送端发来的重传数据，将该重传数据插入组帧缓冲中。本发明在保证数据传输实时性的前提下，减少了恢复丢包所占用的网络带宽。
Description
技术领域
本发明涉及媒体传输技术领域，具体涉及媒体流传输中的实时报文丢包恢复方法、系统及接收端单元。
背景技术
实时媒体流传输已经应用在各个领域如：视频会议系统、监控系统、IP电视(IPTV)等。当前的实时媒体流传输都使用实时传输协议(RTP，Real-timeTransport Protocol)，RTP是一种不支持任何形式的可靠性保证、不支持任何定义拥塞控制的协议。因此，在实时媒体流传输中RTP本身无法对丢包进行恢复。
网络丢包会造成音频停顿、视频花屏及音、视频停止等现象。目前，接收端在发现视频丢包时，直接向发送端请求I帧刷新，同时对丢包的视频数据进行停止解码处理，或者直接解码处理。这种方式的缺点是，少量的网络丢包也会引发大量的I帧数据传送，浪费网络带宽，且容易引起网络拥塞，从而导致丢包加剧，使得丢包恢复的效率得不到保证；同时，在某些存在固定数量丢包的网络中还易发生I帧丢包，导致整个I帧失效，从而引起再次I帧刷新，更加重了网络的负担。
发明内容
本发明提供实时报文丢包恢复方法、系统及接收端单元，以提高实时报文的丢包恢复效率。
本发明的技术方案是这样实现的：
一种实时报文丢包恢复方法，接收端统计包重传所消耗的时长即重传消耗，并把将一个非重传包放入组帧缓冲到将该包送往解码器所消耗的时长作为重传时间窗口，包括：
接收端发现丢包，若确定重传消耗不大于重传时间窗口，则向发送端发送重传请求，同时确定当前时刻为重传时间窗口开始时刻；在重传时间窗口结束时刻前收到发送端发来的重传数据，将该重传数据插入组帧缓冲中。
一种实时报文丢包恢复方法，接收端统计包重传所消耗的时长即重传消耗，并把将一个非重传包放入组帧缓冲到将该包送往解码器所消耗的时长作为重传时间窗口，包括：
发送端将数据打包成实时报文发送给接收端，同时保存数据；接收端发现丢包，若确定重传消耗不大于重传时间窗口，则向发送端发送重传请求，同时确定当前时刻为重传时间窗口开始时刻，发送端将保存的需重传的数据打包成报文发送给接收端；接收端在重传时间窗口结束时刻前收到发送端发来的重传数据，将该重传数据插入组帧缓冲中。
一种实时报文丢包恢复系统，包括：
发送端单元，将数据打包成实时报文发送给接收端单元，同时保存数据；接收到重传请求，将保存的需重传的数据打包成报文发送给接收端单元；
接收端单元，统计包重传所消耗的时长即重传消耗，把将一个非重传包放入组帧缓冲到将该包送往解码器所消耗的时长作为重传时间窗口，当发现丢包时，若确定重传消耗不大于重传时间窗口，则向发送端单元发送重传请求，同时确定当前时刻为重传时间窗口开始时刻；在重传时间窗口结束时刻前收到发送端单元发来的重传数据，将该重传数据插入组帧缓冲中。
一种接收端单元，包括：
接收模块，接收发送端单元发来的重传数据，将重传数据插入组帧缓冲；
丢包发现模块，统计包重传所消耗的时长即重传消耗，把将一个非重传包放入组帧缓冲到将该包送往解码器所消耗的时长作为重传时间窗口；检测到发生丢包，且确定重传消耗不大于重传时间窗口，向重传请求模块发送重传指示，该指示中携带需重传的数据信息；
组帧缓冲，接收接收模块插入的数据；
重传请求模块，接收丢包发现模块发来的重传指示，将该指示中的需重传的数据信息携带在重传请求中发送给发送端单元。
与现有技术相比，本发明中，接收端预先统计包重传所消耗的时长即重传消耗，把将一个非重传包放入组帧缓冲到将该包送往解码器所消耗的时长作为重传时间窗口；发送端发送数据的同时，保存数据；接收端发现丢包，若确定重传消耗不大于重传时间窗口，则向发送端发送重传请求，同时确定当前时刻为重传时间窗口开始时刻；发送端将保存的需重传的数据打包成报文发送给接收端；接收端在重传时间窗口结束时刻前收到发送端发来的重传数据，将该重传数据插入组帧缓冲中。本发明在保证数据传输实时性的前提下，避免了网络拥塞，提高了实时报文的丢包恢复效率。
另外，本发明在重传消耗大于重传时间窗口时，直接进行I帧刷新或将数据直接解码，进一步保证了丢包的恢复，提高了丢包恢复的网络适应能力。
附图说明
图1为本发明实施例提供的在实时媒体流传输中恢复丢包的流程图；
图2为本发明实施例一提供的在实时媒体流传输中恢复丢包的流程图；
图3为本发明实施例二提供的在实时媒体流传输中恢复丢包的流程图；
图4为本发明实施例三提供的在实时媒体流传输中恢复丢包的流程图；
图5为本发明实施例提供的在实时媒体流传输中，进行丢包恢复的发送端单元的结构示意图；
图6为本发明实施例一提供的在实时媒体流传输中，进行丢包恢复的接收端单元的结构示意图；
图7为本发明实施例三提供的在实时媒体流传输中，进行丢包恢复的接收端单元的结构示意图。
具体实施方式
下面结合附图及具体实施例对本发明再作进一步详细的说明。
首先对本发明实施例中提到的“重传消耗”和“重传时间窗口”的物理意义进行说明：
重传消耗指的是，从接收端发现丢包起、到接收端向发送端发起重传请求、再到接收端收到发送端发来的重传包、并将该包插入缓冲区中的相应位置止，这其间的时长。
重传时间窗口指的是，从将一个非重传包放入组帧缓冲，到将该包送往解码器所消耗的时长作为重传时间窗口的长度。可见，重传时间窗口的大小与接收端的组帧缓冲的长度对应。组帧缓冲的长度越长，重传时间窗口所代表的时长越大；组帧缓冲的长度越短，重传时间窗口所代表的时长越小。
图1为本发明实施例提供的在实时媒体流传输中恢复丢包的流程图，如图1所示，其具体步骤如下：
步骤101：接收端预先设定重传消耗和重传时间窗口。
本发明实施例中，重传消耗可通过如下方式得到：
接收端发送一个测试信令给发送端，并等待发送端返回的响应，则将从接收端发送测试信令到收到响应之间的时长，作为重传消耗。
接收端可每隔一段时间更新一次重传消耗，以使得重传消耗更能适应网络状况的变化。
步骤102：发送端将编码后的数据放入发送缓冲中，确定要发送发送缓冲中的数据，将数据打包成RTP报文，将RTP报文发送出去，同时将RTP参数和数据对应保存一份在保留缓冲中，以备重传。
RTP参数包括RTP报文头中的时间戳、包序列号等。
当数据和RTP参数溢出保留缓冲时，该数据和RTP参数即删除。
步骤103：接收端发现丢包，判断重传消耗是否不大于重传时间窗口，若是，执行步骤104；否则，执行步骤108。
由于丢包发现时机会影响到音、视频数据的播放延时，因此，本发明实施例中，丢包发现时机可以在对接收数据的去抖动、乱序后。具体地，接收端可以预先设置一个容许抖动时长，若接收端在容许抖动时长内未接收到数据，则确定产生丢包。
步骤104：接收端确定当前时刻为重传时间窗口开始时刻，向发送端发送重传请求，该请求中携带需重传的数据类型、起始重传包的序列号、需重传的包的连续个数、每个包重传的次数。
可以看出，重传时间窗口开始时刻即：发现丢包并确定重传该包时刻。
步骤104中的重传请求针对的是丢包连续的情况，若丢包不连续，则可为每个丢包发送一个重传请求，或者，也可将各不连续的丢包的序列号携带在同一个重传请求中。
这里，对于每个包重传的次数，一般来说，如果需要保证高可靠性的情况下，在网络带宽允许的范围内，可以设定每个包重传的次数自2次起计数，并可以根据实际的网络情况适当地调整该每个包重传的次数。
需重传的数据类型包括：视频、音频等类型。
步骤105：发送端收到重传请求，根据该请求中的需重传的数据类型及起始重传包的序列号、需重传的包的连续个数，从对应数据类型的保留缓冲中找到需重传的数据及RTP参数，将需重传的数据及RTP参数保存到重传缓冲；依次从重传缓冲取出需重传的数据及RTP参数并打包成RTP报文，并将报文头中的载荷类型字段设定为特定的值，通过复用RTP通道、并采用最高IP优先级将RTP报文发送出去。
RTP报文的格式如表1所示：
| V | P | X | CSRC数量 | M | 载荷类型 | 序列号 |
| 时间戳 | ||||||
| 同步源(SSRC) | ||||||
| Contribution source(CSRC：variable 0-15items，2octets each) | ||||||
表1
可使用RFC标准中未定义的载荷类型值来作为本步骤中的RTP报文头中的载荷类型值。例如：若重传数据类型为音频，则载荷类型值可为67；若重传数据类型为视频，则载荷类型值可为68。
将载荷类型值定义为特定的值，这样，接收端在进行抖动计算时，就不会将该RTP报文的延时计算在内，从而不会产生抖动计算误差。同时，通过复用RTP通道重传数据包，就可以避免发送端、接收端新打开端口，减少端口浪费。
对于重传请求中携带的每个包重传的次数，发送端根据该次数，将每个包含重传数据的RTP报文重复发送。
步骤106：接收端收到RTP报文，根据报文头中的载荷类型值，确定报文中的数据为重传数据，则对报文中的数据进行去抖动、乱序处理后，插入到组帧缓冲中。
当所有丢包都重传成功后，则对数据进行解码，将解码后的数据输出，本流程结束。
步骤107：接收端检测到重传时间窗口结束时刻到来，判断是否所有丢包都已重传成功，若是，本流程结束；否则，执行步骤108。
重传时间窗口结束时刻即：应该将丢包对应的重传包送往解码器的时刻。
步骤108：接收端向发送端发送I帧刷新请求或直接对该不完整数据进行解码。
若本实施例针对的是视频数据，则步骤108为：接收端向发送端发送I帧刷新请求；若本实施例针对的是音频数据，则由于音频数据重传中没有I帧刷新这一步骤，则步骤108为：接收端直接对该不完整数据进行解码。
从图1所示实施例可以看出，当接收端发现丢包时，若重传消耗不大于重传时间窗口，则只向发送端请求重传丢包；若重传消耗大于重传时间窗口，则向发送端请求I帧刷新或者直接进行解码。这样，可以在保证实时性的前提下，提高了网络适应能力，并提高了实时数据传输完整性，同时大大减少了视频数据恢复所占用的网络带宽。
由于在实时媒体流传输中，在有些场合下，对实时性要求较强；而在另外一些情况下，对音、视频的播放连续性要求较强。本发明实施例通过对重传时间窗口的不同设置，来满足实时性、播放连续性的不同需求。
实施例一、在丢包恢复中满足播放连续性要求。
图2为本发明实施例一提供的在实时媒体流传输中恢复丢包的流程图，如图2所示，其具体步骤如下：
步骤201：接收端预先设定重传消耗，并根据组帧缓冲长度确定重传时间窗口。
步骤202与步骤102相同。
步骤203：接收端发现丢包，判断重传消耗是否不大于重传时间窗口，若是，执行步骤204；否则，执行步骤210。
步骤204～205与步骤104～105相同。
步骤206：接收端接收到RTP报文，根据报文头中的载荷类型值，判断该报文中的数据是否为重传数据，若是，执行步骤208；否则，执行步骤207。
步骤207：接收端对报文进行去抖动处理，根据报文中的包序列号，将报文中的数据插入到组帧缓冲中，本流程结束。
步骤208：接收端根据报文中的包序列号，将报文中的重传数据插入到组帧缓冲中。
步骤209：接收端在重传时间窗口结束时刻前接收到所有丢包对应的重传包，则将组帧缓冲中的数据送往解码器，解码器对该数据解码后，将解码后的数据输出，本流程结束。
若重传时间窗口结束时刻已到但仍有丢包未重传成功，则接收端向发送端发送I帧刷新请求，或者直接将组帧缓冲中的数据发往解码器。
步骤210：接收端向发送端发送I帧刷新请求，或者直接将组帧缓冲中的数据发往解码器。
从图2所示实施例可以看出，当发生丢包时，由于组帧缓冲会等待丢包都重传成功后，才将完整的数据送往解码器，因此，会造成播放时延。
实施例二、在丢包恢复中满足实时性要求。
图3为本发明实施例二提供的在实时媒体流传输中恢复丢包的流程图，如图3所示，其具体步骤如下：
步骤301：接收端预先设定重传消耗，并根据组帧缓冲的长度确定重传时间窗口。
步骤302与步骤102相同。
步骤303：接收端发现丢包，判断重传消耗是否不大于重传时间窗口，若是，执行步骤304；否则，执行步骤310。
步骤304：接收端确定当前时刻为重传时间窗口开始时刻，并向发送端发送重传请求，该请求中携带需重传的数据类型、起始重传包的序列号、需重传的包的连续个数、每个包重传的次数；同时，停止组帧缓冲向解码器输出数据，即：停止解码。
步骤305与步骤105相同。
步骤306：接收端接收到RTP报文，根据报文头中的载荷类型值，判断该报文中的数据是否为重传数据，若是，执行步骤308；否则，执行步骤307。
步骤307：接收端对报文进行去抖动处理，根据报文中的包序列号，将报文中的数据插入到组帧缓冲中，本流程结束。
步骤308：接收端根据报文中的包序列号，将报文中的数据插入到组帧缓冲中。
步骤309：接收端在重传时间窗口结束时刻前接收到所有丢包对应的重传包，则恢复向解码器输出数据，即：恢复解码，解码器对组帧缓冲输出的数据进行快进解码，并在所有数据都解码完毕后，再输出解码后数据，本流程结束。
解码器进行快进解码是为了减少播放时延，保证输出的图像或声音延时为固定的组帧缓冲造成的延时，在进行快进解码时不进行输出是因为：此时输出会造成快进播放的效果。
若重传时间窗口结束时刻已到但仍有丢包未重传成功，则接收端向发送端发送I帧刷新请求或直接将组帧缓冲中的数据输出到解码器开始解码。
步骤310：接收端向发送端发送I帧刷新请求，或者直接将组帧缓冲中的数据发往解码器。
另外，为了使得重传时间窗口更能适应网络状况的变化，以在保证重传成功的前提下减少时延，可以在接收端连续m(m≥1)次检测到丢包重传失败即：重传时间窗口结束时刻已到、但仍有丢包未重传成功后，增大重传时间窗口的大小即：增加组帧缓冲的长度，并可增加每个包的重传次数；并在接收端连续n(n≥1)次丢包重传成功即：在重传时间窗口结束时刻前所有丢包都已重传成功后，减少重传时间窗口的大小即：减少组帧缓冲的长度，并可减小每个包的重传次数。这是因为：若接收端连续m(m≥1)次检测到丢包重传失败，则说明网络情况变差，导致重传消耗增大、重传包传输成功率降低等，此时增大组帧缓冲长度，可增加丢包重传的成功率；若接收端连续n(n≥1)次丢包重传成功，则说明网络情况变好，这会导致重传消耗减少，重传包更易传输成功，此时可减少组帧缓冲长度，以减少播放延迟。
在本发明实施例中，重传消耗也会每隔一段时间更新一次，这里重传时间窗口也会随实际网络情况进行调整，这样，就会使得重传消耗和重传时间窗口更能适应实际的网络情况，提高了媒体流的播放质量。
从图3所示实施例可以看出，当接收端发现丢包后，立刻停止解码，并在所有丢包都已重传成功后，才恢复解码，这样，会造成播放停止，但能保证恢复播放时播放的为最新的音、视频数据。
实施例三、在丢包恢复中，平衡满足实时性要求和播放连续性要求。
图4为本发明实施例三提供的在实时媒体流传输中恢复丢包的流程图，如图4所示，其具体步骤如下：
步骤401：接收端预先设定重传消耗，并根据一级组帧缓冲的长度确定重传时间窗口1、根据二级组帧缓冲的长度确定重传时间窗口2。
重传时间窗口1为：将一个非重传包放入一级组帧缓冲到将该包送往二级组帧缓冲所消耗的时长。
重传时间窗口2为：将一个非重传包从一级组帧缓冲放入二级组帧缓冲到将该包送往解码器所消耗的时长。
根据图2、3所示实施例可知：一级组帧缓冲长度越长实时性越差，二级组帧缓冲长度越长，播放连续性越差；因此，若对实时性要求较强，可将一级组帧缓冲长度设置得较小，同时将二级组帧缓冲的长度设置得较长；若对播放连续性要求较强，可将二级组帧缓冲长度设置得较小，同时将一级组帧缓冲长度设置得较长。无论如何设置，都要保证：重传时间窗口1+重传时间窗口2≥重传消耗。
步骤402与步骤102相同。
步骤403：接收端发现丢包，判断重传消耗是否不大于(重传时间窗口1+重传时间窗口2)，若是，执行步骤404；否则，执行步骤413。
步骤404：接收端确定当前时刻为重传时间窗口1开始时刻，同时向发送端发送重传请求，该请求中携带需重传的数据类型、起始重传包的序列号、需重传的包的连续个数、每个包重传的次数。
步骤405与步骤105相同。
步骤406：接收端接收到RTP报文，根据报文头中的载荷类型值，判断该报文中的数据是否为重传数据，若是，执行步骤408；否则，执行步骤407。
步骤407：接收端对报文进行去抖动处理，根据报文中的包序列号，将报文中的数据插入到一级组帧缓冲中，本流程结束。
只要一级组帧缓冲得到完整帧，就将该完整数据输出到二级组帧缓冲。
步骤408：接收端根据报文中的包序列号，将报文中的数据插入到一级组帧缓冲或二级组帧缓冲中。
步骤409：接收端检测到重传时间窗口1结束时刻已到，判断是否所有丢包都已重传成功，若是，执行步骤410；否则，执行步骤411。
步骤410：接收端将一级组帧缓冲中的数据输出到二级组帧缓冲，本流程结束。
步骤411：接收端停止二级组帧缓冲向解码器输出数据，同时确定重传时间窗口2开始时刻到来，并将一级组帧缓冲中的不完整数据输出到二级组帧缓冲。
步骤412：接收端在重传时间窗口2结束时刻前接收到所有丢包对应的重传包，恢复向解码器输出数据；解码器对数据进行快进解码，并在对所有数据解码成功后，再输出解码后的数据，本流程结束。
当重传时间窗口2结束时刻已到但仍有丢包未重传成功时，若数据为视频数据，则接收端向发送端发送I帧刷新请求；若数据为音频数据，则接收端直接将二级组帧缓冲中的数据输出到解码器。
步骤413：接收端向发送端发送I帧刷新请求，或者直接将组帧缓冲中的数据发往解码器。
另外，若接收端连续m(m≥1)次检测到重传时间窗口1+重传时间窗口2结束时刻已到而重传仍未成功，则接收端增大重传时间窗口2的大小，并可增大包重传的次数；若接收端连续n(n≥1)次检测到在重传时间窗口1+重传时间窗口2结束时刻前所有丢包就已重传成功，则接收端减少重传时间窗口2的大小，并可减少包重传的次数。
以下给出本发明实施例提供的丢包恢复系统，该系统包括：发送端单元和接收端单元，其中：
发送端单元：用于将数据打包成实时传输协议RTP报文发送给接收端单元，同时保存数据和RTP参数；接收到重传请求，将保存的需重传的数据和RTP参数打包成RTP报文发送给接收端单元。
接收端单元：用于统计包重传所消耗的时长即重传消耗，把将一个非重传包放入组帧缓冲到将该包送往解码器所消耗的时长作为重传时间窗口，当发现丢包时，若确定重传消耗不大于重传时间窗口，则向发送端单元发送重传请求，同时确定当前时刻为重传时间窗口开始时刻；在重传时间窗口结束时刻前收到发送端单元发来的重传数据，将该重传数据插入组帧缓冲中。
图5为本发明实施例提供的实时媒体流传输中的发送端单元的结构示意图，如图5所示，其主要包括：编码模块51、发送缓冲52、发送模块53、保留缓冲54、重传模块55、重传缓冲56和I帧刷新模块57，其中：
编码模块51：用于对数据进行编码，将编码后的数据输出到发送缓冲52。
发送缓冲52：接收并缓存编码模块51输入的数据。
发送模块53：确定要发送数据，从发送缓冲52中取出数据，将数据打包成RTP报文，将RTP报文发送给接收端单元，同时将RTP参数和数据对应保存一份到保留缓冲54。
保留缓冲54：对应保存已发送的数据和RTP参数，以备重传。
重传模块55：接收接收端单元发来的重传请求，根据请求中携带的重传数据类型、起始重传包序列号、需重传的包的连续个数、每个包重传的次数，从保留缓冲54中取出重传数据和RTP参数，将重传数据和RTP参数放入重传缓冲56等待重传；依次从重传缓冲56取出数据和RTP参数打包成RTP报文，将RTP报文头中的载荷类型值设置为特定值，将RTP报文通过复用RTP通道、并采用最高IP优先级发送给接收端单元。
重传缓冲56：对应保存待重传的数据和RTP参数。
I帧刷新模块57：接收接收端单元发来的I帧刷新请求，根据该请求从编码模块51获取数据。
图6为本发明实施例一提供的实时媒体流传输中的接收端单元的结构示意图，如图6所示，其主要包括：接收模块61、丢包发现模块62、排序缓冲63、组帧缓冲64、重传请求模块65、解码模块66和I帧刷新模块67，其中：
接收模块61：接收发送端单元发来的RTP报文，根据报文中的载荷类型值判断报文中携带的数据是否为重传数据，若是，直接根据报文中的包序列号，将报文中的重传数据插入组帧缓冲64中；否则，根据报文中的包序列号，将报文中的数据插入排序缓冲63中。
丢包发现模块62：统计包重传所消耗的时长即重传消耗，把将一个非重传包放入组帧缓冲到将该包送往解码器所消耗的时长作为重传时间窗口，每检测到排序缓冲中的预定范围内的数据完成去抖动、乱序处理时，判断一次是否发生丢包，若发生，判断重传消耗是否不大于重传时间窗口，若不大于，确定当前时刻为重传时间窗口开始时刻，同时向重传请求模块65发送重传指示，该指示中携带需重传的数据类型、起始重传包的序列号、需重传的包的连续个数、每个包重传的次数；若小于，向I帧刷新模块67发送I帧刷新指示，或者向组帧缓冲64发送解码指示。当检测到重传时间窗口结束时刻已到，但组帧缓冲64中仍有丢包未重传成功，则向I帧刷新模块67发送I帧刷新指示，该指示中携带需刷新的帧标识或条带标识，或者向组帧缓冲64发送解码指示。
排序缓冲63：对接收模块61发来的数据进行去抖动、乱序处理，将去抖动、乱序后的数据送入组帧缓冲64。
组帧缓冲64：对排序缓冲63发来的数据进行组帧处理，组帧成功后，将数据发往解码模块66；接收丢包发现模块62发来的解码指示，将数据发往解码模块66。
重传请求模块65：接收丢包发现模块62发来的重传指示，将该指示中的需重传的数据类型及需重传的包序列号携带在重传请求中发送给发送端单元。
解码模块66：对组帧缓冲64发来的帧进行解码，将解码后的数据输出。
I帧刷新模块67：接收丢包发现模块62发来的I帧刷新请求，向发送端单元发送I帧刷新请求。
若图6所示接收端针对的是音频数据，则不包含I帧刷新模块67。
以下给出本发明实施例二提供的实时媒体流传输中的接收端单元的结构示意图，该实施例中的接收端单元的组成部分与图6所示接收端单元的组成部分相同，且该实施例中的接收端单元的接收模块01、丢包发现模块02、排序缓冲03、I帧刷新模块07与图6中的接收端单元的接收模块61、丢包发现模块62、排序缓冲63、I帧刷新模块67分别相同，区别在于：
组帧缓冲04：用于对排序缓冲03发来的数据进行组帧处理，得到一个完整帧后，将数据发往解码模块06；当接收到丢包发现模块02发来的丢包指示时，停止向解码模块06输出数据，接受接收模块01插入的重传数据，当检测到所有丢包都重传成功时，恢复向解码模块06输出数据，并向解码模块06发送不输出指示；接收丢包发现模块02发来的解码指示，将数据发往解码模块06。
重传请求模块05：接收丢包发现模块02发来重传指示，将该指示中的需重传的数据类型及需重传的包序列号携带在重传请求中发送给发送端单元。
解码模块06：对组帧缓冲04发来的帧进行解码，将解码后的数据输出。当接收到组帧缓冲04发来的数据，并接收到不输出指示时，对组帧缓冲04发来的数据进行快进解码，并在对所有数据都解码完毕后，将解码后的数据输出。
图7为本发明实施例三提供的接收端单元的结构示意图，如图7所示，其主要包括：接收模块71、丢包发现模块72、排序缓冲73、一级组帧缓冲741、二级组帧缓冲742、重传请求模块75、解码模块76和I帧刷新模块77，其中：
I帧刷新模块77与图6中的I帧刷新模块67相同。
接收模块71：接收发送端单元发来的RTP报文，根据报文中的载荷类型值判断报文中携带的数据是否为重传数据，若是，直接根据报文中的包序列号，将报文中的重传数据插入一级组帧缓冲741或二级组帧缓冲742中；否则，根据报文中的包序列号，将报文中的数据插入排序缓冲73中。
丢包发现模块72：统计包重传所消耗的时长即重传消耗，把将一个非重传包放入一级组帧缓冲到将该包送往二级组帧缓冲所消耗的时长作为重传时间窗口1，把将一个非重传包从一级组帧缓冲放入二级组帧缓冲到将该包送往解码器所消耗的时长作为重传时间窗口2，每检测到排序缓冲中的预定范围内的数据完成去抖动、乱序处理时，判断一次是否发生丢包，若发生，判断重传消耗是否不大于重传时间窗口1+重传时间窗口2，若不大于，确定当前时刻为重传时间窗口1开始时刻，同时向重传请求模块75发送重传指示，该指示中携带需重传的数据类型及需重传的包的序列号；若小于，向I帧刷新模块77发送I帧刷新指示，或者向二级组帧缓冲742发送解码指示。当检测到重传时间窗口1结束时刻已到，但一级组帧缓冲741中仍有丢包未重传成功时，则向一级组帧缓冲741发送输出指示，同时向二级组帧缓冲742发送停止输出指示，同时确定重传时间窗口2开始时刻到来；当检测到重传时间窗口2结束时刻已到，但二级组帧缓冲742中仍有丢包未重传成功时，则向I帧刷新模块77发送I帧刷新指示，该指示中携带需刷新的帧标识或条带标识，或者向二级组帧缓冲742发送解码指示。
排序缓冲73：对接收模块71发来的数据进行去抖动、乱序处理，将去抖动、乱序后的数据送入一级组帧缓冲741。
一级组帧缓冲741：对排序缓冲73发来的数据进行组帧处理，组帧成功后将数据发送到二级组帧缓冲742；接收丢包发现模块72发来的输出指示，将本缓冲中的不完整数据输出到二级组帧缓冲742。
二级组帧缓冲742：对一级组帧缓冲741发来的数据进行组帧处理，将数据发送到解码模块76；当收到丢包发现模块72发来的停止输出指示时，停止向解码模块76输出数据，并接收一级组帧缓冲741发来的数据，接受接收模块71插入的重传数据，当检测到所有丢包都已重传成功时，恢复向解码模块76输出数据，并向解码模块76发送不输出指示；接收丢包发现模块72发来的解码指示，将数据发往解码模块76。
重传请求模块75：接收丢包发现模块72发来重传指示，将该指示中的需重传的数据类型及需重传的包序列号携带在重传请求中发送给发送端单元。
解码模块76：对二级组帧缓冲742发来的数据进行解码，将解码后的数据输出。当接收到二级组帧缓冲742发来的数据，并接收到不输出指示时，对二级组帧缓冲742发来的数据进行快进解码，并在对所有数据都解码完毕后，将解码后的数据输出。
以上所述仅为本发明的过程及方法实施例，并不用以限制本发明，凡在本发明的精神和原则之内所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。
Claims (24)
1.一种实时报文丢包恢复方法，其特征在于，接收端统计包重传所消耗的时长即重传消耗，并把将一个非重传包放入组帧缓冲到将该包送往解码器所消耗的时长作为重传时间窗口，包括：
接收端发现丢包，若确定重传消耗不大于重传时间窗口，则向发送端发送重传请求，同时确定当前时刻为重传时间窗口开始时刻；在重传时间窗口结束时刻前收到发送端发来的重传数据，将该重传数据插入组帧缓冲中。
2.如权利要求1所述的方法，其特征在于，所述接收端统计包重传所消耗的时长即重传消耗包括：
接收端每隔预定时间统计并更新一次重传消耗。
3.如权利要求1所述的方法，其特征在于，所述接收端发现丢包进一步包括：停止组帧缓冲向解码器输出数据；
且，所述将重传数据插入组帧缓冲中之后进一步包括：
确定所有丢包都已重传成功，恢复组帧缓冲向解码器输出数据。
4.如权利要求3所述的方法，其特征在于，所述恢复组帧缓冲向解码器输出数据进一步包括：解码器对数据进行快进解码，并在对组帧缓冲输出的所有数据都解码成功后，将解码后的数据输出。
5.如权利要求1所述的方法，其特征在于，所述组帧缓冲包括一级组帧缓冲和二级组帧缓冲，把将一个非重传包放入一级组帧缓冲到将该包送往二级组帧缓冲所消耗的时长作为重传时间窗口1，把将一个非重传包从一级组帧缓冲放入二级组帧缓冲到将该包送往解码器所消耗的时长作为重传时间窗口2；
所述确定当前时刻为重传时间窗口开始时刻为：确定当前时刻为重传时间窗口1开始时刻，
所述接收端在重传时间窗口结束时刻前收到发送端发来的重传数据为：接收端在重传时间窗口1结束时刻前收到发送端发来的重传数据；
所述将该重传数据插入组帧缓冲中包括：根据重传数据的序列号，将重传数据插入一级组帧缓冲或二级组帧缓冲；
所述将该重传数据插入组帧缓冲中进一步包括：检测到重传时间窗口1结束时刻已到但仍有丢包未重传成功，则停止二级组帧缓冲向解码器输出数据，同时确定重传时间窗口2开始时刻到来，在所有丢包都重传成功后，恢复二级组帧缓冲向解码器输出数据。
6.如权利要求5所述的方法，其特征在于，所述恢复二级组帧缓冲向解码器输出数据进一步包括：解码器对二级组帧缓冲输出的数据进行快进解码，并在对所有数据都解码完毕后，将解码后的数据输出。
7.如权利要求1至6任一所述的方法，其特征在于，所述方法进一步包括：接收端连续预定次数检测到重传时间窗口结束时刻已到、但丢包仍未重传成功，则增大组帧缓冲长度，
和/或，通知发送端增加丢包的重传次数。
8.如权利要求1至6任一所述的方法，其特征在于，所述方法进一步包括：接收端连续预定次数检测到在重传时间窗口结束时刻前，丢包就已重传成功，则减少组帧缓冲的长度，
和/或，通知发送端减少丢包的重传次数。
9.如权利要求5或6所述的方法，其特征在于，所述方法进一步包括：检测到用户对播放连续性的要求大于对实时性的要求，则将一级组帧缓冲的长度设置得长于二级组帧缓冲的长度。
10.如权利要求5或6所述的方法，其特征在于，所述方法进一步包括：检测到用户对实时性的要求大于对播放连续性的要求，则将二级组帧缓冲的长度设置得长于一级组帧缓冲的长度。
11.如权利要求1至6任一所述的方法，其特征在于，所述接收端发现丢包包括：接收端在预定的容许抖动时长内未接收到来自发送端的数据，则确定发生丢包。
12.如权利要求1至6任一所述的方法，其特征在于，所述丢包为视频数据，所述方法进一步包括：重传时间窗口结束时刻已到，接收端仍有丢包未重传成功，则接收端向发送端请求I帧刷新，或者直接将组帧缓冲中的数据输出到解码器。
13.如权利要求1至6任一所述的方法，其特征在于，所述丢包为音频数据，所述方法进一步包括：重传时间窗口结束时刻已到，接收端丢包仍未重传成功，则接收端直接将组帧缓冲中的数据输出到解码器。
14.一种实时报文丢包恢复方法，其特征在于，接收端统计包重传所消耗的时长即重传消耗，并把将一个非重传包放入组帧缓冲到将该包送往解码器所消耗的时长作为重传时间窗口，包括：
发送端将数据打包成实时报文发送给接收端，同时保存数据；接收端发现丢包，若确定重传消耗不大于重传时间窗口，则向发送端发送重传请求，同时确定当前时刻为重传时间窗口开始时刻，发送端将保存的需重传的数据打包成报文发送给接收端；接收端在重传时间窗口结束时刻前收到发送端发来的重传数据，将该重传数据插入组帧缓冲中。
15.如权利要求14所述的方法，其特征在于，所述发送端将报文发送给接收端包括：发送端将报文通过已有的实时报文通道发送给接收端。
16.如权利要求14或15所述的方法，其特征在于，所述发送端将报文发送给接收端包括：发送端将报文采用最高IP优先级发送给接收端。
17.如权利要求14或15所述的方法，其特征在于，所述发送端将保存的需重传的数据打包成报文发送给接收端进一步包括：将报文中的载荷类型值被设定为RFC标准中未定义的值，以表示该报文中的数据为重传数据。
18.一种实时报文丢包恢复系统，其特征在于，包括：
发送端单元，将数据打包成实时报文发送给接收端单元，同时保存数据；接收到重传请求，将保存的需重传的数据打包成报文发送给接收端单元；
接收端单元，统计包重传所消耗的时长即重传消耗，把将一个非重传包放入组帧缓冲到将该包送往解码器所消耗的时长作为重传时间窗口，当发现丢包时，若确定重传消耗不大于重传时间窗口，则向发送端单元发送重传请求，同时确定当前时刻为重传时间窗口开始时刻；在重传时间窗口结束时刻前收到发送端单元发来的重传数据，将该重传数据插入组帧缓冲中。
19.如权利要求18所述的系统，其特征在于，所述发送端单元包括：
发送缓冲，缓存待发送数据；
发送模块，从发送缓冲取出数据，将数据打包成实时报文，将报文发送给接收端单元，同时将数据保存到保留缓冲；
保留缓冲，缓存已发送数据；
重传模块，接收接收端单元发来的重传请求，根据请求中携带的重传数据信息，从保留缓冲中取出重传数据放入重传缓冲，从重传缓冲依次取出数据并打包成报文发送给接收端单元；
重传缓冲，缓存待重传的数据。
20.一种接收端单元，其特征在于，包括：
接收模块，接收发送端单元发来的重传数据，将重传数据插入组帧缓冲；
丢包发现模块，统计包重传所消耗的时长即重传消耗，把将一个非重传包放入组帧缓冲到将该包送往解码器所消耗的时长作为重传时间窗口；检测到发生丢包，且确定重传消耗不大于重传时间窗口，向重传请求模块发送重传指示，该指示中携带需重传的数据信息；
组帧缓冲，接收接收模块插入的数据；
重传请求模块，接收丢包发现模块发来的重传指示，将该指示中的需重传的数据信息携带在重传请求中发送给发送端单元。
21.如权利要求20所述的接收端单元，其特征在于，该接收端单元进一步包括：
排序缓冲，用于对接收模块发来的数据包进行去抖动、乱序处理，将去抖动、乱序后的数据送入组帧缓冲，
且，所述接收模块进一步用于，接收到发送端单元发来的非重传包，将该包放入排序缓冲。
22.如权利要求20所述的接收端单元，其特征在于，
所述组帧缓冲进一步用于，当接收到丢包发现模块发来的丢包指示时，停止向解码模块输出数据，当检测到所有丢包都重传成功时，恢复向解码模块输出数据，并向解码模块发送不输出指示；
解码模块，当接收到组帧缓冲发来的数据，并接收到不输出指示时，对组帧缓冲发来的数据进行快进解码，并在对所有数据都解码完毕后，将解码后的数据输出。
23.如权利要求20所述的接收端单元，其特征在于，
所述组帧缓冲包括：一级组帧缓冲和二级组帧缓冲，且所述接收端单元进一步包括解码模块，其中：
一级组帧缓冲，当接收到输出指示时，将本缓冲中的不完整数据输出到二级组帧缓冲；
二级组帧缓冲，当接收到停止输出指示时，停止向解码模块输出数据，同时确定重传时间窗口2开始时刻到来，当在重传时间窗口2结束时刻前接收到所有丢包对应的重传包时，恢复向解码模块输出数据；
解码模块，对二级组帧缓冲发来的数据进行解码，将解码后的数据输出；
且，所述丢包发现模块进一步用于，把将一个非重传包放入一级组帧缓冲到将该包送往二级组帧缓冲所消耗的时长作为重传时间窗口1，把将一个非重传包从一级组帧缓冲放入二级组帧缓冲到将该包送往解码器所消耗的时长作为重传时间窗口2；当向重传请求模块发送重传指示的同时，确定当前时刻为重传时间窗口1开始时刻，若检测到重传时间窗口1结束时刻已到但一级组帧缓冲中仍有丢包未重传成功，则确定重传时间窗口2开始时刻到来，并向一级组帧缓冲发送输出指示，向二级组帧缓冲发送停止输出指示。
24.如权利要求23所述的接收端单元，其特征在于，所述解码模块进一步用于，当接收到不输出指示时，对二级组帧缓冲发来的数据进行快进解码，并在对所有数据都解码完毕后，将解码后的数据输出；
且，所述二级组帧缓冲在恢复向解码模块输出数据的同时，向解码模块发送不输出指示。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN2008100570616A CN101222311B (zh) | 2008-01-29 | 2008-01-29 | 实时报文丢包恢复方法、系统及接收端单元 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN2008100570616A CN101222311B (zh) | 2008-01-29 | 2008-01-29 | 实时报文丢包恢复方法、系统及接收端单元 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN101222311A true CN101222311A (zh) | 2008-07-16 |
| CN101222311B CN101222311B (zh) | 2010-12-08 |
Family
ID=39631910
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN2008100570616A Active CN101222311B (zh) | 2008-01-29 | 2008-01-29 | 实时报文丢包恢复方法、系统及接收端单元 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN101222311B (zh) |
Cited By (23)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101500158A (zh) * | 2008-12-26 | 2009-08-05 | 深圳市同洲电子股份有限公司 | 一种可视对讲机及其音视频数据传输方法和系统 |
| WO2010088836A1 (zh) * | 2009-02-09 | 2010-08-12 | 中兴通讯股份有限公司 | 用户数据报协议传输模式下丢包补偿方法与装置 |
| CN102006476A (zh) * | 2010-11-19 | 2011-04-06 | 厦门雅迅网络股份有限公司 | 一种传输和接收实时视频数据的优化处理方法 |
| CN103096183A (zh) * | 2013-02-05 | 2013-05-08 | 清华大学 | 一种高效流媒体传输方法 |
| CN103368703A (zh) * | 2012-04-10 | 2013-10-23 | 华为技术有限公司 | 数据包重传方法、数据包接收方法及装置 |
| CN103533450A (zh) * | 2013-06-09 | 2014-01-22 | 浙江宇视科技有限公司 | 一种媒体流可靠传输和接收的方法以及装置 |
| CN103546391A (zh) * | 2013-11-04 | 2014-01-29 | 腾讯科技（武汉）有限公司 | 发送数据包的方法、装置及终端 |
| CN103906140A (zh) * | 2012-12-28 | 2014-07-02 | 中国移动通信集团公司 | 一种数据传输动态调整方法及设备 |
| CN104038845A (zh) * | 2014-06-30 | 2014-09-10 | 杭州华三通信技术有限公司 | 报文传输方法及装置 |
| CN105357577A (zh) * | 2014-08-22 | 2016-02-24 | 中兴通讯股份有限公司 | 一种丢包重传方法及装置 |
| CN105450969A (zh) * | 2014-06-16 | 2016-03-30 | 联想(北京)有限公司 | 一种实时视频数据传输方法及电子设备 |
| CN105933319A (zh) * | 2016-05-30 | 2016-09-07 | 贵阳朗玛信息技术股份有限公司 | 视频数据包的发送、接收方法及装置 |
| CN108521382A (zh) * | 2018-04-11 | 2018-09-11 | 中国农业银行股份有限公司 | 一种消息发送方法、装置及系统 |
| CN109328375A (zh) * | 2016-06-30 | 2019-02-12 | 三菱电机株式会社 | 数据收集服务器及缺损数据补充方法 |
| CN110233856A (zh) * | 2019-06-28 | 2019-09-13 | 北京云中融信网络科技有限公司 | 报文处理方法、装置及计算机可读存储介质 |
| CN110601799A (zh) * | 2019-09-12 | 2019-12-20 | 无锡江南计算技术研究所 | 一种基于双滑动窗口的链路重传方法及装置 |
| CN111130720A (zh) * | 2019-12-24 | 2020-05-08 | 天地伟业技术有限公司 | 一种基于内存优化的重传机制 |
| CN111327962A (zh) * | 2020-03-06 | 2020-06-23 | 广州市百果园信息技术有限公司 | 播放控制方法、装置、设备及存储介质 |
| CN111327402A (zh) * | 2018-12-17 | 2020-06-23 | 杭州海康威视数字技术股份有限公司 | 重传数据的方法、装置和系统 |
| CN112953847A (zh) * | 2021-01-27 | 2021-06-11 | 北京字跳网络技术有限公司 | 网络的拥塞控制方法、装置、电子设备及存储介质 |
| CN112995685A (zh) * | 2021-02-05 | 2021-06-18 | 杭州朗和科技有限公司 | 数据发送方法及装置、数据接收方法及装置、介质、设备 |
| CN113572564A (zh) * | 2021-09-22 | 2021-10-29 | 华海通信技术有限公司 | 一种光分插复用分支器、通信系统及信号传输方法 |
| CN115426317A (zh) * | 2022-11-03 | 2022-12-02 | 新华三信息技术有限公司 | 数据传输速率控制方法、装置及电子设备 |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6629285B1 (en) * | 2000-01-04 | 2003-09-30 | Nokia Corporation | Data transmission |
| CN101030839A (zh) * | 2007-02-13 | 2007-09-05 | 华为技术有限公司 | 一种数据重传的方法 |
-
2008
- 2008-01-29 CN CN2008100570616A patent/CN101222311B/zh active Active
Cited By (41)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101500158A (zh) * | 2008-12-26 | 2009-08-05 | 深圳市同洲电子股份有限公司 | 一种可视对讲机及其音视频数据传输方法和系统 |
| CN101500158B (zh) * | 2008-12-26 | 2013-10-16 | 深圳市同洲电子股份有限公司 | 一种可视对讲机及其音视频数据传输方法和系统 |
| WO2010088836A1 (zh) * | 2009-02-09 | 2010-08-12 | 中兴通讯股份有限公司 | 用户数据报协议传输模式下丢包补偿方法与装置 |
| RU2501172C2 (ru) * | 2009-02-09 | 2013-12-10 | Зте Корпорейшн | Способ и устройство для компенсации потери пакетов в режиме передачи данных по протоколу пользовательских дейтаграмм |
| CN102006476A (zh) * | 2010-11-19 | 2011-04-06 | 厦门雅迅网络股份有限公司 | 一种传输和接收实时视频数据的优化处理方法 |
| CN103368703B (zh) * | 2012-04-10 | 2016-08-17 | 华为技术有限公司 | 数据包重传方法、数据包接收方法及装置 |
| CN103368703A (zh) * | 2012-04-10 | 2013-10-23 | 华为技术有限公司 | 数据包重传方法、数据包接收方法及装置 |
| CN103906140A (zh) * | 2012-12-28 | 2014-07-02 | 中国移动通信集团公司 | 一种数据传输动态调整方法及设备 |
| CN103906140B (zh) * | 2012-12-28 | 2018-05-08 | 中国移动通信集团公司 | 一种数据传输动态调整方法及设备 |
| CN103096183A (zh) * | 2013-02-05 | 2013-05-08 | 清华大学 | 一种高效流媒体传输方法 |
| CN103096183B (zh) * | 2013-02-05 | 2015-12-09 | 清华大学 | 一种高效流媒体传输方法 |
| CN103533450B (zh) * | 2013-06-09 | 2018-03-09 | 浙江宇视科技有限公司 | 一种媒体流可靠传输和接收的方法以及装置 |
| CN103533450A (zh) * | 2013-06-09 | 2014-01-22 | 浙江宇视科技有限公司 | 一种媒体流可靠传输和接收的方法以及装置 |
| CN103546391A (zh) * | 2013-11-04 | 2014-01-29 | 腾讯科技（武汉）有限公司 | 发送数据包的方法、装置及终端 |
| CN105450969A (zh) * | 2014-06-16 | 2016-03-30 | 联想(北京)有限公司 | 一种实时视频数据传输方法及电子设备 |
| CN105450969B (zh) * | 2014-06-16 | 2019-01-15 | 联想(北京)有限公司 | 一种实时视频数据传输方法及电子设备 |
| CN104038845A (zh) * | 2014-06-30 | 2014-09-10 | 杭州华三通信技术有限公司 | 报文传输方法及装置 |
| CN104038845B (zh) * | 2014-06-30 | 2017-10-17 | 新华三技术有限公司 | 报文传输方法及装置 |
| CN105357577A (zh) * | 2014-08-22 | 2016-02-24 | 中兴通讯股份有限公司 | 一种丢包重传方法及装置 |
| CN105933319A (zh) * | 2016-05-30 | 2016-09-07 | 贵阳朗玛信息技术股份有限公司 | 视频数据包的发送、接收方法及装置 |
| CN109328375A (zh) * | 2016-06-30 | 2019-02-12 | 三菱电机株式会社 | 数据收集服务器及缺损数据补充方法 |
| CN109328375B (zh) * | 2016-06-30 | 2020-12-15 | 三菱电机株式会社 | 数据收集服务器及缺损数据补充方法 |
| CN108521382B (zh) * | 2018-04-11 | 2021-12-03 | 中国农业银行股份有限公司 | 一种消息发送方法、装置及系统 |
| CN108521382A (zh) * | 2018-04-11 | 2018-09-11 | 中国农业银行股份有限公司 | 一种消息发送方法、装置及系统 |
| CN111327402A (zh) * | 2018-12-17 | 2020-06-23 | 杭州海康威视数字技术股份有限公司 | 重传数据的方法、装置和系统 |
| WO2020125647A1 (zh) * | 2018-12-17 | 2020-06-25 | 杭州海康威视数字技术股份有限公司 | 重传数据的方法、装置和系统 |
| CN111327402B (zh) * | 2018-12-17 | 2021-12-31 | 杭州海康威视数字技术股份有限公司 | 重传数据的方法、装置和系统 |
| CN110233856A (zh) * | 2019-06-28 | 2019-09-13 | 北京云中融信网络科技有限公司 | 报文处理方法、装置及计算机可读存储介质 |
| CN110601799A (zh) * | 2019-09-12 | 2019-12-20 | 无锡江南计算技术研究所 | 一种基于双滑动窗口的链路重传方法及装置 |
| CN111130720B (zh) * | 2019-12-24 | 2022-11-08 | 天地伟业技术有限公司 | 一种基于内存优化的重传机制 |
| CN111130720A (zh) * | 2019-12-24 | 2020-05-08 | 天地伟业技术有限公司 | 一种基于内存优化的重传机制 |
| CN111327962B (zh) * | 2020-03-06 | 2022-07-12 | 广州市百果园信息技术有限公司 | 播放控制方法、装置、设备及存储介质 |
| CN111327962A (zh) * | 2020-03-06 | 2020-06-23 | 广州市百果园信息技术有限公司 | 播放控制方法、装置、设备及存储介质 |
| CN112953847A (zh) * | 2021-01-27 | 2021-06-11 | 北京字跳网络技术有限公司 | 网络的拥塞控制方法、装置、电子设备及存储介质 |
| CN112953847B (zh) * | 2021-01-27 | 2022-11-11 | 北京字跳网络技术有限公司 | 网络的拥塞控制方法、装置、电子设备及存储介质 |
| CN112995685A (zh) * | 2021-02-05 | 2021-06-18 | 杭州朗和科技有限公司 | 数据发送方法及装置、数据接收方法及装置、介质、设备 |
| CN112995685B (zh) * | 2021-02-05 | 2023-02-17 | 杭州网易智企科技有限公司 | 数据发送方法及装置、数据接收方法及装置、介质、设备 |
| CN113572564B (zh) * | 2021-09-22 | 2021-11-26 | 华海通信技术有限公司 | 一种光分插复用分支器、通信系统及信号传输方法 |
| CN113572564A (zh) * | 2021-09-22 | 2021-10-29 | 华海通信技术有限公司 | 一种光分插复用分支器、通信系统及信号传输方法 |
| CN115426317A (zh) * | 2022-11-03 | 2022-12-02 | 新华三信息技术有限公司 | 数据传输速率控制方法、装置及电子设备 |
| CN115426317B (zh) * | 2022-11-03 | 2023-03-24 | 新华三信息技术有限公司 | 数据传输速率控制方法、装置及电子设备 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN101222311B (zh) | 2010-12-08 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN101222311B (zh) | 实时报文丢包恢复方法、系统及接收端单元 | |
| US10645448B2 (en) | Buffer-aware transmission rate control for real-time video streaming system | |
| CN101252425B (zh) | 一种自动适应网络的丢包纠错方法和系统 | |
| CN101552660B (zh) | 对流媒体数据进行重传、播放的方法、装置及通信系统 | |
| US7877514B2 (en) | System and method for time-constrained transmission of video in a communication system | |
| US7756127B2 (en) | Mobile terminal | |
| CN102687448B (zh) | 网络中可靠实时数据流传输的高效应用层自动重复请求重发的方法 | |
| CN101179362B (zh) | 适宜移动流媒体应用的自动重传请求机制 | |
| CN109155707B (zh) | 在多播网络中请求数据重传 | |
| US20050036546A1 (en) | Video data transmission method and apparatus | |
| CN102742245A (zh) | 用于解析网络抽象层以实现可靠数据通信的方法和设备 | |
| JP2003333577A (ja) | メディア・ストリーミング配信システム | |
| JPH09191314A (ja) | 連続データ伝送方法および連続データ伝送装置 | |
| US20060245428A1 (en) | Transmisssion/reception system, transmitting device and method, and receiving device and method | |
| KR20030045643A (ko) | 데이터 통신 시스템, 데이터 송신 장치, 데이터 수신 장치, 데이터 통신 방법, 및 컴퓨터 프로그램 기록 매체 | |
| CN103109485A (zh) | 用于作出重发决定的方法和装置 | |
| US20120201205A1 (en) | Method for improved robust header compression with low signal energy | |
| US10361819B2 (en) | Packet retransmission method in a wireless transmitter | |
| CN101944982B (zh) | 基于时间驱动滑动窗口协议的流媒体实时转发方法 | |
| JP2003324496A (ja) | データ伝送方法，及びパケットデータ構造 | |
| CN109246063B (zh) | 一种lsb回绕优化方法及装置 | |
| JP3735352B2 (ja) | データ伝送方法，データ送信装置，及びデータ受信装置 | |
| EP2418903A1 (en) | A packet retransmission method in a wirelss transmitter |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| C14 | Grant of patent or utility model | ||
| GR01 | Patent grant | ||
| CP03 | Change of name, title or address | ||
| CP03 | Change of name, title or address |
Address after: 310052 Binjiang District Changhe Road, Zhejiang, China, No. 466, No. Patentee after: Xinhua three Technology Co., Ltd. Address before: 310053 Hangzhou hi tech Industrial Development Zone, Zhejiang province science and Technology Industrial Park, No. 310 and No. six road, HUAWEI, Hangzhou production base Patentee before: Huasan Communication Technology Co., Ltd. |