CN117998117A - 直播视频流转码方法、服务器、电子设备及存储介质 - Google Patents

Abstract

本申请公开了一种直播视频流转码方法、服务器、电子设备及存储介质。该方法包括：获取第一直播视频流；对第一直播视频流进行解码，得到直播源视频流；基于第一直播视频流对应的封装格式、预设帧率、直播源视频流的第一帧率，对直播源视频流进行编码，得到目标直播视频流，其中，若第一帧率小于预设帧率，目标直播视频流的帧率等于第一帧率，若第一帧率大于预设帧率，目标直播视频流的帧率小于或等于预设帧率。

Description

直播视频流转码方法、服务器、电子设备及存储介质

技术领域

本申请涉及转码技术领域，具体涉及一种直播视频流转码方法、服务器、电子设备及存储介质。

背景技术

在转码业务中，比如直播业务中的转码，需要对直播视频流进行转码，由于视频画面呈现的流畅度与视频的帧率大小有关系，帧率越高画面越流畅，为了保证直播视频流的流畅度，一般会选择高帧率的直播视频流，然后再对高帧率的直播视频流进行转码，再将转码后的高帧率视频流发送给播放端进行解码播放，然而帧率越高，播放端解码该高帧率视频流时所需带宽也就更大。因此，如何平衡转码后的视频的流畅度和播放端解码所需带宽是亟待解决的问题。

发明内容

本申请提供了一种直播视频流转码方法、服务器、电子设备及存储介质，平衡了转码后的视频流畅度和播放端解码所需带宽。

第一方面，本申请提供一种直播视频流转码方法，该方法应用于服务器，该方法包括：

获取第一直播视频流；

对第一直播视频流进行解码，得到直播源视频流；

基于第一直播视频流对应的封装格式、预设帧率、直播源视频流的第一帧率，对直播源视频流进行编码，得到目标直播视频流，其中，若第一帧率小于预设帧率，目标直播视频流的帧率等于第一帧率，若第一帧率大于预设帧率，目标直播视频流的帧率小于或等于预设帧率。

第二方面，本申请提供一种服务器，该服务器包括：获取单元和处理单元；

获取单元，用于获取第一直播视频流；

处理单元，用于对第一直播视频流进行解码，得到直播源视频流；

处理单元，还用于基于第一直播视频流对应的封装格式、预设帧率、直播源视频流的第一帧率，对直播源视频流进行编码，得到目标直播视频流，其中，若第一帧率小于预设帧率，目标直播视频流的帧率等于第一帧率，若第一帧率大于预设帧率，目标直播视频流的帧率小于或等于预设帧率。

第三方面，本申请提供一种电子设备，包括：处理器和存储器，处理器与存储器相连，存储器用于存储计算机程序，处理器用于执行存储器中存储的计算机程序，以使得电子设备执行如第一方面的方法。

第四方面，本申请提供一种计算机可读存储介质，计算机可读存储介质存储有计算机程序，计算机程序使得计算机执行如第一方面的方法。

第五方面，本申请提供一种计算机程序产品，计算机程序产品包括存储了计算机程序的非瞬时性计算机可读存储介质，计算机可操作来使计算机执行如第一方面的方法。

实施本申请，具有如下有益效果：

在获取第一直播视频流后，对第一直播视频流进行解码，得到直播源视频流；然后基于直播源视频流的第一帧率和预设帧率的关系，以及第一直播视频流对应的封装格式，对直播源视频流进行编码，得到目标直播视频流，其中，预设帧率可以理解为播放端的解码能力所允许的最大帧率，且该帧率下对应的视频流畅度相比于高帧率的原视频流畅度，对用户而言肉眼上不会存在流畅度降低的情形，即若直播源视频流的第一帧率小于预设帧率，则最终编码得到的目标直播视频流的帧率等于第一帧率，也就是说这种情况下，基于第一直播视频流对应的封装格式对直播源视频流进行编码得到的视频的帧率与直播源视频流的帧率保持一致，没有降低直播源视频流的帧率，而现有技术中转码过程中会对直播源视频流进行丢帧或者错误丢帧，降低了直播源视频流的帧率，进而降低了直播源视频流的流畅度，而本方案没有降低直播源视频流的帧率，进而没有降低直播源视频流的流畅度；同理，若直播源视频流的第一帧率大于预设帧率，则最终编码得到的目标直播视频流的帧率小于或等于预设帧率，也就是说这种情况下，先对直播源视频流进行降帧率，比如降到预设帧率或者小于预设帧率，然后再基于第一直播视频流对应的封装格式对降帧率后的直播视频流进行编码，使得最终编码得到的目标直播视频流的帧率与降帧率后的直播视频流的帧率保持一致，即将直播源视频流的帧率降低到肉眼所不能发现流畅度变化的帧率，同时也降低了播放端的解码带宽压力，进而基于第一直播视频流对应的封装格式，保证在编码过程中对已经降了帧率的直播视频流的帧率不再继续降低，进而保障直播视频流的流畅度。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本申请实施例提供的一种转码过程中对视频帧的时间戳的处理示意图；

图2为本申请实施例提供的一种直播视频流转码系统的示意图；

图3为本申请实施例提供的另一种直播视频流转码系统的示意图；

图4为本申请实施例提供的一种直播视频流转码方法的流程示意图；

图5为本申请实施例提供的一种对直播源视频流进行丢帧的示意图；

图6为本申请实施例提供的一种基于候选直播视频流中的视频帧对应的第一时间戳，对候选直播视频流进行编码的示意图；

图7为本申请实施例提供的另一种基于候选直播视频流中的视频帧对应的第一时间戳，对候选直播视频流进行编码的示意图；

图8为本申请实施例提供的又一种基于候选直播视频流中的视频帧对应的第一时间戳，对候选直播视频流进行编码的示意图；

图9为本申请实施例提供的一种服务器的功能单元组成框图；

图10为本申请实施例提供的一种电子设备的结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

本申请的说明书和权利要求书及附图中的术语“第一”、“第二”、“第三”和“第四”等是用于区别不同对象，而不是用于描述特定顺序。此外，术语“包括”和“具有”以及它们任何变形，意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元，而是可选地还包括没有列出的步骤或单元，或可选地还包括对于这些过程、方法、产品或设备固有的其它步骤或单元。

在本文中提及“实施例”意味着，结合实施例描述的特定特征、结果或特性可以包含在本申请的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例，也不是与其它实施例互斥的独立的或备选的实施例。本领域技术人员显式地和隐式地理解的是，本文所描述的实施例可以与其它实施例相结合。

首先，对本申请所涉及的相关技术和相关术语进行解释说明：

视频帧的时间戳：主要包括显示时间戳(Presentation Time Stamp，PTS)、解码时间戳(Decoding Time Stamp，DTS)；PTS主要用于度量解码后的视频帧何时被显示出来(比如在播放端中显示的时间)，DTS主要用于标识视频帧何时被解码(比如在解码器中应该被解码的时间)。在大多数情况下，对于普通的视频帧序列，PTS和DTS是相同的，这表示视频帧按照被编码的顺序进行解码和显示；当存在B(Bi-directional frame)帧时，PTS和DTS一般不同；应说明，本申请中主要以视频帧的时间戳主要是指显示时间戳。

