CN110876091B

CN110876091B - 一种利用rtp扩展头部解决视频帧丢包的方法及装置

Info

Publication number: CN110876091B
Application number: CN202010060865.2A
Authority: CN
Inventors: 董大源; 张倩; 刘鹏飞; 黄永佳
Original assignee: Marvell World Trade Ltd
Current assignee: ASR Microelectronics Co Ltd
Priority date: 2020-01-20
Filing date: 2020-01-20
Publication date: 2020-04-24
Anticipated expiration: 2040-01-20
Also published as: CN110876091A

Abstract

本申请公开了一种利用RTP扩展头部解决视频帧丢包的方法，包括如下步骤。步骤S10：提供一种新的RTP扩展头部，其头部标识具有两种取值。步骤S20：发送端仅在关键帧后面的n个对应于非关键帧的RTP数据包中携带头部标识为第一取值的所述RTP扩展头部。步骤S30：接收端发现RTP数据包有丢失时，根据头部标识为第一取值的所述RTP扩展头部判断丢失的RTP数据包是否属于关键帧。如果是，接收端向发送端发送RTP数据包，其中携带头部标识为第二取值的所述RTP扩展头部。步骤S40：发送端根据头部标识为第二取值的RTP扩展头部向接收端重新发送相应的RTP数据包。本申请只重传关键帧，所以耗费带宽不是很大，但能有效地带来视频传输及播放质量的提升。

Description

一种利用RTP扩展头部解决视频帧丢包的方法及装置

技术领域

本申请涉及一种视频数据的传输方法，特别是涉及一种视频数据在传输过程中丢包的解决方法。

背景技术

在网络通信中，视频通话比音频通话要使用更大的带宽。为了减少视频通话的带宽使用，一般的视频编码器在编码时会对原始的视频流编码成不同类型的视频帧。例如H.264视频压缩标准定义了I帧、P帧、B帧等。I帧采用帧内编码（Intra-coded），优点是不依赖其他帧进行独立解码，缺点是编码后的数据比较大。P帧和B帧都采用帧间编码（Interframe prediction），相对I帧而言其优点是编码后数据较小可以节省带宽，但解码需要依赖I帧，如果依赖的I帧丢失，P帧或B帧无法单独解码。在视频通话过程中，为了节约带宽减少时延，一般的视频编码器例如H.264、H.265等会采用I帧、P帧混合编码，通过周期性的编码I帧，并在两个I帧之间编码P帧达到节约带宽、提高视频质量的效果。例如每间隔1秒发送一个I帧，每两个I帧中间发送P帧。

在TCP/IP网络传输中定义有MTU（Maximum Transmission Unit，最大传输单元），例如以太网（Ethernet）的MTU为1500字节（byte）。当视频通话采用VGA或更高分辨率时，一帧图像的大小往往大于MTU的大小。此时发送端的应用层往往会将一个视频帧分成多个RTP（Real-time Transport Protocol，实时传输协议）数据包（packet）发送，例如RFC 6184规范定义的FU-A分片的RTP数据包。接收端在收到RTP数据包后，根据其中的序列号（sequencenumber）和时间戳（timestamp）重新组成原始视频帧。在视频通话过程中，网络状况经常会发生不可预知的变化，从而造成视频传输过程中丢包。当一个视频帧的某些RTP数据包丢失，接收端就无法组成完整的视频帧，并且不得不丢弃已经收到的该视频帧的其他RTP数据包。如果丢失的是P帧，对接收端的视频播放影响相对较小。如果丢失的是I帧，由于P帧的解码需要参考I帧，I帧的缺失会对接收端的视频播放产生比较大的影响，造成马赛克或者花屏等显示异常。并且，这种显示异常直到接收端收到下一个I帧才能恢复，比如要过1秒。

目前应对网络侧丢包对于视频通话的影响，已有一些解决方案。

其一，接收端通过RTCP（Real-time Transport Control Protocol，实时传输控制协议）发送NACK（Negative Acknowledgement，否定应答）通知发送端重发丢失的RTP数据包。该方案会加重网络负荷。如果此时网络丢包率比较大，会导致网络丢包更加严重，效果可能更差。并且，发送端无选择地重发所有丢失的包，也会在接收端引入较大的延迟。

