视频流数据的传输方法、装置、存储介质及电子设备与流程

1.本公开的实施方式涉及通信技术领域，更具体地，本公开的实施方式涉及一种视频流数据的传输方法、视频流数据的传输装置、计算机可读存储介质及电子设备。


背景技术：

2.本部分旨在为权利要求中陈述的本公开的实施方式提供背景或上下文，此处的描述不因为包括在本部分中就承认是现有技术。
3.视频流数据在网络中传输时，如果发生丢包或者抖动，接收端播放时将会发生卡顿。
4.相关技术中，可以基于实时反馈的长期参考帧进行视频帧流数据的传输。具体的，实时反馈的长期参考帧具有固定的编码参考距离，如编码参考距离是3时，就代表第4帧参考第1帧编码、第5帧参考第2帧编码等，其是在发送端和接收端建立一种联动机制，接收端成功组帧一次，立即对该帧进行ack(acknowledgement，一种正向反馈，接收方在接收到视频数据后回复消息告知发送方)通知发送端，发送端在编码时参考接收端成功接收的ack帧进行参考编码。


技术实现要素：

5.然而，上述的基于实时反馈的长期参考帧技术，在正常网络情况下，由于链路的反馈延时，图像的编码参考距离会被拉大，因此，在正常网络情况下，图像的参考相似性降低，压缩率和图像清晰度会受损。
6.为此，非常需要一种改进的视频流数据的传输方式，可以在正常网络情况下不损失网络清晰度的同时，又可以在丢包或者卡顿时，对传输的视频流进行恢复，以提升视频播放的流畅度。
7.在本上下文中，本公开的实施方式期望提供一种视频流数据的传输方、视频流数据的传输装置、计算机可读存储介质及电子设备。
8.根据本公开实施方式的第一方面，提供一种视频流数据的传输方法，该方法应用于发送端，该方法包括：响应于接收端发送的第一恢复请求，确定出目标前向长期参考帧；根据所述目标前向长期参考帧进行编码，以得到恢复帧；向所述接收端发送所述恢复帧；其中，所述目标前向长期参考帧为最近一次被接收端所成功接收的前向长期参考帧。
9.根据本公开实施方式的第二方面，提供了另一种视频流数据的传输方法，该方法应用于接收端，该方法包括：响应于在第一预设等待时段内未获取到可被成功解析的视频帧，向发送端发送第一恢复请求；其中，所述第一恢复请求用于指示所述发送端基于目标前向长期参考帧进行编码，以生成恢复帧；所述目标前向长期参考帧为由所述发送端标记的且最近一次被所述接收端所成功接收的前向长期参考帧。
10.根据本公开实施方式的第三方面，提供一种视频流数据的传输装置，该装置应用于发送端，该装置包括：第一恢复请求响应模块，被配置为响应于接收端发送的第一恢复请
求，确定出目标前向长期参考帧；恢复帧生成模块，被配置为根据所述目标前向长期参考帧进行编码，以得到恢复帧；恢复帧发送模块，被配置为向所述接收端发送所述恢复帧；其中，所述目标前向长期参考帧为最近一次被接收端所成功接收的前向长期参考帧。
11.根据本公开实施方式的第四方面，提供一种视频流数据的传输装置，该装置应用于接收端，该装置包括：第一恢复请求发送模块，被配置为响应于在第一预设等待时段内未获取到可被成功解析的视频帧，向发送端发送第一恢复请求；其中，所述第一恢复请求用于指示所述发送端基于目标前向长期参考帧进行编码，以生成恢复帧；所述目标前向长期参考帧为由所述发送端标记的且最近一次被所述接收端所成功接收的前向长期参考帧。
12.根据本公开实施方式的第五方面，提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现上述任意一种视频流数据的传输方法。
13.根据本公开实施方式的第六方面，提供一种电子设备，包括：处理器；以及存储器，用于存储所述处理器的可执行指令；其中，所述处理器配置为经由执行所述可执行指令来执行上述任意一种视频流数据的传输方法。
14.根据本公开实施方式的视频流数据的传输方法、视频流数据的传输装置、计算机可读存储介质及电子设备，其可以响应于接收端发送的第一恢复请求，确定出目标前向长期参考帧，其中，目标前向长期参考帧为最近一次被接收端所成功接收的前向长期参考帧，从而根据确定出的目标前向长期参考帧进行参考编码，以得到恢复帧，进而向所述接收端发送所述恢复帧。与相关技术相比，一方面，本公开可以根据接收端发送的恢复请求，准确的进行视频流数据的传输与恢复，提高视频流数据传输的准确性；另一方面，本公开在接收到接收端发送的第一恢复请求时，可以基于确定出的目标前向长期参考帧进行编码以得到恢复帧，从而可以提高视频的流畅性。
附图说明
15.通过参考附图阅读下文的详细描述，本公开示例性实施方式的上述以及其他目的、特征和优点将变得易于理解。在附图中，以示例性而非限制性的方式示出了本公开的若干实施方式，其中：
16.图1示出了相关技术中的一种发送端在编码时进行参考帧选择的过程的示意图；
17.图2示出了根据本公开实施方式的一种应用于发送端的视频流数据的传输方法的示意图；
18.图3示出了根据本公开实施方式的一种涉及多个接收端的场景中，如何确定标记周期的方法的流程示意图；
19.图4示出了根据本公开实施方式的一种发送端根据接收端发送的第二恢复请求，进行视频流传输的方法的流程示意图；
20.图5示出了根据本公开实施方式的一种第一预设时间段和第二预设时间段在时间轴中的关系的示意图；
21.图6示出了根据本公开实施方式的一种发送端根据接收端发送的第三恢复请求进行视频流传输的方法的流程示意图；
22.图7示出了根据本公开实施方式的一种第一预设时间段和第三预设时间段在时间轴中的关系的示意图；
23.图8示出了根据本公开实施方式的一种第一预设时间段、第二预设时间段、第三预设时间段在时间轴中的关系的示意图；
24.图9示出了根据本公开实施方式的一种发送端在编码时进行参考帧选择的过程的示意图；
25.图10示出了根据本公开实施方式的一种应用于接收端的视频流数据的传输方法的流程示意图；
26.图11示出了根据本公开实施方式的一种视频流数据的传输过程中发送端和接收端进行交互的流程示意图；
27.图12示出了根据本公开实施方式的一种作为发送端的视频流数据的传输装置的结构图；
28.图13示出了本公开实施方式的一种作为接收端的视频流数据的传输装置的结构图；
29.图14示出了根据本公开实施方式的一种电子设备的结构图；
30.在附图中，相同或对应的标号表示相同或对应的部分。
具体实施方式
31.下面将参考若干示例性实施方式来描述本公开的原理和精神。应当理解，给出这些实施方式仅仅是为了使本领域技术人员能够更好地理解进而实现本公开，而并非以任何方式限制本公开的范围。相反，提供这些实施方式是为了使本公开更加透彻和完整，并且能够将本公开的范围完整地传达给本领域的技术人员。
32.本领域技术人员知道，本公开的实施方式可以实现为一种系统、装置、设备、方法或计算机程序产品。因此，本公开可以具体实现为以下形式，即：完全的硬件、完全的软件(包括固件、驻留软件、微代码等)，或者硬件和软件结合的形式。
33.根据本公开的实施方式，提供了视频流数据的传输方法、视频流数据的传输装置、计算机可读存储介质及电子设备。
34.在本文中，附图中的任何元素数量均用于示例而非限制，以及任何命名都仅用于区分，而不具有任何限制含义。
35.下面参考本公开的若干代表性实施方式，详细阐述本公开的原理和精神。
36.发明概述
37.本公开的发明人发现，在现有的视频流数据传输的技术方案中，有的是牺牲了视频图像的清晰度，来提高视频的整体流畅性，有的是牺牲了视频图像的整体流畅性，来提高视频图像的清晰度，难以在二者之间进行很好的平衡。
38.鉴于上述内容，本公开的基本思想在于：提供一种视频流数据的传输方法、视频流数据的传输装置、计算机可读存储介质及电子设备，其可以响应于接收端发送的第一恢复请求，确定出目标前向长期参考帧，其中，目标前向长期参考帧为最近一次被接收端所成功接收的前向长期参考帧；从而根据确定出的目标前向长期参考帧进行参考编码，以得到恢复帧，进而向所述接收端发送所述恢复帧。与相关技术相比，一方面，本公开可以根据接收端发送的恢复请求，准确的进行视频流数据的传输与恢复，提高视频流数据传输的准确性；另一方面，本公开在接收到接收端发送的第一恢复请求时，可以基于确定出的目标前向长
期参考帧进行编码以得到恢复帧，从而可以提高视频的流畅性。
39.在介绍了本公开的基本原理之后，下面具体介绍本公开的各种非限制性实施方式。
40.应用场景总览
41.需要注意的是，下述应用场景仅是为了便于理解本公开的精神和原理而示出，本公开的实施方式在此方面不受任何限制。相反，本公开的实施方式可以应用于适用的任何场景。
42.本公开可以应用于各种需要进行视频流数据传输的场景，如会议、直播等。例如，以会议场景为例，可以使用本公开的视频流数据传输方法进行多人视频会议，某个会议客户端发生因为网络等原因出现卡顿情况下，可以向发送端发送恢复请求，发送端可以对接收到的恢复请求进行响应，以解决视频播放卡顿的情况，从而保证该会议客户端接收的视频图像的流畅性。
43.示例性方法
44.相关技术中的视频流数据传输的方案，难以在传输的视频图像的清晰度和视频播放的整体流畅度之间进行平衡，要么是牺牲了清晰度来保证流畅度，要么是牺牲了流畅度来保证清晰度。
45.如一种相关技术中，是基于实时反馈的长期参考帧进行参考编码，从而实现视频流数据的传输的。具体的，实时反馈的长期参考帧实现方案是在发送端和接收端之间建立一种联动机制，接收端成功组帧一次，立即向发送端发送一个与该帧对应的ack消息，以通知发送端该帧已被接收端成功接收，该帧可以被用于进行长期参考帧编码。其中，被接收端接收成功的帧也可以称之为ack帧，发送端在编码时就可以根据固定的编码参考距离去参考接收端成功接收的ack帧进行编码。
46.例如，图1以实时反馈的长期参考帧的编码参考距离是间隔3帧为例，在图1中，数字1至8分别对应的表示某个视频流中的第1帧至第8帧，图1中的箭头线的箭头所指向的帧是参考了箭头线的出发点所指示的帧而进行编码的，图1中的附图标记11所指示的“x”表示图1中的第3帧在视频流传输的过程中出现了丢包。
47.下面，结合图1对基于实时反馈的长期参考帧在进行编码时如何选择参考帧的过程进行说明：在图1中，第1帧被接收端接收成功，所以接收端会向发送端发送一个与第1帧对应的ack消息(如ack1)，以通知发送端第1帧已被接收端接收成功，第1帧可以作为长期参考帧进行参考编码；第2帧也被接收端接收成功，所以接收端也会向发送端发送一个与第2帧对应的ack消息(如ack2)，以通知发送端第2帧已被接收端接收成功，第2帧也可以作为长期参考帧进行参考编码；第3帧在传输过程中出现了丢包，其未被接收端接收成功，所以接收端不会向发送端发送与第3帧对应的ack消息，由于发送端没有接收到与第3帧对应的ack消息，所以发送端在进行长期参考帧编码时，也不会使用第3帧进行编码；第4帧被接收端接收成功，所以接收端也会向发送端发送一个与第4帧对应的ack消息，以通知发送端第4帧已被接收端接收成功，第4帧可以作为长期参考帧进行参考编码；后面的帧以此类推，第5、6、7、8帧也分别被接收端接收成功，发送端也可以接收到接收端发送的分别与第5、6、7、8帧对应的ack消息ack5、ack6、ack7、ack8，这样，发送端也可以基于编码参考距离分别以第5、6、7、8帧对后续的帧进行长期参考编码。
48.图1中，是以参考编码距离是3为例的，第1帧和第2帧已分别被接收端接收成功，所以发送端在编码第4帧时，参考第1帧进行编码，在编码第5帧时，参考第2帧进行编码。然而，由于第3帧出现了丢包，所以发送端在对第6帧进行编码时，不会参考第3帧进行编码，而是参考被接收端最近一次接收成功的第2帧进行编码；由于第4帧被接收端接收成功，所以发送端在对7帧进行编码时，参考第4帧进行编码，且由于第5帧也被接收端接收成功，所以发送端在对第8帧进行编码时，可以参考第5帧进行编码，以此类推，以实现基于实时反馈的长期参考帧编码。
49.基于实时反馈的长期参考帧进行编码的优点在于，当发生丢包时，通过感知接收端发送的ack信息，位于发送端的编码器可以快速调整参考关系，避免了使用丢失的帧作为参考帧进行编码，从而保证接收端接收到的任意完整的帧都能被成功解码，不会存在因接收端未成功接收到参考帧而无法解码的情况，从而提升视频的整体流畅性。
50.然而，该方案的不足之处在于，在正常网络情况下，编码参考距离也会被拉大，从而导致图像的参考相似性降低，影响图像的压缩效果，降低了编码质量，进而影响了图像质量。所以，其是牺牲了视频的清晰度，来提高视频的流畅度。
51.本公开的示例性实施方式首先提供一种视频流数据的传输方法，以至少克服相关技术中存在的上述的全部或部分缺陷。
52.图2示出了本公开一示例性实施例中视频流数据传输的方法，其可以应用于发送端，该方法可以包括：
53.步骤s210，响应于接收端发送的第一恢复请求，确定出目标前向长期参考帧，其中，所述目标前向长期参考帧为最近一次被接收端所成功接收的前向长期参考帧；
54.步骤s220，根据所述目标前向长期参考帧进行编码，以得到恢复帧；
55.步骤s230，向所述接收端发送所述恢复帧。
56.下面分别对图2中的每个步骤做具体说明。
57.在步骤s210中，响应于接收端发送的第一恢复请求，确定出目标前向长期参考帧。
58.在一种可选的实施方式中，第一恢复请求由接收端响应于第一预设条件的达成而产生。其中，第一预设条件包括所述接收端在第一预设等待时段内未接收到可被成功解析的视频帧。
59.在一种可选的实施方式中，未接收到可被成功解析的视频帧可以包括接收端没有接收到视频帧的相关数据，而无法对视频帧进行解析，还可以包括接收端接收到了视频帧的相关数据，但是接收端接收到的视频帧的相关数据不完整，由于接收到的视频帧的相关数据不完整，所以接收端仍然无法成功对视频帧进行解析。如果视频流中的某帧出现了丢包情况，也就是说，接收端没有接收到该帧的任何相关数据或者接收端接收到的关于该帧的相关数据不完整，则接收端就无法成功的对该帧进行解析。而如果视频流中的某帧被接收端成功解析，则接收端在成功解析完该帧后，接收端就会从接收端中存储视频流中的视频帧的位置处去获取下一个待解析的视频帧。
60.对于视频流中的某一帧而言，第一预设等待时段的起点为接收端最近一次成功解析完视频帧的时刻。
61.在一种可选的实施方式中，第一预设等待时段对应的第一预设等待时长大于0.5秒且小于1秒。当然，第一预设等待时段对应的第一预设等待时长也可以根据需求进行自定
义，本示例性实施方式对此不做特殊限定。
62.举例而言，在网络环境较差的情况下发送视频流时，即网络存在数据丢包的情况下，接收端自最近一次成功解析完视频帧的时刻起等待了第一预设等待时长之后仍然没有获取到可被成功解析的视频帧，则接收端可以向发送端发送第一恢复请求。
63.在一种可选的实施方式中，第一恢复请求用于指示发送端根据目标前向长期参考帧进行编码。其中，目标前向长期参考帧为最近一次被接收端所成功接收的前向长期参考帧。
64.前向长期参考帧可以理解为ltr(long term reference，长期参考)帧。在本公开中，可以通过发送端在传输的视频流中周期性地标记出前向长期参考ltr帧。
65.在一种可选的实施方式中，发送端可以根据所述第一预设等待时段和网络状态信息，确定所述前向长期参考帧的标记周期，并且基于所述标记周期对发往接收端的视频流添加参考帧标记。其中，参考帧标记用于指示视频流中的相应帧为前向长期参考帧。
66.举例而言，发送端可以根据网络状态信息和上述的第一预设等待时段对应的第一预设等待时长确定前向长期参考帧的标记周期，然后根据确定出的标记周期在发往接收端的视频流中添加参考帧标记，以在视频流中标记出前向长期参考帧。
67.其中，网络状态信息可以包括往返时延。往返时延即rtt(round-trip time)，其可以理解为网络中来回往返一次的耗时，即从发送端发送数据开始，到发送端接收到来自接收端的确认(接收端在收到发送端发送的数据后立即发送确认)，总共经历的时延，是一种用于评价网络延时的指标。
68.在一种可选的实施方式中，网络状态信息可以包括一个往返时延，该往返时延对应一个接收端。基于此，根据第一预设等待时段和网络状态信息，确定所述前向长期参考帧的标记周期的具体实施方式可以是:将所述第一预设等待时段所对应的第一预设等待时长与所述往返时延求和，以基于二者之和确定所述前向长期参考帧的标记周期，其中，所述标记周期不小于所述二者之和。
69.举例而言，在涉及一个接收端的场景中，可以直接通过该接收端对应的往返时延和上述的第一预设等待时段对应的第一预设等待时长确定出标记周期。具体的，可以对第一预设等待时段对应的第一预设等待时长和该接收端对应的往返时延求和，以得到第一和值，将标记周期配置为等于或稍大于该第一和值。
70.例如，第一预设等待时段对应的第一预设等待时长为0.9秒，接收端对应的往返时延为0.4秒，则标记周期可以为1.3秒或1.34秒。
71.其中，标记周期配置为稍大于上述的第一和值，可以理解为，标记周期减去上述的第一和值后得到第一差值，该第一差值小于或等于某个第一阈值。此处的第一阈值大于0，其可以根据需求进行自定义，如0.2，0.3，0.4等，本示例性实施方式对此不做特殊限定。
72.在另一种可选的实施方式中，网络状态信息可以包括多个往返时延，多个往返时延分别对应于多个接收端。示例性的，图3示出了根据本公开实施方式的一种涉及多个接收端的场景中确定标记周期的方法的流程示意图。参考图3，该方法可以包括步骤s310至步骤s320。其中：
73.在步骤s310中，确定出多个往返时延中的最小往返时延。
74.例如，在多人会议场景下，会有多个接收端，而每个接收端所处的网络的不同导致
每个接收端对应的网络时延可能也不相同。可以确定出多个接收端对应的多个往返时延中的最小往返时延。
75.在步骤s320中，根据所述第一预设等待时段和所述最小往返时延，确定出所述前向长期参考帧的标记周期。
76.示例性的，步骤s320的具体实施方式可以是，将上述的第一预设等待时段所对应的第一预设等待时长与上述的最小往返时延求和，以基于二者之和确定所述前向长期参考帧的标记周期，其中，所述标记周期不小于所述二者之和。
77.举例而言，在涉及多个接收端的场景中，可以先确定出多个接收端对应的往返时延中的最小往返时延。然后，再确定出该最小往返时延和上述的第一预设等待时长之和，以得到第二和值，可以将标记周期配置为等于或稍大于第二和值。
78.例如，第一预设等待时段对应的第一预设等待时长为0.9，多个接收端对应的多个往返时延中的最小往返时延为0.3，则标记周期可以为1.2秒或1.25秒。
79.其中，标记周期配置为稍大于上述的第二和值，可以理解为，标记周期减去上述的第二和值后得到第二差值，该第二差值小于或等于某个第二阈值。此处的第二阈值大于0，其可以根据需求进行自定义，如0.2，0.3，0.4等，本示例性实施方式对此不做特殊限定。
80.在编码得到的编码帧和编码时参考的参考帧之间的参考距离变大时，二者之间的相似度也会降低，在相似度降低的情况下，需要较大的码率(把每秒显示的图片进行压缩后的数据量)才能保证视频帧的画质(即清晰度)。但码率的增大，会增加视频文件的体积，使得视频文件会占用较大的存储空间，且码率大到一定程度后，其对于视频帧的清晰度的改善程度就会显著减小。所以编码参考距离不宜过大，这样，才可以通过一个合适的码率在保证视频的清晰度的同时又不会导致视频文件太大。
81.而在本公开中，将标记周期配置为等于或者稍大于上述的第二和值，这样，一方面，可以避免由于标记周期太大，在需要进行恢复时，发送端最近一次标记前向长期参考帧的时刻很可能距离当前时刻较远，导致在当前时刻生成恢复帧时，只能采用距离当前时刻较远的前向长期参考帧进行编码。所以，在进行恢复帧的编码时，编码参考距离会被拉大，导致编码得到的恢复帧和参考帧之间的相似度变小，从而需要较大的码率才能保证图像的画质(即清晰度)，而较大的码率又会导致视频文件的体积过大，占用过多的存储空间，进而难以在视频的清晰度和视频文件的大小之间进行一个较好的平衡。另一方面，标记出的前向长期参考帧可以存储在与发送端对应的第一存储单元中，而由于第一存储单元的存储容量有限，所以需要对存储在第一存储单元中的前向长期参考帧进行更新，以保证第一存储单元中可以存储最新生成的前向长期参考帧。所以，将标记周期配置为等于或稍大于上述的第二和值，可以避免由于标记周期太小，频繁的更新存储在第一存储单元中的前向长期参考帧，而导致在需要进行恢复帧的编码时，被接收端最近一次接收成功前向长期参考帧可能已经被剔除出了第一存储单元，进而无法在第一存储单元中找到目标前向长期参考帧以进行恢复帧的参考编码。
82.在一种可选的实施方式中，发送端可以根据确定出的标记周期在发往接收端的视频流中标记出前向长期参考帧。例如，以标记周期为时间间隔在发往接收端的视频流中标记出前向长期参考帧。
83.接收端在接收到发送端发送的视频流后，如果确定某个帧添加了参考帧标记，就
确定该帧为前向长期参考帧，然后立即向发送端返回一个ack消息，该ack消息用于通知发送端接收端此时已经成功接收到了该前向长期参考帧。其中，每个ack消息分别对应一个前向长期参考帧。
84.所以，在一种可选的实施方式中，发送端还可以接收所述接收端发送的与每个前向长期参考帧对应的回复消息，所述回复消息用于表征所述前向长期参考帧已被所述接收端成功接收。
85.发送端在根据确定出的标记周期标记出前向长期参考帧后，还可以将标记出的前向长期参考帧进行存储。
86.如前所述，在一种可选的实施方式中，发送端可以将标记出的前向长期参考帧存储在第一存储单元中。其中，第一存储单元用于存储预设数量的前向长期参考帧，预设数量为大于1的任意整数。
87.示例性的，发送端将标记出的前向长期参考帧存储在第一单元的具体实施方式可以是，发送端根据最新标记出的前向长期参考帧更新第一存储单元中存储的前向长期参考帧。
88.其中，发送端根据最新标记出的前向长期参考帧更新第一存储单元中存储的前向长期参考帧的具体实施方式可以是，响应于第一存储单元中所存储的前向长期参考帧超过所述预设数量，将所述第一存储单元中最早被标记的前向长期参考帧剔除，然后将最新标记出的前向长期参考帧添加至第一存储单元中。
89.在第一存储单元中当前所存储的前向长期参考帧小于所述预设数量时，则可以直接将最新标记出的前向长期参考帧添加至第一存储单元。
90.在一种可选的实施方式中，步骤s210的具体实施方式可以是，响应于接收端发送的第一恢复请求，从所述第一存储单元中存储的前向长期参考帧中确定出所述目标前向长期参考帧。
91.在一种可选的实施方式中，第一存储单元可以包括编码器dpb(decoded picture buffer，解码图像缓存器)。在第一存储单元为编码器dpb时，编码器dpb中存储的前向长期参考帧的数量可以根据编码器dpb自身的容量确定，如编码器dpb中最多只能存放15个前向长期参考帧，则预设数量可以为15。当然，第一存储单元也可以是其它的存储容器，如redis缓存、队列等，本示例性实施方式对此不做特殊限定。
92.在第一存储单元为编码器dpb时，由于编码器dpb本身的存储限制，每次最多只能存储预设数量的最新标记出的前向长期参考帧，如编码器dpb的存储容量为15帧，就表示编码器dpb中最多只能存储最新标记出的15个前向长期参考帧。
93.在一种示例性实施例中，本公开是基于nack(negative acknowledgement，负向反馈)进行接收端的视频恢复的，即接收端只在没有接收到数据的时候才会通知发送端，发送端根据接收端发送的不同请求，利用不同的方式进行视频恢复。
94.对于负反馈而言，需要接收端在没有接收到数据的情况下才会通知发送端。那么，从发送端给接收端发送数据，到接收端在没有接收到发送端发送的数据的情况下向发送端发送恢复请求，再到接收端发送的恢复请求达到接收端，需要经历的时延相比正反馈而言会变大。换言之，负反馈存在的时延较大。
95.如果前向长期参考帧的标记周期太小，则由于负反馈存在的时延较大，可能会导
致发送端无法在发送端的dpb中找到确定出的目标前向长期参考帧，进而导致发送端的dpb中存储资源的浪费。也就说，在标记周期太小的情况下，发送端的dpb中存储的前向长期参考帧可能并不能真正的被用于生成恢复帧，所以会导致dpb中存储资源的浪费。
96.例如，在dpb中存储的前向长期参考帧的数量为15个时，需要用到的时间是200毫秒，而负反馈对应的往返时延是400毫秒，也就是说，接收端发送给发送端的恢复请求需要经历400毫秒的时延才能到达发送端。也就是说，发送端在接收到接收端发送的恢复请求时，对于发送端的编码器而言，已经经过了400毫秒的时间，而在这400毫秒的时间内，发送端的编码器已经继续重新存储了最新标记出的30个前向长期参考帧，而最新标记出的这30个前向长期参考帧中的第16个前向长期参考帧在向接收端传输的过程中，接收端就已经发生了卡顿，接收端只成功接收到了发送端在400毫秒的往返时延内最新标记出的30个前向长期参考帧中的前15个前向长期参考帧(即第1个至第15个前向长期参考帧)，并没有接收到发送端发送的最新标记出的30个前向长期参考帧的第16至第30个前向长期参考帧。而目标前向长期参考帧为接收到最近一次接收成功的前向长期参考帧，也就是说，发送端在接收到第一恢复请求时，确定出的目标前向长期参考帧为发送端在第一恢复请求达到发送端的400毫秒的时延内最新标记出的第15个前向长期参考帧。
97.但是，发送端在接收到第一恢复请求时，发送端对应的dpb中存储的前向长期参考帧，已经被更新为在400毫秒的时延内最新生成的30个前向长期参考帧中的后15个前向长期参考帧，也就是说，发送端在400毫秒的往返时延内最新标记出的第15个前向长期参考帧已经被剔除出了发送端的dpb中。换言之，发送端在响应于第一恢复请求确定出目标前向长期参考帧后，发送端确定出的目标前向长期参考帧没有存储在发送端，所以发送端无法基于确定出的目标前向长期参考帧进行参考编码。
98.因此，如果标记周期太小，会导致发送端的dpb中存储的前向长期参考帧被频繁的更新。由于负反馈链路(即接收端到发送端的传输链路，即第一恢复请求对应的链路)可能存在较大的时延，所以会导致发送端在接收到第一恢复请求时，确定出的目标前向长期参考帧由于发送端dpb的频繁更新而被剔除出了发送端的dpb，进而导致发送端无法在发送端的dpb中找到可以用于参考编码的目标前向长期参考帧。也就是说，如果标记周期太小，可能会由于负反馈链路的时延导致存储在发送端的dpb中的前向长期参考帧不能真正的被用于进行参考编码，也就相当于造成了发送端的dpb中存储资源的浪费。
99.而如前所述，如果标记周期太大，在需要进行恢复时，发送端最新标记出的前向长期参考帧很可能距离当前时刻较远，导致在当前时刻生成恢复帧时，只能采用距离当前时刻较远的前向长期参考帧进行编码。这样，在进行恢复帧的编码时，编码参考距离被拉大，导致编码的得到的恢复帧和参考帧之间的相似度变小，从而需要较大的码率才能保证图像的画质(即清晰度)。但在码率达到一定程度时，码率对视频的清晰度的改善效果显著下降，且码率的增大会导致视频文件的体积过大。所以，如果标记周期太大，则难以在视频的清晰度和视频文件的体积之间进行平衡。
100.本公开中的发明人发现了上述问题的存在，所以在本公开中，在涉及一个接收端的场景中，可以根据该接收端对应的往返时延和第一预设等待时段对应的第一预设等待时长确定标记周期。例如，确定出该接收端对应的往返时延和第一预设等待时段对应的第一预设等待时长之间的第一和值，将标记周期配置为等于或者稍大于该第一和值。
101.发送端在接收到接收端发送的第一恢复请求时，需要经历的时间刚好是往返时延加上第一预设等待时段对应的第一预设等待时长，即发送端向接收端发送视频帧，接收端在等待第一预设等待时段对应的第一预设等待时长后向发送端发送第一恢复请求，在第一恢复请求到达发送端时，需要经历的时间刚好是往返时延加上第一预设等待时段对应的第一预设等待时长。
102.而在本公开中，标记周期最小也要等于往返时延加上第一预设等待时段对应的第一预设等待时长，也就是说，在发送端接收到第一恢复请求时，发送端最多经历了一个标记周期，最多重新标记出了一个前向长期参考帧，即发送端的dpb中存储的前向长期参考帧没有被频繁的更新，所以在发送端的dpb中无法找到确定出的目标前向长期参考帧的可能性也就降低了。同时，由于标记周期没有过多的大于上述的第一和值，即标记周期不至于过大，所以在根据接收端发送的第一恢复请求进行编码时，也会降低确定出的目标前向长期参考帧距离当前时刻太远，而导致编码参考距离被拉大的可能性。从而在保证能够使用确定出的目标前向长期参考帧进行编码的同时，确保编码参考距离不会过大，进而在保证视频清晰度的同时尽量保证接收端可以正常解码。
103.进一步的，本公开中，在涉及多个接收端的场景中，可以确定出多个接收端对应的往返时延中的最小往返时延，并确定出最小往返时延和第一预设等待时段对应的第一预设等待时长之间的第二和值，将标记周期配置为等于或者稍大于第二和值。这样，对于最小往返时延的接收端而言，不会因为标记周期太大而导致编码参考距离变大，也不会因为标记周期太小，而导致无法在发送端的编码器dpb中找到确定出的目标前向长期参考帧，所以，首先可以保证最小往返时延对应的接收端不仅可以成功解码，也可以在视频的清晰度和视频文件的大小之间进行较好的平衡。
104.而对于其它的往返时延比最小往返时延大的接收端而言，一方面，将标记周期配置为等于或稍大于上述的第二和值，虽然可能会由于标记周期较小，导致最新标记出的前向长期参考帧仅被往返时延较小的接收端接收成功，并没有被往返时延较大的接收端接收成功，进而导致往返时延较大的接收端无法成功解码，但这只是极端情况，大多数情况下，在标记周期等于或稍大于上述的第二和值时，可以满足最新标记出的前向长期参考帧可以被尽可能多的接收端接收成功；另一方面，由于基于最小往返时延确定出的标记周期相比于基于最大往返时延确定出的标记周期小，所以，可以避免编码参考距离过大，进而对于每个接收端而言，都可以在视频清晰度和视频文件大小之间进行一个良好的平衡。因此，基于最小往返时延与第一预设等待时段对应的第一预设等待时长之和确定出的标记周期，可以在保证每个接收端都可以在视频清晰度和视频文件大小之间进行一个良好的平衡的同时，确保尽可能多的接收端都能成功解码。
105.对于涉及多个接收端的场景而言，如果是确定出多个往返时延中的最大往返时延与第一预设等待时段对应的第一预设等待时长的第三和值，将标记周期配置为等于或稍大于该第三和值。这样，对于往返时延最大的接收端而言，不会因为标记周期太大而导致编码参考距离变大，也不会因为标记周期太小，而导致无法在发送端的编码器dpb中找到确定出的目标前向长期参考帧，所以，首先可以保证最大往返时延对应的接收端不仅可以成功解码，也可以在视频的清晰度和视频文件的大小之间进行较好的平衡。
106.而对于其它的往返时延比最大往返时延小的接收端而言，一方面，由于标记周期
较大，所以最新标记出的前向长期参考帧被尽可能多的接收端都接收成功的可能性会变大，因此其可以保证尽可能多的接收端都能成功解码，但另一方面，由于基于最大往返时延确定出的标记周期较大，所以编码参考距离会被拉大。因此，基于最大往返时延确定标记周期时，虽然可以最大程度上保证尽可能多的接收端都能成功解码，但会由于标记周期较大而使得编码参考距离被拉大，进而导致每个接收端都难以在视频的清晰度和视频文件的大小之间进行一个较好的平衡。
107.所以，通过本公开的确定标记周期的方法，无论对于单个接收端而言，还是对于多个接收端而言，都可以确定出一个合适的标记周期。一方面，可以避免由于标记周期太大而使得编码时的参考距离太大，进而导致难以在视频的清晰度和视频文件的大小之间进行平衡；另一方面，可以避免由于标记周期太小，而频繁的更新第一存储单元中存储的前向长期参考帧，进而导致在需要进行前向长期参考帧编码时，无法从第一存储单元中获取到可以用于进行视频流恢复的目标前向长期参考帧。
108.此外，在本公开中，标记周期与往返时延有关，而往返时延是动态变化的，所以标记周期也会随着往返时延的变化而动态变化，这样，可以实时的根据网络状态确定标记前向长期参考帧的周期，以进一步的在视频的清晰度和视频文件的大小之间进行良好的平衡的同时，保证尽可能多的接收端都可以成功进行解码。
109.由于往返时延是实时变化的，在本公开中，可以对其进行平滑处理，如在一个时间窗口内确定往返时延的平均值，然后在下一个时间窗口内使用该平均值进行前向长期参考帧的标记。或者根据一定的采样周期对往返时延进行采样，以对往返时延进行更新，从而根据更新后的往返时延更新标记周期。当然，也可以不对往返时延进行平滑或采样处理，根据实时反馈的往返时延，确定出实时变化的标记周期，以基于实时变化的标记周期进行前向长期参考帧的实时动态标记，本示例性实施方式对此不做特殊限定。
110.在本公开中，传输的视频流中的某个帧如果被标记为ltr帧，就表示该帧可以被用于长期参考帧编码，但该帧最终不一定实际的被用于长期参考帧编码，只有在接收端向发送端发送第一恢复请求时，发送端才会从第一存储单元中确定出最近一次被接收端所成功接收的前向长期参考帧，将其作为目标前向长期参考帧，才会被真正的用于进行参考编码。
111.发送端在响应于接收端发送的第一恢复请求，确定出目标前向长期参考帧后，在步骤s220中，发送端可以根据所述目标前向长期参考帧进行编码，以得到恢复帧。然后，在步骤s230中，发送端可以向接收端发送根据目标前向长期参考帧进行编码得到的恢复帧。
112.在本公开中，当在网络较差的情况下发送视频流时，网络可能存在数据丢包，进而导致接收端出现卡顿。此时，接收端可以主动向发送端发送第一恢复请求，而发送端可以根据接收端发送的第一恢复请求，利用目标前向长期参考帧进行编码，从而得到恢复帧，并且将恢复帧发送给接收端，以避免接收端出现长时间的卡顿。
113.在一种可选的实施方式中，发送端还可以根据接收端发送的第二恢复请求进行视频流的传输。示例性的，图4示出了根据本公开实施方式的一种发送端根据接收端发送的第二恢复请求进行视频流传输的方法的流程示意图。示例性的，参考图4，该方法可以包括步骤s410至步骤s420。其中：
114.在步骤s410中，响应于接收端发送的第二恢复请求，根据网络状态信息，确定针对于丢包视频帧的发送方式。
115.在一种可选的实施方式中，第二恢复请求由所述接收端响应于第二预设条件的达成而产生，第二预设条件包括接收端在第二预设等待时段内未接收到可被成功解析的视频帧。其中，未接收到可被成功解析的视频帧的理解可以参考在上述的步骤s210中的相关说明，此处不再进行赘述。
116.在一种可选的实施方式中，第二预设等待时段与所述第一预设等待时段具有相同的起始点，换言之，第二预设等待时段的起始点也可以包括接收端最近一次成功解析完视频帧的时刻，且所述第一预设等待时段对应的第一预设等待时长大于所述第二预设等待时段对应的第二预设等待时长。
117.参考图5，图5所示的时间轴中的时间点o可以表示接收端最近一次成功解析完视频帧的时刻,也即第一预设等待时段和第二预设等待时段的起点。以图5中的时间点o为起始点，时间点o到时间点t2对应的线段可以表示第二预设等待时段、时间点o到时间点t1对应的线段可以表示第一预设等待时段，线段ot1的长度大于线段ot2的长度，即第一预设等待时段对应的第一预设等待时长大于第二预设等待时段对应的第二预设等待时长。
118.在一种可选的实施方式中，第一预设等待时段对应的第一预设等待时长大于0.5秒且小于1秒，如图5中的线段ot1所表示的时长大于0.5秒且小于1秒，即以单位长度为基准，线段ot1的长度可以为大于0.5个单位长度且小于1个单位长度中的任意长度。第二预设等待时段对应的第二预设等待时长大于0秒且不大于0.5秒，如图5中的线段ot2所表示的时长大于0秒且不大于0.5秒，即以单位长度为基准，线段ot2的长度可以为大于0个单位长度且小于0.5个单位长度中的任意长度。当然，第一预设等待时段对应的第一预设等待时长和第二预设等待时段对应的第二预设等待时长都可以根据用户需求进行自定义确定，只需要满足第一预设等待时长大于第二预设等待时长即可，本示例性实施方式对此不做特殊限定。
119.举例而言，接收端在等待时长大于第二预设值(即第二预设等待时长)时，如果还没有获取到可被成功解析的视频帧，则可以先向发送端发送第二恢复请求，以请求发送端根据第二恢复请求对应的第二恢复方式进行视频流的恢复。但是第二恢复请求可能恢复失败，即根据第二恢复请求发送的视频帧在传输的过程中可能会再次丢包，导致接收端还是未能获取到可成功解析的视频帧，而接收端的等待时间从向发送端发送第二恢复请求的时刻起也一直在延续，即接收端的等待时长一直在增加，所以，在接收端的等待时长大于第一预设值(即第一预设时长)时，如果还没有获取到可被成功解析的视频帧，则接收端可以向发送端发送第一恢复请求，以请求发送端根据第一恢复请求对应的第一恢复方式进行视频流的恢复。
120.例如，如果接收端在等待0.5秒后，仍然没有获取到可解码的视频帧，则可以向发送端发送第二恢复请求，因为接收端发送的第二恢复请求到达发送端有传输延时，且发送端根据第二恢复请求发送的视频帧到达接收端也有传输延时，所以接收端会继续等待，如果接收端在继续等待0.4秒后，也就是说共计等了0.9秒(即第一预设等待时段对应的第一预设等待时长为0.9)后，还没有获取到可解码的视频帧，就说明第二恢复请求恢复失败了，即根据第二恢复请求发送的视频帧在传输的过程中再次出现了丢包，则接收端可以向发送端发送第一恢复请求，以使用第一恢复请求对应的恢复方式进行视频帧的恢复，从而避免接收端长时间的卡顿。
121.在一种可选的实施方式中，丢包视频帧包括接收端因丢包而未能成功解析的原视频帧数据，针对于丢包视频帧的发送方式可以包括重传方式或前向纠错方式。
122.第二恢复请求用于指示发送端根据当前的网络状态信息确定当前针对于丢包视频帧的发送方式为重传方式还是前向纠错方式。其中，网络状态信息可以包括往返时延。
123.示例性的，根据网络状态信息，确定向所述接到端发送丢包视频帧的方式，包括：在往返时延小于第一阈值时，确定针对于丢包视频帧的发送方式为重传方式；在往返时延大于或等于所述第一阈值时，确定针对于所述丢包视频帧的发送方式为前向纠错方式。
124.举例而言，当网络中发生丢包时，可以首先利用重传方式或fec(forward error correction，前向纠错)方式进行抗丢包恢复。对于重传和fec而言，二者适用的网络场景不同。当rtt(round-trip time，往返时延，网络中来回往返一次的耗时)较小时，重传的性价比较高，既可以对抗丢包，又可以保证视频清晰度，所以发送端可以采用重传的方式进行丢包对抗；当rtt较大时，由于重传效率较低，所以可以利用fec进行恢复，以保证通信的实时性，但是fec会消耗更多的流量。换言之，重传是通过牺牲延时进行抗丢包，fec是通过牺牲流量进行对抗丢包，所以二者的适用的网络场景不一样。对于不同的应用场景，可以选择不同的方式进行抗丢包，例如，在实时互动场景，对实时性要求较高，所以可以使用fec进行丢包对抗，而对于一些实时性要求不高的场景，则可以使用重传进行丢包对抗。
125.其中，重传方式是根据rtp(real-time process，实时传输协议)的序列号来判断是否丢包，正常情况下序列号是连续的。接收端如果发现数据丢失，则向发送端发出第二恢复请求，请求发送端发送指定数据包(即丢失的数据包)。
126.fec是一种编码方法，通过在传输中引入冗余信息来提高数据可靠性。在网络数据传输中主要有丢失和错误两种差错。错误的原因是某些比特数据发生畸变；丢失的原因是某些数据包没有收到。底层协议通常需要考虑这两种情况，如链路层的fec使用差错校正码，在同时出现丢包和错误两种差错的情况下，仍然能重新恢复出正确的数据。fec的主要思想是：k个数据包在发送端经过冗余编码后生成n个数据包，将n个数据包发送端接收端，接收端收到至少任意k个数据包就可以通过译码使原码数据还原。n-k为冗余校验信息的数量。
127.在步骤s410中根据网络状态信息确定出针对于丢包视频帧的重传方式后，在步骤s420中，根据确定的发送方式向所述接收端发送所述丢包视频帧。
128.考虑到基于重传或fec方式进行视频帧的恢复时，其编码参考距离没有变，所以对清晰度没有损失，但在长时间卡顿的情况下，其可能难以进行视频流的恢复；而基于第一恢复请求使用目标前向长期参考帧进行重新编码的方式，对于得到的恢复帧而言，其编码参考距离被拉大，所以清晰度有所降低，但其可以保证视频的流畅度，在长时间卡顿的情况下，仍然有较大的可能进行视频流的恢复。所以在本公开中，可以先使用重传或fec方式尝试进行恢复，以最大可能的保证视频图像的清晰度，在重传或fec方式尝试不成功时，再使用目标前向长期参考帧进行重新编码，以保证视频流的整体流畅性。二者结合，最大限度的进行视频的清晰度与流畅性之间的平衡。
129.但是，在极端弱网的情况下，如突发的50％以上的高丢包或者网络突然的拥塞导致的丢包，目标前向长期参考帧可能也无法对抗丢包，所以接收端可以向发送端发送第三恢复请求，以使得发送端基于关键帧进行视频流的丢包恢复。
130.示例性的，图6示出了根据本公开实施方式的一种发送端根据接收端发送的第三恢复请求进行视频流传输的方法的流程示意图。参考图5，该方法可以包括步骤s610至步骤s620。其中：
131.在步骤s610中，响应于接收端发送的第三恢复请求，编码生成关键帧。
132.在一种可选的实施方式中，第三恢复请求可以包括pli(picture loss indication)消息。其中，pli消息用于指示发送端编码生成关键帧，并向接收端发送该关键帧。
133.关键帧在视频流中也可以称之为i帧，关键帧在解码时不需要依赖其它帧就可以独立解码。
134.在一种可选的实施方式中，第三恢复请求由所述接收端响应于第三预设条件的达成而产生；所述第三预设条件包括所述接收端在第三预设等待时段内未接收到可被成功解析的视频帧。
135.其中，未接收到可被成功解析的视频帧的理解仍然可以参考在上述的步骤s210中的相关说明，此处不再进行赘述。
136.在一种可选的实施方式中，所述第三预设等待时段与所述第一预设等待时段具有相同的起始点，换言之，第三预设等待时段的起始点也可以包括接收端最近一次成功解析完视频帧的时刻，且所述第三预设等待时段对应的第三预设等待时长大于所述第一预设等待时段对应的第一预设等待时长。
137.参考图7，图7所示的时间轴中的时间点o可以表示接收端最近一次解析完视频帧的时刻，也即第二预设等待时段和第三预设等待时段的起点。以图7中的时间点o为起始点，时间点o到时间点t2对应的线段可以表示第二预设等待时段、时间点o到时间点t3对应的线段可以表示第三预设等待时段，线段ot3的长度大于线段ot2的长度，即第三预设等待时段对应的第三预设等待时长大于第二预设等待时段对应的第二预设等待时长。
138.在一种可选的实施方式中，所述第一预设等待时段对应的等待时长大于0.5秒且小于1秒，如图7中的线段ot1所表示的时长大于0.5秒且小于1秒，即以单位长度为基准，线段ot1的长度可以为大于0.5个单位程度且小于1个单位长度中的任意长度。所述第三预设等待时段对应的时长不小于1秒且不大于3秒，如图7中的线段ot3所表示的时长不小于1秒且不大于3秒，即以单位长度为基准，线段ot3的长度可以为不小于1个单位长度且不大于3个单位长度的任意长度。
139.举例而言，在弱网情况下，即网络存在丢包的情况下，接收端从最近一次成功解析完视频帧的时刻起，等待的时长达到第一预设等待时段对应的第一预设等待时长时，还没有获取到可成功解析的视频帧，则接收端可以向发送端发送第一恢复请求。由于第一恢复请求的传输存在延时，接收端在继续等待一段时间后，如达到第三预设等待时段对应的第三预设等待时长时，还没有获取到可成功解析的视频帧，则说明第一恢复请求可能恢复失败，即基于第一恢复请求生成的恢复帧在传输的过程中可能再次出现了丢包，则接收端可以向发送端发送第三恢复请求，以请求发送端基于pli的方式进行视频流的恢复。
140.在本公开的一种可选的实施方式中，在弱网情况下，接收端可以根据不同的等待时段对应的不同等待时长，向发送端发送不同的恢复请求，以请求发送端根据不同的方式进行视频流的恢复。如，可以先尝试使用重传或fec方式进行恢复，如果接收端继续等待一
段时间未能恢复成功，再请求发送端使用基于目标前向长期参考帧的方式进行恢复，如果接收端再继续等待一段时间还未恢复成功，再请求发送端使用pli的方式进行恢复。
141.例如，参考图8所示，线段ot2表示第一预设等待时段、线段ot2表示第二预设等待时段、线段ot3表示第三预设等待时段。以第一预设等待时段对应的第一预设等待时长为0.5秒、第二预设等待时段对应的第二预设等待时长为1秒、第三预设等待时段对应的第三预设等待时长为3秒为例，接收端从最近一次成功解析完视频帧的时刻，即图8中的o时刻起，在等待时长达到0.5秒时，接收端还未获取到可成功解析的视频帧，则可以向发送端发送第二恢复请求，以让发送端基于重传或fec方式进行视频流的恢复；如果在发出第二恢复请求的时刻起再继续等待0.5秒，即从o时刻起总共等待时长达到1秒时，接收端还是未获取到可成功解析的视频帧，则可以向发送端发送第一恢复请求，以请求发送端基于目标前向长期参考帧进行视频流的编码恢复；如果在发出第一恢复请求的时刻起再继续等待2秒，即从o时刻起总共等待的时长达到3秒时，接收端还是未获取到可成功解析的视频帧，则接收端可以向发送端发送第三恢复请求，以请求发送端强制编码关键帧，以进行视频流的恢复。
142.如前所述，接收端在一定的时间段内没有接收到可成功解析的视频帧，如上述的第三预设等待时段内，接收端没有获取到可成功解析的视频帧，就可以向发送端发送第三恢复请求，发送端在接收到第三恢复请求，如pli消息后，可以强制编码生成关键帧。
143.发送端编码生成关键帧后，可以在步骤s620中，向所述接收端发送所述关键帧。
144.举例而言，发送端根据接收端发送的第三恢复请求编码生成关键帧后，可以将编码生成的关键帧发送给接收端，以使得接收端可以根据该关键帧进行独立解码，以恢复视频流。等关键帧到达接收端后，接收端可以在不利用前面丢包的视频帧的情况下进行解码，从而缓解卡顿。
145.在传输的视频流中可以包括关键帧和非关键帧。其中，关键帧也可以称之为i帧，i帧可以通过帧内编码，其在进行解码时不需要依赖其它帧就可以独立解码；非关键帧也可以称之为p帧p帧可以通过帧间编码，其在进行解码时需要依赖相应的参考帧才能解码。
146.在pli方式中，其需要依靠i帧进行画面恢复，对于编码器而言，i帧的编码耗时会比p帧大，i帧的帧大小也比p帧大，在涉及多个接收端的场景中，如多人会议场景中，某个接收端的网络环境较差导致其频繁请求关键帧编码时，也会对其他网络环境好的接收端产生影响，网络环境好的接收端会因为网络环境差的接收端频繁收到i帧而导致卡顿。为了避免这种情况发生，所以接收端请求pli的超时时间可以较长一些，如在等待3秒后还没有获取到可被成功解析的视频帧，则接收端可以向发送端发送第三恢复请求，也就意味着，接收端在等待3秒以后才能恢复画面。
147.与此同时，对于已经发生卡顿的接收者来说，迫切需要i帧恢复画面。而i帧跟p帧相比，编码耗时更长，帧大小更大，在弱网时更不容易传输。如果i帧在传输过程中再次发生丢包且无法恢复，接收端将卡顿更长时间，从而陷入恶性循环。所以，本公开中，在极端弱网情况下，在使用pli方式进行恢复之前，增加了基于目标前向长期参考帧进行恢复的方式，即接收端可以先向发送端发送第一恢复请求，即先请求发送端基于目标前向长期参考帧进行编码恢复。如果在第三预设时间段内第一恢复请求还未恢复成功，再向发送端发送第三恢复请求。这样，一方面，当第一恢复请求恢复成功时，即接收端在等待时长还未达到第三预设等待时长时，就对发送端发送的基于第一恢复请求生成的恢复帧进行了成功解析，所
以可以避免接收端在极端弱网情况下的长时间等待；另一方面，只有在第一恢复请求未恢复成功的情况下，才向发送端发送第三恢复请求，以请求发送端通过关键帧进行视频流的恢复所以可以避免弱网接收端频繁的请求关键帧编码对非弱网接收端的影响；再一方面，由于关键帧编码的信息量较多，其在极端弱网环境下可能再次丢包，而增加了基于第一恢复请求进行恢复的方式，则可以降低使用关键帧编码进行丢包恢复的概率，所以本公开通过第一恢复请求和第三恢复请请求的结合，还可以降低弱网环境下的二次丢包带来的恶性循环的可能性。
148.在一种可选的实施方式中，在本公开中，发送端在未接收到所述接收端发送的任一恢复请求时，根据当前视频帧的前一帧对所述当前视频帧进行编码，以得到编码视频流；将所述编码视频流发送至所述接收端。
149.换言之，在本公开中，在正常情况下，发送端可以基于ippp(p帧参考前一帧编码)模式进行编码，即非关键帧参考前一帧编码的编码模式进行编码。由于前后两帧的内容相似度最大，因此，ippp模式下压缩率和图像质量都可以得到有效保障。
150.如果在弱网环境下，即丢包时，发送端可以根据接收端发送的不同恢复请求，自适应的选择合适的恢复方式进行视频流的恢复。对于第一恢复请求、第二恢复请求、第三恢复请求而言，其对应的等待时段就可以在一定程度上反映当前的网络状况，等待时段越长，说明网络状况越差。
151.示例性的，图9示出了根据本公开实施方式的一种发送端在编码时进行参考帧选择的过程的示意图。在图9中，数字1至8分别表示第1帧至第8帧，图9中的91所指示的“x”用于表示第6帧出现了丢包，对于图9中的每个箭头线而言，箭头线中的前头所指示的帧是参考箭头线的起点所指示的帧进行参考编码的，图9中的第1帧和第5帧是两个ltr标记帧，即标记出的前向长期参考帧。对于ltr标记帧而言，其只用于指示该帧可以被用于长期参考帧编码，但并不一定被实际的用于长期参考帧编码，发送端只有在接收端第一恢复请求时，才会使用当前最近一次被接收端接收成功的ltr帧进行参考编码。图9中的第8帧为基于接收端在帧6丢失后而向发送端发送第一恢复请求后，发送端参考最近一次被接收端成功接收的前向长期参考帧(即图9中的第5帧)，进行编码得到的ltr恢复帧。
152.下面，结合图9对本公开的一种示例性实施方式中，发送端在编码时进行参考帧选择的过程进行具体说明。发送端在未接收到任一恢复请求的情况下，即在网络正常的情况下，分别基于向前一帧参考编码的方式编码了当前视频流中的第1帧、第2帧、第3帧、第4帧、第5帧、第6帧、第7帧。其中，发送端根据标记周期将第1帧和第5帧标记为前向长期参考帧，如图9中第1帧和第5帧分别被标记为ltr1和ltr2。在传输过程中，第6帧出现了丢包，即接收端没有成功解析到第6帧。接收端在等待第一预设时段对应的第一预设时长后，仍然没有获取到可成功解析的视频帧。所以，接收端向发送端发送了第一恢复请求，发送端在接收到第一恢复请求后，根据被接收端最近一次接收成功的前向长期参考帧，即ltr2，也就是已经被接收端成功接收的第5帧进行参考编码，得到了第8帧(即ltr恢复帧)，然后将第8帧发送给接收端。也就是说，第8帧是发送端基于接收端的nack(即复反馈)，参考最近一次被接收端接收成功的前向长期参考帧ltr2(即第5帧)而生成的ltr恢复帧。由于接收端已经成功接收到了第5帧，所以接收端在接收到第8帧后，可以基于成功接收的第5帧对第8帧进行解码。
153.在本公开中，在正常网络情况下，即未发生丢包的情况下，采用参考前一帧进行编
码的方式进行视频流的编码传输，其可以保证接收端显示的视频图像的清晰度。在网络状况较差时，又根据不同的预设等待时段，对不同程度的差网络环境自适应的使用不同的视频帧恢复方式进行不同的处理，以在视频图像的清晰度和视频流的流畅性之间进行更好的平衡。
154.进一步的，对于极端弱网环境而言，本公开中增加了接收端发送第一恢复请求以请求基于目标前向长期参考帧进行恢复卡顿的方案，即基于ltr恢复帧进行恢复卡顿的方案，该方案的触发时机介于第二恢复请求和第三恢复请求之间，由于ltr恢复帧在帧大小和编码耗时上比关键帧有优势，所以有利于改善极端弱网环境下的卡顿。与此同时，在多人会议场景下，通过先发送第一恢复请求，在第一恢复请求不成功的情况下再发送第二恢复请求的方式，可以大大减少请求关键帧进行恢复的次数，从而降低关键帧对会议中其它与会者接收体验造成的副作用。
155.接下来，图10示出了根据本公开实施方式的一种应用于接收端的视频流数据的传输方法的流程示意图。该方法可以应用于接收端。该方法可以包括步骤s1010。其中：
156.在步骤s1010中，响应于在第一预设等待时段内未获取到可被成功解析的视频帧，向发送端发送第一恢复请求。
157.在一种可选的实施方式中，图10所述方法中提及到的未获取到可被成功解析的视频帧可以包括：接收端没有获取到视频帧的相关数据，而无法对视频帧进行解析；还可以包括：接收端获取到了视频帧的相关数据，但是接收端获取到的视频帧的相关数据不完整，由于获取到的视频帧的相关数据不完整，所以接收端仍然无法成功对视频帧进行解析。
158.在一种可选的实施方式中，步骤s1010中的第一恢复请求用于指示与接收端进行通信的发送端基于目标前向长期参考帧进行编码，以生成恢复帧。其中，目标前向长期参考帧为由所述发送端标记的且最近一次被所述接收端所成功接收的前向长期参考帧。
159.其中，发送端在根据接收端的第一恢复请求生成恢复帧后，可以将恢复帧发送至接收端。
160.在一种可选的实施方式中，所述前向长期参考帧由与所述接收端进行通信的发送端根据标记周期在传输的视频流中进行标记；所述标记周期由所述发送端基于所述第一预设等待时段和网络状态信息确定。
161.在一种可选的实施方式中，所述网络状态信息包括一个往返时延，所述往返时延对应于一个接收端；所述标记周期由所述发送端基于所述第一预设等待时段和网络状态信息确定，包括：所述标记周期由所述发送端基于所述第一预设等待时段对应的第一预设等待时长与所述往返时延之和确定，其中，所述标记周期不小于二者之和。
162.在一种可选的实施方式中，所述网络状态信息包括多个往返时延，多个往返时延分别对应于多个接收端；所述标记周期由所述发送端基于所述第一预设等待时段和网络状态信息确定，包括：所述标记周期由所述发送端基于所述第一预设等待时段和多个往返时延中的最小往返时延确定。
163.在一种可选的实施方式中，所述标记周期由所述发送端基于所述第一预设等待时段和多个往返时延中的最小往返时延确定，包括：所述标记周期由所述发送端基于所述第一预设等待时段与所述最小往返时延之和确定，其中，所述标记周期不小于所述第一预设等待时段与所述最小往返时延之和。
164.举例而言，在图10所示的方法中，可以有多个接收端同时和发送端进行通信。任一接收端都可以分别响应于在第一预设等待时段内未获取到可被成功解析的视频帧，而向发送端发送第一恢复请求。且每个接收端由于所处的网络环境不同，其对应的往返延时也不相同，发送端可以根据每个接收端对应的往返时延中的最小往返时延和第一预设等待时段对应的第一预设等待时长，确定出标记周期。
165.其中，发送端根据第一预设等待时段和网络状态信息确定往返时延的具体实施方式已经在图2所示的方法中进行了详细说明，此处不再进行赘述。
166.示例性的，发送端根据确定出的标记周期在传输的视频流中标记出前向长期参考帧后，接收端根据参考帧标记可以从接收的视频流中确定出前向长期参考帧。
167.在一种可选的实施方式中，图10所示的方法还包括：接收端在接收到每个所述前向长期参考帧后，向所述发送端发送回复消息，所述回复消息用于表征所述前向长期参考帧已被所述接收端成功接收。其中，一个回复消息对应一个前向长期参考帧。换言之，接收端每成功接收一个前向长期参考帧，都要向发送端发送该前向长期参考帧被成功接收的回复消息。
168.在一种可选的实施方式中，图10所示的方法还包括：根据当前接收到的前向长期参考帧更新第二存储单元中存储的前向长期参考帧，所述第二存储单元与所述接收端对应。
169.举例而言，接收端当前接收到的前向长期参考帧，对于发送端而言，就是最近一次被接收端接收成功的前向长期参考帧。所以，接收端当前接收到的前向长期参考帧有可能被发送端用于进行参考编码，即可能会被确定为目标前向长期参考帧，因此，可以在与接收端对应的第二存储单元中存储当前接收到的前向长期参考帧。这样，当发送端向接收端发送了基于目标前向长期参考帧进行编码的恢复帧后，接收端可以从第二存储单元中获取到该目标前向长期参考帧，进而基于该目标前向长期参考帧进行解码。
170.也就是说，与接收端对应的第二存储单元中可以只存储接收端最近一次接收到的前向长期参考帧。即，随着新的前向长期参考帧的到来，接收端可以将之前存储的前向长期参考帧剔除，而将最新的前向长期参考帧存储至第二存储单元中。这样，既可以保证接收端能够成功的解码发送端发送的恢复帧，也可以避免存储过多的不必要的前向长期参考帧而造成的接收端的存储资源的浪费。
171.其中，第二存储单元可以为解码器dpb，即接收端的解码器对应的解码图像缓存器。
172.当然，与接收端对应的第二存储单元中也可以存储当前最新接收到的预设数量的前向长期参考帧，其中，预设数量可以根据用户需求进行自定义，如在第二存储单元为解码器dpb时，解码器dpb由于硬件条件的限制目前最多也只能存储15个帧，所以，也可以在与接收端对应的解码器dpb中存储接收端接收到的最新的15个前向长期参考帧，本示例性实施方式对此不做特殊限定。
173.在一种可选的实施方式中，图10所示的方法还包括：响应于在第二预设等待时段内未获取到可被成功解析的视频帧，向所述发送端发送第二恢复请求，所述第二恢复请求用于指示所述发送端根据网络状态信息确定针对于丢包视频帧的发送方式，所述发送方式包括重传方式或前向纠错方式，所述丢包视频帧包括所述接收端因丢包而未能成功解析的
原视频帧数据；所述第二预设等待时段与所述第一预设等待时段具有相同的起始点，且所述第一预设等待时段对应的第一预设等待时长大于所述第二预设等待时段对应的第二预设等待时长。
174.在一种可选的实施方式中，所述网络状态信息包括往返时延；所述第二恢复请求用于指示所述发送端根据所述网络状态信息确定针对于丢包视频帧的发送方式，包括：在所述往返时延小于第一阈值时，所述第二恢复请求指示所述发送端针对于丢包视频帧的发送方式为重传方式；
175.在所述接收端反馈的往返时延大于或等于所述第一阈值时，所述第二恢复请求指示所述发送端针对于丢包视频帧的发送方式为前向纠错方式。
176.在一种可选的实施方式中，所述第一预设等待时段对应的第一预设等待时长大于0.5秒且小于1秒，所述第二预设等待时段对应的第二预设等待时长大于0秒且不大于0.5秒。
177.举例而言，当在网络较差的环境下发送视频流时，即网络存储数据丢包时，接收端可以先等待第二预设等待时段对应的第二预设等待时长，如果在到达第二预设等待时段对应的第二预设等待时长时，仍未获取到可被成功解析的视频帧，则接收端可以向发送端发送第二恢复请求；由于接收端的第二恢复请求到达发送端存在时延，且发送端在根据第二恢复请求进行重传或fec方式进行视频帧的恢复后的传输过程中也存在时延，所以接收端可以继续等待，如果在总共的等待时间达到第二预设等待时段对应的第二等待时长时，接收端仍然没有获取到可被成功解析的视频帧，则其可以向发送端发送第一恢复请求。
178.在一种可选的实施方式中，图10所示的方法还可以包括：响应于在第三预设等待时段内未获取到可被成功解析的视频帧，向所述发送端发送第三恢复请求，所述第三恢复请求用于指示所述发送端向所述接收端发送关键帧；所述第三预设等待时段与所述第一预设等待时段具有相同的起始点，且所述第三预设等待时段对应的第三预设等待时长大于所述第一预设等待时段对应的第一预设时长。
179.在一种可选的实施方式中，所述第一预设等待时段对应的等待时长大于0.5秒且小于1秒，所述第三预设等待时段对应的等待时长不小于1秒且不大于3秒。
180.其中，第三恢复请求可以包括上述的pli消息。该pli消息可以用于指示发送端进行编码生成关键帧，并将生成的关键帧发送给接收端。
181.以第一预设等待时长为0.9秒、第二预设等待时长为0.5秒，第三预设等待时长为3秒为例。接收端在等待时长达到0.5秒时还没有获取到可被成功解析的视频帧，则可以向发送端发送第二恢复请求；由于第二恢复请求可能存在恢复失败的情况，所以接收端可以继续等待0.4秒，即总共等待时长达到0.9时如果还是没有获取到可被成功解析的视频帧，则接收端可以向发送端发送第一恢复请求；第一恢复请求也可能存在恢复失败的情况，所以接收端可以继续等待2.1秒，即总共等待时长达到3秒时如果还没有获取到可被成功解析的视频帧，则接收端可以向发送端发送第三恢复请求。
182.需要说明的是，在图10所示的方法中提及的第一预设等待时长、第二预设等待时长、第三预设等待时长都可以根据需求进行自定义，本示例性实施方式对此不做特殊限定。
183.在一种可选的实施方式中，图10所示的方法还可以包括：接收所述发送端发送的根据前一帧参考编码生成的编码视频流；其中，所述发送端在未接到任一恢复请求时，根据
前一帧参考编码生成编码视频流，并将所述编码视频流发送至所述接收端。
184.在本公开中，接收端只有在未成功获取到可解码的视频帧时，才会根据不同的等待时间主动向发送端发送不同的恢复请求，以使得发送端可以根据不同的恢复请求对应的恢复方式进行恢复。而在正常情况下，发送端会根据前一帧参考编码的方式生成编码视频流，并将其发送给发送端，如果网络正常的话，即不存在丢包的情况，接收端也就可以正常的接收到发送端发送的根据前一帧编码生成的编码视频流，这样在网络正常的情况下，可以不损失图像的清晰度。
185.在本公开中，发送端可以根据接收端反馈的恢复需求，采用不同的恢复方式进行视频的恢复。其中，本公开根据接收端反馈的不同恢复请求，采用的恢复方式包括：基于第一恢复请求采用的重传或fec方式、基于第二恢复请求采用的根据目标前向长期参考帧进行参考编码，以生成恢复帧的方式、基于第三恢复请求采用关键帧编码进行恢复的方式。对于这三种恢复方式而言，在网络状况不是特别差的情况下，重传或fec的方式可以在不损失视频的清晰度的同时进行视频的恢复，所以其代价较小；相比于重传或fec的恢复方式而言，基于目标前向长期参考帧进行参考编码，以生成恢复帧的方式，在一定程度上降低了视频的清晰度，所以其代价较大；而对于采用关键帧编码进行恢复的方式而言，如前所述，在涉及多个接收端的场景中，弱网接收端频繁的请求关键帧恢复会到非弱网接收端产生影响，且关键帧需要传输的信息量大，在弱网环境下更不容易传输，可能会出现再次丢包，而导致接收端的卡顿时间更长，从而陷入恶性循环，所以采用关键帧编码进行恢复的方式在3种恢复方式中，代价最大。
186.基于此，在本公开的一种示例性实施方式中，可以根据3种恢复方式的代价从小到大的顺序，先使用重传或fec进行恢复，如果恢复不成功，再牺牲一些清晰度，使用目标前向长期参考帧进行恢复，如果还没有恢复成功，再使用关键帧进行编码恢复。从而，可以根据不同的网络状况，从3种方式中选择出适合当前网络状况的恢复方式，以尽可能快速的进行视频流的恢复，避免接收端出现长时间的卡顿。进而，可以在视频流的流畅性和视频的清晰度之间进行一个较好的平衡。
187.需要说明的是，图10所示实施例中的具体实施方式和具体实施细节可以对应的参考图2所示实施例中的说明，如图10所示实施例中的标记周期、第一预设等待时段、第二预设等待时段、第三预设等待时段、第一恢复请求、第二恢复请求、第三恢复请求等均与图2所示实施例的对应技术术语完全相同，此处不再进行赘述。
188.图11示出了根据本公开实施方式的一种视频流数据的传输过程中发送端和接收端进行交互的流程示意图。参考图11，该方法可以包括步骤s1110至步骤s1190。其中：
189.在步骤s1110中，发送端111根据前一帧进行参考编码，以生成编码视频流。
190.举例而言，在正常情况下，也就是发送端111未接收到任何恢复请求的情况下，说明当前网络正常，没有出现丢包卡顿的情况，则发送端就会一直根据向前一帧参考的原则进行编码，前后两帧的图像内容相似度最大，因此在这种编码方式下编码压缩率以及图像质量都得到了保证。
191.发送端在编码的同时可以根据标记周期周期性的在编码的视频流中标记出一些长期参考帧，这些长期参考帧可以被用于远距离参考编码。标记出的前向长期参考帧可以被记为ltr标记帧。
192.需要说明的是，标记出的ltr标记帧并不一定会用于长期参考帧编码，只要该ltr标记帧不用于长期参考帧编码，参考距离仍然是参考前一帧的方式，图像质量不会受牺牲。
193.在步骤s1120中，发送端111将编码视频流发送至接收端112。
194.举例而言，发送端可以将按照前一帧进行参考编码且标记了前向长期参考帧的编码视频流发送给接收端。
195.在步骤s1130中，接收端112向发送端发送回复消息。
196.其中，该回复消息用于表征接收端112已经成功接收端发送端111发送的编码视频流中的前向长期参考帧。一个回复消息对应于一个前向长期参考帧。
197.举例而言，接收端每接收到一个ltr标记帧后，立即对该ltr标记帧进行ack反馈，通知发送端此时已经成功接收到了相应的ltr标记帧，该帧可用于长期参考帧编码。
198.在步骤s1140中，接收端112向发送端111发送第二恢复请求。
199.举例而言，当在弱网情况下进行视频流的发送时，即网络存在数据丢包时，接收端从最近一次成功解析完视频帧的时刻起，等待了第二预设等待时段对应的第二预设等待时长后，仍然没有获取到可解码的视频帧时，为了避免长时间的卡段，接收端立即向发送端发送第二恢复请求，请求发送端使用重传或fec方式进行视频帧的传输，以尽快进行视频流的恢复。
200.在步骤s1150中，发送端111基于重传或fec方式向接收端发送视频帧。
201.举例而言，发送端在接收到接收端发送的第二恢复请求后，可以立即以重传或fec的方式向发送端发送视频帧。其中，基于重传或fec的方式进行视频帧传输的具体实施方式已经上述的图2所示的方法中进行了详细描述，此处不再进行赘述。
202.在一种示例性的实施方式中，如果重传或fec方式恢复成功，即接收端从最近一次成功解析完视频帧的时刻起，在等待时长还未达到第一预设等待时段对应的第一预设等待时长时，就已经获取到可被成功解析的视频帧，则接收端可以继续进行下一个待解析的视频帧的获取与解析。
203.在另一种示例性的实施方式中，如果重传或fec方式恢复失败，也即接收端从最近一次成功解析完视频帧的时刻起，在等待时长达到第一预设等待时段对应的第一预设等待时长时，还未获取到可被成功解析的视频帧，则转至步骤s1160。
204.在步骤s1160中，接收端112向发送端111发送第一恢复请求。
205.举例而言，如前所述，当在弱网情况下进行视频流的发送时，即网络存在数据丢包时，从最近一次成功解析完视频帧的时刻起，在等待时长达到第一预设等待时段对应的第一预设等待时长时，还未获取到可被成功解析的视频帧的情况下，为了避免长时间的卡顿，接收端可以立即向发送端请求ltr恢复，即接收端立即向发送端发送第一恢复请求，以指示发送端根据目标前向长期参考帧进行编码，以得到恢复帧，并将得到的恢复帧发送给接收端。在步骤s1170中，发送端111向接收端112发送恢复帧。
206.举例而言，发送端收到接收端发送的ltr恢复请求之后，立即响应一个ltr恢复帧，该ltr恢复帧的编码参考帧是步骤s1130中收到的最新的ack回复消息所对应的前向长期参考帧，由于该前向长期参考帧是从接收端确认过已经成功接收的帧，那么当ltr恢复帧成功到达接收端时肯定能够正常解码，从而恢复画面的正常播放。
207.在一种示例性的实施方式中，如果第二恢复请求恢复成功，即接收端从最近一次
成功解析完视频帧的时刻起，在等待时长还未达到第三预设等待时段对应的第三预设等待时长时，就已经获取到可被成功解析的视频帧，则接收端可以继续进行下一个待解析的视频帧的获取与解析。
208.在另一种示例性的实施方式中，如果第二恢复请求恢复失败，也即接收端从最近一次成功解析完视频帧的时刻起，在等待时长达到第三预设等待时段对应的第三预设等待时长时，还未获取到可被成功解析的视频帧，则转至步骤s1180。
209.在步骤s1180中，接收端112向发送端111发送第三恢复请求。
210.在步骤s1190中，发送端111将编码得到的关键帧发送至接收端112。
211.举例而言，发送端在接收到接收端发送的第三恢复请求时，可以进行关键帧编码，以将编码得到的关键帧发送给发送端。这样，接收端在接收到关键帧时，可以不依赖于其它帧就可以独立的对关键帧进行解码，从而可以尽可能的进行视频帧的恢复。
212.如果第三恢复请求恢复成功，则接收端可以继续进行一个待解析视频帧的获取与解析。
213.在涉及多个接收端的场景中，如果第三恢复请求也恢复失败，则接收端可以继续向发送端发送第三恢复请求，直到接收端从最近一次成功解析完视频帧的时刻起，在等待时长达到第四预设等待时段对应的第四预设等待时长时，还未获取到可被成功解析的视频帧，则接收端可以停止向发送端发送任何恢复请求。也就是说，此时接收端的网络已经差到使用本公开的任一恢复方式都无法进行恢复了，为了避免弱网接收端对其它非弱网接收端的影响，则可以停止弱网接收端继续发送恢复请求。
214.在涉及一个接收端的场景中，其不会涉及到对其它接收端有影响的相关问题，所以如果第三恢复请求也恢复失败，则该一个接收端可以继续向发送端发送第三恢复请求，直到接收端从最近一次成功解析完视频帧的时刻起，在等待时长达到第四预设等待时段对应的第四预设等待时长时，还未获取到可被成功解析的视频帧，则该一个接收端可以停止向发送端发送任何恢复请求，也可以一直向发送端继续发送第三恢复请求，而不受第四预设等待时长的限制，直到恢复成功。
215.在本公开中，在正常网络情况下，采用参考前一帧进行编码的方式进行视频流的编码传输，其可以保证接收端显示的视频图像的清晰度。在网络状况较差时，又根据不同的预设等待时段对不同程度的差网络环境自适应的使用不同的视频帧恢复方式进行不同的处理，以在视频图像的清晰度和视频流的流畅性之间进行更好的平衡。
216.示例性装置
217.本公开示例性实施方式还提供一种作为发送端的视频流数据的传输装置。参考图12所示，该视频流数据的传输装置1200可以包括：第一恢复请求响应模块1210、恢复帧生成模块1220、恢复帧发送模块1230。其中：
218.第一恢复请求响应模块1210，被配置为响应于接收端发送的第一恢复请求，确定出目标前向长期参考帧；
219.恢复帧生成模块1220，被配置为根据所述目标前向长期参考帧进行编码，以得到恢复帧；
220.恢复帧发送模块1230，被配置为向所述接收端发送所述恢复帧；其中，所述目标前向长期参考帧为最近一次被接收端所成功接收的前向长期参考帧。
221.在一种可选的实施方式中，所述第一恢复请求由所述接收端响应于第一预设条件的达成而产生；所述第一预设条件包括所述接收端在第一预设等待时段内未接收到可被成功解析的视频帧。
222.在一种可选的实施方式中，所述装置还包括:标记周期确定模块，该模块被配置为所述发送端根据所述第一预设等待时段和网络状态信息，确定所述前向长期参考帧的标记周期，以基于所述标记周期对发往接收端的视频流添加参考帧标记，所述参考帧标记用于指示视频流中的相应帧为前向长期参考帧。
223.在一种可选的实施方式中，所述网络状态信息包括一个往返时延，所述往返时延对应于一个接收端；所述根据所述第一预设等待时段和网络状态信息，确定所述前向长期参考帧的标记周期，包括：将所述第一预设等待时段所对应的第一预设等待时长与所述往返时延求和，以基于二者之和确定所述前向长期参考帧的标记周期，其中，所述标记周期不小于所述二者之和。
224.在一种可选的实施方式中，所述网络状态信息包括多个往返时延，所述多个往返时延分别对应于多个接收端；所述根据所述第一预设等待时段和所述网络状态信息，确定所述前向长期参考帧的标记周期，包括：确定出多个往返时延中的最小往返时延；根据所述第一预设等待时段和所述最小往返时延，确定出所述前向长期参考帧的标记周期。
225.在一种可选的实施方式中，所述根据所述第一预设等待时段和所述最小往返时延，确定出所述前向长期参考帧的标记周期，包括：将所述第一预设等待时段所对应的第一预设等待时长与所述最小往返时延求和，以基于二者之和确定所述前向长期参考帧的标记周期，其中，所述标记周期不小于所述二者之和。
226.在一种可选的实施方式中，所述装置还包括：第一存储单元更新模块，该模块被配置为根据最新标记的前向长期参考帧更新第一存储单元中存储的前向长期参考帧，所述第一存储单元与所述发送端对应，所述第一存储单元用于存储预设数量的前向长期参考帧，所述预设数量为大于1任意整数；其中，响应于所述第一存储单元中所存储的前向长期参考帧超过所述预设数量，将所述第一存储单元中最早被标记的前向长期参考帧剔除。
227.在一种可选的实施方式中，所述第一恢复请求模块还可以被具体配置为：响应于接收端发送的第一恢复请求，从所述第一存储单元中存储的前向长期参考帧中确定出所述目标前向长期参考帧。
228.在一种可选的实施方式中，所述装置还包括：回复消息接收模块，该模块被配置为接收所述接收端发送的与每个前向长期参考帧对应的回复消息，所述回复消息用于表征所述前向长期参考帧已被所述接收端成功接收。
229.在一种可选的实施方式中，所述装置还包括：第二恢复请求响应模块，该模块被配置为响应于接收端发送的第二恢复请求，根据网络状态信息，确定针对于丢包视频帧的发送方式，以根据确定的发送方式向所述接收端发送所述丢包视频帧；所述丢包视频帧包括所述接收端因丢包而未能成功解析的原视频帧数据，所述发送方式包括重传方式或前向纠错方式。
230.在一种可选的实施方式中，所述第二恢复请求由所述接收端响应于第二预设条件的达成而产生；所述第二预设条件包括所述接收端在第二预设等待时段内未接收到可被成功解析的视频帧，其中，所述第二预设等待时段与所述第一预设等待时段具有相同的起始
点，且所述第一预设等待时段对应的第一预设等待时长大于所述第二预设等待时段对应的第二预设等待时长。
231.在一种可选的实施方式中，所述第一预设等待时段对应的第一预设等待时长大于0.5秒且小于1秒，所述第二预设等待时段对应的第二预设等待时长大于0秒且不大于0.5秒。
232.在一种可选的实施方式中，所述网络状态信息包括往返时延；所述根据网络状态信息，确定向所述接到端发送丢包视频帧的方式，包括：在所述往返时延小于第一阈值时，确定针对于丢包视频帧的发送方式为重传方式；在所述往返时延大于或等于所述第一阈值时，确定针对于所述丢包视频帧的发送方式为前向纠错方式。
233.在一种可选的实施方式中，所述装置还包括：第三恢复请求响应模块，该模块被配置为响应于接收端发送的第三恢复请求，编码生成关键帧；向所述接收端发送所述关键帧。
234.在一种可选的实施方式中，所述第三恢复请求由所述接收端响应于第三预设条件的达成而产生；所述第三预设条件包括所述接收端在第三预设等待时段内未接收到可被成功解析的视频帧，其中，所述第三预设等待时段与所述第一预设等待时段具有相同的起始点，且所述第三预设等待时段对应的第三预设等待时长大于所述第一预设等待时段对应的第一预设时长。
235.在一种可选的实施方式中，所述第一预设等待时段对应的等待时长大于0.5秒且小于1秒，所述第三预设等待时段对应的时长不小于1秒且不大于3秒。
236.在一种可选的实施方式中，所述装置还包括：前一帧参考编码模块，该模块被配置为在未接收到所述接收端发送的任一恢复请求时，根据当前视频帧的前一帧对所述当前视频帧进行编码，以得到编码视频流；将所述编码视频流发送至所述接收端。
237.本公开示例性实施方式还提供了一种作为接收端的视频流数据的传输装置，如图1300所示，该装置可以包括第一恢复请求发送模块1310。其中：
238.第一恢复请求发送模块1310，被配置为响应于在第一预设等待时段内未获取到可被成功解析的视频帧，向发送端发送第一恢复请求；其中，所述第一恢复请求用于指示所述发送端基于目标前向长期参考帧进行编码，以生成恢复帧；所述目标前向长期参考帧为由所述发送端标记的且最近一次被所述接收端所成功接收的前向长期参考帧。
239.在一种可选的实施方式中，所述前向长期参考帧由所述发送端根据标记周期在传输的视频流中进行标记；所述标记周期由所述发送端基于所述第一预设等待时段和网络状态信息确定。
240.在一种可选的实施方式中，所述网络状态信息包括一个往返时延，所述往返时延对应于一个接收端；所述标记周期由所述发送端基于所述第一预设等待时段和网络状态信息确定，包括：所述标记周期由所述发送端基于所述第一预设等待时段对应的第一预设等待时长与所述往返时延之和确定，其中，所述标记周期不小于二者之和。
241.在一种可选的实施方式中，所述网络状态信息包括多个往返时延，多个往返时延分别对应于多个接收端；所述标记周期由所述发送端基于所述第一预设等待时段和网络状态信息确定，包括：所述标记周期由所述发送端基于所述第一预设等待时段和多个往返时延中的最小往返时延确定。
242.在一种可选的实施方式中，所述标记周期由所述发送端基于所述第一预设等待时
段和多个往返时延中的最小往返时延确定，包括：所述标记周期由所述发送端基于所述第一预设等待时段与所述最小往返时延之和确定，其中，所述标记周期不小于所述第一预设等待时段与所述最小往返时延之和。
243.在一种可选的实施方式中，所述装置还包括：恢复消息发送模块，该模块被配置为在接收到每个所述前向长期参考帧后，向所述发送端发送回复消息，所述回复消息用于表征所述前向长期参考帧已被所述接收端成功接收。
244.在一种可选的实施方式中，所述装置还包括：第二存储单元更新模块，该模块被配置为根据当前接收到的前向长期参考帧更新第二存储单元中存储的前向长期参考帧，所述第二存储单元与所述接收端对应。
245.在一种可选的实施方式中，所述装置还包括：第二恢复请求发送模块，该模块被配置为响应于在第二预设等待时段内未获取到可被成功解析的视频帧，向所述发送端发送第二恢复请求，所述第二恢复请求用于指示所述发送端根据网络状态信息确定针对于丢包视频帧的发送方式，所述发送方式包括重传方式或前向纠错方式，所述丢包视频帧包括所述接收端因丢包而未能成功解析的原视频帧数据；所述第二预设等待时段与所述第一预设等待时段具有相同的起始点，且所述第一预设等待时段对应的第一预设等待时长大于所述第二预设等待时段对应的第二预设等待时长。
246.在一种可选的实施方式中，所述网络状态信息包括往返时延；所述第二恢复请求用于指示所述发送端根据所述网络状态信息确定针对于丢包视频帧的发送方式，包括：在所述往返时延小于第一阈值时，所述第二恢复请求指示所述发送端针对于丢包视频帧的发送方式为重传方式；在所述接收端反馈的往返时延大于或等于所述第一阈值时，所述第二恢复请求指示所述发送端针对于丢包视频帧的发送方式为前向纠错方式。
247.在一种可选的实施方式中，所述第一预设等待时段对应的第一预设等待时长大于0.5秒且小于1秒，所述第二预设等待时段对应的第二预设等待时长大于0秒且不大于0.5秒。
248.在一种可选的实施方式中，所述装置还包括：第三恢复请求发送模块，被配置为响应于在第三预设等待时段内未获取到可被成功解析的视频帧，向所述发送端发送第三恢复请求，所述第三恢复请求用于指示所述发送端向所述接收端发送关键帧；所述第三预设等待时段与所述第一预设等待时段具有相同的起始点，且所述第三预设等待时段对应的第三预设等待时长大于所述第一预设等待时段对应的第一预设时长。
249.在一种可选的实施方式中，所述第一预设等待时段对应的等待时长大于0.5秒且小于1秒，所述第三预设等待时段对应的时长不小于1秒且不大于3秒。
250.在一种可选的实施方式中，所述装置还包括：编码视频流接收模块，该模块被配置为接收所述发送端发送的根据前一帧参考编码生成的编码视频流；其中，所述发送端在未接到任一恢复请求时，根据前一帧参考编码生成编码视频流，并将所述编码视频流发送至所述接收端。
251.此外，本公开实施方式的其他具体细节在上述对应的方法的发明实施方式中已经详细说明，在此不再赘述。
252.示例性存储介质
253.下面对本公开示例性实施方式的存储介质进行说明。
254.本示例性实施方式中，可以通过程序产品实现上述的方法，如可以采用便携式紧凑盘只读存储器(cd-rom)并包括程序代码，并可以在设备，例如个人电脑上运行。然而，本公开的程序产品不限于此，在本文件中，可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。
255.该程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以为但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(eprom或闪存)、光纤、便携式紧凑盘只读存储器(cd-rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。
256.计算机可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。
257.可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于无线、有线、光缆、re等等，或者上述的任意合适的组合。
258.可以以一种或多种程序设计语言的任意组合来编写用于执行本公开操作的程序代码，程序设计语言包括面向对象的程序设计语言-诸如java、c 等，还包括常规的过程式程序设计语言-诸如"c"语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络，包括局域网(lan)或广域网(wan)，连接到用户计算设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。
259.示例性电子设备
260.参考图14对本公开示例性实施方式的电子设备进行说明。该电子设备可以是客户端或服务端。图14显示的电子设备1400仅仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。
261.如图14所示，电子设备1400以通用计算设备的形式表现。电子设备1400的组件可以包括但不限于：至少一个处理单元1410、至少一个存储单元1420、连接不同系统组件(包括存储单元1420和处理单元1410)的总线1430、显示单元1440。
262.其中，存储单元存储有程序代码，程序代码可以被处理单元1410执行，使得处理单元1410执行本说明书上述"示例性方法"部分中描述的根据本公开各种示例性实施方式的步骤。例如，处理单元1410可以执行如图2、图3、图4、图6、图9、图10、图11所示的方法步骤等。
263.存储单元1420可以包括易失性存储单元，例如随机存取存储单元(ram)1421和/或高速缓存存储单元1422，还可以进一步包括只读存储单元(rom)1423。存储单元1420还可以包括具有一组(至少一个)程序模块1425的程序/实用工具1424，这样的程序模块1425包括但不限于：操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的
每一个或某种组合中可能包括网络环境的实现。
264.总线1400可以包括数据总线、地址总线和控制总线。电子设备1400也可以与一个或多个外部设备1500(例如键盘、指向设备、蓝牙设备等)通信，这种通信可以通过输入/输出(i/o)接口1450进行。电子设备1400还包括显示单元1440，其连接到输入/输出(i/o)接口1450，用于进行显示。并且，电子设备1400还可以通过网络适配器1460与一个或者多个网络(例如局域网(lan)，广域网(wan)和/或公共网络，例如因特网)通信。如图所示，网络适配器1460通过总线1430与电子设备1400的其它模块通信。应当明白，尽管图中未示出，可以结合电子设备1400使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、raid系统、磁带驱动器以及数据备份存储系统等。
265.应当注意，尽管在上文详细描述中提及了装置的若干模块或子模块，但是这种划分仅仅是示例性的并非强制性的。实际上，根据本公开的实施方式，上文描述的两个或更多单元/模块的特征和功能可以在一个单元/模块中具体化。反之，上文描述的一个单元/模块的特征和功能可以进一步划分为由多个单元/模块来具体化。
266.此外，尽管在附图中以特定顺序描述了本公开方法的操作，但是，这并非要求或者暗示必须按照该特定顺序来执行这些操作，或是必须执行全部所示的操作才能实现期望的结果。附加地或备选地，可以省略某些步骤，将多个步骤合并为一个步骤执行，和/或将一个步骤分解为多个步骤执行。
267.虽然已经参考若干具体实施方式描述了本公开的精神和原理，但是应该理解，本公开并不限于所公开的具体实施方式，对各方面的划分也不意味着这些方面中的特征不能组合以进行受益，这种划分仅是为了表述的方便。本公开旨在涵盖所附权利要求的精神和范围内所包括的各种修改和等同布置。