CN105657448A - 一种编码视频流的转发方法、装置及系统 - Google Patents

Abstract

本发明提供一种编码视频流转发方法，包括：1)接收至少一路原始编码视频流，对所述原始编码视频流进行实时解码得到原始图像序列；2)接收客户端对所述视频流中一个视频流的请求；3)对客户端所请求的视频流所对应的原始图像序列进行帧内编码，并利用帧内编码的图像帧构建视频流头部，然后将所述视频流头部发送给所述客户端，然后向该客户端转发该客户端所请求的视频流所对应的原始编码视频流。本发明还提供了相应的编码视频流转发装置和系统。本发明既能够保留原始的大GOP编码视频流编解码复杂度低、延迟小、码率小的优势，又能够抑制视频流切换时的非正常显示现象，显著提高用户体验。

Description

一种编码视频流的转发方法、装置及系统

技术领域

本发明涉及视频编码技术领域和视频传输技术领域，具体地说，本发明涉及一种编码视频流的转发方法、装置及系统。

背景技术

H.264/AVC是当今比较主流的视频编码方式，在2005年3月份正式发布。它具有比较优秀的压缩性能，广泛应用于广电、网络视频、监控等各个领域。不同于传统的H.264视频编码方式，一些新的应用场景中，在进行视频编码的时候会采取一种比较特殊的编码策略，即大GOP编码策略。例如纯P帧视频流，这种视频流中采用帧内编码的方式帧非常稀少，每隔120个帧才会有一个恢复点。大GOP编码策略主要具有两点优势：首先，可以降低编解码的复杂度，进而降低编解码所需要花费的时延，目前采用纯P帧编码方式可以达到业界最小的仅为1帧(约40ms)的延迟。其次，可以使得生成的流的码率变小(相同的画质下，一个P帧在码流中的大小大约为I帧的1/5，B帧则更小)。然而，大GOP编码策略也存在比较明显的缺点：在用户对视频流进行随机访问或进行视频切换时，解码过程是从视频流中随机的任意一点开始的，当所要访问或切换至的视频流的GOP较大且GOP中的大多帧采用P帧或B帧编码时，解码过程开始后的很长一段时间内往往都是P帧或B帧，导致用户端因缺乏准确参考图像而无法正常解码和显示，这会带给用户较差的体验。尤其是切换视频流较为频繁的应用场合，上述缺陷将变得更难以容忍。

发明内容

因此，本发明的任务是提供一种能够克服现有技术的上述缺陷的解决方案。

本发明提供了一种编码视频流转发方法，包括下列步骤：

1)接收至少一路原始编码视频流，对所述原始编码视频流进行实时解码得到原始图像序列；

2)接收客户端对所述视频流中一个视频流的请求；

3)对客户端所请求的视频流所对应的原始图像序列进行帧内编码，并利用帧内编码的图像帧构建视频流头部，然后将所述视频流头部发送给所述客户端，然后向该客户端转发该客户端所请求的视频流所对应的原始编码视频流。

其中，所述步骤1)中，所接收的原始编码视频流至少包括第一视频流和第二视频流，其中第一视频流直接转发给客户端；

所述步骤2)中，客户端对视频流的请求是从第一视频流切换到第二视频流的切换请求；

所述步骤3)还包括：停止转发步骤1)中向客户端直接转发的第一视频流。

其中，所述步骤2)中，客户端对视频流的请求是初次请求，之前未向该客户端转发原始编码视频流。

其中，所述步骤1)还包括：对所述第二视频流进行实时解包和解码，提取第二视频流中的参数；

所述步骤3)中，根据步骤1)所提取的参数构建第二视频流的头部，使所述头部与后续的第二视频流无缝拼接。

其中，所述原始编码视频流为TS流，所述步骤3)中，根据步骤1)所提取的参数构建视频流头部时，在TS流，PES流和ES流层面均实现无缝拼接。

其中，所述步骤3)中，在TS流层面实现无缝拼接的方法是：构建视频流头部时，使得所构建的视频流头部的PID信息和计数戳与后续的原始编码视频流保持前后一致。

其中，所述步骤3)中，在PES流层面实现无缝拼接的方法是：构建视频流头部时，使得所构建的视频流头部的PTS和DTS参数与后续的原始编码视频流连续。

其中，所述步骤1)中，从原始编码视频流中所提取的参数包括SPS和PPS参数信息；

所述步骤3)中，在ES流层面实现无缝拼接的方法包括：根据步骤1)所获取的SPS和PPS参数信息对编码器进行重新配置，使得编码器能够按照原始流中的SPS和PPS参数进行编码，生成可以独立解码的I帧，并利用所生成的I帧构建视频流头部，视频流头部的SPS参数与原始编码视频流的SPS参数保持一致；还将最新的PPS参数添加到后续的原始编码视频流的第一个P帧的条带头之前。

其中，所述步骤3)中，在ES流层面实现无缝拼接的方法还包括：在读取原始TS流的包的同时，解析原始流中所包含的条带头中的参数，并根据这些参数，修改编码器的相应参数的初始状态，使得从转发服务器的编码器中输出的视频流头部的条带头中的参数与原始编码视频流保持连贯性。

其中，所述步骤1)和3)中，采用软件编解码技术，所述步骤3)中，计算编解码延时，并对所构建的视频流头部的PTS和DTS参数进行延时补偿，构建视频流头部时使用延时补偿后的PTS和DTS参数。