其二，接收端发送PLI（Picture Loss Indication，图像丢失指示）通知发送端立即编码新的I帧发送。该方案中，发送端接收到PLI请求后，需要控制视频编码器编码出新的I帧并分包传输，接收端需要接收这些RTP数据包并重组为新的I帧，视频才能恢复。编码、分包、传输、组包的延迟叠加，导致接收端的视频恢复需要较长的时间。

发明内容

本申请所要解决的技术问题是提出了一种新机制，通过对RTP扩展头部的扩充，标识出关键帧的索引。当网络出现丢包时，利用关键帧的索引，优先传送关键帧。这样，在消耗带宽不大的前提下，可以有效地提升视频质量。

为解决上述技术问题，本申请提供了一种利用RTP扩展头部解决视频帧丢包的方法，包括如下步骤。步骤S10：提供一种新的RTP扩展头部，其头部标识具有两种取值；头部标识为第一取值时，所述RTP扩展头部中记载了发送端所发送的一个或多个RTP历史数据包是否属于关键帧；头部标识为第二取值时，所述RTP扩展头部中记载了接收端要求发送端重新发送的RTP数据包的信息。步骤S20：发送端向接收端发送RTP数据包，所述RTP数据包属于视频帧；发送端仅在关键帧后面的n个对应于非关键帧的RTP数据包中携带头部标识为第一取值的所述RTP扩展头部。步骤S30：接收端发现RTP数据包有丢失时，根据头部标识为第一取值的所述RTP扩展头部判断丢失的RTP数据包是否属于关键帧。如果否，接收端继续接收发送端发来的RTP数据包。如果是，接收端向发送端发送RTP数据包，其中携带头部标识为第二取值的所述RTP扩展头部；后续进入步骤S40。步骤S40：发送端根据头部标识为第二取值的RTP扩展头部向接收端重新发送相应的RTP数据包。

进一步地，所述步骤S10中，所述新的RTP扩展头部属于单字节头部。这是一种优选的实现方式，对带宽占用较小。

进一步地，所述步骤S10中，头部标识为第一取值时，所述RTP扩展头部中的数据有X位，记为data[1...X]；data[k] = 0表示序列号为RTP_seq-k的RTP历史数据包属于非关键帧；data[k] = 1表示序列号为RTP_seq-k的RTP历史数据包属于关键帧；其中1≤k≤X。这是头部标识为第一取值的RTP扩展头部的一种具体实现方式。

优选的，X为16。这是一种优选的取值。

进一步地，所述步骤S10中，头部标识为第二取值时，所述RTP扩展头部中的数据有Y位，Y>X；其中前X个字节的数据为定位序列号，表示发送端所发送的某一个RTP历史数据包的序列号；后面的数据记为data[1...Y-X]；data[z] = 0表示不做处理；data[z] = 1表示接收端要求发送端重发序列号为“定位序列号+z”的RTP数据包；其中1≤z≤Y-X。这是头部标识为第二取值的RTP扩展头部的一种具体实现方式。

优选地，Y为24。这是一种优选的取值。

优选地，所述步骤S20中，2≤n≤5。这是一种优选的取值。

进一步地，所述步骤S40中，发送端仅重发data[z] = 1指示的序列号为“定位序列号+z”的RTP数据包。或者，所述步骤S40中，发送端除了重发data[z] = 1指示的序列号为“定位序列号+z”的RTP数据包外，还重发序列号为定位序列号的RTP数据包。这是两种可选的实现方式。

进一步地，所述关键帧是指不依赖其他视频帧、可独立解码的视频帧，包括I帧。所述非关键帧是指需要依赖关键帧才能解码、不能独立解码的视频帧，包括P帧、B帧。这是对关键帧、非关键帧的解释说明。

