视频编码方法、设备、装置及计算机可读存储介质与流程

1.本发明涉及视频处理技术领域，尤其涉及一种视频编码方法、设备、装置及计算机可读存储介质。


背景技术：

2.在现有直播导播方案的编码环节中，为了在节目导播切换新节目时，能通过idr/i帧及时解码新的视频数据源，往往将idr/i帧(gop)间隔设置得很小，比如设置为1s～2s。但是，idr/i帧是一帧完整的图像，因此，相比gop中的p帧/b帧来说，idr/i帧的数据量非常大，很容易造成网络拥塞或者产生丢包，以及接收端处理大量数据出现耗时或者延迟，导致视频接收端容易出现画面卡顿、花屏。
3.上述内容仅用于辅助理解本发明的技术方案，并不代表承认上述内容是现有技术。


技术实现要素：

4.本发明的主要目的在于提供一种视频编码方法、设备、装置及计算机可读存储介质，旨在解决现有技术中由于idr/i帧(gop)间隔设置得很小，从而导致在低网速的情况下视频接收端容易出现画面卡顿、花屏的技术问题。
5.为实现上述目的，本发明提供一种视频编码方法，所述视频编码方法包括以下步骤：
6.获取待编码帧与前一i帧之间的帧间隔，并判断所述帧间隔是否等于预设i帧间隔；
7.监听是否接收到终端设备根据直播视频流反馈的i帧请求；
8.根据判断结果和监听结果判断是否将所述待编码帧编码为i帧。
9.可选地，所述获取待编码帧与前一i帧之间的帧间隔，并判断所述帧间隔是否等于预设i帧间隔的步骤，包括：
10.获取前一i帧，并检测所述前一i帧是否为插入i帧，所述插入i帧为基于预设i帧间隔插入的i帧；
11.若是，则获取待编码帧与前一i帧之间的帧间隔，并判断所述帧间隔是否等于预设i帧间隔。
12.可选地，所述获取前一i帧，并检测所述前一i帧是否为插入i帧的步骤之后，还包括：
13.若否，则获取前一插入i帧；
14.获取待编码帧与前一插入i帧的帧间隔，并判断所述帧间隔是否等于预设i帧间隔。
15.可选地，所述获取待编码帧与前一i帧之间的帧间隔，并判断所述帧间隔是否等于预设i帧间隔的步骤之前，还包括：
16.获取初始i帧间隔，并判断所述初始i帧间隔是否处于预设区间；
17.根据判断结果对初始阈值进行调整，获得预设i帧间隔。
18.可选地，所述监听是否接收到终端设备根据直播视频流反馈的i帧请求的步骤，包括：
19.在直播视频流的视频数据源为单路时，接收终端设备根据直播视频流反馈的播放失败信息；
20.根据所述播放失败信息监听是否接收到终端设备根据直播视频流反馈的i帧请求。
21.可选地，所述监听是否接收到终端设备根据直播视频流反馈的i帧请求的步骤，包括：
22.在直播视频流的视频数据源为多路时，接收终端设备根据直播视频流反馈的源切换信息；
23.根据所述源切换信息监听是否接收到终端设备根据直播视频流反馈的i帧请求。
24.可选地，所述根据判断结果和监听结果判断是否将所述待编码帧编码为i帧的步骤，包括：
25.在帧间隔等于预设i帧间隔，或接收到终端设备根据直播视频流反馈的i帧请求时，判定将所述待编码帧编码为i帧；
26.在帧间隔不等于预设i帧间隔，且未接收到终端设备根据直播视频流反馈的i帧请求时，判定不将所述待编码帧编码为i帧。
27.此外，为实现上述目的，本发明还提出一种视频编码设备，所述视频编码设备包括：中央处理器和图形处理器；所述视频编码设备包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的视频编码程序，所述视频编码程序配置为实现如上文所述的视频编码方法。
28.此外，为实现上述目的，本发明还提出一种计算机可读存储介质，所述计算机可读存储介质上存储有视频编码程序，所述视频编码程序被处理器执行时实现如上文所述的视频编码方法。
29.此外，为实现上述目的，本发明还提出一种视频编码装置，所述视频编码装置包括：所述视频编码装置包括：间隔判断模块、请求监听模块以及帧编码模块；
30.所述间隔判断模块，用于获取待编码帧与前一i帧之间的帧间隔，并判断所述帧间隔是否等于预设i帧间隔；
31.所述请求监听模块，用于监听是否接收到终端设备根据直播视频流反馈的i帧请求；
32.所述帧编码模块，用于根据判断结果和监听结果判断是否将所述待编码帧编码为i帧。
33.在本发明中，公开了获取待编码帧与前一i帧之间的帧间隔，并判断帧间隔是否等于预设i帧间隔，监听是否接收到终端设备根据直播视频流反馈的i帧请求，根据判断结果和监听结果判断是否将待编码帧编码为i帧；由于本发明在待编码帧与前一i帧之间的帧间隔等于预设i帧间隔，或接收到终端设备根据直播视频流反馈的i帧请求时，才将待编码帧编码为i帧，从而增大了i帧之间的间隔，并且能够基于用户请求动态插入i帧，进而降低了
视频流的传输数据量，极大降低甚至避免直播画面出现卡顿、花屏的情况，提高了用户体验。
附图说明
34.图1是本发明实施例方案涉及的硬件运行环境的视频编码设备的结构示意图；
35.图2为本发明视频编码方法第一实施例的流程示意图；
36.图3为本发明视频编码方法一实施例的直播采集设备位置示意图；
37.图4为本发明视频编码方法第二实施例的流程示意图；
38.图5为本发明视频编码方法第三实施例的流程示意图；
39.图6为本发明视频编码方法一实施例的图片分块示意图。
40.本发明目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。
具体实施方式
41.应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。
42.参照图1，图1为本发明实施例方案涉及的硬件运行环境的视频编码设备结构示意图。
43.如图1所示，该视频编码设备可以包括：处理器1001，例如中央处理器(central processing unit，cpu)，通信总线1002、用户接口1003，网络接口1004，存储器1005。其中，通信总线1002用于实现这些组件之间的连接通信。用户接口1003可以包括显示屏(display)，可选用户接口1003还可以包括标准的有线接口、无线接口，对于用户接口1003的有线接口在本发明中可为usb接口。网络接口1004可选的可以包括标准的有线接口、无线接口(如无线保真(wireless-fidelity，wi-fi)接口)。存储器1005可以是高速的随机存取存储器(random access memory，ram)，也可以是稳定的存储器(non-volatile memory，nvm)，例如磁盘存储器。存储器1005可选的还可以是独立于前述处理器1001的存储装置。
44.本领域技术人员可以理解，图1中示出的结构并不构成对视频编码设备的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。
45.如图1所示，认定为一种计算机存储介质的存储器1005中可以包括操作系统、网络通信模块、用户接口模块以及视频编码程序。
46.在图1所示的视频编码设备中，网络接口1004主要用于连接后台服务器，与所述后台服务器进行数据通信；用户接口1003主要用于连接用户设备；所述视频编码设备通过处理器1001调用存储器1005中存储的视频编码程序，并执行本发明实施例提供的视频编码方法。
47.基于上述硬件结构，提出本发明视频编码方法的实施例。
48.参照图2，图2为本发明视频编码方法第一实施例的流程示意图，提出本发明视频编码方法第一实施例。
49.步骤s10：获取待编码帧与前一i帧之间的帧间隔，并判断所述帧间隔是否等于预设i帧间隔。
50.需要说明的是，本实施例方法的执行主体可以是具有数据处理、网络通信以及程序运行功能的直播采集设备，例如，摄像头等，或者是其他能够实现相同或相似功能的电子
设备，本实施例对此不加以限制。
51.应当理解的是，本方法可以应用于需要在网络中传输视频数据的场景，例如，网络直播、视频会议以及网课等，本实施例对此不加以限制。
52.可以理解的是，随着科学技术的发展，数字视频技术在通信和广播直播、远程会议领域获得了日益广泛的应用，特别是90年代以来，随着internet和移动通信的迅猛发展，视频信息和多媒体信息在internet网络和移动网络中的处理和传输成为了当前我国信息化中的热点技术。视频信息具有一系列的优点，如直观性、确切性、高效性、广泛性等，但是，视频信息量太大，要是视频得到有效的应用，首先必须解决视频压缩编码问题的，其次是解决压缩后视频质量保证的问题，同时保证网络传输视频数据的可靠和稳定。
53.现有的专业直播导播应用中，一般是先使用自有的数据采集设备(例如相机)采集视频，直出的视频数据通常是yuv420/422/444、yuyv、nv12、nv21以及其他视频格式，通过设备的编码压缩功能将数据压缩数据量很小的新数据，比如h264/hevc/h266等，再根据传输协议，例如rtp，打包封装后传输到媒体服务器上，这里媒体服务器是个统称的服务器，包含集群或者转码增强分发等功能，导播端再经过导播操作完成要求后，用户就可以根据指定的url进行访问浏览观看。
54.借助现代的编码解码和网络通信技术，现在的直播导播也同步获得了很好的发展和体验。现有的直播导播方案编码环节中，为了在节目导播切换新节目时，能通过idr/i帧及时解码新的视频数据源时，往往将idr/i帧(gop)间隔设置的很小，比如1s～2s。但是idr/i是一帧完整的图像，相比p帧b帧来说，数据量非常大，即使现代网络很发达，由于不同地域网络设备条件差异以及网络中不可预知的影响，大数据量的数据传输更容易造成丢包，对用户的存储设备要求更高。无论发送端还是接收端，对处理器能否及时处理大数据量的数据也是有要求的，性能不够的处理器很可能无法及时处理大数据量而造成数据丢失，同时造成图像画面延迟。而且在视频质量越来越高的发展趋势下，适应性越来越差，即使在末端使用fec/丢包重传/nack等各种补救机制，但是大数据量容易造成补救自身数据也容易丢失，补救效果不好，尤其是未来4k/8k等大分辨率数据条件下更不容易补救。另外，画面容易出现肉眼可见的收敛、跳跃等现象，体验感很差。
55.为了克服上述缺陷，本实施例中在待编码帧与前一i帧之间的帧间隔等于预设i帧间隔，或接收到终端设备根据直播视频流反馈的i帧请求时，才将待编码帧编码为i帧，从而增大了i帧之间的间隔，大大降低了数据传输量，降低甚至避免了丢包或者大量数据处理错误引起的直播画面出现卡顿、花屏，同时能够基于用户请求动态插入i帧，解决了视频源不解码或者切换视频源所依赖需要的idr/i帧问题，从而提高了用户体验。
56.需要说明的是，待编码帧可以是视频源中需要编码的视频帧。
57.为了便于理解，以下进行举例说明，但并不对本方案进行限定。视频源采集流程步骤如下：
58.(1)布置好直播采集设备的位置，该位置需要对直播的场景具有良好的视野角度和画面构图感，并将设备固定好；
59.(2)打开设备进行采集；
60.通常windows通过vfw或者directshow实时视频采集，linux系统过v4l2标准接口采集，android通过android api进行采集，ios或者其他系统都有对应平台的采集方法，这
里不再详述。
61.采集完成后的视频数据通常是yuv420/422/444、yuyv、nv12、nv21以及其他视频格式体现的，数据量很大。
62.为了便于理解，参考图3进行说明，但并不对本方案进行限定。图3为直播采集设备位置示意图，图中，在篮球场周围分别布置cam1～8八个直播采集设备，布置位置如图所示。
63.需要说明的是，待编码帧与前一i帧之间的帧间隔可以是待编码帧与前一插入i帧的帧间隔，也可以是待编码帧与前一请求插入i帧的帧间隔。其中，插入i帧可以是基于预设i帧间隔插入的i帧，请求插入i帧可以是基于终端设备反馈的i帧请求插入的i帧。
64.帧间隔可以是帧数间隔；也可以是编码时间间隔，在本实施例和其他实施例中，以待编码帧与前一i帧之间的编码时间间隔为例进行说明。
65.预设i帧间隔可以是两个i帧之间的时间间隔，在本实施例和其他实施例中，以iftimevalue表示预设i帧间隔。
66.可以理解的是，预设i帧间隔可以预先设置，例如，为了增大idr/i帧的间隔，预设i帧间隔可以预先设置为120s。
67.预设i帧间隔也可以根据直播视频流的帧数确定，例如，iftimevalue＝fps*2，其中，iftimevalue表示预设i帧间隔，fps表示直播视频流的帧数。
68.应当理解的是，为了增大idr/i帧的间隔，本实施例中，可以先判断帧间隔是否等于预设i帧间隔，在帧间隔等于预设i帧间隔时，将待编码帧编码为i帧。
69.步骤s20：监听是否接收到终端设备根据直播视频流反馈的i帧请求。
70.应当理解的是，增大了i帧之间的间隔后，可能存在丢包、卡顿的风险。因此，为了克服上述缺陷，本实施例中，还监听终端设备根据直播视频流反馈的i帧请求，以在终端设备反馈卡顿或切换直播源时进行i帧编码。
71.需要说明的是，终端设备可以是直播视频流的接收端，例如，客户端、导播端以及服务端等。
72.可以理解的是，终端设备在监测到直播视频流卡顿或切换直播源时，可以发送i帧请求给直播采集设备，以使直播采集设备进行i帧编码。
73.步骤s30：根据判断结果和监听结果判断是否将所述待编码帧编码为i帧。
74.应当理解的是，根据判断结果和监听结果判断是否将待编码帧编码为i帧可以是在帧间隔等于预设i帧间隔，或接收到终端设备根据直播视频流反馈的i帧请求时，将待编码帧编码为i帧；
75.在帧间隔等于预设i帧间隔，且接收到终端设备根据直播视频流反馈的i帧请求时，将待编码帧编码为i帧。
76.在帧间隔不等于预设i帧间隔，且未接收到终端设备根据直播视频流反馈的i帧请求时，将待编码帧编码为p帧或b帧。
77.为了便于理解，以下进行举例说明，但并不对本方案进行限定。将待编码帧编码为p帧的步骤如下：利用视频图像中相邻像素间的空间或者时间相关性，用已传输的像素对当前正在编码的像素进行预测，计算预测值与真实性的差。同时将空间域描述的图像，经过某种变换(如离散余弦、正弦，哈达玛等)形成变换域中的数据(系数)，达到改变数据分布、减少有效数据量的目的。结合运动估计和运动补偿、量化扫描和熵编码、环路滤波完成下一帧
p帧的编码。
78.可以理解的是，在编码完成后，可以将视频流根据预设传输方式(http、rtp/rtcp等)进行处理后打包发送到媒体服务器或终端设备。
79.应当理解的是，视频流的传输方式可以大大缩短启动延时，降低缓存需求，并实现现场直播形式的实时媒体数据传输。
80.需要说明的是，媒体服务器可以对视频流解码、编码、转码、增强以及分发等处理。
81.可以理解的是，直播采集设备成功将视频流传输到服务器后，导播端就可以在从媒体服务器拉流获取视频，并进行播放。同理，用户客户端也可以根据媒体服务器提供的url进行浏览播放。
82.在具体实现中，例如，某地a有一场体育比赛赛事，需要通过直播的方式将赛事精彩过程向全社会观众开放，采用camera1～camera8 8个摄像头分别布局在场馆的8个观赏视角较好的位置，并将idr/i帧间隔iftimevalue设置为120s。
83.比赛开始后，8个摄像头均启动推流功能，通过网络向媒体服务器mediaa推送赛事视频数据，并开启idr/i帧请求监听服务。服务器请求idr/i帧。
84.比赛前，后端管理员managera登录南京后端服务器servicea，先通过预监或者主监预览效果，如果播放器播放流出错或者出现无效流无法解码时，则servicea向camera1～camera8请求idr/i帧，一旦能正常解码则停止请求idr/i帧。同时，比赛中在切换镜头camera1～camera8前，先向camera1～camera8请求idr/i帧，然后再执行源切换与导播功能。
85.用户通过浏览器或者客户端观看直播时，如果解码不出来，则浏览器或者客户端向后端服务器servicea请求idr/i帧，由servicea再向camera1～camera8请求idr/i帧。
86.编码过程中视频数据源端在大大增大idr/i帧间隔的同时，又通过动态请求idr/i帧解决解码所需要的完整图像，以此达到传输时主要以p帧/b帧数据量很小的形式存在。
87.同样的画质效果，并且没有了画面跳转和呼吸收敛，带宽却降低了2～15倍以上。假设以4k图像为例，一张4k完整图像约为8m，如果每2秒一个idr帧，则120s产生8m*60 (p帧/b帧)*60*29》480m，而p帧/b帧是由于2帧画面差异产生的，在直播导播中，这个画面差异部分其实很小的，往往只有几kb，所以如果120s只有一个idr帧，则数据量大小为8m*1 59*30*(p帧/b帧)，如果p帧平均按10kb，计算，则使用本提案前数据量为：8m*60 10kb*60*29
→
大约497m左右，使用本提案后：8m*1 59*60*(p帧/b帧)-》42.57m左右。修改后的数据量将近是修改前的十分之一的大小。
88.在第一实施例中，公开了获取待编码帧与前一i帧之间的帧间隔，并判断帧间隔是否等于预设i帧间隔，监听是否接收到终端设备根据直播视频流反馈的i帧请求，根据判断结果和监听结果判断是否将待编码帧编码为i帧；由于本实施例在待编码帧与前一i帧之间的帧间隔等于预设i帧间隔，或接收到终端设备根据直播视频流反馈的i帧请求时，才将待编码帧编码为i帧，从而增大了i帧之间的间隔，大大降低了数据传输量，降低甚至避免了丢包或者大量数据处理错误以及延迟引起的直播画面出现卡顿、花屏，同时能够基于用户请求动态插入i帧，解决了视频源不解码或者切换视频源所依赖需要的idr/i帧问题，从而提高了用户体验。
89.参照图4，图4为本发明视频编码方法第二实施例的流程示意图，基于上述图2所示
的第一实施例，提出本发明视频编码方法的第二实施例。
90.在第二实施例中，所述步骤s10，包括：
91.步骤s101：获取前一i帧，并检测所述前一i帧是否为插入i帧，所述插入i帧为基于预设i帧间隔插入的i帧。
92.应当理解的是，在实际应用中，需要区别插入i帧与请求插入i帧，以提高帧间隔的准确性。其中，插入i帧可以是基于预设i帧间隔插入的i帧，请求插入i帧可以是基于终端设备反馈的i帧请求插入的i帧。
93.在具体实现中，例如，当前视频数据源为c，iftimevalue＝120s，当前时间为t1，并且产生第一个idr/i帧，那么后面自发产生的idr/i帧为：t1 120s*n，但t1之后第45和255秒丢包产生无法解码而分别产生一个动态请求idr/i帧。当n为3时，实际产生的idr/i帧时间点为t1，t1 45s，t1 120s，t1 240s，t1 255s，t1 360s，一共6个，而不是3个。
94.因此，为了克服上述缺陷，本实施例中，先检测前一i帧是否为插入i帧，在前一i帧为插入i帧时，才直接获取待编码帧与前一i帧之间的帧间隔。
95.进一步地，为了在前一i帧不为插入i帧时，获取正确的帧间隔，所述步骤s101之后，还包括：
96.若否，则获取前一插入i帧；
97.获取待编码帧与前一插入i帧的帧间隔，并判断所述帧间隔是否等于预设i帧间隔。
98.可以理解的是，若否，则说明前一i帧不可以用于确定帧间隔，因此，本实施例中，先获取前一插入i帧，再获取待编码帧与前一插入i帧的帧间隔。
99.步骤s102：若是，则获取待编码帧与前一i帧之间的帧间隔，并判断所述帧间隔是否等于预设i帧间隔。
100.应当理解的是，若是，则说明前一i帧可以用于确定帧间隔，因此，本实施例中，直接获取待编码帧与前一i帧之间的帧间隔，并判断帧间隔是否等于预设i帧间隔。
101.在第二实施例中，公开了获取前一i帧，并检测前一i帧是否为插入i帧，插入i帧为基于预设i帧间隔插入的i帧，若是，则获取待编码帧与前一i帧之间的帧间隔，并判断帧间隔是否等于预设i帧间隔；由于本实施例基于帧间隔进行判断之前，还会验证帧间隔是否可靠，从而确保了帧间隔判断的准确性，进而确保了视频编码的可靠性。
102.在第二实施例中，所述步骤s20，包括：
103.步骤s201：在直播视频流的视频数据源为单路时，接收终端设备根据直播视频流反馈的播放失败信息。
104.应当理解的是，在视频数据源始终只有一路时，播放前，导播台或者用户客户端先向直播采集设备发送内容带有“request idr”的idr/i帧请求，每隔1～2秒连续请求，此时再点击播放，播放成功后，再停止发送idr/i帧请求。如果播放过程中出现丢包，则发送idr/i帧请求。
105.步骤s202：根据所述播放失败信息监听是否接收到终端设备根据直播视频流反馈的i帧请求。
106.可以理解的是，根据播放失败信息监听是否接收到终端设备根据直播视频流反馈的i帧请求可以是在播放失败信息为播放丢包时，判定接收到终端设备根据直播视频流反
馈的i帧请求。
107.在第二实施例中，公开了在直播视频流的视频数据源为单路时，接收终端设备根据直播视频流反馈的播放失败信息，根据播放失败信息监听是否接收到终端设备根据直播视频流反馈的i帧请求，从而能够在直播视频流出错或者出现无效流无法解码时，及时编码i帧，以确保直播视频的正常播放。
108.在第二实施例中，所述步骤s20，还包括：
109.步骤s201'：在直播视频流的视频数据源为多路时，接收终端设备根据直播视频流反馈的源切换信息。
110.应当理解的是，当视频数据源存在多路时，导播端播放前，先向直播采集设备发送idr/i帧请求，然后点击播放。当导播需要切换不同的源时，可以先发送idr/i帧请求，然后再执行切换以及播放，不断切换则不断发送idr/i帧请求，当完成切换视频数据源时，只要播放正常播放，则停止发送idr/i帧请求。
111.步骤s202'：根据所述源切换信息监听是否接收到终端设备根据直播视频流反馈的i帧请求。
112.可以理解的是，根据源切换信息监听是否接收到终端设备根据直播视频流反馈的i帧请求可以是在源切换信息为切换视频数据源时，判定接收到终端设备根据直播视频流反馈的i帧请求。
113.在第二实施例中，公开了在直播视频流的视频数据源为多路时，接收终端设备根据直播视频流反馈的源切换信息，根据源切换信息监听是否接收到终端设备根据直播视频流反馈的i帧请求；由于本实施例在终端设备切换视频数据源时，能够确保数据源切换的正常播放。
114.参照图5，图5为本发明视频编码方法第三实施例的流程示意图，基于上述图2所示的第一实施例，提出本发明视频编码方法的第三实施例。
115.在第三实施例中，所述步骤s10之前，还包括：
116.步骤s01：获取初始i帧间隔，并判断所述初始i帧间隔是否处于预设区间。
117.应当理解的是，为了避免预设i帧间隔过大或过小，本实施例中，可以先获取用户输入的初始i帧间隔，再基于预设区间对初始i帧间隔进行调整，获得预设i帧间隔。
118.需要说明的是，预设区间可以由最小间隔值和最大间隔值组成，其中，最小间隔值和最大间隔值都可以预先设置，在本实施例和其他实施例中，以miniftimevalue表示最小间隔值，以maxiftimevalue表示最大间隔值，预设区间为[miniftimevalue，maxiftimevalue]。
[0119]
在具体实现中，例如，miniftimevalue值预先设置为3s，maxiftimevalue预先设置为240s，预设区间为[3s，240s]。
[0120]
步骤s02：根据判断结果对初始阈值进行调整，获得预设i帧间隔。
[0121]
可以理解的是，根据判断结果对初始阈值进行调整，获得预设i帧间隔可以是在初始i帧间隔位于预设区间时，将初始i帧间隔作为预设i帧间隔；在初始i帧间隔小于最小间隔值时，将最小间隔值作为预设i帧间隔；在初始i帧间隔大于最大间隔值时，将最大间隔值作为预设i帧间隔。
[0122]
在第三实施例中，公开了获取初始i帧间隔，并判断初始i帧间隔是否处于预设区
间，根据判断结果对初始阈值进行调整，获得预设i帧间隔；由于本实施例中限定了预设i帧间隔的取值范围，从而确保了预设i帧间隔的取值合理性，进而增大了i帧之间的间隔。
[0123]
此外，本发明实施例还提出一种计算机可读存储介质，计算机可读存储介质上存储有视频编码程序，所述视频编码程序被处理器执行时实现如上文所述的视频编码方法。
[0124]
此外，参照图6，本发明实施例还提出一种视频编码装置，所述视频编码装置包括：间隔判断模块10、请求监听模块20以及帧编码模块30；
[0125]
所述间隔判断模块10，用于获取待编码帧与前一i帧之间的帧间隔，并判断所述帧间隔是否等于预设i帧间隔。
[0126]
应当理解的是，本方法可以应用于需要在网络中传输视频数据的场景，例如，网络直播、视频会议以及网课等，本实施例对此不加以限制。
[0127]
可以理解的是，随着科学技术的发展，数字视频技术在通信和广播直播、远程会议领域获得了日益广泛的应用，特别是90年代以来，随着internet和移动通信的迅猛发展，视频信息和多媒体信息在internet网络和移动网络中的处理和传输成为了当前我国信息化中的热点技术。视频信息具有一系列的优点，如直观性、确切性、高效性、广泛性等，但是，视频信息量太大，要是视频得到有效的应用，首先必须解决视频压缩编码问题的，其次是解决压缩后视频质量保证的问题，同时保证网络传输视频数据的可靠和稳定。
[0128]
现有的专业直播导播应用中，一般是先使用自有的数据采集设备(例如相机)采集视频，直出的视频数据通常是yuv420/422/444、yuyv、nv12、nv21以及其他视频格式，通过设备的编码压缩功能将数据压缩数据量很小的新数据，比如h264/hevc/h266等，再根据传输协议，例如rtp，打包封装后传输到媒体服务器上，这里媒体服务器是个统称的服务器，包含集群或者转码增强分发等功能，导播端再经过导播操作完成要求后，用户就可以根据指定的url进行访问浏览观看。
[0129]
借助现代的编码解码和网络通信技术，现在的直播导播也同步获得了很好的发展和体验。现有的直播导播方案编码环节中，为了在节目导播切换新节目时，能通过idr/i帧及时解码新的视频数据源时，往往将idr/i帧(gop)间隔设置的很小，比如1s～2s。但是idr/i是一帧完整的图像，相比p帧b帧来说，数据量非常大，即使现代网络很发达，由于不同地域网络设备条件差异以及网络中不可预知的影响，大数据量的数据传输更容易造成丢包，对用户的存储设备要求更高。无论发送端还是接收端，对处理器能否及时处理大数据量的数据也是有要求的，性能不够的处理器很可能无法及时处理大数据量而造成数据丢失，同时造成图像画面延迟。而且在视频质量越来越高的发展趋势下，适应性越来越差，即使在末端使用fec/丢包重传/nack等各种补救机制，但是大数据量容易造成补救自身数据也容易丢失，补救效果不好，尤其是未来4k/8k等大分辨率数据条件下更不容易补救。另外，画面容易出现肉眼可见的收敛、跳跃等现象，体验感很差。
[0130]
为了克服上述缺陷，本实施例中在待编码帧与前一i帧之间的帧间隔等于预设i帧间隔，或接收到终端设备根据直播视频流反馈的i帧请求时，才将待编码帧编码为i帧，从而增大了i帧之间的间隔，并且能够基于用户请求动态插入i帧，进而降低了视频流的传输数据量，避免了直播画面出现卡顿、花屏，提高了用户体验。
[0131]
需要说明的是，待编码帧可以是视频源中需要编码的视频帧。
[0132]
为了便于理解，以下进行举例说明，但并不对本方案进行限定。视频源采集流程步
骤如下：
[0133]
(1)布置好直播采集设备的位置，该位置需要对直播的场景具有良好的视野角度和画面构图感，并将设备固定好；
[0134]
(2)打开设备进行采集；
[0135]
通常windows通过vfw或者directshow实时视频采集，linux系统过v4l2标准接口采集，android通过android api进行采集，ios或者其他系统都有对应平台的采集方法，这里不再详述。
[0136]
采集完成后的视频数据通常是yuv420/422/444、yuyv、nv12、nv21以及其他视频格式体现的，数据量很大。
[0137]
为了便于理解，参考图3进行说明，但并不对本方案进行限定。图3为直播采集设备位置示意图，图中，在篮球场周围分别布置cam1～8八个直播采集设备，布置位置如图所示。
[0138]
需要说明的是，待编码帧与前一i帧之间的帧间隔可以是待编码帧与前一插入i帧的帧间隔，也可以是待编码帧与前一请求插入i帧的帧间隔。其中，插入i帧可以是基于预设i帧间隔插入的i帧，请求插入i帧可以是基于终端设备反馈的i帧请求插入的i帧。
[0139]
帧间隔可以是帧数间隔；也可以是编码时间间隔，在本实施例和其他实施例中，以待编码帧与前一i帧之间的编码时间间隔为例进行说明。
[0140]
预设i帧间隔可以是两个i帧之间的时间间隔，在本实施例和其他实施例中，以iftimevalue表示预设i帧间隔。
[0141]
可以理解的是，预设i帧间隔可以预先设置，例如，预设i帧间隔可以预先设置为120s。
[0142]
预设i帧间隔也可以根据直播视频流的帧数确定，例如，iftimevalue＝fps*2，其中，iftimevalue表示预设i帧间隔，fps表示直播视频流的帧数。
[0143]
应当理解的是，为了增大idr/i帧的间隔，本实施例中，可以先判断帧间隔是否等于预设i帧间隔，在帧间隔等于预设i帧间隔时，将待编码帧编码为i帧。
[0144]
应当理解的是，为了增大idr/i帧的间隔，本实施例中，可以先判断帧间隔是否等于预设i帧间隔，在帧间隔等于预设i帧间隔时，将待编码帧编码为i帧。
[0145]
所述请求监听模块20，用于监听是否接收到终端设备根据直播视频流反馈的i帧请求。
[0146]
应当理解的是，增大了i帧之间的间隔后，可能存在丢包、卡顿的风险。因此，为了克服上述缺陷，本实施例中，还监听终端设备根据直播视频流反馈的i帧请求，以在终端设备反馈卡顿或切换直播源时进行i帧编码。
[0147]
需要说明的是，终端设备可以是直播视频流的接收端，例如，客户端、导播端以及服务端等。
[0148]
可以理解的是，终端设备在监测到直播视频流卡顿或切换直播源时，可以发送i帧请求给直播采集设备，以使直播采集设备进行i帧编码。
[0149]
所述帧编码模块30，用于根据判断结果和监听结果判断是否将所述待编码帧编码为i帧。
[0150]
应当理解的是，根据判断结果和监听结果判断是否将待编码帧编码为i帧可以是在帧间隔等于预设i帧间隔，或接收到终端设备根据直播视频流反馈的i帧请求时，将待编
码帧编码为i帧；
[0151]
在帧间隔等于预设i帧间隔，且接收到终端设备根据直播视频流反馈的i帧请求时，将待编码帧编码为i帧。
[0152]
在帧间隔不等于预设i帧间隔，且未接收到终端设备根据直播视频流反馈的i帧请求时，将待编码帧编码为p帧或b帧。
[0153]
为了便于理解，以下进行举例说明，但并不对本方案进行限定。将待编码帧编码为p帧的步骤如下：利用视频图像中相邻像素间的空间或者时间相关性，用已传输的像素对当前正在编码的像素进行预测，计算预测值与真实性的差。同时将空间域描述的图像，经过某种变换(如离散余弦、正弦，哈达玛等)形成变换域中的数据(系数)，达到改变数据分布、减少有效数据量的目的。结合运动估计和运动补偿、量化扫描和熵编码、环路滤波完成下一帧p帧的编码。
[0154]
可以理解的是，在编码完成后，可以将视频流根据预设传输方式(http、rtp/rtcp等)进行处理后打包发送到媒体服务器或终端设备。
[0155]
应当理解的是，视频流的传输方式可以大大缩短启动延时，降低缓存需求，并实现现场直播形式的实时媒体数据传输。
[0156]
需要说明的是，媒体服务器可以对视频流解码、编码、转码、增强以及分发等处理。
[0157]
可以理解的是，直播采集设备成功将视频流传输到服务器后，导播端就可以在从媒体服务器拉流获取视频，并进行播放。同理，用户客户端也可以根据媒体服务器提供的url进行浏览播放。
[0158]
在具体实现中，例如，某地a有一场体育比赛赛事，需要通过直播的方式将赛事精彩过程向全社会观众开放，采用camera1～camera8 8个摄像头分别布局在场馆的8个观赏视角较好的位置，并将idr/i帧间隔iftimevalue设置为120s。
[0159]
比赛开始后，8个摄像头均启动推流功能，通过网络向媒体服务器mediaa推送赛事视频数据，并开启idr/i帧请求监听服务。服务器请求idr/i帧。
[0160]
比赛前，后端管理员managera登录南京后端服务器servicea，先通过预监或者主监预览效果，如果播放器播放流出错或者出现无效流无法解码时，则servicea向camera1～camera8请求idr/i帧，一旦能正常解码则停止请求idr/i帧。同时，比赛中在切换镜头camera1～camera8前，先向camera1～camera8请求idr/i帧，然后再执行源切换与导播功能。
[0161]
用户通过浏览器或者客户端观看直播时，如果解码不出来，则浏览器或者客户端向后端服务器servicea请求idr/i帧，由servicea再向camera1～camera8请求idr/i帧。
[0162]
编码过程中视频数据源端在大大增大idr/i帧间隔的同时，又通过动态请求idr/i帧解决解码所需要的完整图像，以此达到传输时主要以p帧/b帧数据量很小的形式存在。
[0163]
同样的画质效果，并且没有了画面跳转和呼吸收敛，带宽却降低了2～15倍以上。假设以4k图像为例，一张4k完整图像约为8m，如果每2秒一个idr帧，则120s产生8m*60 (p帧/b帧)*60*29》480m，而p帧/b帧是由于2帧画面差异产生的，在直播导播中，这个画面差异部分其实很小的，往往只有几kb，所以如果120s只有一个idr帧，则数据量大小为8m*1 59*30*(p帧/b帧)，如果p帧平均按10kb，计算，则使用本提案前数据量为：8m*60 10kb*60*29
→
大约497m左右，使用本提案后：8m*1 59*60*(p帧/b帧)-》42.57m左右。修改后的数据量将近
是修改前的十分之一的大小。
[0164]
在第一实施例中，公开了获取待编码帧与前一i帧之间的帧间隔，并判断帧间隔是否等于预设i帧间隔，监听是否接收到终端设备根据直播视频流反馈的i帧请求，根据判断结果和监听结果判断是否将待编码帧编码为i帧；由于本实施例在待编码帧与前一i帧之间的帧间隔等于预设i帧间隔，或接收到终端设备根据直播视频流反馈的i帧请求时，才将待编码帧编码为i帧，从而增大了i帧之间的间隔，大大降低了数据传输量，降低甚至避免了丢包或者大量数据处理错误以及延迟引起的直播画面出现卡顿、花屏，同时能够基于用户请求动态插入i帧，解决了视频源不解码或者切换视频源所依赖需要的idr/i帧问题，从而提高了用户体验。
[0165]
在一实施例中，所述间隔判断模块10，还用于获取前一i帧，并检测所述前一i帧是否为插入i帧，所述插入i帧为基于预设i帧间隔插入的i帧；
[0166]
所述间隔判断模块10，还用于若是，则获取待编码帧与前一i帧之间的帧间隔，并判断所述帧间隔是否等于预设i帧间隔。
[0167]
在一实施例中，所述间隔判断模块10，还用于若否，则获取前一插入i帧；
[0168]
所述间隔判断模块10，还用于获取待编码帧与前一插入i帧的帧间隔，并判断所述帧间隔是否等于预设i帧间隔。
[0169]
在一实施例中，所述视频编码装置还包括：区间调整模块；
[0170]
所述区间调整模块，用于获取初始i帧间隔，并判断所述初始i帧间隔是否处于预设区间；
[0171]
所述区间调整模块，还用于根据判断结果对初始阈值进行调整，获得预设i帧间隔。
[0172]
在一实施例中，所述请求监听模块20，还用于在直播视频流的视频数据源为单路时，接收终端设备根据直播视频流反馈的播放失败信息；
[0173]
所述请求监听模块20，还用于根据所述播放失败信息监听是否接收到终端设备根据直播视频流反馈的i帧请求。
[0174]
在一实施例中，所述请求监听模块20，还用于在直播视频流的视频数据源为单路时，接收终端设备根据直播视频流反馈的播放失败信息；
[0175]
所述请求监听模块20，还用于根据所述播放失败信息监听是否接收到终端设备根据直播视频流反馈的i帧请求。
[0176]
在一实施例中，所述帧编码模块30，还用于在帧间隔等于预设i帧间隔，或接收到终端设备根据直播视频流反馈的i帧请求时，判定将所述待编码帧编码为i帧；
[0177]
所述帧编码模块30，还用于在帧间隔不等于预设i帧间隔，且未接收到终端设备根据直播视频流反馈的i帧请求时，判定不将所述待编码帧编码为i帧。
[0178]
需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者系统不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者系统所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括该要素的过程、方法、物品或者系统中还存在另外的相同要素。
[0179]
上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。
[0180]
通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个计算机可读存储介质(如只读存储器镜像(read only memory image，rom)/随机存取存储器(random access memory，ram)、磁碟、光盘)中，包括若干指令用以使得一台接入设备(可以是手机，计算机，服务器，空调器，或者网络设备等)执行本发明各个实施例所述的方法。
[0181]
以上仅为本发明的优选实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本发明的专利保护范围内。