本发明还提供了一种编码视频流转发装置，包括：

视频流接收单元，用于接收至少一路原始编码视频流并对原始编码视频流进行实时解码得到原始图像序列；

请求接收单元，用于接收客户端对视频流的请求；以及

转发单元，用于对客户端所请求的视频流所对应的原始图像序列进行帧内编码，并利用帧内编码的图像帧构建视频流头部，然后将所述视频流头部发送给所述客户端，然后向该客户端转发该客户端所请求的视频流所对应的原始编码视频流。

本发明还提供了一种编码视频流转发系统，包括至少一路原始编码视频流和至少一个客户端，其特征在于，所述编码视频流转发系统还包括视频流转发服务器，所述视频流转发服务器用于接收所述的至少一路原始编码视频流，以及根据所述客户端所请求的原始编码视频流重构含有采用帧内编码的图像帧的视频流头部，再将视频流头部与所请求的原始编码视频流拼接后发送给相应的客户端；

所述客户端用于向所述视频流转发服务器请求视频流，并对所接收到的视频流进行解码。

其中，所述视频流转发服务器还用于：在同一时刻，对所接收的每一路原始编码视频流，按下述三种模式之一进行处理：模式一，对输入的原始编码视频流进行解包和解码，生成原始图像序列；模式二，仅仅对原始编码视频流进行简单地转发；模式三，对原始图像序列进行帧内编码和重新打包形成所述视频流头部，并在发送所述视频头后恢复对原始编码视频流的转发；并且，对于同一路原始编码视频流，处理模式可以在上述模式一，模式二和模式三之间转换。

与现有技术相比，本发明具有下列技术效果：

1、本发明既能够保留原始的大GOP编码视频流编解码复杂度低、延迟小、码率小的优势，又能够抑制视频流切换时的非正常显示现象，显著提高用户体验。

2、本发明不需要更换视频终端的解码器，成本低廉。

3、本发明能够呈现原视频流的画质效果。

4、本发明特别适合于视频会议等需要频繁切换视频流的应用场合。

5、本发明采用软件的方式实现视频之间的流畅切换，可以代替成本高昂的硬件切换台。

附图说明

以下，结合附图来详细说明本发明的实施例，其中：

图1(a)示出了根据本发明一个实施例的基于大GOP编码策略的视频流转发系统

图1(b)示出了现有技术中一种视频流传输系统；

图2示出了本发明一个实施例中利用转发服务器实现基于大GOP编码策略的视频流的快速切换过程的流程图；

图3示出了本发明一个实施例中视频流切换前的工作状态示意图；

图4示出了本发明一个实施例中视频流切换第一阶段的工作状态示意图；

图5示出了本发明一个实施例中视频流切换第二阶段的工作状态示意图；

图6示出了本发明一个实施例中视频流切换完成后的工作状态示意图；

图7示出了本发明一个实施例中的视频流的状态一、状态二和状态三之间的转换示意图；

图8示出了本发明一个实施例中的转发服务器的一个构架实例；

图9示出了本发明一个实施例中在原始流输出的第一个P帧条带头之前加上SPS与PPS参数集的流程；

图10示出了在读包和写包过程中造成PES/DTS异常的主要原因；

图11示出了本发明一个实施例中，读包过程中对PTS与DTS处理的流程；

图12示出了本发明另一个实施例中，在读写包过程中实现PTS与DTS的调整的流程；

图13示出了本发明一个实施例中顶层软件处理层对延迟编码下最后几帧的PTS与DTS的处理流程。

具体实施方式

首先，为便于理解，对本发明所涉及的H.264/AVC协议以及传输流层面中的各个技术术语进行解释。

参考图像：参考图像包含可用于对解码顺序上后续图像的解码过程进行帧间预测的样点。

I帧:采用帧内编码的方式编码的帧，解码时，只需要根据本身的数据包信息就可以解出完整的图像。

IDR帧:与I帧类似，唯一的区别是当解码器收到IDR帧后，会进行初始化操作。

P帧：采用帧间编码的方式编码的帧，在解码的时候需要根据前面已解码帧保留下的一个参考图像序列进行解码，如果没有参考图像，将无法进行正常解码。

B帧：采用帧间编码的方式编码的帧，与P帧不同的是，B帧采用两个参考图像序列进行解码。

场：在采用隔行扫描方式进行播放的设备中，每一帧画面都会被拆分开进行显示，而拆分后得到的残缺画面就称为“场”，一帧画面内首先显示的场被称为“顶场”而组成该帧画面的另一场被称为“底场”。

编码场:一个场的编码表示。

PAFF:传统的场编码方式。

MBAFF(macro-blockadaptivefieldframe):是H.264引入的新的编码特性之一。它根据图像各部分特性，确定部分图像以场方式编码，另一部分图像以帧方式编码。

NAL(networkaddressinglayer):网络提取层。

VCL(videocodinglayer):视频编码层。

GOP(groupofpicture)：一组可以连续解码的图像组。

SPS(sequenceparameterset)：序列参数集。

PPS(pictureparameterset)：图像参数集。

SEI(supplementalenhancementinformation)：补充的增强信息。

QP：量化系数。

恢复点：包含在SEI包中，表示随机访问或断裂链接之后从此处解码器可以得到一个该比特流所表示的精确或大致的解码图像。