本申请还提供了一种利用RTP扩展头部解决视频帧丢包的装置，包括RTP扩展头部提供单元、关键帧指示单元、重传指示单元和重传处理单元。所述RTP扩展头部提供单元用来提供一种新的RTP扩展头部，其头部标识具有两种取值；头部标识为第一取值的所述RTP扩展头部中记载了发送端所发送的一个或多个RTP历史数据包是否属于关键帧；头部标识为第二取值的所述RTP扩展头部中记载了接收端要求发送端重新发送的RTP数据包的信息。所述关键帧指示单元用来在发送端向接收端发送RTP数据包、且所述RTP数据包属于视频帧时，仅在关键帧后面的n个对应于非关键帧的RTP数据包中携带头部标识为第一取值的所述RTP扩展头部。所述重传指示单元用来在接收端发现RTP数据包有丢失时，根据头部标识为第一取值的所述RTP扩展头部判断丢失的RTP数据包是否属于关键帧；仅在丢失的RTP数据包属于关键帧时，由接收端向发送端发送携带头部标识为第二取值的所述RTP扩展头部的RTP数据包。所述重传处理单元用来使发送端根据头部标识为第二取值的RTP扩展头部向接收端重新发送相应的RTP数据包。

本申请取得的技术效果是在消耗带宽极小的前提下，通过RTP扩展头部标识视频帧类型信息，在丢包发生时通过仅重传关键帧（I帧），有效地减少了视频恢复需要的带宽和时延，提升了视频质量。

附图说明

图1是本申请提供的利用RTP扩展头部解决视频帧丢包的方法的流程图。

图2是ID=1时的RTP扩展头部的一个实施例的示意图。

图3是ID=2时的RTP扩展头部的一个实施例的示意图。

图4是发送端发送的多个RTP数据包的一个示例的示意图。

图5是本申请提供的利用RTP扩展头部解决视频帧丢包的装置的结构示意图。

图中附图标记说明：10为RTP扩展头部提供单元；20为关键帧指示单元；30为重传指示单元；40为重传处理单元。

具体实施方式

本申请是基于下面的环境提出的，即发送端发送的RTP数据包的类型是不一样的。有的RTP数据包属于关键帧，丢失之后对视频质量影响较大，比如I帧。有的RTP数据包属于非关键帧，丢失之后对视频质量影响较小，比如P帧。

本申请是让接收端知道被网络丢弃的RTP数据包中，哪些是属于关键帧，哪些是属于非关键帧。这样接收端只通知发送端重新发送属于关键帧的RTP数据包，从而在消耗带宽比较小的前提下，有效地改善视频传输和播放质量。

请参阅图1，本申请提供的利用RTP扩展头部解决视频帧丢包的方法包括如下步骤。

步骤S10：提供一种新的RTP扩展头部，其头部标识具有两种取值。头部标识为第一取值时，所述RTP扩展头部中记载了发送端所发送的一个或多个RTP历史数据包是否属于关键帧的信息。所述关键帧是指不依赖其他视频帧、可独立解码的视频帧。头部标识为第二取值时，所述RTP扩展头部中记载了接收端要求发送端重新发送的RTP数据包的信息。

步骤S20：发送端向接收端发送RTP数据包，所述RTP数据包属于视频帧；发送端仅在关键帧后面的n个对应于非关键帧的RTP数据包中携带头部标识为第一取值的所述RTP扩展头部。所述非关键帧是指需要依赖关键帧才能解码、不能独立解码的视频帧。

步骤S30：接收端发现RTP数据包有丢失时，根据头部标识为第一取值的所述RTP扩展头部判断丢失的RTP数据包是否属于关键帧。

如果否，接收端对丢失的RTP数据包不做处理，继续接收发送端发来的RTP数据包。

如果是，接收端向发送端发送RTP数据包，其中携带头部标识为第二取值的所述RTP扩展头部。后续进入步骤S40。

步骤S40：发送端根据头部标识为第二取值的RTP扩展头部向接收端重新发送相应的RTP数据包。

所述步骤S10中，新的RTP扩展头部是在RFC 8285规范定义的RTP扩展头部的框架下提出的一种新的扩展类型，属于该规范第4.2节记载的单字节头部（One-Byte Header）。该新的RTP扩展头部的头部标识ID有两种取值，描述如下。为了描述方便，假设发送端为用户设备（UE）A，接收端为用户设备B，关键帧为I帧，非关键帧为P帧。