时间基准：又称时间基(Time Base，TB)，不同的封装格式对应不同的时间基准，比如流媒体(Flash Video，FLV)格式的时间基准为1/1000秒(即1秒＝1000时间单位)，MP 4(MPEG-4Part 14)格式的时间基准为1/100000秒(1秒＝100000时间单位)，还有一些封装格式的时间基准为1/帧率，等等。另外，编码器使用时间基准来确定时间戳(即PTS和DTS)，时间基准和时间戳的关系是：时间戳×时间基准＝实际的时刻值(以秒等为单位)，例如，如果一个视频帧的DTS是40，PTS是160，其TB是1/1000秒，那么可以计算出此视频帧实际的解码时刻是40毫秒(即40×1/1000)，实际的显示时刻是160毫秒(即160×1/1000)。

下面介绍现有技术转码过程中对视频帧的时间戳的处理，具体参阅图1，图1为本申请实施例提供的一种转码过程中对视频帧的时间戳的处理示意图。如图1所示，假设直播源视频流的帧率＝20，图1示出的直播源视频流中的视频帧的初始PTS依次为：0、50、75、100、150、150、175、200、175；转码过程中的编码器需要对这些视频帧进行编码，在编码时需要依次执行图1中虚线框中的步骤，首先是需要将这些视频帧的初始PTS转换为编码器对应的PTS，依次为：0、1.0、1.5、2.0、3.0、3.0、3.5、4.0、3.5，之所以需要转换是因为这些视频帧的初始PTS是基于直播源视频流的封装格式所对应的时间基准(对转码过程中的编码器而言可以理解为是输入时间基准)确定的，编码器不一定能够识别基于这种时间基准确定的PT S，所以需要转换为编码器能够识别的PTS，即基于编码器对应的时间基准(一般设置为输出帧率，同理，对编码器而言可以理解为是转码时间基准)对视频帧的初始PTS进行转换，其中，编码器对应的PTS可以通过公式(1)得到：“视频帧的初始PTS×输入时间基准÷转码时间基准”(1)，其中，假设图1中直播源视频流的封装格式为FLV格式，则输入时间基准为1/1000，现有技术中转码时间基准一般为转码中的输出帧率，比如这里对直播源视频流进行转码，即转码中的输出帧率为直播源视频流的帧率。

然后，对编码器对应的PTS进行取整，得到取整后的PTS依次为：0、1、2、2、3、3、3、4、4；然后编码器基于取整后的PTS对每一帧进行编码，在编码过程中，编码器会对取整后的PTS处于异常的视频帧进行丢帧处理(即图1中存在“×”标识的第4个视频帧、第6个视频帧、第7个视频帧和第9个视频帧所对应的取整后的PTS存在异常)，比如若当前视频帧对应的取整后的PTS小于或者等于上一帧对应的取整后的PTS，则丢掉当前帧，即第3个视频帧和第4个视频帧对应的取整后的PTS均为“2”，则丢掉第4个视频帧，以及第6个视频帧和第5个视频帧对应的取整后的PTS均为“3”，则丢掉第6个视频帧，以及第7个视频帧和第5个视频帧(因为第6个视频帧已经丢掉，所以第7个视频帧的上一帧就是第5个视频帧)对应的取整后的PTS均为“3”，则丢掉第7个视频帧，以及第9个视频帧和第8个视频帧对应的取整后的PTS均为“4”，则丢掉第9个视频帧，最终编码完得到PTS为0、1、2、3、4的视频帧。

从图1可以看出，第3个视频帧的初始PTS为75，第4个视频帧的初始PTS为100，说明第4个视频帧的PTS未存在异常，而转码过程中却把第4个视频帧进行丢弃，相当于错误丢帧，由于图1仅示出了9个视频帧，而针对存在更多帧的视频出现图1中错误丢帧情况的概率会更大，丢帧越多，会降低帧率，相应地流畅度也会降低，进而难以保证转码后的视频的流畅度。

再加上从上述背景技术可知，为了保证直播源视频流的流畅度，一般会选择高帧率的直播源视频流，然后对高帧率的直播源视频流进行转码，再将转码后的高帧率视频发送给播放端进行解码播放，然而帧率越高，播放端解码该高帧率视频时所需带宽也就更大，针对这种情况，在转码时一般是先对高帧率的直播源视频流进行丢帧，来降低直播源视频流的帧率得到直播视频流A，然后再对该直播视频流A进行编码，而在该编码过程中对于直播视频流A中视频帧的时间戳存在异常(比如当前视频帧的时间戳小于或者等于上一视频帧的时间戳)的情形，编码器会直接将异常的视频帧进行丢掉，得到直播视频流B，相当于直播视频流B是先基于对直播源视频流进行丢帧得到直播视频流A来满足带宽需求，然后在对直播视频流A进行编码时又会丢掉异常帧(也包括上述图1示出的错误丢帧的情形)，得到直播视频流B，即直播源视频流→直播视频流A→直播视频流B的过程，不断丢帧会使得帧率越来越低，虽然减轻了播放端的带宽压力，但是不能保证转码后视频的流畅度，进而降低用户的体验。

有鉴于此，本申请在获取第一直播视频流后，对第一直播视频流进行解码，得到直播源视频流；然后基于直播源视频流的第一帧率和预设帧率的关系，以及第一直播视频流对应的封装格式，对直播源视频流进行编码，得到目标直播视频流，其中，预设帧率可以理解为播放端的解码能力所允许的最大帧率且该帧率下对应的视频流畅度相比于高帧率的原直播视频流，对用户而言肉眼上不会存在流畅度降低的情形，即若直播源视频流的第一帧率小于预设帧率，则最终编码得到的目标直播视频流的帧率等于第一帧率，也就是说这种情况下，基于第一直播视频流对应的封装格式对直播源视频流进行编码得到的视频的帧率与直播源视频流的帧率保持一致，没有降低对直播源视频流的帧率，进而没有降低直播源视频流的流畅度；同理，若直播源视频流的第一帧率大于预设帧率，则最终编码得到的目标直播视频流的帧率小于或等于预设帧率，也就是说这种情况下，先对直播源视频流进行降帧率，比如降到预设帧率或者小于预设帧率，然后再基于第一直播视频流对应的封装格式对降帧率后的直播视频流进行编码，使得最终编码得到的目标直播视频流的帧率与降帧率后的直播视频流的帧率保持一致，即将直播源视频流的帧率降低到肉眼所不能发现流畅度变化的帧率，同时也降低了播放端的解码带宽压力，进而基于第一直播视频流对应的封装格式，保证在编码过程中对已经降了帧率的直播视频流的帧率不再继续降低，进而保障直播视频流的流畅度。

参阅图2，图2为本申请实施例提供的一种直播视频流转码系统的示意图。

图2所示的系统包括服务器、第一用户端、第二用户端；其中，服务器可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务，以及大数据和人工智能平台等基础云计算服务的云服务器，本申请对服务器不作具体限定；第一用户端比如可以是发起直播的用户(比如主播)所对应的终端，第一用户端的数量可以为一个或多个，本申请主要以一个第一用户端为例进行说明；第二用户端比如可以是观看直播的用户所对应的终端，第二用户端的数量可以为一个或多个，图2主要以一个第二用户端为例进行说明，应说明，不同系统的第二用户端则服务器向第二用户端下发目标直播视频流所采用的传输协议可能不同，比如若第二用户端为安卓系统(Android)，则传输协议可以是超文本传输的流媒体传输协议(Hypertext Transfer Protocol-FlashVideo，HTTP-FL V)、实时传输(Real-Time Messaging Protocol，RTMP)协议，若第二用户端为iOS系统，则传输协议可以是基于超文本传输协议流媒体(HTTP Live Streaming，HLS)协议、基于超文本传输协议动态自适应流(Dynamic Adaptive Streaming over Http，DASH)协议，若第二用户端为Windows系统，则传输可以是RTMP协议，等等，此处不一一列举限定；另外，第一用户端和第二用户端均可以是智能手机、平板电脑、笔记本电脑、桌上型电脑、智能电视、台式计算机、智能手表、智能车载等智能终端，本申请不作具体的限定。