PTS(presentationtimestamp)：呈现时间标记。

DTS(decodetimestamp)：解码时间标记。

PCR(programclockreference)：节目时钟基准。

YUV格式:是被欧洲电视系统所采用的一种颜色编码方法，属于没有编码过的视频原始图像数据。

TS(transportstream)流:将具有共同时间基准或者具有独立时间基准的一个或者多个PES组成的单一数据流，可采用多种传输协议进行数据传送。

PES(packetizedelementarystream)流:将ES流进行打包后的流。

ES(elementarystream)流:由MPEG通信协议定义，通常为从音频、视频编码器直接产生的码流。

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用于解释本发明，并不用于限定本发明。

图1(a)示出了根据本发明一个实施例的基于大GOP编码策略的视频流转发系统，它包括视频流发送源，转发服务器和客户端。其中，视频流发送源用于发送基于大GOP编码策略的视频流(为方便描述，下文中简称编码视频流)，客户端用于接收编码视频流并将其解码和显示。视频流发送源可以有一个或多个，客户端也可以有一个或多个。本实施例的特点是在视频流发送源与客户端之间增设了转发服务器。本实施例中，转发服务器可以是设置在云端的独立的服务器，也可以在通用的云端服务器中以云端软件的方式实现。该转发服务器用于对基于大GOP编码策略的视频流进行重构，使得客户端的解码器可以从重构后的视频流的任意一个断点开始正常解码，并且显示正常的图像。这样，在客户端对视频流进行随机访问或进行视频切换时，能够以极小的延迟得到正常显示的图像。作为对比，图1(b)示出了现有技术中一种视频流传输系统，其中视频流发送源通过网络将编码视频流传输至请求该路视频流的客户端，可以看出，其视频流发送源与客户端之间没有设置用于减少随机访问视频流或切换视频流的所造成延迟的转发服务器。

概括而言，本实施例中，为实现基于大GOP编码策略的视频流的快速重构，转发服务器根据原始流中的参数计算出所需要的参考图像；通过软件编码将这些需要的参考帧重新编码成可以独立解码的I帧；通过调整编码器出来的码流参数，使得这些I帧经过解码器解码后可以进入到解码器的DPB(DecodedPictureBuffer)中作为参考图像；解码器可以把这些I帧解码出的图像作为参考图像，根据这些参考图像对原始流中的P帧，B帧进行正常的解码，并且显示正确的图像。

为便于理解，图2示出了本发明一个实施例中实现基于大GOP编码策略的视频流的快速切换过程的流程图，图3～6示出了视频流的快速切换过程中各个阶段下的不同工作状态的示意图。图2～6中，转发服务器用于转发流I与流II。流I与流II都是由视频流发送源的编码器输出的原始TS流，通过转发服务器处理后将指定的流发送到相应客户端的解码器进行解码。

下面将参考图2，根据本发明的一个实施例，对基于大GOP编码策略的视频流的快速切换方法进行描述，其包括下列步骤：

步骤1：输入流I与流II，直接将流I转发给客户端，同时对流II进行实时解码，得到流II所对应的未压缩图像序列II。本步骤中，所缓存的未压缩图像序列II的长度预先设置，例如其长度可以为三，也就是说，在解码后缓存未压缩图像序列II中最新的三个未压缩图像即可。此时，客户端正常解码并显示流I。本步骤可看作视频流切换前的工作状态，图3示出了本实施例的视频流切换前的工作状态示意图。

步骤2：在接收客户端请求切换至流II的请求后，阻塞向客户端发送的流I，同时对步骤1所缓存的当前的未压缩图像序列II重新进行编码，生成能够作为解码参考图像的若干个(例如三个)I帧，并将其打包成TS流的数据包。本步骤可看作视频流切换第一阶段，图4示出了本实施例的视频流切换第一阶段的工作状态示意图。需要说明的是，在另一实施例中，前面的步骤1中，未压缩图像序列II也可以仅缓存一帧，仅缓存当前最新的一帧未压缩图像，此时可以减少所需的缓存空间，但是在步骤2进行重编码时也会相应地增加两帧的延迟。

步骤3：将重编码的TS流数据包构造成流头,并将该流头发送至客户端。将原始流解码再重编码的过程即为重构过程，本步骤中的流头可看作重构的流II的流头。本步骤可看作视频流切换第二阶段，图5示出了本实施例的视频流切换第二阶段的工作状态示意图。

步骤4：将所接收的流II直接转发至客户端。客服端接收并解码流II。由于在先发送的重构的流II的流头中含有能够独立解码的I帧，所以客户端能够以这些I帧解码后的图像作为参考图像，对后续接收的流II进行解码。另外，本步骤中，开始对流I进行解码，以备下一次切换。同时停止对流II的解码，以节省开销。本步骤可看作视频流切换完成状态，图6示出了本实施例的视频流切换完成后的工作状态示意图。

图3～6所示的场景中只涉及流I和流II的转发，当需要转发的视频流超出两路时，可以对其进行分类，一类为正在转发的视频流，这类视频流均按流I的方式处理，另一类为待转发的视频流，这类视频流均按流II的方式处理。例如，当需要转发的流的数目为三路时，在视频流切换前，流I被直接转发至客户端，同时对流II和流Ⅲ进行实时解码，分别得到所对应的未压缩图像序列II和Ⅲ。如果客户端请求切换至流II，则在视频流切换的第一阶段，第二阶段以及完成后，流I和流II仍按图4～6所示的方式处理，而流Ⅲ保持不变，即保持对流Ⅲ的解码并实时得到所对应的未压缩图像序列Ⅲ，以备客户端的下一次切换请求。