所述RTP扩展头部在ID=1时，记载了用户设备A所发送一个或多个RTP历史数据包是否属于I帧。请参阅图2，这是ID=1时的RTP头部的一个实施例。RTP头部的长度为20字节，其中前12个字节为RTP基本头部，后8个字节为新的RTP扩展头部。其中，RTP基本头部中，序列号sequence number的值记为RTP_seq，RFC 3350规范要求每发送一个RTP数据包，序列号加1。RTP扩展头部中，头部标识ID=1，数据data有16位，记为data[1...16]。data[k] = 0表示序列号为RTP_seq-k的RTP历史数据包属于非I帧；data[k] = 1表示序列号为RTP_seq-k的RTP历史数据包属于I帧；其中1≤k≤16。通过这种方法，用户设备A可以将所发送的RTP历史数据包所对应的视频帧是否属于关键帧的信息发送给用户设备B。

所述RTP扩展头部在ID=2时，记载了用户设备B通知用户设备A重新发送的RTP数据包的信息。请参阅图3，这是ID=2时的RTP扩展的一个实施例。RTP头部的长度为20字节，其中前12个字节为RTP基本头部，后8个字节为新的RTP扩展头部。其中，RTP基本头部中，序列号sequence number的值记为RTP_seq，RFC 3350规范要求每发送一个RTP数据包，序列号加1。RTP扩展头部中，头部标识ID=2，数据data有24位即3个字节。其中前2个字节合成为用于定位用户设备A所发送的某一个RTP历史数据包的序列号，称为定位序列号；后一个字节为位标识，记为data[1...8]。data[z] = 0表示不做处理；data[z] = 1表示用户设备B要求用户设备A重发序列号为“定位序列号+z”的RTP数据包；其中1≤z≤8。

所述步骤S20中，发送ID=1的RTP扩展头部需要占用额外的带宽，每个ID=1的RTP扩展头部例如占用8字节。如果每个RTP数据包都携带本申请提出的ID=1的新的RTP扩展头部，会显著地增加带宽的使用，并且各个RTP扩展头部之间冗余比较多。为此，本申请提出了一种有效地发送ID=1的RTP扩展头部的方法，在消耗带宽非常小的前提下，帮助用户设备A将I帧的信息发给用户设备B。所述方法是：用户设备A只在I帧后面的n个对应于P帧的RTP数据包中携带ID=1的RTP扩展头部，优选地，2≤n≤5。

请参阅图4，这是发送端发送的多个RTP数据包的一个示例。例如有发送端发送了15个RTP数据包，序列号分别为1至15。这些RTP数据包属于RFC 6184规范定义的FU-A分片。如果是其他方式的分片，或者没有分片，所述步骤S20同样适用。其中，序列号1~3的RTP数据包是第一个视频帧的分片，第一个视频帧是P帧。序列号4~10的RTP数据包是第二个视频帧的分片，第二个视频帧是I帧。序列号11~12的RTP数据包是第三个视频帧的分片，第三个视频帧是P帧。序列号13~15的RTP数据包是第四个视频帧的分片，第四个视频帧是P帧。假设上面定义的n=3，图4中I帧后面的分片是从序列号11的RTP数据包开始，那么序列号11~13的分片需要带上ID=1的RTP扩展头部，其他的分片都不需要带ID=1的RTP扩展头部。

通过这种方法，用户设备A可以将I帧的信息完全告诉用户设备B。如果I帧编码速率是每秒一个的话，这种发送ID=1的RTP扩展头部的方法占用额外的带宽每秒只有24字节，就可以保证I帧的完整。

所述步骤S30中，当用户设备B发现有RTP数据包丢包时，首先根据收到的用户设备A发来的ID=1的RTP扩展头部信息，判断网络丢失的RTP数据包是不是属于I帧。如果是属于I帧，则用户设备B发送ID=2的RTP扩展头部通知用户设备A重发相关的I帧。

所述步骤S40中，用户设备A根据ID=2的RTP扩展头部里面指示的序列号发送相应的RTP数据包。

优选地，用户设备A除了重发data[z] = 1指示的序列号为“定位序列号+z”的RTP数据包外，还重发序列号为定位序列号的RTP数据包。