首先，服务器从第一用户端获取第一直播视频流；然后服务器对第一直播视频流进行解码，得到直播源视频流；然后服务器基于第一直播视频流对应的封装格式、预设帧率、直播源视频流的第一帧率，对直播源视频流进行编码，得到目标直播视频流，其中，若第一帧率小于预设帧率，目标直播视频流的帧率等于第一帧率，若第一帧率大于预设帧率，目标直播视频流的帧率小于或等于预设帧率；最后服务器再将目标直播视频流发送给第二用户端，以使第二用户端对目标直播视频流进行解码并播放。

基于图2实施例，参阅图3，图3为本申请实施例提供的另一种直播视频流转码系统的示意图。

图3所示的系统包括服务器、第一用户端、第二用户端、上行节点、下行节点、直播源站，其中，图3中的服务器、第一用户端、第二用户端可以参照图2实施例的相关阐述，此处不再赘述，图3以一个第一用户端和一个第二用户端为例进行说明。

首先，第一用户端向上行节点发送第一直播视频流，比如第一用户端通过RTMP协议或者SRT协议向上行节点发送第一直播视频流；然后上行节点向直播源站发送第一直播视频流，比如上行节点通过RTMP协议或者SRT协议向直播源站发送第一直播视频流；然后直播源站向服务器发送第一直播视频流，比如直播源站通过RTMP协议向服务器发送第一直播视频流；然后服务器对第一直播视频流进行解码，得到直播源视频流；然后服务器基于第一直播视频流对应的封装格式、预设帧率、直播源视频流的第一帧率，对直播源视频流进行编码，得到目标直播视频流，其中，若第一帧率小于预设帧率，目标直播视频流的帧率等于第一帧率，若第一帧率大于预设帧率，目标直播视频流的帧率小于或等于预设帧率；最后服务器再将目标直播视频流发送给直播源站，比如服务器通过RTMP协议向直播源站发送目标直播视频流；然后直播源站通过下行节点，采用与第二用户端对应的传输协议，向第二用户终端发送目标直播视频流，然后第二用户端对目标直播视频流进行解码并播放，即实现第二用户端显示目标直播视频流。

参阅图4，图4为本申请实施例提供的一种直播视频流转码方法的流程示意图，该方法应用于上述实施例中的服务器，该方法包括但不限于步骤S401-S403：

S401、获取第一直播视频流。

在本申请的实施例中，第一直播视频流是对直播源视频流进行编码、封装后的编码流，对于直播视频流的封装格式可以有多种，比如FLV格式、MP4格式、HLS格式，本申请下文主要以第一直播视频流的封装格式为FLV格式为例进行说明。

S402、对第一直播视频流进行解码，得到直播源视频流。

在本申请的实施例中，由于视频帧的时间戳是在编码时生成，而第一直播视频流是通过对直播源视频流进行编码得到，因此，服务器获取到第一直播视频流之后，便可以知道第一直播视频流中每个视频帧的时间戳，也即是可以知道直播源视频流中每个视频帧对应的时间戳。

S403、基于第一直播视频流对应的封装格式、预设帧率、直播源视频流的第一帧率，对直播源视频流进行编码，得到目标直播视频流。

在本申请的实施例中，直播源视频流是一段时间内的视频，因此直播源视频流的第一帧率可以通过直播源视频流的总帧数与直播源视频流的总时长(单位为秒)的比值得到，若第一帧率小于预设帧率，目标直播视频流的帧率等于第一帧率，若第一帧率大于预设帧率，目标直播视频流的帧率小于或等于预设帧率。示例性的，步骤S403可以包括但不限于步骤S11-S13：

S11、若第一帧率大于预设帧率，基于直播源视频流中的视频帧的时间戳，对直播源视频流进行丢帧，得到第二直播视频流。

其中，第二直播视频流的帧率小于或者等于预设帧率，也就是说，若直播源视频流的第一帧率大于预设帧率，则将第一帧率降低到等于预设帧率，或者降低到小于预设帧率。示例性的，首先，基于第一帧率和预设帧率，确定目标丢帧数，比如确定第一帧率和预设帧率的帧率差值，然后该帧率差值和直播源视频流的总时长，得到目标丢帧数，比如目标丢帧数为该帧率差值和该总时长的乘积，这种情形下就是将第一帧率降低到等于预设帧率，或者，目标丢帧数为该帧率差值和该总时长的乘积与预设值之和，之前情形下就是将第一帧率降低到小于预设帧率；然后，确定直播源视频流中相邻视频帧的差值，其中，相邻视频帧的差值为相邻视频帧中两个视频帧的时间戳之间的差值，也就是说，相邻视频帧可以看成一对视频帧，即计算直播源视频流中每一对视频帧中两个视频帧的时间戳之间的差值。

然后，基于目标丢帧数、相邻视频帧的差值，对直播源视频流进行丢帧，得到第二直播视频流。示例性的，若直播源视频流中任意两个相邻视频帧对应的差值相同，对直播源视频流进行间隔丢帧，直至丢帧数等于目标丢帧数，得到第二直播视频流，也就是说，若直播源视频流中任意两对视频帧对应的差值都相同，则对直播源视频流中的视频帧从头开始遍历，对直播源视频流中的视频帧进行间隔丢帧，比如间隔一帧进行丢帧、间隔两帧进行丢帧、间隔预设数量进行丢帧，等等，本申请不作具体限定，直至丢帧数达到目标丢帧数就停止丢帧，然后基于直播源视频流中剩余未被丢掉的视频帧得到第二直播视频流。

同理，若直播源视频流中任意两个相邻视频帧对应的差值不同，基于目标丢帧数，确定第二直播视频流中的相邻视频帧对应的第二时间间隔，也就是说，若直播源视频流中任意两对视频帧对应的差值不同，则基于目标丢帧数确定第二直播视频流中每一对视频帧对应的第二时间间隔(即理想情况下的时间间隔，该理想情况是指第二直播视频流中视频帧对应的时间戳基于第二时间间隔单调递增)，比如第二时间间隔为1秒/(第一帧率－目标丢帧数/直播源视频流的总时长)；然后，从直播源视频流中的第二个视频帧开始遍历，确定直播源视频流中的第Z个视频帧的时间戳与第一视频帧的时间戳的第一差值，其中，第一视频帧为直播源视频流中未被丢掉的视频帧中第Z个视频帧的上一帧，Z＞1；若第一差值小于第二时间间隔，丢掉第Z个视频帧，直至丢帧数达到目标丢帧数，得到第二直播视频流，也就是说，对直播源视频流的视频帧进行丢帧是按照从头开始、一帧一帧判断是否需要丢掉当前帧，比如，直播源视频流中的第1个视频帧默认不丢帧，然后从直播源视频流中的第2个视频帧开始遍历，确定第2个视频帧的时间戳与第1个视频帧的时间戳的第一差值，若该第一差值大于或者等于第二时间间隔，则不丢第2个视频帧，继续确定第3个视频帧的时间戳与第2个视频帧的时间戳的第一差值，若该第一差值小于第二时间间隔，则丢掉第3个视频帧，由于第3个视频帧被丢掉，那么第4个视频帧对应的第一视频帧应该是第2个视频帧，则确定第4个视频帧对应的时间戳与第2个视频帧的时间戳的第一差值，若该第一差值大于或者等于第二时间间隔，则不丢第4个视频帧，后续视频帧同理，此处不一一列举。