进一步地，为实现图2所示的快速切换过程，在一个实施例中，从输入流的角度看，对每一路流的处理均设置三个状态(即三个处理模式)，分别是：状态一，对输入的流进行解包和解码，并且生成原始图像序列，这个状态将保持下去直到收到触发信号，在收到触发切换的信号时进入状态三；状态二，仅仅对原始流进行简单地转发，这个状态将保持直到收到触发信号进入状态一；状态三，对原始图像进行编码和重新打包，并且恢复原始流(即输入的流)传输，这个状态下实现了从编码视频流任意点开始进行解码。图7示出了视频流的状态一、状态二和状态三之间的转换示意图。其中，状态一、状态二是稳态，状态三实现对原始流的重构和拼接，是暂态。分别控制各路视频流在上述状态一、状态二和状态三之间切换，即可实现对任意一路视频流的转发，并且能够使得客户端从发出视频流请求到该客户端接收并正常解码该路视频流之间的延迟显著缩小，从而提升用户体验。

需要说明的是，上述实施例的视频流转发方案除了用于视频流切换场景外，还可用于客户端初次开启视频流的场景。在客户端请求视频流之前，转发服务器将所接收的所有视频流进行解码，当客户端请求其中某一路视频流时，转发服务器对该路视频流按上述流II的方式进行处理，即将实时解码流II得到的原始图像序列进行帧内编码，并利用帧内编码的图像帧构建视频流头部，然后将所述视频流头部发送给所述客户端，再紧接着转发客户端所请求的流II的原始编码视频流。客户端在接收到转发服务器传输的流头后即可直接解码，从而大大减少了从客户端发出视频流请求到客户端开始正常解码并输出视频之间的时间延迟，从而改善用户体验。

前述实施例的编码视频流转发系统及其视频流转发方法既能够保留原始的大GOP编码视频流编解码复杂度低、延迟小、码率小的优势，又能够抑制视频流切换时的非正常显示现象，显著提高用户体验，特别适合于视频会议等需要频繁切换视频流的应用场合。并且，前述编码视频流转发系统不需要更换视频终端的解码器，成本低廉，可以代替成本高昂的硬件切换台。再者，前述实施例的编码视频流转发系统及其视频流转发方法能够呈现原视频流的画质效果。

进一步地，下文中以图1(a)所示的视频流转发系统和TS视频流为例，说明如何重构视频流的流头并实现与原始编码视频流的无缝拼接。

在一个实施例中，为重构视频流的流头与原始编码视频流的无缝拼接，所述步骤1中，在对原始编码视频流进行实时解包和解码，提取视频流中的参数；所述步骤3中，根据步骤1所提取的参数对构建视频流头部，使视频流头部与后续的原始编码视频流无缝拼接。

更进一步地，图8示出了本发明一个实施例中的转发服务器的一个构架实例的示意图，它在TS流、PES流、ES流层面上均实现了对原始编码视频流的重构与无缝拼接，从而保证了从转发服务器的编码器(由于该编码器处于云端，因此也可称为云端编码器)生成的TS流的流头与原始流具有连续性，使得重构后的流可以在客户端的解码器实现正常解码。参考图8，转发服务器的构架包括由上至下包括顶层软件处理层、TS流处理层、PES流处理层和ES流处理层。其中，顶层软件处理层用于实现图7示出的三种状态及状态间的转换，TS流处理层负责TS流层面的解包和打包，PES流处理层负责PES流层面的解包和打包，ES流处理层负责ES流层面的解码和编码。在解码过程中，编码视频流的数据包由各个层面由上至下依次进行处理，在编码过程中，当前解码出的原始图像由各个层面由下至上依次进行处理。其中，TS流处理层与文件、传输协议相关联，而最底层的ES流处理层与原始图像的编解码相关联，即ES流处理层的编码器对原始图像编码后得到ES流，ES流处理层的解码器对ES流解码后直接得到原始图像。

在一个实施例中，在TS流层面，转发服务器对原始TS流解包和重新打包，使得TS流的PID信息与计数戳保持前后一致。在PES流层面，使得转发服务器与部分流的格式兼容，保证编码器出来的流与原始编码视频流在PTS与DTS参数连续。在ES流层面，转发服务器在读取原始TS流的包时，同时可以解析出原始TS流中的SPS，PPS参数，利用获取的SPS，PPS参数信息对转发服务器的编码器进行重新配置，使得编码器能够按照原始流中的SPS，PPS参数进行编码，生成可以独立解码的I帧，这里值得注意的是，重新编码的视频流的SPS参数与原始编码视频流的SPS参数保持一致，从而避免解码器判定前后两个流为不同流，启动初始化过程，导致拼接失败。另外，转发服务器在读取原始TS流的包的同时，解析原始流中所包含的条带头中的参数，并根据这些参数，修改编码器的部分参数的初始状态，使得从转发服务器的编码器中出来的流头的这两个参数与原始流保持连贯性。再者，转发服务器还将最新的PPS参数添加到恢复输出流(指在重构的流头之后直接转发的原始流)的第一个P帧的条带头之前。