下面举例来说明ID=2的所述RTP头部中的序列号和定位序列号。请参阅图3，在RTP基本头部的第三、第四个字节是sequence number字段，用来记录用户设备B向用户设备A发送的RTP数据包的序列号。在RTP扩展头部的第六、第七个字节是data字段的前两个字节，用来记录定位序列号，也就是用户设备A向用户设备B发送的某一个RTP历史数据包的序列号。

例如，某个时间点用户设备A向用户设备B发送了1个RTP数据包，序列号是4040。如果没有丢包，用户设备B会给用户设备A发送RTP数据包，序列号是7439。用户设备A、用户设备B所发送的RTP数据包中的序列号彼此之间没有任何关系。

又如，某个时间点用户设备A向用户设备B发送了1个RTP数据包，序列号是4040。此时用户设备B发现序列号为4031至4033的3个RTP数据包都丢失了，并且这3个RTP数据包都是属于I帧的。此时有两种处理方式可供选择。第一种处理方式为：用户设备B向用户设备A发送RTP数据包时携带有ID=2的所述RTP扩展头部，在RTP基本头部的第三、第四个字节是该RTP数据包的序列号7439，在RTP扩展头部的第六、第七个字节是定位序列号4031，并且data[1]和data[2]置为1。用户设备A收到用户设备B发来的序列号为7439的RTP数据包时，解析RTP扩展头部，会重发序列号为4031至4033的RTP数据包。第一种处理方式可以归纳为：发送端除了重发data[z] = 1指示的序列号为“定位序列号+z”的RTP数据包外，还重发序列号为定位序列号的RTP数据包。第二种处理方式为：用户设备B向用户设备A发送RTP数据包时携带有ID=2的所述RTP扩展头部，在RTP基本头部的第三、第四个字节是该RTP数据包的序列号7439，在RTP扩展头部的第六、第七个字节是定位序列号4030，并且data[1]、data[2]和data[3]置为1。此时用户设备A收到用户设备B发来的序列号为7439的RTP数据包时，解析RTP扩展头部，会重发序列号为4031至4033的RTP数据包。第二种处理方式可以归纳为：发送端仅重发data[z] = 1指示的序列号为“定位序列号+z”的RTP数据包外，不重发序列号为定位序列号的RTP数据包。

请参阅图5，本申请提供的利用RTP扩展头部解决视频帧丢包的装置包括RTP扩展头部提供单元10、关键帧指示单元20、重传指示单元30和重传处理单元40。图5所示的装置与图1所示的方法相对应。

所述RTP扩展头部提供单元10用来提供一种新的RTP扩展头部，其头部标识具有两种取值。头部标识为第一取值的所述RTP扩展头部中记载了发送端所发送的一个或多个RTP历史数据包是否属于关键帧。头部标识为第二取值的所述RTP扩展头部中记载了接收端要求发送端重新发送的RTP数据包的信息。

所述关键帧指示单元20用来在发送端向接收端发送RTP数据包、且所述RTP数据包属于视频帧时，仅在关键帧后面的n个对应于非关键帧的RTP数据包中携带头部标识为第一取值的所述RTP扩展头部。

所述重传指示单元30用来在接收端发现RTP数据包有丢失时，根据头部标识为第一取值的所述RTP扩展头部判断丢失的RTP数据包是否属于关键帧；仅在丢失的RTP数据包属于关键帧时，由接收端向发送端发送携带头部标识为第二取值的所述RTP扩展头部的RTP数据包。

所述重传处理单元40用来使发送端根据头部标识为第二取值的RTP扩展头部向接收端重新发送相应的RTP数据包。

上述利用RTP扩展头部解决视频帧丢包的方法及装置只重传关键帧，所以耗费带宽不是很大，但能有效地带来视频传输及播放质量的提升。

以上仅为本申请的优选实施例，并不用于限定本申请。对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims

1.一种利用RTP扩展头部解决视频帧丢包的方法，其特征是，包括如下步骤：

步骤S10：提供一种新的RTP扩展头部，其头部标识具有两种取值；头部标识为第一取值时，所述RTP扩展头部中记载了发送端所发送的一个或多个RTP历史数据包是否属于关键帧；头部标识为第二取值时，所述RTP扩展头部中记载了接收端要求发送端重新发送的RTP数据包的信息；