为了便于理解，下面结合图示说明丢帧原理，具体参阅图5，图5为本申请实施例提供的一种对直播源视频流进行丢帧的示意图。如图5所示，假设直播源视频流的总时长为1秒、第一帧率为40，预设帧率为20，若目标丢帧数为20帧(即第一帧率与预设帧率的差值与直播源视频流的总时长的乘积)，则基于上述原理确定第二时间间隔为50毫秒；图5示出了直播源视频流的部分视频帧(即直播源视频流中的前8个视频帧，序号依次为：1、2、3、4、5、6、7、8)，这前8个视频帧对应的时间戳PTS依次为：0、50、75、100、150、150、175、200；然后第1个视频帧默认保留，从第2个视频帧开始，确定第2个视频帧的PTS与第1个视频帧的PTS的差值为50(等于第二时间间隔)，所以第2个视频帧保留；然后，确定第3个视频帧的PTS与第3个视频帧的PTS的差值为25(小于第二时间间隔)，所以第3个视频帧丢掉；然后，确定第4个视频帧的PTS与第2个视频帧的PTS的差值为50(等于第二时间间隔)，所以第4个视频帧保留；然后，确定第5个视频帧的PTS与第4个视频帧的PTS的差值为50(等于第二时间间隔)，所以第5个视频帧保留；然后，确定第6个视频帧的PTS与第5个视频帧的PTS的差值为0(小于第二时间间隔)，所以第6个视频帧丢掉；然后，确定第7个视频帧的PTS与第5个视频帧的PTS的差值为25(小于第二时间间隔)，所以第7个视频帧丢掉；然后确定第8个视频帧的PTS与第5个视频帧的PTS的差值为50(等于第二时间间隔)，所以第8个视频帧保留，所以最终直播源视频流的前8个视频帧在丢帧之后还剩下原本的第1个视频帧、第2个视频帧、第4个视频帧、第5个视频帧和第8个视频帧；因此，对于直播源视频流的后续剩余视频帧的丢帧逻辑和该前8个视频帧的丢帧逻辑相同，依次遍历每个视频帧，直至丢帧数达到目标丢帧数即可停止丢帧，当然，若存在对直播源视频流的所有视频帧均遍历完且丢帧数还未达到目标丢帧数这一特殊情况，则可以再对直播源视频流中剩余未被丢掉的视频帧进行随机丢帧(比如间隔丢帧等)，直至总的丢帧数达到目标丢帧数即可，最终基于直播源视频流中未被丢掉的视频帧得到第二直播视频流。

S12、基于第一直播视频流对应的封装格式、第二直播视频流中的视频帧的时间戳，对第二直播视频流进行编码操作，得到目标直播视频流。

S13、若第一帧率小于预设帧率，基于第一直播视频流对应的封装格式、直播源视频流中的视频帧的时间戳，对直播源视频流进行编码操作，得到目标直播视频流。

示例性的，步骤S12中对第二直播视频流进行编码操作和步骤S13中对直播源视频流进行编码的原理类似，该编码操作具体包括但不限于步骤S21-S23：

S21、基于第一直播视频流对应的封装格式，确定第一时间基准和第二时间基准。

S22、基于第一时间基准、第二时间基准，对候选直播视频流中的视频帧的时间戳进行转换，得到候选直播视频流中的视频帧对应的第一时间戳。

S23、基于候选直播视频流中的视频帧对应的第一时间戳，对候选直播视频流进行编码，得到目标直播视频流。

其中，第一时间基准表示编码器对候选直播视频流编码为目标直播视频流所使用的时间格式或者时间基准，也可以理解为是上述实施例中的“转码时间基准”；第二时间基准表示编码器对直播源视频流编码为第一直播视频流所使用的时间格式，即第一客户端的编码器对直播源视频流编码为第一直播视频流所使用的时间基准，也可以理解为是上述实施例中的“输入时间基准”；候选直播视频流为直播源视频流或者第二直播视频流。

在一种可选的实施例中，第一时间基准和第二时间基准可以相同，因此若第一直播视频流对应的封装格式为FLV格式，与FLV格式对应的时间基准为1/1000秒，则确定第一时间基准为1/1000，第二时间基准也为1/1000(而不是候选直播视频流的帧率)，即对于转码过程中的编码器而言输入时间基准和转码时间基准相同。

由于第一时间基准和第二时间基准相同，所以依据上述公式(1)的原理，可以确定候选直播视频流中的视频帧对应的第一时间戳为：“候选直播视频流中的视频帧的时间戳×1/1000÷1/1000”，即此时候选直播视频流中的视频帧对应的第一时间戳和原本候选直播视频流中的视频帧的时间戳相同。

在将候选直播视频流中的视频帧的时间戳转化为转码过程中的编码器所能够识别的格式，即候选直播视频流中的视频帧对应的第一时间戳之后，编码器便可以基于候选直播视频流中的视频帧对应的第一时间戳，对候选直播视频流中的每一个视频帧进行编码，在编码时，对候选直播视频流中的视频帧对应的第一时间戳存在异常的视频帧进行丢帧，一般情况下，候选直播视频流中的第一个视频帧的第一时间戳不会存在异常，从第二个视频帧开始遍历，若遍历的当前视频帧的第一时间戳小于或者等于直播源视频流中未被丢掉的视频帧中当前视频帧的上一帧，则丢掉当前帧，即不对当前帧进行编码，直至对候选直播视频流中的最后一个视频帧编码结束，得到目标直播视频流。

为了便于理解，基于图1实施例中的示例，参阅图6，图6为本申请实施例提供的一种基于候选直播视频流中的视频帧对应的第一时间戳，对候选直播视频流进行编码的示意图。如图6所示，以候选直播视频流为直播源视频流(即第一帧率小于预设帧率)为例进行说明，图6示出的直播源视频流中的视频帧的初始PTS与图1实施例相同，依次为：0、50、75、100、150、150、175、200、175；然后转码过程中的编码器也需要对这些视频帧进行编码，在编码时需要依次执行图6中虚线框中的步骤，首先是需要将这些视频帧的初始PTS转换为编码器所能识别的PTS即上述第一时间戳，依次为：0、50、75、100、150、150、175、200、175，其中，转换原理参照上述第一时间戳的确定原理，此处不再赘述；然后编码器在编码时，会对第一时间戳存在异常的视频帧进行丢帧处理(即图6中存在“×”标识的第6个视频帧和第9个视频帧对应的PTS存在异常)，比如若当前视频帧对应的第一时间小于或者等于未被丢掉的视频帧中该当前视频帧的上一帧的第一时间戳，则丢掉当前帧，具体的，第1个视频帧、第2个视频帧、第3个视频帧、第4个视频帧和第5个视频帧的第一时间戳均是递增，不存在异常，就不存在丢帧，而第6个视频帧和第5个视频帧的第一时间戳均是150，则需要丢掉第6个视频帧，进一步的，第7个视频帧的第一时间戳大于第7个视频帧的上一帧(由于第6个视频帧被丢掉，所以此时第7个视频帧的上一帧为第5个视频帧)的第一时间戳，第8个视频帧的第一时间戳也大于第7个视频帧的第一时间戳，则不存在丢帧，而第9个视频帧的第一时间戳小于第8个视频帧的第一时间戳，则丢掉第9个视频帧，最终剩下第1个视频帧、第2个视频帧、第3个视频帧、第4个视频帧和第5个视频帧、第7个视频帧、第8个视频帧，即总计只丢了2个视频帧，而图1实施例中编码器执行图1中虚线框中的步骤总计却丢了4个视频帧，因为图1会存在错误丢帧的情形，而本申请编码器执行图6实施例中虚线框中的步骤，使得让直播源视频流不被错误丢帧，即尽可能少丢帧，避免因错误丢帧导致对直播源视频流的帧率大幅度降低，进而不能保证转码后视频的流畅度，降低观看体验。