此外，由于转发服务器在解码时会产生一帧的延迟时间，编码时会产生4帧的延迟时间，因此，在一个优选实施例中，顶层软件处理层还用于进行转发服务器的编解码延迟补偿，使得解码和编码时不会发生丢帧现象。延迟补偿的具体方案是本领域技术人员公知的，此处不再赘述。

下面分别介绍ES流、PES流以及TS流层面重构连续性的实现方案的一些示例。

1、ES流层面的重构连续性实现的示例

在一个优选实施例中，为实现ES流层面的重构连续性，转发服务器执行下列步骤：

1.1原始流中SPS,PPS,frame_num,pic_order_cnt_lsb参数获取

在一个实施例中，首先创建一个结构体，该结构体用来存储SPS，PPS,frame_num,pic_order_cnt_lsb指针参数。由于SPS与PPS包需要从原始流中提取，所以还需要两个参数描述SPS与PPS包的大小，所以这个结构体中一共包含6个参数。这6个参数的含义具体如下：指向暂存SPS参数集的首地址的指针；SPS参数集的大小；指向PPS参数集的首地址的指针；PPS参数集的大小；当前条带头中的frame_num(具体含义参见h264协议7.4.3)；当前条带头中的pic_order_cnt_lsb(具体含义参见h264协议7.4.3)。在进行包解析的时候，nal_unit_type(参见h264协议7.3.1)等于7为SPS参数集或8为PPS参数集，按下述方法将指向该包首地址的指针和该包裹的大小保存下来。

在一个实施例中，通过在底层的解析H.264的视频流的函数从原始流中提取所需的SPS/PPS参数集。首先，设置一个指向当前包头的指针(这里不妨记为buf，指向一个8位的寄存器)和指明当前包的大小的整数(这里不妨记为consumed)；接着，找包的起始码，’\0’,’\0’,’\1’。当找到起始码后，指向包头的指针会自动指向起始码之后的八个比特，其中后五个比特可以帮助判断出当前包的类型。其中，buf&0xE0为nal_ref_idc。buf&0x1F为nal_unit_type。SPS的nal_unit_type为7，PPS的nal_unit_type为8。当nal_unit_type为所需的类型时候，即可将这个包保存到前文所述的结构体中，这里只需要直接复制包的内容到一块分配好的内存空间中即可，不需要进一步做解析处理。

获取frame_num,poc_order_cnt_lsb这两个参数的方法与获取SPS/PPS参数集的方法类似。首先寻找起始码，其后可以获取nal_unit_type。当nal_unit_type等于1的时候，表示该条带nal单元为一个非IDR图像的编码条带。从这里可以解析出条带头中frame_num与pic_order_cnt_lsb的等位于条带头的信息，并且放到上面所创建的结构体中。

此外，在每次读到的一个新的包中检测到上数参数时，就对这些参数进行刷新。因为原先的参数此时已失去意义了，所以可以直接覆盖。

1.2转发服务器重新配置云端编码器的参数，使得重新编码的视频流头部与原始流可以顺利衔接。

下文的1.2.1～1.2.7中，分别从七个不同方面阐述了一个优选实施例中的确保重新编码的流头与原始流可以顺利衔接的方案。

1.2.1场编码格式与帧编码格式

在SPS参数集中有一个参数为frame_mbs_only_flag与mb_adaptive_frame_field_flag.

当frame_mbs_only_flag＝1时表示采用的是帧编码的方式；

当frame_mbs_only_flag＝0,mb_adaptive_frame_field_flag＝0时表示采用的是PAFF的场编码方式；

当frame_mbs_only_flag＝0,mb_adaptive_frame_field_flag＝1时表示采用的是MBAFF的编码方式；

根据这些参数进入编码器中找到相应的参数作配置，使得编码器采用的编码方式与原始流一致。

需注意的是，有些编码器并不支持PAFF的编码格式，但是可以将编码格式设置成MBAFF格式。实验证明，在解码器解码过程中，PAFF编码的流与MBAFF编码的流在解码的过程中是互相兼容的。

1.2.2修改云端编码器中的SPS参数

重编码的流头中，除了SPS参数集中的mb_adaptive_frame_field_flag这一参数可以有所不同，其它的SPS集的参数应当与原始流保持一致性。因为如果SPS参数不同，解码器会认为两个输入的流不是同一个流，则导致解码器的初始化过程，导致dpb的清空。而本次发明的关键之一是保证生产的几个I帧可以顺利成为原始流的参考图像，是不允许解码器存在初始化这一过程的。

因此，在编码器初始化的过程中，需要根据解码器解析SPS所获得的参数，并且将这些参数用于配置编码器参数的操作，使得编码流的SPS参数与原始的SPS参数保持一致。

这种配置参数的方式可以分为以下两种方式：

直接在打开编码器的时，对编码器初始化的函数中去修改默认参数，可以将H.264解析到的SPS参数保存到一个结构体中，再将这个结构体传送到这个初始化函数中去对编码器做配置；

另外，可以在编码器初始化完成之后，写一个函数，重新再对编码器进行配置。

采用哪种方式进行编码器配置取决于编码器初始化与获取SPS参数集的时序逻辑。

1.2.3取消编码器中GOP中第一帧为IDR帧的设置

