一种音视频同步方法、存储介质及电子设备与流程

1.本技术涉及视频播放技术领域，具体而言，涉及一种音视频同步方法、存储介质及电子设备。


背景技术：

2.在移动端通讯软件中，常常会使用声音和视频进行互动，因此声音和视频画面的同步是非常重要的。但是，移动端的网络环境通常是非常复杂的，在网络较差或者网络波动的过程中，往往会导致声音和画面的不同步或者卡顿的问题存在。因此，移动端通讯软件通常需要一套稳定健硕的音视频同步方案：例如，在屏幕分享看电影时，就需要非常高要求的音视频同步；在视频聊天中，也需要比较好的同步效果，但同样需要较好的实时性；在网络比较差的情况，需要能尽量保证用户的正常使用；而在网络波动的时候能尽快自动恢复同步。


技术实现要素：

3.本技术实施例的目的在于提供一种音视频同步方法、存储介质及电子设备，以保证音视频同步的可靠性。
4.为了实现上述目的，本技术的实施例通过如下方式实现：
5.第一方面，本技术实施例提供一种音视频同步方法，包括：获取在播音频数据包的音频时间戳和在播视频数据包的视频时间戳；若所述视频时间戳超前于所述音频时间戳，保持在播音频数据包的刷新并暂停在播视频数据包的刷新，待所述音频时间戳不落后于所述视频时间戳时，恢复在播视频数据包的刷新；若所述视频时间戳落后于所述音频时间戳，判断所述音频时间戳与所述视频时间戳之间的当前时间差是否大于设定时间差；在所述当前时间差不大于所述设定时间差时，保持在播音频数据包的刷新和在播视频数据包的刷新；在所述当前时间差大于所述设定时间差时，保持在播音频数据包的刷新和加速在播视频数据包的刷新。
6.在本技术实施例中，由于人对声音的卡顿是更敏感的，因此采用了视频向音频同步的方式。以在播音频数据包的音频时间戳和在播视频数据包的视频时间戳为判断依据，可以保证音视频同步的基础的可靠性。在视频超前时即立刻停止刷新，使得视频不会超过音频的播放进度而使用户察觉(可以永远将视频的超前进度控制在一帧视频数据的播放时间之内)；在音频超前时，可以判断音频的超前进度(即音频时间戳与视频时间戳之间的当前时间差)是否大于设定时间差(此时间差以用户难以觉察为佳，例如30ms、25ms等)，在音频的超前进度不大于设定时间差时可不作调节，此时用户基本无感知，仍然可以给用户极好的同步体验；在音频的超前进度大于设定时间差时需要进行调节，通过保持在播音频数据包的刷新和加速在播视频数据包的刷新来实现视频播放进度的追赶，从而保持很好的音视频同步效果，给用户极佳的同步体验。
7.结合第一方面，在第一方面的第一种可能的实现方式中，所述方法还包括：接收待
播音频数据包和待播视频数据包，其中，每个待播音频数据包携带有音频时间戳，每个待播视频数据包携带有视频时间戳；基于待播音频数据包携带的音频时间戳和待播视频数据包携带的视频时间戳，分别确定出已缓存的待播音频数据包和待播视频数据包的播放次序。
8.结合第一方面的第一种可能的实现方式，在第一方面的第二种可能的实现方式中，在接收待播音频数据包和待播视频数据包后，所述方法还包括：基于最新接收的待播数据包的收包时间和上一个待播数据包的收包时间，确定出最新接收的待播数据包的传输时间，其中，待播数据包为待播音频数据包或待播视频数据包；基于待播数据包的传输时间，确定出用于表示收包连续性的网络参数；基于所述网络参数，确定是否调节待播数据包对应的缓存长度；在确定对待播数据包对应的缓存长度进行调节时，基于待播数据包的传输时间对待播数据包对应的缓存长度进行动态调节。
9.在该实现方式中，通过确定出最新接收的待播数据包(待播音频数据包或待播视频数据包)的传输时间，来判断表征当前收包连续性的网络参数，并确定是否需要动态调节待播数据包对应的缓存长度。通过这样的方式可以实时评估网络情况，进一步确定是否要调节对应的缓存长度，能够在网络不好时，缓存更多的数据，来保证用户观看(和听)的连续性，减少网络卡顿带来的不良观看体验。并且，此种方式在网络波动的情况下，由于音频缓存进度和视频缓存进度可以相互分离，音频数据较小，可以优先保证音频数据的正常播放，从而能够很好的应用在实时性要求较高的场景中(例如视频聊天、通话等)，在网络恢复时，可以利用网络恢复的时间将视频进度赶上音频进度，从而保证音视频的同步性。因此，此种音视频同步方案可以很好地应用于各种复杂的网络情况下，仍然能够在保证音频连续性(有效应对音频信息和视频信息的同步丢失、音视频播放严重卡顿、缓存时间过长等问题)的同时，尽可能保证音视频的同步，提供健硕的音视频同步方案。
10.结合第一方面的第二种可能的实现方式，在第一方面的第三种可能的实现方式中，所述基于最新接收的待播数据包的收包时间和上一个待播数据包的收包时间，确定出最新接收的待播数据包的传输时间，包括：将最新接收的待播数据包的收包时间减去上一个接收的同类型待播数据包的收包时间，再减去播放一帧数据所需的时间，得到最新接收的待播数据包的传输时间。
11.在该实现方式中，利用此种方式计算最新接收的待播数据包的传输时间，可以保证传输时间的准确性，且此种方式计算的传输时间，能够更好地反映实时网络状态。
12.结合第一方面的第二种可能的实现方式，在第一方面的第四种可能的实现方式中，所述基于待播数据包的传输时间，确定出用于表示收包连续性的网络参数，包括：确定出包含待播数据包的传输时间在内的设定数量的传输历史时间，并确定出其中的传输最大时间与传输最小时间之间的传输时间差，此传输时间差为所述网络参数；对应的，所述基于所述网络参数，确定是否调节待播数据包对应的缓存长度，包括：确定所述网络参数的所属范围，其中，所述网络参数的所属范围包括第一范围和第二范围，且所述第二范围中的最小值大于所述第一范围中的最大值；若所述网络参数位于所述第一范围，确定不调节待播数据包对应的缓存长度；若所述网络参数位于所述第二范围，确定调节待播数据包对应的缓存长度。
13.在该实现方式中，通过确定出包含待播数据包的传输时间在内的设定数量的传输历史时间，并确定出其中的传输最大时间与传输最小时间之间的传输时间差，此传输时间
差作为网络参数，可以很好地反映收包连续性，并且能够结合近期的网络状况进行综合考量(通过设定数量的传输历史时间来进行考量)。通过确定网络参数的所属范围，例如网络参数位于第一范围，确定不调节待播数据包对应的缓存长度。即，在网络参数较好的情况下，说明收包连续性佳，无需进行缓存的调节。网络参数位于第二范围时确定调节待播数据包对应的缓存长度，说明收包连续性较差，甚至可能导致卡顿，因此需要及时进行缓存长度的调节。这样的方式可以在网络较差时自动调整缓存长度，从而保证用户观看的连续性。
14.结合第一方面的第四种可能的实现方式，在第一方面的第五种可能的实现方式中，所述基于待播数据包的传输时间对待播数据包对应的缓存长度进行动态调节，包括：将所述传输最大时间加上传输时间补偿值，得到缓存长度参照值；若所述缓存长度参照值大于当前缓存长度，将所述缓存长度参照值设定为新的缓存长度；若所述缓存长度参照值小于当前缓存长度，且二者之间的差值大于设定长度差，则将所述缓存长度参照值减去所述设定长度差后设定为新的缓存长度；若所述缓存长度参照值小于当前缓存长度，且二者之间的差值不大于设定长度差，则将所述缓存长度参照值设定为新的缓存长度。
15.在该实现方式中，此种缓存长度的动态调节方式，可以很好地考虑到当前网络状态的具体情况，以及，能够考虑到近期的网络状态，从而在缓存长度参照值大于当前缓存长度时将缓存长度参照值设定为新的缓存长度，及时扩展缓存长度，尽可能保证用户观看的连续性(应对频繁的卡顿情况)，在缓存长度参照值小于当前缓存长度，且二者之间的差值大于设定长度差(以实际需要确定)，则将缓存长度参照值减去设定长度差后设定为新的缓存长度；若缓存长度参照值小于当前缓存长度，且二者之间的差值不大于设定长度差，则将缓存长度参照值设定为新的缓存长度，若缓存长度参照值小于当前缓存长度，且二者之间的差值不大于设定长度差，则将缓存长度参照值设定为新的缓存长度。这样可以在网络情况好转时分情况逐步降低缓存长度，从而尽可能保证观看的实时性和同步性。
16.结合第一方面的第二种可能的实现方式，在第一方面的第六种可能的实现方式中，在基于待播数据包的传输时间对待播数据包对应的缓存长度进行动态调节之后，所述方法还包括：若所述待播数据包为待播音频数据包，判断已缓存的待播音频数据包是否达到对应的音频缓存长度，并在达到该音频缓存长度时，按照播放次序对已缓存的待播音频数据包进行播放；若所述待播数据包为待播视频数据包，判断已缓存的待播视频数据包是否达到对应的视频缓存长度，在达到该视频缓存长度时，判断当前在播音频数据包的音频时间戳是否落后于当前在播视频数据包的视频时间戳，若当前在播音频数据包的音频时间戳落后于当前在播视频数据包的视频时间戳，则继续缓存待播视频数据包，若当前在播音频数据包的音频时间戳不落后于当前在播视频数据包的视频时间戳，则按照播放次序对已缓存的待播视频数据包进行播放。
17.在该实现方式中，在音频数据缓存好时，可以进行播放，由于音频数据较小，传输时间较少，因此可以在网络差的情况下优先保证音频数据的播放，在网络恢复时，可以将视频与音频同步进行播放，从而保证较好的音视频同步效果。
18.第二方面，本技术实施例提供一种基于应用场景的音视频同步方法，应用于数据传输的发送端，所述方法包括：确定出接收端的应用场景类型，其中，所述应用场景类型包括同步优先应用场景和实时优先同步场景，所述同步优先应用场景优先保证音频和视频的同步性，所述实时优先应用场景优先保证音频和/或视频的实时性；针对所述同步优先应用
场景，通过tcp协议组合包发送音频数据包和视频数据包，以使接收端基于接收的音频数据包和视频数据包执行第一方面或第一方面的可能的实现方式中任一项所述的音视频同步方法；针对所述实时优先应用场景，采用udp协议实时发送音频数据包和视频数据包，以使接收端基于接收的音频数据包和视频数据包执行第一方面或第一方面的可能的实现方式中任一项所述的音视频同步方法。
19.在本技术实施例中，通过区分应用场景：同步优先应用场景(优先保证音频和视频的同步性，例如屏幕共享观看电影等同步性要求较高的应用场景)和实时优先同步场景(优先保证音频和/或视频的实时性，例如视频聊天，需要保证实时性，特别是音频的实时性和连续性)，采用不同的协议进行数据包的传输。针对同步优先应用场景，通过tcp协议组合包发送音频数据包和视频数据包，tcp保证了传输的有序性，仅需把同一时间段的视频数据和音频数据同时发送出去，接收端就会按顺序收到这些包，直接进行播放就是同步的了，可以减少音视频同步时所需要的操作。而针对实时优先应用场景，采用udp协议实时发送音频数据包和视频数据包，这样可以优先保证音视频数据的实时性，结合音视频同步的流程，同样可以在网络较好时保证音视频的同步效果，在网络较差时保证音视频的连续性(优先保证音频的正常播放)。
20.第三方面，本技术实施例提供一种存储介质，所述存储介质包括存储的程序，其中，在所述程序运行时控制所述存储介质所在设备执行第一方面或第一方面的可能的实现方式中任一项所述的音视频同步方法，或者执行第二方面所述的基于应用场景的音视频同步方法。
21.第四方面，本技术实施例提供一种电子设备，包括存储器和处理器，所述存储器用于存储包括程序指令的信息，所述处理器用于控制程序指令的执行，所述程序指令被处理器加载并执行时实现第一方面或第一方面的可能的实现方式中任一项所述的音视频同步方法，或者实现第二方面所述的基于应用场景的音视频同步方法。
22.为使本技术的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。
附图说明
23.为了更清楚地说明本技术实施例的技术方案，下面将对本技术实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本技术的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。
24.图1为本技术实施例提供的一种基于应用场景的音视频同步方法的流程图。
25.图2为本技术实施例提供的tcp数据包传输的示意图。
26.图3为本技术实施例提供的一种音视频同步方法的流程图。
27.图4为本技术实施例提供的一种电子设备的结构框图。
28.图标：10-电子设备；11-存储器；12-通信模块；13-总线；14-处理器。
具体实施方式
29.下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行描述。
30.请参阅图1，图1为本技术实施例提供的一种基于应用场景的音视频同步方法的流程图。
31.在本实施例中，基于应用场景的音视频同步方法可以包括步骤s11、步骤s12和步骤s13。
32.在本实施例中，基于应用场景的音视频同步方法可以内置于数据传输中的发送端，而接收端则采用与之配套的接收方式进行数据接收即可。此处的发送端和接收端均为电子设备(发送端以终端为主，当然也可以是服务器之类的电子设备，而接收端则是终端)。
33.为了接收端能够有较好的音视频同步效果，发送端可以执行步骤s11。
34.步骤s11：确定出接收端的应用场景类型，其中，所述应用场景类型包括同步优先应用场景和实时优先同步场景，所述同步优先应用场景优先保证音频和视频的同步性，所述实时优先应用场景优先保证音频和/或视频的实时性。
35.在本实施例中，发送端可以确定出接收端的应用场景类型。此处的应用场景类型包括同步优先应用场景和实时优先同步场景，其中，同步优先应用场景优先保证音频和视频的同步性，例如通过屏幕共享观看电影、通过屏幕共享游戏界面等，此处不作限定；实时优先应用场景优先保证音频和/或视频的实时性，例如视频通话、视频聊天等。
36.示例性的，发送端确定接收端的应用场景类型的方式具体可以为：发送端选定应用场景类型，即，通过发送端发起请求的情况，例如发送端向接收端发起屏幕共享观看电影的请求，或者，发送端向接收端发起视频通话的请求，由此可以确定应用场景类型的类型。也可以是接收端选定应用场景类型，即通过接收端发起请求的情况，例如接收端向发送端发起屏幕共享观看电影的请求，或者，接收端向发送端发起视频通话的请求，此处不作限定。
37.针对同步优先应用场景，发送端可以执行步骤s12。
38.步骤s12：通过tcp协议组合包发送音频数据包和视频数据包，以使接收端基于接收的音频数据包和视频数据包执行音视频同步方法。
39.针对同步优先应用场景，发送端可以通过tcp协议组合包发送音频数据包和视频数据包。此处提到的音视频同步方法应用于接收端，后文将详细介绍。
40.例如，请参阅图2，发送端可以通过tcp协议组合包发出40ms(也可以是其他时长，以实际需要为准，此处以配合传输25帧视频的情况为例)内的音频和视频数据，利用了tcp传输的有序性，保证了音频和视频数据的同步传输。
41.针对实时优先应用场景，发送端可以执行步骤s13。
42.步骤s13：采用udp协议实时发送音频数据包和视频数据包，以使接收端基于接收的音频数据包和视频数据包执行音视频同步方法。
43.针对实时优先应用场景，发送端可以通过udp协议实时发送音频数据包和视频数据包。此处提到的音视频同步方法应用于接收端，后文将详细介绍。
44.例如，发送端可以采用udp协议分别同时传输音频数据和视频数据。接收端自身利用udp协议进行收包，检查和排序等事项由接收端保证，此处不作限定。
45.通过区分应用场景：同步优先应用场景(优先保证音频和视频的同步性，例如屏幕共享观看电影等同步性要求较高的应用场景)和实时优先同步场景(优先保证音频和/或视频的实时性，例如视频聊天，需要保证实时性，特别是音频的实时性和连续性)，采用不同的
协议进行数据包的传输。针对同步优先应用场景，通过tcp协议组合包发送音频数据包和视频数据包，tcp保证了传输的有序性，仅需把同一时间段的视频数据和音频数据同时发送出去，接收端就会按顺序收到这些包，直接进行播放就是同步的了，可以减少音视频同步时所需要的操作，也能够保证音视频的稳定性。而针对实时优先应用场景，采用udp协议实时发送音频数据包和视频数据包，这样可以优先保证音视频数据的实时性，结合音视频同步的流程，同样可以在网络较好时保证音视频的同步效果，在网络较差时保证音视频的连续性(优先保证音频的正常播放)。
46.为了保证接收端的音视频同步，本技术实施例还提供一种音视频同步方法，此音视频同步方法应用于接收端。为了便于对本方案的理解，此处先对基础的音视频同步流程进行介绍，后续再对音视频同步播放过程中涉及的动态调节缓存长度等复杂的方式进行详细介绍。
47.请参阅图3，图3为本技术实施例提供的一种音视频同步方法的流程图。在本实施例中，音视频同步方法可以包括步骤s21、步骤s22、步骤s23、步骤s24和步骤s25。
48.在发送端发送音频数据包和视频数据包后，接收端可以接收待播音频数据包和待播视频数据包(即发送端发送的音频数据包和视频数据包)，其中，每个待播音频数据包携带有音频时间戳，每个待播视频数据包携带有视频时间戳。
49.在接收端接收待播音频数据包和待播视频数据包后，接收端可以基于待播音频数据包携带的音频时间戳和待播视频数据包携带的视频时间戳，分别确定出已缓存的待播音频数据包和待播视频数据包的播放次序。即，在接收端接收到足够装满音频缓存的待播音频数据包后，接收端才开始基于已缓存的待播音频数据包播放音频。同理，在接收到足够装满视频缓存的待播视频数据包后，接收端才开始基于已缓存的待播视频数据包播放视频。
50.当然，播放的方式，接收端可以按照待播音频数据包的音频播放次序播放音频，按照待播视频数据包的播放次序播放视频，而播放过程中需要保持音视频的同步，因此接收端需要执行步骤s21。
51.步骤s21：获取在播音频数据包的音频时间戳和在播视频数据包的视频时间戳。
52.在本实施例中，接收端可以获取在播音频数据包的音频时间戳和在播视频数据包的视频时间戳。此处的在播音频数据包，即当前正在播放的一帧音频所对应的音频数据包；而在播视频数据包，即当前正在播放的一帧视频所对应的视频数据包。
53.获取音频时间戳和视频时间戳后，接收端可以判断视频时间戳与音频时间戳的进度差异。
54.针对视频时间戳超前于音频时间戳的情况，接收端可以执行步骤s22。
55.步骤s22：保持在播音频数据包的刷新并暂停在播视频数据包的刷新，待所述音频时间戳不落后于所述视频时间戳时，恢复在播视频数据包的刷新。
56.在本实施例中，接收端可以保持在播音频数据包的刷新并暂停在播视频数据包的刷新。这样可以理解为音频正常播放，而画面则暂停刷新，从而使得在播音频数据包的音频时间戳可以追赶上在播视频数据包的视频时间戳。等到音频时间戳不落后于视频时间戳时，即可恢复在播视频数据包的刷新。这样可以很好地保持音视频的同步，且在视频进度超前时，不会超过一个视频帧，可以简单地通过暂停视频画面刷新的方式解决视频超前的情况，且能够将视频播放进度超前的量控制在一帧之内。
57.需要说明的是，本文中所描述的在播音频数据包的刷新，以及在播视频数据包的刷新，表示对待播音频数据包和待播视频数据包的提取，提取的待播音频数据包，可以实现音频的播放，提取的待播视频数据包，可以实现视频画面的更新(即实现视频的播放)，此处不作限定。
58.针对视频时间戳落后于音频时间戳的情况，接收端可以执行步骤s23。
59.步骤s23：判断所述音频时间戳与所述视频时间戳之间的当前时间差是否大于设定时间差。
60.在视频时间戳落后于音频时间戳时，接收端可以判断音频时间戳与视频时间戳之间的当前时间差(即视频播放进度与音频播放进度的差异)是否大于设定时间差。此处的设定时间差可以选取让人难以感知的时间差为限，例如30ms、25ms等，用户很难察觉。
61.在当前时间差不大于设定时间差时，接收端可以执行步骤s24。
62.步骤s24：保持在播音频数据包的刷新和在播视频数据包的刷新。
63.在本实施例中，由于在当前时间差不大于设定时间差时，用户几乎不能察觉音视频的不同步，那么，针对此种情况，接收端可以不作处理，减少数据处理所占用的资源。
64.在当前时间差大于设定时间差时，接收端可以执行步骤s25。
65.步骤s25：保持在播音频数据包的刷新和加速在播视频数据包的刷新。
66.在本实施例中，由于在当前时间差大于设定时间差时，用户通常可以感受到音视频不同步带来的不佳体验，因此需要进行干预。基于此，接收端可以保持在播音频数据包的刷新的同时，加速在播视频数据包的刷新。
67.由于加速视频画面刷新的方式多种多样，例如减少播放时长(加快刷新频率)，丢帧处理(可以连续性丢帧，即跳过连续的多个待播视频数据包的播放，进行跳跃式的视频数据包的播放；也可以间隔性丢帧，例如，每播放x个待播视频数据包即跳过一个待播视频数据包，此处不作限定)。
68.由于人对声音的卡顿是更敏感的，因此采用了视频向音频同步的方式。以在播音频数据包的音频时间戳和在播视频数据包的视频时间戳为判断依据，可以保证音视频同步的基础的可靠性。在视频超前时即立刻停止刷新，使得视频不会超过音频的播放进度而使用户察觉(可以永远将视频的超前进度控制在一帧视频数据的播放时间之内)；在音频超前时，可以判断音频的超前进度(即音频时间戳与视频时间戳之间的当前时间差)是否大于设定时间差(此时间差以用户难以觉察为佳，例如30ms、25ms等)，在音频的超前进度不大于设定时间差时可不作调节，此时用户基本无感知，仍然可以给用户极好的同步体验；在音频的超前进度大于设定时间差时需要进行调节，通过保持在播音频数据包的刷新和加速在播视频数据包的刷新来实现视频播放进度的追赶，从而保持很好的音视频同步效果，给用户极佳的同步体验。
69.以上是对基础的音视频同步流程的介绍，以下将对音视频同步播放过程中涉及的动态调节缓存长度等复杂的方式进行详细介绍。
70.由于在音视频的播放过程中，也会接收待播音频数据包和待播视频数据包，因此，针对网络环境复杂的接收端来说，网络信号差、网络不稳定(网络波动)等情况也是常见的。为了应对复杂网络环境下的音视频同步，保证音视频同步方案的健壮性，可以采用动态调节缓存长度的方式保证用户观看的连续性，采用优先保证音频数据正常播放的方式，弱化
网络差而导致的频繁卡顿现象。
71.示例性的，在接收端接收待播音频数据包和待播视频数据包后，还可以根据最新接收的待播数据包的收包时间确定出对应的传输时间。此处，待播数据包可以为待播音频数据包，也可以为待播视频数据包。本实施例中以待播音频数据包对应的传输时间和待播视频数据包的传输时间相互独立为例进行说明，但不作限定。
72.在本实施例中，接收端可以基于最新接收的待播数据包的收包时间和上一个待播数据包的收包时间，确定出最新接收的待播数据包的传输时间。
73.示例性的，接收端可以将最新接收的待播数据包的收包时间减去上一个接收的同类型待播数据包的收包时间，再减去播放一帧数据所需的时间，得到最新接收的待播数据包的传输时间。
74.例如，针对待播音频数据包的传输时间的确定：接收端可以将最新接收的待播音频数据包的收包时间减去上一个接收的待播音频数据包的收包时间，再减去播放一帧音频数据所需的时间(例如25帧/每秒的视频，每一帧播放时间是40ms)，得到最新接收的待播数据包的传输时间。针对待播视频数据包的传输时间的确定同样如此，不再赘述。
75.利用此种方式计算最新接收的待播数据包的传输时间，可以保证传输时间的准确性，并且能够更好地反映实时的网络状态。
76.当然，在一些其他的可能的实现方式中，接收端还可以采用其他的方式确定最新接收的待播数据包的传输时间，例如，可以利用最新接收的待播音频数据包的收包时间减去最新接收的待播音频数据包的发包时间，得到最新接收的待播数据包的传输时间，此处不作限定。
77.在确定出最新接收的待播数据包的传输时间后，接收端可以基于待播数据包的传输时间，确定出用于表示收包连续性的网络参数。
78.在本实施例中，接收端可以确定出包含待播数据包的传输时间在内的设定数量的传输历史时间。例如，接收端内可以保存最近100个这样的传输历史时间(针对每一类待播数据包，即，待播音频数据包对应的有100个音频传输历史时间，待播视频数据包对应的有100个视频传输历史时间)。
79.而后，接收端可以确定出其中的传输最大时间与传输最小时间之间的传输时间差，此传输时间差为网络参数。
80.示例性的，针对待播音频数据包，接收端可以获取最近100个音频传输历史时间，确定出其中的音频传输最大时间与音频传输最小时间，以及确定出二者之间的音频传输时间差，此音频传输时间差即音频网络参数，用于表征待播音频数据包的收包连续性。
81.同理，针对待播视频数据包，接收端可以获取最近100个视频传输历史时间，确定出其中的视频传输最大时间与视频传输最小时间，以及确定出二者之间的视频传输时间差，此视频传输时间差即视频网络参数，用于表征待播视频数据包的收包连续性。
82.确定出网络参数后，接收端可以基于此网络参数，确定是否调节待播数据包对应的缓存长度。
83.在本实施例中，接收端可以确定网络参数的所属范围，其中，网络参数的所属范围包括第一范围和第二范围，且第二范围中的最小值大于第一范围中的最大值。若网络参数位于第一范围，确定不调节待播数据包对应的缓存长度；若网络参数位于第二范围，确定调
节待播数据包对应的缓存长度。
84.示例性的，针对音频网络参数，接收端可以确定音频网络参数的所属范围，此所属范围可以确定为100ms以下(第一范围)和100ms以上(第二范围)，当然，仅是举例。音频网络参数在100ms以下(属于第一范围，表示网络非常好)，可以不需要进行音频缓存长度的调节。若是音频网络参数在100ms以上(属于第二范围)，表明表示网络还行(100～600ms)，或者网络很差(600ms以上)，对于第二范围内的情况，需要进行音频缓存长度的动态调节。
85.当然，针对视频网络参数也是类似的判断方式，此处不再赘述。当然，视频网络参数对应的具体范围值与音频网络参数对应的具体范围值可以有差异(也可相同)，此处不作限定。
86.通过确定出包含待播数据包的传输时间在内的设定数量的传输历史时间，并确定出其中的传输最大时间与传输最小时间之间的传输时间差，此传输时间差作为网络参数，可以很好地反映收包连续性，并且能够结合近期的网络状况进行综合考量(通过设定数量的传输历史时间来进行考量)。通过确定网络参数的所属范围，例如网络参数位于第一范围，确定不调节待播数据包对应的缓存长度。即，在网络参数较好的情况下，说明收包连续性佳，无需进行缓存的调节。网络参数位于第二范围时确定调节待播数据包对应的缓存长度，说明收包连续性较差，甚至可能导致卡顿，因此需要及时进行缓存长度的调节。这样的方式可以在网络较差时自动调整缓存长度，从而保证用户观看的连续性。
87.在确定对待播数据包对应的缓存长度进行调节时，基于待播数据包的传输时间对待播数据包对应的缓存长度进行动态调节。
88.通过确定出最新接收的待播数据包(待播音频数据包或待播视频数据包)的传输时间，来判断表征当前收包连续性的网络参数，并确定是否需要动态调节待播数据包对应的缓存长度。通过这样的方式可以实时评估网络情况，进一步确定是否要调节对应的缓存长度，能够在网络不好时，缓存更多的数据，来保证用户观看(和听)的连续性，减少网络卡顿带来的不良观看体验。并且，此种方式在网络波动的情况下，由于音频缓存进度和视频缓存进度可以相互分离，音频数据较小，可以优先保证音频数据的正常播放，从而能够很好的应用在实时性要求较高的场景中(例如视频聊天、通话等)，在网络恢复时，可以利用网络恢复的时间将视频进度赶上音频进度，从而保证音视频的同步性。因此，此种音视频同步方案可以很好地应用于各种复杂的网络情况下，仍然能够在保证音频连续性(有效应对音频信息和视频信息的同步丢失、音视频播放严重卡顿、缓存时间过长等问题)的同时，尽可能保证音视频的同步，提供健硕的音视频同步方案。
89.示例性的，接收端可以将传输最大时间加上传输时间补偿值，得到缓存长度参照值。例如，传输时间补偿值可以设为定值(如100ms、10000ms等)，也可以根据传输时间差进行动态确定(例如，确定为传输时间差的一半，或者，通过一个设定的计算公式来确定此传输时间补偿值)，此处不作限定。
90.若缓存长度参照值大于当前缓存长度，接收端可以将缓存长度参照值设定为新的缓存长度。若缓存长度参照值小于当前缓存长度，且二者之间的差值大于设定长度差，接收端则可以将缓存长度参照值减去设定长度差后设定为新的缓存长度。若缓存长度参照值小于当前缓存长度，且二者之间的差值不大于设定长度差，接收端则可以将缓存长度参照值设定为新的缓存长度。
91.例如，以动态调整视频缓存长度为例，若此视频缓存长度参照值大于当前视频缓存长度，接收端可以将此视频缓存长度参照值设定为新的视频缓存长度。若此视频缓存长度参照值小于当前视频缓存长度，且二者之间的差值大于设定长度差(例如5)，接收端则可以将视频缓存长度参照值减去设定长度差(即减去5)后设定为新的视频缓存长度。若此视频缓存长度参照值小于当前视频缓存长度，且二者之间的差值不大于设定长度差(例如5)，接收端则可以将此视频缓存长度参照值设定为新的视频缓存长度。
92.当然，针对音频缓存长度的动态调节亦是类似的方式，此处不再赘述。具体的设定长度差可有不同(也可相同)，此处不作限定。
93.此种缓存长度的动态调节方式，可以很好地考虑到当前网络状态的具体情况，以及，能够考虑到近期的网络状态，从而在缓存长度参照值大于当前缓存长度时将缓存长度参照值设定为新的缓存长度，及时扩展缓存长度，尽可能保证用户观看的连续性(应对频繁的卡顿情况)，在缓存长度参照值小于当前缓存长度，且二者之间的差值大于设定长度差(以实际需要确定)，则将缓存长度参照值减去设定长度差后设定为新的缓存长度；若缓存长度参照值小于当前缓存长度，且二者之间的差值不大于设定长度差，则将缓存长度参照值设定为新的缓存长度，若缓存长度参照值小于当前缓存长度，且二者之间的差值不大于设定长度差，则将缓存长度参照值设定为新的缓存长度。这样可以在网络情况好转时分情况逐步降低缓存长度，从而尽可能保证观看的实时性和同步性。
94.在基于待播数据包的传输时间对待播数据包对应的缓存长度进行动态调节之后，接收端还可以判断已缓存的待播数据包是否达到对应的缓存长度，以此确定是否可进行播放。
95.示例性的，若待播数据包为待播音频数据包，接收端可以判断已缓存的待播音频数据包是否达到对应的音频缓存长度，并在达到该音频缓存长度时，按照播放次序对已缓存的待播音频数据包进行播放。
96.若待播数据包为待播视频数据包，接收端可以判断已缓存的待播视频数据包是否达到对应的视频缓存长度，在达到该视频缓存长度时，判断当前在播音频数据包的音频时间戳是否落后于当前在播视频数据包的视频时间戳，若当前在播音频数据包的音频时间戳落后于当前在播视频数据包的视频时间戳，则继续缓存待播视频数据包，若当前在播音频数据包的音频时间戳不落后于当前在播视频数据包的视频时间戳，则按照播放次序对已缓存的待播视频数据包进行播放。
97.在音频数据缓存好时，可以进行播放，由于音频数据较小，传输时间较少，因此可以在网络差的情况下优先保证音频数据的播放，在网络恢复时，可以将视频与音频同步进行播放，从而保证较好的音视频同步效果。
98.请参阅图4，图4为本技术实施例提供的一种电子设备10的结构框图。
99.在本实施例中，电子设备10为终端(可以为发送端，也可以为接收端)，例如个人电脑、平板电脑、智能手机等，此处不作限定。
100.示例性的，电子设备10可以包括：通过网络与外界连接的通信模块12、用于执行程序指令的一个或多个处理器14、总线13和不同形式的存储器11，例如，磁盘、rom、或ram，或其任意组合。存储器11、通信模块12、处理器14之间可以通过总线13连接。
101.示例性的，存储器11中存储有程序。处理器14可以从存储器11调用并运行这些程
序，从而便可以通过运行程序而实现音视频同步方法或基于应用场景的音视频同步方法。
102.本技术实施例提供一种存储介质，所述存储介质包括存储的程序，其中，在所述程序运行时控制所述存储介质所在设备执行本实施例中的音视频同步方法，或者本实施例中的基于应用场景的音视频同步方法。
103.综上所述，本技术实施例提供一种音视频同步方法、存储介质及电子设备，由于人对声音的卡顿是更敏感的，因此采用了视频向音频同步的方式。以在播音频数据包的音频时间戳和在播视频数据包的视频时间戳为判断依据，可以保证音视频同步的基础的可靠性。在视频超前时即立刻停止刷新，使得视频不会超过音频的播放进度而使用户察觉(可以永远将视频的超前进度控制在一帧视频数据的播放时间之内)；在音频超前时，可以判断音频的超前进度(即音频时间戳与视频时间戳之间的当前时间差)是否大于设定时间差(此时间差以用户难以觉察为佳，例如30ms、25ms等)，在音频的超前进度不大于设定时间差时可不作调节，此时用户基本无感知，仍然可以给用户极好的同步体验；在音频的超前进度大于设定时间差时需要进行调节，通过保持在播音频数据包的刷新和加速在播视频数据包的刷新来实现视频播放进度的追赶，从而保持很好的音视频同步效果，给用户极佳的同步体验。
104.在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。
105.以上所述仅为本技术的实施例而已，并不用于限制本技术的保护范围，对于本领域的技术人员来说，本技术可以有各种更改和变化。凡在本技术的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本技术的保护范围之内。