当然，在一种可选的实施例中，步骤S23还可以包括但不限于步骤S31-S32：

S31、针对候选直播视频流中的第i个视频帧，基于第i个视频帧对应的第一时间戳和第i-1个视频帧对应的第二时间戳，确定第i个视频帧对应的第二时间戳。

S32、基于候选直播视频流中的视频帧对应的第二时间戳，对候选直播视频流中的视频帧进行编码，得到目标直播视频流。

也就是说，在得到视频帧对应的第一时间戳之后，还可再对第一时间戳进行校正，得到视频帧对应的第二时间戳，具体的：当i＝1时，不存在第0个视频帧，则直接基于第1个视频帧对应的第一时间戳，确定第1个视频帧对应的第二时间戳，即第1个视频帧对应的第二时间戳就是第1个视频帧对应的第一时间戳。同理，当i＞1时，基于候选直播视频流的帧率，确定候选直播视频流中的相邻视频帧对应的第一时间间隔，比如第一时间间隔为1秒(即1000毫秒)与候选直播视频流的帧率的比值；然后若第i个视频帧对应的第一时间戳小于或者等于第i-1个视频帧对应的第二时间戳，则基于第i-1个视频帧对应的第二时间戳和第一时间间隔，确定第i个视频帧对应的第二时间戳，比如此时第i个视频帧对应的第二时间戳为第i-1个视频帧对应的第二时间戳和第一时间间隔之和；若第i个视频帧对应的第一时间戳大于第i-1个视频帧对应的第二时间戳，基于第i个视频帧对应的第一时间戳，确定第i个视频帧对应的第二时间戳，比如此时第i个视频帧对应的第二时间戳就是第i个视频帧对应的第一时间戳；然后再基于候选直播视频流中的视频帧对应的第二时间戳，对候选直播视频流中的视频帧进行编码，得到目标直播视频流，由于第二时间戳是对第一时间戳进行校正后的，相当于直播源视频流中视频帧对应的第二时间戳从头开始会呈现递增的情况，不会出现后一帧的时间戳小于或者等于前一帧的时间戳，因此编码器编码时就不会触发丢帧逻辑，而是对候选直播视频流中的所有视频帧都会编码，即保证了候选直播视频流在编码时不再被丢帧，进而可以保证转码后视频的流畅度。

为了便于理解，基于图6实施例，参阅图7，图7为本申请实施例提供的另一种基于候选直播视频流中的视频帧对应的第一时间戳，对候选直播视频流进行编码的示意图。如图7所示，图7以候选直播视频流为直播源视频流为例进行说明，即第一帧率小于预设帧率，假设第一帧率为20，图7示出的直播源视频流中视频帧的初始PTS与图1实施例相同，依次为：0、50、75、100、150、150、175、200、175；然后转码过程中的编码器也需要对这些视频帧进行编码，在编码时需要依次执行图8中虚线框中的步骤，首先是对初始PTS转换为第一时间戳，依次为：0、50、75、100、150、150、175、200、175，其中，转换原理参照上述第一时间戳的确定原理，此处不再赘述；然后对视频帧的第一时间戳进行修正，得到视频帧的第二时间戳，依次为：0、50、75、100、150、200、250、300、350，其中，此处的修正原理可以参照上述确定第二时间戳的原理，不再赘述；从视频帧的第二时间戳来看，是呈现递增的情形，不存在后一帧的第二时间戳小于或者等于前一帧的第二时间戳的情况，所以编码器在编码时不会对直播源视频流进行丢帧，即保证直播源视频流在转码之前和转码之后的视频帧的帧数是相同的，进而可以保证转码后的直播视频流的流畅度，因为这种情况下直播源视频流的第一帧率本就小于预设帧率了，所以解码带宽可以满足该第一帧率，所以这种情况下就需要尽可能地保证直播源视频流在转码时不被丢帧，如果像编码器所执行图1实施例中虚线框中的步骤，转码时会再继续丢帧或者错误丢帧，会使得直播源视频流的帧率变得更低，进而不能保证转码后视频的流畅度，而编码器执行图7实施例中虚线框中的步骤的可以避免这种问题出现。

当然，在本申请一种可选的实施例中，上述第一时间基准和第二时间基准也可以不同，若第一直播视频流对应的封装格式为FLV格式，则确定第一时间基准仍为1/1000，第二时间基准为候选直播视频流的帧率；则在基于第一时间基准、第二时间基准，对候选直播视频流中的视频帧的时间戳进行转换，得到候选直播视频流中的视频帧对应的第一时间戳方面，可以具体包括：基于第一时间基准、第二时间基准，对候选直播视频流中的视频帧的时间戳进行转换，得到候选直播视频流中的视频帧对应的第三时间戳，其中，确定第三时间戳的原理和上述确定第一时间戳的原理相同，此处不再赘述；然后对候选直播视频流中的视频帧对应的第三时间戳进行取整，得到候选直播视频流中的视频帧对应的第一时间戳。然后，在基于候选直播视频流中的视频帧对应的第一时间戳，对候选直播视频流进行编码，得到目标直播视频流方面，可以具体包括：针对第i个视频帧，当i＝1时，基于第1个视频帧对应的第一时间戳，确定第1个视频帧对应的第二时间戳；当i＞1时，基于第i个视频帧对应的第一时间戳和第i-1个视频帧对应的第二时间戳，确定第i个视频帧对应的第二时间戳，其中，第i个视频帧为候选直播视频流中的一个视频帧；其中，在基于第i个视频帧对应的第一时间戳和第i-1个视频帧对应的第二时间戳，确定第i个视频帧对应的第二时间戳方面，可以具体包括：若第i个视频帧对应的第一时间戳小于或者等于第i-1个视频帧对应的第二时间戳，则对第i-1个视频帧对应的第二时间戳执行加一操作，得到第i个视频帧对应的第二时间戳；若第i个视频帧对应的第一时间戳大于第i-1个视频帧对应的第二时间戳，则将基于第i个视频帧对应的第一时间戳确定为第i个视频帧对应的第二时间戳；最后，再基于候选直播视频流中的视频帧对应的第二时间戳，对候选直播视频流中的视频帧进行编码，得到目标直播视频流，此处不再赘述如何基于候选直播视频流中的视频帧对应的第二时间戳，对候选直播视频流中的视频帧进行编码的原理。