由于本次方案所针对的流需要按照原始流中SPS的参数和PPS的参数，分析出所需要的参考图像的数量和其标号，对这些图像重新编码成为I帧，才能使得重构后的流可以进行解码显示出正常图像，为了输出这些I帧，这里在对编码器进行配置的时候把GOP的大小设置为1。然而这会触发部分编码器默认配置中的一个机制，将GOP序列的第一个帧设置为IDR帧。然而IDR帧会导致包括frame_num，pic_order_cnt_lsb，以及参考图像缓存区等的初始化过程，导致重构TS流的衔接失败。因此需要取消这种机制，在一个例子中，在编码器的编码函数中找到触发前述初始化过程的强制转换的代码，将这段码行去掉，即可防止因触发初始化过程而导致的重构TS流衔接失败。

1.2.4frame_num重新配置

Frame_num这个参数用于标记解码图像，和在解码过程中起到比较重要的作用。在SPS参数中，gaps_in_frame_num_value_allowed_flag如果等于零，就意味着在解码的过程中不允许出现frame_num的不连续的情况。实验验证了如果frame_num不连续，解码将不能正常进行。

在1.1中已经阐明了如何从原始流中获取frame_num参数，由于编码器的打开与初始化在获取实时的frame_num之前，所以需要重新配置frame_num参数。

因此，在对原始图像重编码前，添加重新配置编码器的函数，将frame_num这个参数传递到ES流底层，对编码器的frame_num进行重新配置。

1.2.5pic_order_cnt_lsb的重新配置

Pic_order_cnt_lsb这一参数在GOP中用于计算Pic_cnt，这一参数对于标记解码参考图像起到比较重要的作用。

在1.1中已经阐明了如何从原始流中获取pic_order_cnt_lsb参数,由于编码器的打开与初始化在获取实时的pic_order_cnt_lsb之前，所以需要重新配置pic_order_cnt_lsb参数。

这里采取的手段是将最新的pic_order_cnt_lsb传递到底层的编码器函数，在编码器中计算当前pic_order_cnt_lsb的代码行之前加上初始pic_order_cnt_lsb偏移量，这里不必要担心pic_order_cnt_lsb的值会超出条带头中log2_max_frame_num_minus4所规定的值，因为在程序的后端写条带头的函数中，会自行修正这个问题。

1.2.6码率控制修改和QP值的设定

修改默认配置，设置为恒定QP值的控制码率模式，QP值设置为与原始流相近的值，使得从编码器出来的图像数据包不至于过大，同时减少因为再一次的图像压缩造成的画面质量的损失。

1.2.7恢复输出的原始流的处理

原始流由于每隔120个帧才会出现一次SPS，PPS参数，所以在恢复原始流的输出之前，需要恢复输出的原始流的第一个P帧的条带头之前加上该流所对应的SPS，PPS参数集。(需注意的是，实验验证：仅在原始流的第一个P帧的条带头之前加上该流所对应的SPS参数集，客户端也可以正常解码)

步骤1.1已经阐明了如何获得离当前P帧最近的SPS，PPS参数的方法，本步骤中，在原有的P帧条带数据之前加上步骤1.1所得SPS与PPS参数集，在实现上，SPS与PPS参数集可构建为临时包，然后通过软件接口，将临时包作为原始流的开头。在完成了这本步骤以后，之后对原始编码视频流直接进行转发即可。

图9示出了本发明一个实施例中在原始流输出的第一个P帧条带头之前加上SPS与PPS参数集的流程，包括下列步骤：

步骤101：初始化一个新的包temppkt。

步骤102：将temppkt包的数据量(即temppkt包的大小)赋值为SPS包，PPS包和第一个P帧顶场包的数据量之和，将temppkt的数据指针指向包头。

步骤103：将SPS包复制到temppkt中，将temmppkt的数据指针偏置一个SPS包的距离，即将temmppkt的数据指针指向包头+SPS包尺寸的位置。

步骤104：将PPS包复制到temppkt中，将temmppkt的数据指针再偏置一个PPS包的距离，即将temppkt的数据指针指向包头+SPS包尺寸+PPS包尺寸的位置。

步骤105：将第一个P帧顶场对应的包的数据复制到temppkt中。

2、PES层面重构连续性实现的示例

在一个优选实施例中，PES层面主要解决的是转发服务器在编解码和简单的读写原始TS流过程中，保证PTS与DTS与原始流保持一致。

原始流的PES流结构中，每一个PES包包头会对应一个P帧的两个场，即顶场和低场。这种PES流的格式与一些软件并不兼容。图10示出了在读包和写包过程中造成PES/DTS异常的主要原因。参考图10，在读取TS流包的过程中，在读取顶场时，可以找到对应的PES包头获取正确的PTS与DTS，但是在读取底场时，由于找不到PES包头，因而获得的PTS与DTS为在初始化函数中设置的默认值。而在将数据送入编码器时，编码器会认为获取的PTS与DTS有误，进而重新对PTS和DTS进行计数。因此，需要对读取PES包的函数和解析PES包函数进行修改，使其与原始流的格式兼容。另一方面，由于从解码器中出来的原始图像没有设置正确的PTS与DTS值，因此，需要在顶层软件处理层将正确的PTS值与DTS值传递到最终的重构TS流中。

正确的PTS值与DTS值获取方法如下：当读取TS流过程中发现读取的PTS与DTS是正常值时，将这个值保存下来；在下一次读包的过程中，如果发现所读取的包的PTS与DTS的值等于初始化产生的默认值时，将上一次读包保存下来的正确PTS与DTS值赋值给这个包的PTS与DTS值。