步骤S20：发送端向接收端发送RTP数据包，所述RTP数据包属于视频帧；发送端仅在关键帧后面的n个对应于非关键帧的RTP数据包中携带头部标识为第一取值的所述RTP扩展头部；

步骤S30：接收端发现RTP数据包有丢失时，根据头部标识为第一取值的所述RTP扩展头部判断丢失的RTP数据包是否属于关键帧；

如果否，接收端继续接收发送端发来的RTP数据包；

如果是，接收端向发送端发送RTP数据包，其中携带头部标识为第二取值的所述RTP扩展头部；后续进入步骤S40；

2.根据权利要求1所述的利用RTP扩展头部解决视频帧丢包的方法，其特征是，所述步骤S10中，所述新的RTP扩展头部属于单字节头部。

3. 根据权利要求1所述的利用RTP扩展头部解决视频帧丢包的方法，其特征是，所述步骤S10中，头部标识为第一取值时，所述RTP扩展头部中的数据有X位，记为data[1...X]；data[k] = 0表示序列号为RTP_seq-k的RTP历史数据包属于非关键帧；data[k] = 1表示序列号为RTP_seq-k的RTP历史数据包属于关键帧；其中1≤k≤X。

4.根据权利要求3所述的利用RTP扩展头部解决视频帧丢包的方法，其特征是，X为16。

5. 根据权利要求3所述的利用RTP扩展头部解决视频帧丢包的方法，其特征是，所述步骤S10中，头部标识为第二取值时，所述RTP扩展头部中的数据有Y位，Y>X；其中前X个字节的数据为定位序列号，表示发送端所发送的某一个RTP历史数据包的序列号；后面的数据记为data[1...Y-X]；data[z] = 0表示不做处理；data[z] = 1表示接收端要求发送端重发序列号为“定位序列号+z”的RTP数据包；其中1≤z≤Y-X。

6.根据权利要求5所述的利用RTP扩展头部解决视频帧丢包的方法，其特征是，Y为24。

7.根据权利要求1所述的利用RTP扩展头部解决视频帧丢包的方法，其特征是，所述步骤S20中，2≤n≤5。

8. 根据权利要求5所述的利用RTP扩展头部解决视频帧丢包的方法，其特征是，所述步骤S40中，发送端仅重发data[z] = 1指示的序列号为“定位序列号+z”的RTP数据包；或者，所述步骤S40中，发送端除了重发data[z] = 1指示的序列号为“定位序列号+z”的RTP数据包外，还重发序列号为定位序列号的RTP数据包。

9.根据权利要求1所述的利用RTP扩展头部解决视频帧丢包的方法，其特征是，所述关键帧是指不依赖其他视频帧、可独立解码的视频帧，包括I帧；

所述非关键帧是指需要依赖关键帧才能解码、不能独立解码的视频帧，包括P帧、B帧。

10.一种利用RTP扩展头部解决视频帧丢包的装置，其特征是，包括RTP扩展头部提供单元、关键帧指示单元、重传指示单元和重传处理单元；

所述RTP扩展头部提供单元用来提供一种新的RTP扩展头部，其头部标识具有两种取值；头部标识为第一取值的所述RTP扩展头部中记载了发送端所发送的一个或多个RTP历史数据包是否属于关键帧；头部标识为第二取值的所述RTP扩展头部中记载了接收端要求发送端重新发送的RTP数据包的信息；

所述关键帧指示单元用来在发送端向接收端发送RTP数据包、且所述RTP数据包属于视频帧时，仅在关键帧后面的n个对应于非关键帧的RTP数据包中携带头部标识为第一取值的所述RTP扩展头部；

所述重传指示单元用来在接收端发现RTP数据包有丢失时，根据头部标识为第一取值的所述RTP扩展头部判断丢失的RTP数据包是否属于关键帧；仅在丢失的RTP数据包属于关键帧时，由接收端向发送端发送携带头部标识为第二取值的所述RTP扩展头部的RTP数据包；

所述重传处理单元用来使发送端根据头部标识为第二取值的RTP扩展头部向接收端重新发送相应的RTP数据包。