为了便于理解，参阅图8，图8为本申请实施例提供的又一种基于候选直播视频流中的视频帧对应的第一时间戳，对候选直播视频流进行编码的示意图。如图8所示，仍以候选直播视频流为直播源视频流(即第一帧率小于预设帧率)为例进行说明，图8示出的直播源视频流中的视频帧的初始PTS(即直播源视频流中视频帧的时间戳)与图1实施例相同，依次为：0、50、75、100、150、150、175、200、175；然后转码过程中的编码器也需要对这些视频帧进行编码，在编码时需要依次执行图8中虚线框中的步骤，首先是对视频帧的初始PTS进行转换，得到这些视频帧的第三时间戳依次为：0、1.0、1.5、2.0、3.0、3.0、3.5、4.0、3.5；然后对视频帧的第三时间戳取整，得到视频帧对应的第一时间戳依次为0、1、2、2、3、3、3、4、4；然后对视频帧的第一时间戳进行修正，得到视频帧的第二时间戳依次为：0、1、2、3、4、5、6、7、8，具体地，第1个视频帧的第二时间戳为第1个视频帧的第一时间戳(即0)，然后确定第i个视频帧的第一时间戳是否小于或者等于第i-1个视频帧的第二时间戳，若是，则将第i-1个视频帧的第二时间戳加一，得到第i个视频帧的第二时间戳，若都，则将第i个视频帧的第一时间戳，确定为第i个视频帧的第二时间戳，从图8可知，第2个视频帧的第一时间戳(即1)大于第1个视频帧的第二时间戳(即0)，则第2个视频帧的第二时间戳为1，以及第3个视频帧的第一时间戳(即2)大于第2个视频帧的第二时间戳(即1)，则第3个视频帧的第二时间戳为2，以及第4个视频帧的第一时间戳(即2)等于第3个视频帧的第二时间戳(即2)，则第4个视频帧的第二时间戳为第3个视频帧的第二时间戳加1(即3)，同理，后续第5个视频帧、第6个视频帧、第7个视频帧、第8个视频帧和第9个视频帧的第二时间戳的确定原理类似，此处不一一列举；可以看出，图8实施例中编码器所执行的虚线框中的步骤，即通过对第一时间戳进行修正，得到的第二时间戳是递增的，不存在后一帧的第二时间戳小于或者等于前一帧的第二时间戳的情况，因此编码器在依次对每一个视频帧进行编码时，不会触发对直播源视频流的丢帧逻辑，即保证直播源视频流在转码之前和转码之后的视频帧的帧数是相同的，进而可以保证转码后的直播视频流的流畅度，因为这种情况下直播源视频流的第一帧率本就小于预设帧率了，所以解码带宽可以满足该第一帧率，所以这种情况下就需要尽可能地保证直播源视频流在转码时不被丢帧，如果转码时再继续丢帧或者错误丢帧，会使得直播源视频流的帧率变得更低，进而不能保证转码后视频的流畅度，而图8实施例中的方式也可以避免这种问题出现。

可以看出，在本申请实施例中，在获取第一直播视频流后，对第一直播视频流进行解码，得到直播源视频流；然后基于直播源视频流的第一帧率和预设帧率的关系，以及第一直播视频流对应的封装格式，对直播源视频流进行编码，得到目标直播视频流，其中，预设帧率可以理解为播放端的解码能力所允许的最大帧率且该帧率下对应的视频流畅度相比于高帧率的原直播视频流，对用户而言肉眼上不会存在流畅度降低的情形，即若直播源视频流的第一帧率小于预设帧率，则最终编码得到的目标直播视频流的帧率等于第一帧率，也就是说这种情况下，基于第一直播视频流对应的封装格式对直播源视频流进行编码得到的视频的帧率与直播源视频流的帧率保持一致，没有降低对直播源视频流的帧率，进而没有降低直播源视频流的流畅度；同理，若直播源视频流的第一帧率大于预设帧率，则最终编码得到的目标直播视频流的帧率小于或等于预设帧率，也就是说这种情况下，先对直播源视频流进行降帧率，比如降到预设帧率或者小于预设帧率，然后再基于第一直播视频流对应的封装格式对降帧率后的直播视频流进行编码，使得最终编码得到的目标直播视频流的帧率与降帧率后的直播视频流的帧率保持一致，即将直播源视频流的帧率降低到肉眼所不能发现流畅度变化的帧率，同时也降低了播放端的解码带宽压力，进而基于第一直播视频流对应的封装格式，保证在编码过程中对已经降了帧率的直播视频流的帧率不再继续降低，进而保障直播视频流的流畅度。

参阅图9，图9为本申请实施例提供的一种服务器的功能单元组成框图。服务器900包括：获取单元901和处理单元902；

获取单元901，用于获取第一直播视频流；

处理单元902，用于对第一直播视频流进行解码，得到直播源视频流；

处理单元902，还用于基于第一直播视频流对应的封装格式、预设帧率、直播源视频流的第一帧率，对直播源视频流进行编码，得到目标直播视频流，其中，若第一帧率小于预设帧率，目标直播视频流的帧率等于第一帧率，若第一帧率大于预设帧率，目标直播视频流的帧率小于或等于预设帧率。

在本申请的一个实施方式中，在基于第一直播视频流对应的封装格式、预设帧率、直播源视频流的第一帧率，对直播源视频流进行编码，得到目标直播视频流方面，处理单元902，具体用于：

若第一帧率大于预设帧率，基于直播源视频流中的视频帧的时间戳，对直播源视频流进行丢帧，得到第二直播视频流，其中，第二直播视频流的帧率小于或者等于预设帧率；

基于第一直播视频流对应的封装格式、第二直播视频流中的视频帧的时间戳，对第二直播视频流进行编码操作，得到目标直播视频流；

若第一帧率小于预设帧率，基于第一直播视频流对应的封装格式、直播源视频流中的视频帧的时间戳，对直播源视频流进行编码操作，得到目标直播视频流。

在本申请的一个实施方式中，处理单元902，具体用于执行编码操作，该编码操作包括：

基于第一直播视频流对应的封装格式，确定第一时间基准和第二时间基准，其中，第一时间基准表示编码器对候选直播视频流编码为目标直播视频流所使用的时间格式，第二时间基准表示编码器对直播源视频流编码为第一直播视频流所使用的时间格式，候选直播视频流为直播源视频流或者第二直播视频流；

基于第一时间基准、第二时间基准，对候选直播视频流中的视频帧的时间戳进行转换，得到候选直播视频流中的视频帧对应的第一时间戳；

基于候选直播视频流中的视频帧对应的第一时间戳，对候选直播视频流进行编码，得到目标直播视频流。

在本申请的一个实施方式中，在基于候选直播视频流中的视频帧对应的第一时间戳，对候选直播视频流进行编码，得到目标直播视频流方面，处理单元902，具体用于：

针对候选直播视频流中的第i个视频帧，基于第i个视频帧对应的第一时间戳和第i-1个视频帧对应的第二时间戳，确定第i个视频帧对应的第二时间戳；

基于候选直播视频流中的视频帧对应的第二时间戳，对候选直播视频流中的视频帧进行编码，得到目标直播视频流。

在本申请的一个实施方式中，若第一时间基准和第二时间基准相同，在基于第i个视频帧对应的第一时间戳和第i-1个视频帧对应的第二时间戳，确定第i个视频帧对应的第二时间戳方面，处理单元902，具体用于：

基于候选直播视频流的帧率，确定候选直播视频流中的相邻视频帧对应的第一时间间隔；

若第i个视频帧对应的第一时间戳小于或者等于第i-1个视频帧对应的第二时间戳，基于第i-1个视频帧对应的第二时间戳和第一时间间隔，确定第i个视频帧对应的第二时间戳；

若第i个视频帧对应的第一时间戳大于第i-1个视频帧对应的第二时间戳，基于第i个视频帧对应的第一时间戳，确定第i个视频帧对应的第二时间戳。