图11示出了一个实施例中，读包过程中对PTS与DTS处理的流程，包括下列步骤：

步骤201：读取当前包。

步骤202：判断当前包的PTS与DTS是否为默认值，如果是，则执行步骤203，否则，执行步骤204。

步骤203：此时，认为当前包的PTS与DTS为非正常值，将当前包的PTS与DTS设置为上一次读包过程保存下来的值。

步骤204：此时，认为当前包的PTS与DTS为正常值，将当前包的PTS与DTS暂时存放起来，刷新上一次保存的值。

在基于图11所示流程获得当前包的正确PTS与DTS值后，将正确PTS与DTS值传递至顶层进行编解码延迟补偿处理，然后再由顶层软件处理层传递回PES流处理层。

在另一个实施例中，直接在PES流处理层来实现PTS与DTS的调整，以保证重构的流头与原始流在PES层面的一致性。在PES流处理层进行的读写包时，每一次写包需要一个PES头，因此最后产生的流格式为P帧的顶场对应一个PES头，P帧的底场对应一个PES头，这与原始流稍有区别，因此需要在读写的时候稍作调整。调整的方法为：以帧率为25的视频流为例，当读包过程中发现读取的PTS与DTS是正常值时，将这个值保存下来；在下一次读包的过程中，如果发现所读取的包的PTS与DTS的值等于初始化产生的默认值时，将上一次读包所保存下来的值加1800并在写包时将该值(加1800后的值)写入。图12示出了该实施例在读写包过程中实现PTS与DTS的调整的流程，包括下列步骤：

步骤301：读取当前包。

步骤302：判断当前包的PTS与DTS是否为默认值，如果是，进入步骤303，否则，进入步骤304。

步骤303：将本次读包的PTS设置为上一次读包获取的PTS值加上1800；将本次读包的DTS值设置为上一次读包获取的DTS值加上1800。

步骤304：将当前包的PTS与DTS暂时存放起来，刷新上一次保存的数值。

3、TS层面重构连续性实现的示例

在一个优选实施例中，输入的转发服务器编码视频流(例如TS流)经过读包、重新写包的过程，使得TS流中的计数戳重新进行计数；同时，所有的PID信息设置成默认的PID信息格式；并且，转发服务器输出的TS流同时支持文件形式的TS流与实时流的传输。

4、顶层的实现示例

在一个优选实施例中，顶层软件处理层设置了三个状态：状态一，对输入的流进行解包和解码，并且生成原始图像；状态二，仅仅对原始流进行简单地传输；状态三，对原始图像进行编码和重新打包，并且恢复原始流传输。

状态一需要完成的操作有：编解码器的初始化，IO口的初始化，原始图像、数据包的初始化与分配内存空间，解码过程中的一系列参数的配置。当完成以上一系列操作之后，整个程序就会处于稳定的解码状态，并且会将解码获得的原始图像存储起来，每当获得一个新的图像，便对这个原始图像进行刷新。

当程序收到一个触发信号后，程序会进入状态三。对解码获得原始图像按照以上步骤进行配置后进行编码，产生三个I帧，最后将编码获得的ES流打包成TS流并发送。

当发送完三个I帧后，程序会进入状态二，在此之前会优先传输距离当前P帧最近的PPS，此后就是原始流进行简单的读写过程。

如果程序再次收到触发信号，则程序会结束状态二的过程，并且释放内存，重新进入状态一的过程。

整个程序执行的过程中，如果接受到结束信号，则程序会释放掉所有内存，并且退出。

当程序加入多线程机制之后，就会形成如图6所示的切换状态，实现对两个流甚至更多的流的快速切换。

另外，在一个实施例中，转发服务器采用软件编解码技术，编解码的过程会有不同程度的延迟，此时，在顶层处理读包与解码、编码与写包的过程中，需要考虑到这种延迟的出现，并且在传递PTS与DTS时进行延时补偿。也有必要计算这种延迟，确保不会出现丢帧的现象。

进一步地，在一个实施例中，由顶层软件处理层传递正确PTS与DTS时，其方法如下：将原始图像的PTS与DTS值经过计算编码延迟后赋值给最后从解码器出来的原始图像，其中，

解码器输出的原始图像对应的PTS＝解码器输入的流的PTS-3600*解码延迟；解码器输出的原始图像对应的DTS＝解码器输入的流的DTS-3600*解码延迟；

输入编码器的流的PTS＝解码器输出的原始图像对应的PTS；输入编码器的流的DTS＝解码器输出的原始图像对应的DTS；

编码器输出流的PTS＝输入编码器流的PTS-3600*编码延迟；编码器输出流的DTS＝输入编码器流的DTS-3600*编码延迟。

此外，在一个优选实施例中，还对编码延迟输出的最后几帧进行单独处理，图13示出了延迟编码下处理最后几帧PTS与DTS的流程，包括下列步骤：

步骤401：令i＝1，

步骤402：开始构建延迟输出的第i帧；

步骤403：对当前包的PTS和DTS进行赋值，当前包PTS＝最后一个读入包的PTS-3600*(编码延迟-i)；其中，编码延迟以帧数为单位；

步骤404：令i＝i++，即对i值累加2；

步骤405：判断i是否不超过编码延迟，如果是，返回步骤402，如果否，结束本次处理。

