本发明涉及数据处理技术领域，尤其涉及一种视频流数据处理系统。
背景技术：
现有的视频流数据通常基于h264、h265编码协议编码，适用于视频通话和直播的视频流数据传输场景，视频通话流媒体数据传输链路的延迟范围通常为100ms-1s，直播的流媒体数据传输链路的延迟范围通常为1s-10s。而h264、h265并不能完全适应超低延迟的流媒体数据的传输，例如云游戏场景下的延迟要求通常在1ms-100ms。但是，由于显卡的硬解编码支持问题，现有的超低延迟的流媒体数据仍然需要选用h264,h265编码协议编码作为主要编码协议。由于h264、h265编码协议缺乏时间分片能力，使得在云游戏等超低延迟要求的视频流数据传输过程中，无法快速识别和处理丢包、乱序等问题，造成很大的延迟和性能消耗。由此可知，如何降低在超低延迟应用场景下的视频流数据传输延迟和性能消耗成为亟待解决的技术问题。
技术实现要素：
本发明目的在于，提供一种视频流数据处理系统，降低了在超低延迟应用场景下的视频流数据传输延迟和性能消耗。
根据本发明第一方面，提供了一种视频流数据处理系统，包括发送端、处理器和存储有计算机程序的存储器，所述系统预先设置有视频数据包结构，所述视频数据包结构包括附加协议头，rtp协议头、附加数据、rtp数据，其中，所述附加协议头包括帧序号数据段、rtp首包序号数据段，rtp包数量数据段和i帧标识数据段；所述附加数据为所述附加协议头对应的数据，所述rtp协议头和所述rtp数据基于rtp协议生成，当所述处理器执行所述计算机程序时，实现以下步骤：
步骤s1、所述发送端获取待发送视频帧，基于rtp协议生成所述待发送视频帧对应的rtp协议头和rtp数据，判断所述待发送视频帧是否为i帧，若是，执行步骤s2，否则，执行步骤s3；
步骤s2、将i帧标识数据段设置为“1”，直接生成附加协议头和对应的附加数据，执行步骤s4；
步骤s3、将i帧标识数据段设置为“0”，并按照预设的递增排序为所述待发送视频帧设置帧序号，存储至所述帧序号数据段，基于rtp协议头和rtp数据确定所述待发送视频帧的rtp视频包数量和对应的首个rtp视频包的rtp包序号，对应存储至rtp首包序号数据段，rtp包数量数据段，生成附加协议头和对应的附加数据，执行步骤s4；
步骤s4、基于所述待发送视频帧对应的附加协议头、附加数据、rtp协议头和rtp数据，按照所述视频数据包结构进行封装，生成视频数据包。
本发明与现有技术相比具有明显的优点和有益效果。借由上述技术方案，本发明提供的一种视频流数据处理系统可达到相当的技术进步性及实用性，并具有产业上的广泛利用价值，其至少具有下列优点：
本发明降低了在超低延迟应用场景下的视频流数据传输延迟和性能消耗，提高了视频质量。
上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其他目的、特征和优点能够更明显易懂，以下特举较佳实施例，并配合附图,详细说明如下。
附图说明
图1为本发明实施例提供的视频流数据处理系统示意图。
具体实施方式
为更进一步阐述本发明为达成预定发明目的所采取的技术手段及功效,以下结合附图及较佳实施例，对依据本发明提出的一种视频流数据处理系统的具体实施方式及其功效，详细说明如后。
在更加详细地讨论示例性实施例之前应当提到的是，一些示例性实施例被描述成作为流程图描绘的处理或方法。虽然流程图将各步骤描述成顺序的处理，但是其中的许多步骤可以被并行地、并发地或者同时实施。此外，各步骤的顺序可以被重新安排。当其操作完成时处理可以被终止，但是还可以具有未包括在附图中的附加步骤。处理可以对应于方法、函数、规程、子例程、子程序等等。
本发明实施例提供了一种视频流数据处理系统，如图1所示，包括发送端、处理器和存储有计算机程序的存储器，所述系统预先设置有视频数据包结构，所述视频数据包结构包括附加协议头，rtp（real-timetransportprotocol，实时传输协议）协议头、附加数据、rtp数据，其中，所述附加协议头包括帧序号数据段、rtp首包序号数据段，rtp包数量数据段和i帧（i帧通常是每个gop(mpeg所使用的一种视频压缩技术)的第一个帧，经过适度地压缩，做为随机访问的参考点，可以当成图像）标识数据段；所述附加数据为所述附加协议头对应的数据。所述rtp协议头和所述rtp数据基于rtp协议生成，附加协议头和附加数据基于预设的时间分片协议来生成，在rtp的基础上进行了二次封装，得到所述视频数据包结构形式的视频数据。需要说明的是，基于rtp协议生成rtp协议头和所述rtp数据的过程为现有技术，在此不在展开描述。附加协议头中，rtp首包序号指的是视频帧对应的多个rtp视频包中，首个rtp视频包对应的rtp包序号，基于rtp协议为视频帧生成每一的rtp视频包，均分配有对应的rtp包序号，rtp首包序号数据段的位数基于rtp包序号的大小决定，本发明实施例中，rtp首包序号数据段设置为16bit。帧序号数据段、rtp包数量数据段的位数可根据实际应用需求来具体设定。当所述处理器执行所述计算机程序时，实现以下步骤：
步骤s1、所述发送端获取待发送视频帧，基于rtp协议生成所述待发送视频帧对应的rtp协议头和rtp数据，判断所述待发送视频帧是否为i帧，若是，执行步骤s2，否则，执行步骤s3；
步骤s2、将i帧标识数据段设置为“1”，直接生成附加协议头和对应的附加数据，执行步骤s4；
步骤s3、将i帧标识数据段设置为“0”，并按照预设的递增排序为所述待发送视频帧设置帧序号，存储至所述帧序号数据段，基于rtp协议头和rtp数据确定所述待发送视频帧的rtp视频包数量和对应的首个rtp视频包的rtp包序号，对应存储至rtp首包序号数据段，rtp包数量数据段，生成附加协议头和对应的附加数据，执行步骤s4；
步骤s4、基于所述待发送视频帧对应的附加协议头、附加数据、rtp协议头和rtp数据，按照所述视频数据包结构进行封装，生成视频数据包。
本发明实施例基于视频数据包结构封装视频数据进行传输，能够有效降低了前向纠错解包、解码判断、视频帧组装的算力消耗，使得在超低延时无缓冲的要求下，rtp可支持码率有了大幅提升，可稳定传输16m码率的视频率，不会因为重发的产生明显视频卡顿，降低了在超低延迟应用场景下的视频流数据传输延迟和性能消耗，提高了视频质量。超低延时的指的是待发送视频帧的目标延迟范围在1ms-100ms之内。
作为一种实施例，所述系统还预先设置有冗余数据包结构，所述冗余数据包结构包括rtp协议头和rtp数据，当所述处理器执行所述计算机程序时，还实现以下步骤：
步骤s5、基于预设的视频冗余系数和冗余数据包结构生成所述待发送视频帧对应的冗余数据包，将所述冗余数据包和视频数据包发送给接收端。
作为一种实施例，当所述处理器执行所述计算机程序时，还实现以下步骤：
步骤s6、基于数据包结构判断接收端所接收的数据包是否为视频数据包，若是，则执行步骤s7，否则，结束流程；
需要说明的是，现有技术中不做时间分片，无法区分冗余数据包和视频数据包，这样使得冗余数据包丢失的情况下也会触发重发操作，浪费资源，降低数据输传输效率，而本发明实施例基于视频数据包结构和冗余数据包结构两种不同数据结构对视频数据包和冗余数据包进行了区分，仅针对视频数据包进行丢包判断和重发，不浪费算力和网络能力用来处理和重发丢包中的冗余数据包。
步骤s7、判断所述视频数据包的附加协议头中的i帧标识数据段是否为“1”，若是，则直接将所述视频数包进行解码，并结束流程，否则，基于所述视频数据包的视频数据包结构判断当前视频帧是否与上一视频帧连续，以及是否发生丢包，若当前视频帧与上一视频帧连续且未发生丢包，则进行视频数包进行解码，并通过hash算法进行帧内包组装。
需要说明的是，i帧标识有效的降低了i帧的判断过程复杂度，只需对附加协议头单个bit的判断即可确定是否为i帧，无需解析视频数据包内数据。通过hash控制帧内包组装，能够将查找视频数据包位置和组帧的时间复杂度降低至o(1)，且解包时是同hash查找基础数据位置，减少解包时间，多方向验证包长度等信息，降低了解包错误引起的连锁错误。
作为一种实施例，所述步骤s7中，基于所述视频数据包的视频数据包结构判断当前视频帧是否与上一视频帧连续，包括：
步骤s71、获取上一视频帧序号，基于所述视频数据包的附加协议头中的帧序号数据段获取当前视频帧序号，判断当前视频帧序号和所述上一视频帧序号是否符合预设的递增排序，若符合，则确定当前视频帧与上一视频帧连续。
需要说明的是，通过附加协议头的帧序号的连续性即可判断原始视频数据的视频帧是否连贯，当视频帧连贯时即可解码，无需基于逐个rtp报序号来判断，可有效减少其数据在流媒体发送中对于主数据流的影响，传送更多冗余信息。
作为一种实施例，所述步骤s71中，若当前视频帧序号和所述上一视频帧序号不符合预设的递增排序，则执行以下步骤：
步骤s711、基于当前视频帧序号向所述发送端发送视频帧重发请求。
作为一种实施例，所述步骤s7中，基于所述视频数据包的视频数据包结构判断当前视频帧否发生丢包，包括：
步骤s72、基于所述视频数据包的附加协议头中的rtp首包序号数据段、rtp包数量数据段，获取当前视频帧对应的rtp首包序号和rtp包数量；
步骤s73、基于所述当前视频帧对应的rtp首包序号和rtp包数量确定当前视频帧对应的目标接收rtp包序号列表；
步骤s74、基于视频数据包对应的rtp协议头，获取所述接收端已经接收的帧序号为当前视频帧序号的视频数据包所对应的当前接收rtp包序号列表；
步骤s75、对比所述目标接收rtp包序号列表和当前接收rtp包序号列表，若相同，则确定当前视频帧未发生丢包。
需要说明的是，视频帧发生丢包指的是视频帧对应多个视频数据包，其中部分视频数据包未发送至接收端。
作为一种实施例，所述步骤s75中，若所述目标接收rtp包序号列表和当前接收rtp包序号列表不同，则确定当前视频帧发生丢包，并执行以下步骤：
步骤s751、基于所述目标接收rtp包序号列表和当前接收rtp包序号列表确定未接收当前视频帧的丢失rtp包序号；
步骤s752、基于当前视频帧丢失rtp包序号向所述发送端发送丢失视频包重发请求。
需要说明的是，本发明实施例在收到视频帧中的任意一个视频数据包即可基于附加协议头获取到整帧数据的预估大小，直接开始为整帧数据分配内存空间，而不需要为每个rtp包准备内存，减少内存分配次数。此外，本发明实施例能够准确快速判断是否有后序丢包存在，而不用等到接收所有rtp视频包以后再进行判断，本发明实施例增加了重选处理效率，无需收到下一个rtp包才能够知道当前视频帧存在后序丢包的个数和包号。
在一些应用实施例中，可能遇到视频帧较大，对应的rtp视频包数量较多的情况下，可能出现rtp视频包数量数据段存储位数不够的情况，因此，所述附加协议头还包括预留数据段，用于在rtp包数量数据段存储位不足时，扩充rtp包数量数据段的存储位。还可能需要在视频数据包中附加其他数据信息，则所述附加协议头还可包括扩展标识数据段和扩展长度数据段，所述预留数据段所述扩展标识数据段用于标识扩展数据，所述扩展长度数据段用于标识扩展数据位置。例如，所述扩展数据可包括时间戳，或者其他一些预设的私有数据。
以上所述，仅是本发明的较佳实施例而已，并非对本发明作任何形式上的限制，虽然本发明已以较佳实施例揭露如上，然而并非用以限定本发明,任何熟悉本专业的技术人员，在不脱离本发明技术方案范围内,当可利用上述揭示的技术内容作出些许更动或修饰为等同变化的等效实施例,但凡是未脱离本发明技术方案的内容，依据本发明的技术实质对以上实施例所作的任何简单修改、等同变化与修饰，均仍属于本发明技术方案的范围内。
1.一种视频流数据处理系统，其特征在于，
包括发送端、处理器和存储有计算机程序的存储器，所述系统预先设置有视频数据包结构，所述视频数据包结构包括附加协议头，rtp协议头、附加数据、rtp数据，其中，所述附加协议头包括帧序号数据段、rtp首包序号数据段，rtp包数量数据段和i帧标识数据段；所述附加数据为所述附加协议头对应的数据，所述rtp协议头和所述rtp数据基于rtp协议生成，当所述处理器执行所述计算机程序时，实现以下步骤：
步骤s1、所述发送端获取待发送视频帧，基于rtp协议生成所述待发送视频帧对应的rtp协议头和rtp数据，判断所述待发送视频帧是否为i帧，若是，执行步骤s2，否则，执行步骤s3；
步骤s2、将i帧标识数据段设置为“1”，直接生成附加协议头和对应的附加数据，执行步骤s4；
步骤s3、将i帧标识数据段设置为“0”，并按照预设的递增排序为所述待发送视频帧设置帧序号，存储至所述帧序号数据段，基于rtp协议头和rtp数据确定所述待发送视频帧的rtp视频包数量和对应的首个rtp视频包的rtp包序号，对应存储至rtp首包序号数据段，rtp包数量数据段，生成附加协议头和对应的附加数据，执行步骤s4；
步骤s4、基于所述待发送视频帧对应的附加协议头、附加数据、rtp协议头和rtp数据，按照所述视频数据包结构进行封装，生成视频数据包。
2.根据权利要求1所述的系统，其特征在于，
所述系统还预先设置有冗余数据包结构，所述冗余数据包结构包括rtp协议头和rtp数据，当所述处理器执行所述计算机程序时，还实现以下步骤：
步骤s5、基于预设的视频冗余系数和冗余数据包结构生成所述待发送视频帧对应的冗余数据包，将所述冗余数据包和视频数据包发送给接收端。
3.根据权利要求2所述的系统，其特征在于，
当所述处理器执行所述计算机程序时，还实现以下步骤：
步骤s6、基于数据包结构判断接收端所接收的数据包是否为视频数据包，若是，则执行步骤s7，否则，结束流程；
步骤s7、判断所述视频数据包的附加协议头中的i帧标识数据段是否为“1”，若是，则直接将所述视频数包进行解码，并结束流程，否则，基于所述视频数据包的视频数据包结构判断当前视频帧是否与上一视频帧连续，以及是否发生丢包，若当前视频帧与上一视频帧连续且未发生丢包，则进行视频数包进行解码，并通过hash算法进行帧内包组装。
4.根据权利要求3所述的系统，其特征在于，
所述步骤s7中，基于所述视频数据包的视频数据包结构判断当前视频帧是否与上一视频帧连续，包括：
步骤s71、获取上一视频帧序号，基于所述视频数据包的附加协议头中的帧序号数据段获取当前视频帧序号，判断当前视频帧序号和所述上一视频帧序号是否符合预设的递增排序，若符合，则确定当前视频帧与上一视频帧连续。
5.根据权利要求4所述的系统，其特征在于，
所述步骤s71中，若当前视频帧序号和所述上一视频帧序号不符合预设的递增排序，则执行以下步骤：
步骤s711、基于当前视频帧序号向所述发送端发送视频帧重发请求。
6.根据权利要求3所述的系统，其特征在于，
所述步骤s7中，基于所述视频数据包的视频数据包结构判断当前视频帧否发生丢包，包括：
步骤s72、基于所述视频数据包的附加协议头中的rtp首包序号数据段、rtp包数量数据段，获取当前视频帧对应的rtp首包序号和rtp包数量；
步骤s73、基于所述当前视频帧对应的rtp首包序号和rtp包数量确定当前视频帧对应的目标接收rtp包序号列表；
步骤s74、基于视频数据包对应的rtp协议头，获取所述接收端已经接收的帧序号为当前视频帧序号的视频数据包所对应的当前接收rtp包序号列表；
步骤s75、对比所述目标接收rtp包序号列表和当前接收rtp包序号列表，若相同，则确定当前视频帧未发生丢包。
7.根据权利要求6所述的系统，其特征在于，
所述步骤s75中，若所述目标接收rtp包序号列表和当前接收rtp包序号列表不同，则确定当前视频帧发生丢包，并执行以下步骤：
步骤s751、基于所述目标接收rtp包序号列表和当前接收rtp包序号列表确定未接收当前视频帧的丢失rtp包序号；
步骤s752、基于当前视频帧丢失rtp包序号向所述发送端发送丢失视频包重发请求。
8.根据权利要求1所述的系统，其特征在于，
所述附加协议头还包括预留数据段、扩展标识数据段和扩展长度数据段，所述预留数据段用于在rtp包数量数据段存储位不足时，扩充rtp包数量数据段的存储位；所述扩展标识数据段用于标识扩展数据，所述扩展长度数据段用于标识扩展数据位置。
9.根据权利要求8所述的系统，其特征在于，
所述扩展数据包括时间戳。
10.根据权利要求1-9中任意一项所述的系统，其特征在于，
所述待发送视频帧的目标延迟范围为1ms-100ms。
技术总结