在本申请的一个实施方式中，在基于直播源视频流中的视频帧的时间戳，对直播源视频流进行丢帧，得到第二直播视频流方面，处理单元902，具体用于：

基于第一帧率和预设帧率，确定目标丢帧数；

确定直播源视频流中相邻视频帧的差值，其中，相邻视频帧的差值为相邻视频帧中两个视频帧的时间戳之间的差值；

基于目标丢帧数、相邻视频帧的差值，对直播源视频流进行丢帧，得到第二直播视频流。

在本申请的一个实施方式中，在基于目标丢帧数、相邻视频帧的差值，对直播源视频流进行丢帧，得到第二直播视频流方面，处理单元902，具体用于：

若直播源视频流中任意两个相邻视频帧对应的差值相同，对直播源视频流进行间隔丢帧，直至丢帧数等于目标丢帧数，得到第二直播视频流；

若直播源视频流中任意两个相邻视频帧对应的差值不同，基于目标丢帧数，确定第二直播视频流中的相邻视频帧对应的第二时间间隔；

从直播源视频流中的第二个视频帧开始遍历，确定直播源视频流中的第Z个视频帧的时间戳与第一视频帧的时间戳的第一差值，其中，第一视频帧为直播源视频流中未被丢掉的视频帧中第Z个视频帧的上一帧，Z＞1；

若第一差值小于第二时间间隔，丢掉第Z个视频帧，直至丢帧数达到目标丢帧数，得到第二直播视频流。

具体实现中，本发明实施例中所描述的获取单元901和处理单元902可执行本发明实施例提供的直播视频流转码方法的实施例中所描述的其他实现方式，在此不再赘述。

参阅图10，图10为本申请实施例提供的一种电子设备的结构示意图。如图10所示，电子设备1000包括收发器1001、处理器1002和存储器1003。它们之间通过总线1004连接。存储器1003用于存储计算机程序和数据，并可以将存储器1003存储的数据传输给处理器1002。

处理器1002用于读取存储器1003中的计算机程序执行以下操作：

控制收发器1001获取第一直播视频流；

对第一直播视频流进行解码，得到直播源视频流；

基于第一直播视频流对应的封装格式、预设帧率、直播源视频流的第一帧率，对直播源视频流进行编码，得到目标直播视频流，其中，若第一帧率小于预设帧率，目标直播视频流的帧率等于第一帧率，若第一帧率大于预设帧率，目标直播视频流的帧率小于或等于预设帧率。

在本申请的一个实施方式中，在基于第一直播视频流对应的封装格式、预设帧率、直播源视频流的第一帧率，对直播源视频流进行编码，得到目标直播视频流方面，处理器1002，具体用于执行以下步骤：

若第一帧率大于预设帧率，基于直播源视频流中的视频帧的时间戳，对直播源视频流进行丢帧，得到第二直播视频流，其中，第二直播视频流的帧率小于或者等于预设帧率；

基于第一直播视频流对应的封装格式、第二直播视频流中的视频帧的时间戳，对第二直播视频流进行编码操作，得到目标直播视频流；

若第一帧率小于预设帧率，基于第一直播视频流对应的封装格式、直播源视频流中的视频帧的时间戳，对直播源视频流进行编码操作，得到目标直播视频流。

在本申请的一个实施方式中，处理器1002，具体用于执行编码操作，该编码操作包括以下步骤：

基于第一直播视频流对应的封装格式，确定第一时间基准和第二时间基准，其中，第一时间基准表示编码器对候选直播视频流编码为目标直播视频流所使用的时间格式，第二时间基准表示编码器对直播源视频流编码为第一直播视频流所使用的时间格式，候选直播视频流为直播源视频流或者第二直播视频流；

基于第一时间基准、第二时间基准，对候选直播视频流中的视频帧的时间戳进行转换，得到候选直播视频流中的视频帧对应的第一时间戳；

基于候选直播视频流中的视频帧对应的第一时间戳，对候选直播视频流进行编码，得到目标直播视频流。

在本申请的一个实施方式中，在基于候选直播视频流中的视频帧对应的第一时间戳，对候选直播视频流进行编码，得到目标直播视频流方面，处理器1002，具体用于执行以下步骤：

针对候选直播视频流中的第i个视频帧，基于第i个视频帧对应的第一时间戳和第i-1个视频帧对应的第二时间戳，确定第i个视频帧对应的第二时间戳；

基于候选直播视频流中的视频帧对应的第二时间戳，对候选直播视频流中的视频帧进行编码，得到目标直播视频流。

在本申请的一个实施方式中，若第一时间基准和第二时间基准相同，在基于第i个视频帧对应的第一时间戳和第i-1个视频帧对应的第二时间戳，确定第i个视频帧对应的第二时间戳方面，处理器1002，具体用于执行以下步骤：

基于候选直播视频流的帧率，确定候选直播视频流中的相邻视频帧对应的第一时间间隔；

若第i个视频帧对应的第一时间戳小于或者等于第i-1个视频帧对应的第二时间戳，基于第i-1个视频帧对应的第二时间戳和第一时间间隔，确定第i个视频帧对应的第二时间戳；

若第i个视频帧对应的第一时间戳大于第i-1个视频帧对应的第二时间戳，基于第i个视频帧对应的第一时间戳，确定第i个视频帧对应的第二时间戳。

在本申请的一个实施方式中，在基于直播源视频流中的视频帧的时间戳，对直播源视频流进行丢帧，得到第二直播视频流方面，处理器1002，具体用于执行以下步骤：

基于第一帧率和预设帧率，确定目标丢帧数；

确定直播源视频流中相邻视频帧的差值，其中，相邻视频帧的差值为相邻视频帧中两个视频帧的时间戳之间的差值；

基于目标丢帧数、相邻视频帧的差值，对直播源视频流进行丢帧，得到第二直播视频流。

在本申请的一个实施方式中，在基于目标丢帧数、相邻视频帧的差值，对直播源视频流进行丢帧，得到第二直播视频流方面，处理器1002，具体用于执行以下步骤：

若直播源视频流中任意两个相邻视频帧对应的差值相同，对直播源视频流进行间隔丢帧，直至丢帧数等于目标丢帧数，得到第二直播视频流；

若直播源视频流中任意两个相邻视频帧对应的差值不同，基于目标丢帧数，确定第二直播视频流中的相邻视频帧对应的第二时间间隔；

从直播源视频流中的第二个视频帧开始遍历，确定直播源视频流中的第Z个视频帧的时间戳与第一视频帧的时间戳的第一差值，其中，第一视频帧为直播源视频流中未被丢掉的视频帧中第Z个视频帧的上一帧，Z＞1；

若第一差值小于第二时间间隔，丢掉第Z个视频帧，直至丢帧数达到目标丢帧数，得到第二直播视频流。

具体地，上述收发器1001可为图9的实施例的服务器900的获取单元901，上述处理器1002可以为图9的实施例的服务器900的处理单元902。

具体实现中，本发明实施例中所描述的收发器1001、处理器1002还可执行本发明实施例提供的直播视频流转码方法的实施例所描述的其他实现方式，在此不再赘述。

应理解，本申请的电子设备可以包括云计算服务器、内容分发网络(ContentDelivery Network，CDN)服务器、网络时间协议(Network Time Protocol，NTP)、域名解析系统(Domain Name System，DNS)服务器，等其他各种类型的服务器。上述服务器仅是举例，而非穷举，包含但不限于上述服务器。