本发明特别适用于大GOP编码策略的编码视频流的转发，大GOP编码策略通常指每个GOP的帧数超过30的编码策略，但需要说明的是，对于帧数小于30的GOP编码策略，利用本发明同样能够实现一定的有益效果。

最后应说明的是，以上实施例仅用以描述本发明的技术方案而不是对本技术方法进行限制，本发明在应用上可以延伸为其它的修改、变化、应用和实施例，并且因此认为所有这样的修改、变化、应用、实施例都在本发明的精神和教导范围内。

Claims (13)

1.一种编码视频流转发方法，其特征在于，包括下列步骤：

1)接收至少一路原始编码视频流，对所述原始编码视频流进行实时解码得到原始图像序列；

2)接收客户端对所述视频流中一个视频流的请求；

3)对客户端所请求的视频流所对应的原始图像序列进行帧内编码，并利用帧内编码的图像帧构建视频流头部，然后将所述视频流头部发送给所述客户端，然后向该客户端转发该客户端所请求的视频流所对应的原始编码视频流。

2.根据利用权利要求1所述的编码视频流转发方法，其特征在于，所述步骤1)中，所接收的原始编码视频流至少包括第一视频流和第二视频流，其中第一视频流直接转发给客户端；

所述步骤2)中，客户端对视频流的请求是从第一视频流切换到第二视频流的切换请求；

所述步骤3)还包括：停止转发步骤1)中向客户端直接转发的第一视频流。

3.根据利用权利要求1所述的编码视频流转发方法，其特征在于，所述步骤2)中，客户端对视频流的请求是初次请求，之前未向该客户端转发原始编码视频流。

4.根据利用权利要求2所述的编码视频流转发方法，其特征在于，所述步骤1)还包括：对所述第二视频流进行实时解包和解码，提取第二视频流中的参数；

所述步骤3)中，根据步骤1)所提取的参数构建第二视频流的头部，使所述头部与后续的第二视频流无缝拼接。

5.根据权利要求4所述的视频流转发方法，其特征在于，所述原始编码视频流为TS流，所述步骤3)中，根据步骤1)所提取的参数构建视频流头部时，在TS流，PES流和ES流层面均实现无缝拼接。

6.根据权利要求5所述的视频流转发方法，其特征在于，所述步骤3)中，构建视频流头部时，使所构建的视频流头部的PID信息和计数戳与后续的原始编码视频流保持前后一致，以在TS流层面实现无缝拼接。

7.根据权利要求5所述的视频流转发方法，其特征在于，所述步骤3)中，构建视频流头部时，使所构建的视频流头部的PTS和DTS参数与后续的原始编码视频流连续，以在PES流层面实现无缝拼接。

8.根据权利要求5所述的视频流转发方法，其特征在于，所述步骤1)中，从原始编码视频流中所提取的参数包括SPS和PPS参数信息；

所述步骤3)中，通过下列方式在ES流层面实现无缝拼接：根据步骤1)所获取的SPS和PPS参数信息对编码器进行重新配置，使得编码器能够按照原始流中的SPS和PPS参数进行编码，生成可以独立解码的I帧，并利用所生成的I帧构建视频流头部，视频流头部的SPS参数与原始编码视频流的SPS参数保持一致；还将最新的PPS参数添加到后续的原始编码视频流的第一个P帧的条带头之前。

9.根据权利要求8所述的视频流转发方法，其特征在于，所述步骤3)中，通过下列方式在ES流层面实现无缝拼接：在读取原始TS流的包的同时，解析原始流中所包含的条带头中的参数，并根据这些参数，修改编码器的相应参数的初始状态，使得从转发服务器的编码器中输出的视频流头部的条带头中的参数与原始编码视频流保持连贯性。

10.根据权利要求7所述的视频流转发方法，其特征在于，所述步骤1)和3)中，采用软件编解码技术，以及在所述步骤3)中，计算编解码延时，并对所构建的视频流头部的PTS和DTS参数进行延时补偿，构建视频流头部时使用延时补偿后的PTS和DTS参数。

11.一种编码视频流转发装置，包括：

视频流接收单元，用于接收至少一路原始编码视频流并对原始编码视频流进行实时解码得到原始图像序列；

请求接收单元，用于接收客户端对视频流的请求；以及

转发单元，用于对客户端所请求的视频流所对应的原始图像序列进行帧内编码，并利用帧内编码的图像帧构建视频流头部，然后将所述视频流头部发送给所述客户端，然后向该客户端转发该客户端所请求的视频流所对应的原始编码视频流。

12.一种编码视频流转发系统，包括至少一路原始编码视频流和至少一个客户端，其特征在于，所述编码视频流转发系统还包括权利要求11所述的视频流转发装置；以及

所述客户端用于向所述视频流转发装置请求视频流，并对所接收到的视频流进行解码。

13.根据利用权利要求12所述的编码视频流转发系统，其特征在于，所述视频流转发装置还用于：在同一时刻，对所接收的每一路原始编码视频流，按下述三种模式之一进行处理：模式一，对输入的原始编码视频流进行解包和解码，生成原始图像序列；模式二，仅仅对原始编码视频流进行简单地转发；模式三，对原始图像序列进行帧内编码和重新打包形成所述视频流头部，并在发送所述视频头后恢复对原始编码视频流的转发；并且，对于同一路原始编码视频流，处理模式可以在上述模式一，模式二和模式三之间转换。