应理解，本申请实施例还提供一种计算机可读存储介质，计算机可读存储介质存储有计算机程序，计算机程序被处理器执行以实现如上述方法实施例中记载的任何一种直播视频流转码方法的部分或全部步骤。

本申请实施例还提供一种计算机程序产品，计算机程序产品包括存储了计算机程序的非瞬时性计算机可读存储介质，计算机程序可操作来使计算机执行如上述方法实施例中记载的任何一种直播视频流转码方法的部分或全部步骤。

需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请并不受所描述的动作顺序的限制，因为依据本申请，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于可选实施例，所涉及的动作和模块并不一定是本申请所必须的。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

在本申请所提供的几个实施例中，应该理解到，所揭露的装置，可通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性或其它的形式。

作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件程序模块的形式实现。

集成的单元如果以软件程序模块的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储器中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储器中，包括若干指令用以使得一台计算机设备(可为个人计算机、服务器或者网络设备等)执行本申请各个实施例方法的全部或部分步骤。而前述的存储器包括：U盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，RandomAccess Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

本领域普通技术人员可以理解上述实施例的各种方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序可以存储于一计算机可读存储器中，存储器可以包括：闪存盘、只读存储器(英文：Read-Only Memory，简称：ROM)、随机存取器(英文：Random Access Memory，简称：RAM)、磁盘或光盘等。

以上对本申请实施例进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上，本说明书内容不应理解为对本申请的限制。

Claims (10)

1.一种直播视频流转码方法，其特征在于，所述方法包括：

获取第一直播视频流；

对所述第一直播视频流进行解码，得到直播源视频流；

基于所述第一直播视频流对应的封装格式、预设帧率、所述直播源视频流的第一帧率，对所述直播源视频流进行编码，得到目标直播视频流，其中，若所述第一帧率小于所述预设帧率，所述目标直播视频流的帧率等于所述第一帧率，若所述第一帧率大于所述预设帧率，所述目标直播视频流的帧率小于或等于所述预设帧率。

2.根据权利要求1所述的方法，其特征在于，所述基于所述第一直播视频流对应的封装格式、预设帧率、所述直播源视频流的第一帧率，对所述直播源视频流进行编码，得到目标直播视频流，包括：

若所述第一帧率大于所述预设帧率，基于所述直播源视频流中的视频帧的时间戳，对所述直播源视频流进行丢帧，得到第二直播视频流，其中，所述第二直播视频流的帧率小于或者等于所述预设帧率；

基于所述第一直播视频流对应的封装格式、所述第二直播视频流中的视频帧的时间戳，对所述第二直播视频流进行编码操作，得到所述目标直播视频流；

若所述第一帧率小于所述预设帧率，基于所述第一直播视频流对应的封装格式、所述直播源视频流中的视频帧的时间戳，对所述直播源视频流进行所述编码操作，得到所述目标直播视频流。

3.根据权利要求2所述的方法，其特征在于，所述编码操作，包括：

基于所述第一直播视频流对应的封装格式，确定第一时间基准和第二时间基准，其中，所述第一时间基准表示编码器对候选直播视频流编码为所述目标直播视频流所使用的时间格式，所述第二时间基准表示编码器对所述直播源视频流编码为所述第一直播视频流所使用的时间格式，所述候选直播视频流为所述直播源视频流或者所述第二直播视频流；

基于所述第一时间基准、所述第二时间基准，对所述候选直播视频流中的视频帧的时间戳进行转换，得到所述候选直播视频流中的视频帧对应的第一时间戳；

基于所述候选直播视频流中的视频帧对应的第一时间戳，对所述候选直播视频流进行编码，得到所述目标直播视频流。

4.根据权利要求3所述的方法，其特征在于，所述基于所述候选直播视频流中的视频帧对应的第一时间戳，对所述候选直播视频流进行编码，得到所述目标直播视频流，包括：

针对所述候选直播视频流中的第i个视频帧，基于第i个视频帧对应的第一时间戳和第i-1个视频帧对应的第二时间戳，确定第i个视频帧对应的第二时间戳；

基于所述候选直播视频流中的视频帧对应的第二时间戳，对所述候选直播视频流中的视频帧进行编码，得到所述目标直播视频流。

5.根据权利要求4所述的方法，其特征在于，若所述第一时间基准和所述第二时间基准相同，所述基于第i个视频帧对应的第一时间戳和第i-1个视频帧对应的第二时间戳，确定第i个视频帧对应的第二时间戳，包括：

基于所述候选直播视频流的帧率，确定所述候选直播视频流中的相邻视频帧对应的第一时间间隔；

若第i个视频帧对应的第一时间戳小于或者等于第i-1个视频帧对应的第二时间戳，基于所述第i-1个视频帧对应的第二时间戳和所述第一时间间隔，确定第i个视频帧对应的第二时间戳；

若第i个视频帧对应的第一时间戳大于第i-1个视频帧对应的第二时间戳，基于第i个视频帧对应的第一时间戳，确定第i个视频帧对应的第二时间戳。

6.根据权利要求2-5任一项所述的方法，其特征在于，所述基于所述直播源视频流中的视频帧的时间戳，对所述直播源视频流进行丢帧，得到第二直播视频流，包括：

基于所述第一帧率和所述预设帧率，确定目标丢帧数；

确定所述直播源视频流中相邻视频帧的差值，其中，所述相邻视频帧的差值为所述相邻视频帧中两个视频帧的时间戳之间的差值；

基于所述目标丢帧数、所述相邻视频帧的差值，对所述直播源视频流进行丢帧，得到所述第二直播视频流。

7.根据权利要求6所述的方法，其特征在于，所述基于所述目标丢帧数、所述相邻视频帧的差值，对所述直播源视频流进行丢帧，得到所述第二直播视频流，包括：

若所述直播源视频流中任意两个相邻视频帧对应的差值相同，对所述直播源视频流进行间隔丢帧，直至丢帧数等于所述目标丢帧数，得到所述第二直播视频流；

若所述直播源视频流中任意两个相邻视频帧对应的差值不同，基于所述目标丢帧数，确定所述第二直播视频流中的相邻视频帧对应的第二时间间隔；

从所述直播源视频流中的第二个视频帧开始遍历，确定所述直播源视频流中的第Z个视频帧的时间戳与第一视频帧的时间戳的第一差值，其中，所述第一视频帧为所述直播源视频流中未被丢掉的视频帧中所述第Z个视频帧的上一帧，Z＞1；

若所述第一差值小于所述第二时间间隔，丢掉所述第Z个视频帧，直至丢帧数达到所述目标丢帧数，得到所述第二直播视频流。

8.一种服务器，其特征在于，所述服务器包括：获取单元和处理单元；

所述获取单元，用于获取第一直播视频流；

所述处理单元，用于对所述第一直播视频流进行解码，得到直播源视频流；

所述处理单元，还用于基于所述第一直播视频流对应的封装格式、预设帧率、所述直播源视频流的第一帧率，对所述直播源视频流进行编码，得到目标直播视频流，其中，若所述第一帧率小于所述预设帧率，所述目标直播视频流的帧率等于所述第一帧率，若所述第一帧率大于所述预设帧率，所述目标直播视频流的帧率小于或等于所述预设帧率。

9.一种电子设备，其特征在于，包括：处理器和存储器，所述处理器与所述存储器相连，所述存储器用于存储计算机程序，所述处理器用于执行所述存储器中存储的计算机程序，以使得所述电子设备执行如权利要求1-7中任一项所述的方法。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行以实现如权利要求1-7中任一项所述的方法。