CN107820100B

CN107820100B - 互联网音视频播放方法及装置

Info

Publication number: CN107820100B
Application number: CN201711035528.2A
Authority: CN
Inventors: 陈卫强; 宋建斌; 庞一; 高岳
Original assignee: Beijing Star Times Software Technology Co ltd
Current assignee: Beijing Star Times Software Technology Co ltd
Priority date: 2017-10-30
Filing date: 2017-10-30
Publication date: 2020-08-28
Anticipated expiration: 2037-10-30
Also published as: CN107820100A

Abstract

本发明提供了一种互联网音视频播放方法及装置，其中，该方法包括：在接收到用户对待播放音视频的播放指令前，预先建立用户端到待播放音视频所在服务器的socket连接路径；在检测到有预先建立的待播放音视频的socket连接路径时，利用所述预先建立的待播放音视频的socket连接路径，下载并播放待播放音视频。上述技术方案降低了互联网音视频播放的启动时间，提高了用户的体验。

Description

互联网音视频播放方法及装置

技术领域

本发明涉及音视频播放技术领域，特别涉及一种互联网音视频播放方法及装置。

背景技术

近年来,由于互联网的快速发展以及网络上对多媒体信息需求的不断增加，网络流媒体受到了学术上和应用领域上广泛关注。网络音视频的传输方式主要有两种:一种是下载方式,另一种是流传输方式。在下载模式中,用户先下载整个视频文件,然后再播放这个视频文件,但是在下载模式中的整个文件的传输通常会花费比较长的时间,而且这个时间可能是用户不能接受的。相比之下,在流传输模式中,视频内容不需要被完全的下载下来,而是在播放一段视频的同时接收另一部分的视频内容并解码。由于这种方式的时效性,音视频流传输通常需要有一定的带宽、延时以及丢包之类的参数要求。

当前的互联网并不能保证音视频流媒体的服务质量,而只能做到尽力而为。音视频用户的主观体验包括音视频的启动时间，在网络不好的情况下,互联网音视频启动时间过长，严重影响用户体验。

发明内容

本发明实施例提供了一种互联网音视频播放方法，用以降低互联网音视频播放的启动时间，该方法包括：

在接收到用户对待播放音视频的播放指令前，预先建立用户端到待播放音视频所在服务器的socket连接路径；

在检测到有预先建立的待播放音视频的socket连接路径时，利用所述预先建立的待播放音视频的socket连接路径，下载并播放待播放音视频。

本发明实施例还提供了一种互联网音视频播放装置，用以降低互联网音视频播放的启动时间，该装置包括：

预连接单元，用于在接收到用户对待播放音视频的播放指令前，预先建立用户端到待播放音视频所在服务器的socket连接路径；

播放单元，用于在检测到有预先建立的待播放音视频的socket连接路径时，利用所述预先建立的待播放音视频的socket连接路径，下载并播放待播放音视频。

本发明实施例还提供了一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述互联网音视频播放方法。

本发明实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质存储有执行上述互联网音视频播放方法的计算机程序。

本发明实施例提供的技术方案通过在接收到用户对待播放音视频的播放指令前，预先建立用户端到待播放音视频所在服务器的socket连接路径；在检测到有预先建立的待播放音视频的socket连接路径时，利用所述预先建立的待播放音视频的socket连接路径，下载并播放待播放音视频，实现了提前将tcp连接建立好，启动时直接使用该预连接socket进行http交互，进行数据收发，实现播放，有效地降低了互联网音视频播放的启动时间，提高了用户体验。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，并不构成对本发明的限定。在附图中：

图1是本发明实施例中tcp连接三次握手的原理流程示意图；

图2是本发明实施例中直播流程中m3u8文件和ts文件更新的流程示意图；

图3是本发明实施例中hls协议下视频从点击到显示的流程示意图；

图4是本发明实施例中互联网音视频播放方法的流程示意图；

图5是本发明实施例中tcp预连接原理示意图；

图6是本发明实施例中检测tcp连接的socket是否有效或空闲超时流程示意图；

图7是本发明实施例中互联网音视频播放装置的结构示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚明白，下面结合实施方式和附图，对本发明做进一步详细说明。在此，本发明的示意性实施方式及其说明用于解释本发明，但并不作为对本发明的限定。

为了便于理解本发明如何实施，在介绍本发明实例提供的技术方案之前，首先对TCP连接的三次握手技术和HLS相关技术进行介绍。

首先，介绍TCP连接的三次握手技术。

如图1所示，首先，客户程序发送一个设置SYN标志而且不带数据负载的TCP包(一个SYN包)。服务器则以发出带SYN/ACK标志的数据包(一个SYN/ACK包)作为刚才收到包的确认响应。客户随后发送一个ACK包确认收到了第2个包，从而结束连接过程。

播放器与服务端每次建立tcp连接时，tcp协议栈需要三次握手。根据使用ffplay播放在线视频使用wireshark的抓包数据，分析可以看出获取m3u8和ts之前，都进行了tcp连接的三次握手。根据tcp握手耗时，可见tcp三次握手时间主要在第二次握手，等待服务器ack上耗时严重。第三次握手向服务器ack和向服务器发送http请求之间几乎没有时间消耗。

播放器hls协议播放流程分别对m3u8文件和ts文件进行tcp连接和读取。3.15.2版本线上统计tcp连接时间，m3u8连接时间为0.6s,ts连接时间为连接0.4s。tcp连接时间即tcp三次握手时间，实际wireshark抓包分析主要耗时是第二次握手，也就是服务器ack时间。播放器每次启动时都需要进行这两次tcp连接，可以提前将tcp连接建立好(具体连接方法详见下文)，播放器启动时直接使用预连接socket进行http交互，进行数据收发，实现播放。理论上两次连接(m3u8连接和ts连接)时间都节省，可以提高启动时间1s。

其次，介绍HLS相关技术。

第一，介绍hls播放流程。

hls协议媒体流播放m3u8和每个ts片段都进行一次tcp连接，tcp连接的建立都是根据每次url的http请求创建的。socket连接使用非阻塞模型,读写数据使用poll(类似select)判断读写状态，tcp连接超时时间由tcp的option的timeout选项配置。默认tcp超时时间为5秒。tcp读数据超时时间为永久等待。

第二，介绍m3u8打开流程。

m3u8打开流程主要包括创建tcp连接(http_open_ctx_internal)，发送http请求(http_connect)，分析http回复获取m3u8文件demuxer(av_probe_input_buffer2)，读m3u8的文件头(hls_read_header)，根据文件m3u8中描述的ts分段的url，打开第一个ts文件(avformat_open_input)。

打开ts文件的流程与打开m3u8的流程基本一致，只是文件格式的不同，此时获取ts文件的demuxer。

第三，介绍读取流程。

读取ts帧流程为单线程串行顺序读取，读取帧先考虑从帧缓冲区读区。缓冲区没有数据再使用io从远程读取，每次读取buffer大小为32k，将读完的数据放到包缓冲区，直到当前ts读取结束后，再读取下一个ts文件(再次创建tcp/http等资源)。

第四，介绍直播流程。

直播流程与点播流程的唯一区别在于：需要不断更新m3u8文件，进而更新ts的播放列表。直播的m3u8文件的更新时间间隔为ts分片的时间，所以播放端为保证流畅播放的缓存，每隔一个ts分片时间就需要更新一次播放列表。每次更新播放列表都需要重新进行tcp连接，发送http请求，具体流程请参见图2。

如图3所示，一般情况下，hls协议下视频从点击到显示包含如下过程：获取m3u8的url，对m3u8域名进行DNS解析，m3u8TCP连接，m3u8下载，获取ts的url,对ts域名进行DNS解析，ts TCP连接，下载ts，解码视频，显示视频。TCP连接时间占到视频播放启动时间的25％，本发明的核心要点是将费时的TCP连接在启动播放之前就预先连接好。当真正下载m3u8或者ts的时候已经就绪，有效地降低了启动时间。下面对本发明实例提供的互联网音视频播放方案进行详细介绍。

图4是本发明实施例中互联网音视频播放方法的流程示意图，如图4所示，该方法包括如下步骤：

步骤101：在接收到用户对待播放音视频的播放指令前，预先建立用户端到待播放音视频所在服务器的socket连接路径；

步骤102：在检测到有预先建立的待播放音视频的socket连接路径时，利用所述预先建立的待播放音视频的socket连接路径，下载并播放待播放音视频。

具体实施时，Tcp预连接原理是指播放器启动前预先建立与媒体服务器的socket连接并保持，当播放器启动时首先检测是否有预连接的socket，如果有预连接的socket且socket有效，则直接使用该socket，否则创建新的socket。具体原理示意图如图5所示。

在一个实施例中，在接收到用户对待播放音视频的播放指令前，预先建立用户端到待播放音视频所在服务器的socket连接路径，可以包括：

在接收到用户对待播放音视频的播放指令前，定时检测预先建立的待播放音视频的socket连接路径是否有效或空闲超时，根据检测结果，重新建立用户端到待播放视频所在服务器的socket连接路径。

具体实施时，实现上，ffmpeg底层增加启动和停止tcp预连接工作线程的接口。tcp预连接工作线程定时建立与服务器的tcp连接，并检测tcp连接的socket是否有效，是否空闲超时，具体请参见附图6。

具体实施时，连接是否有效，通过poll函数判断socket是否可写；连接空闲是否超时，由AWS服务器决定超时时间，现在AWS对tcp连接空闲超时限制为30秒。为保证预连接的socket空闲超时候失效，工作线程判断socket的空闲时间超过25秒后，主动断开再重新预连接。因为AWS对连接时间的限制可能有调整，所以实现上将超时时间通过接口参数方式传入。

在互联网音视频所在APP启动完成后，预先建立用户端到待播放视频所在服务器的socket连接路径。

具体实施时，界面显示后启动：如果考虑tcp三次握手占用网络带宽，启动线程影响启动时间，可以将tcp预连接工作线程放在app界面显示后再启动。APP界面显示后，创建连接，用户在app启动后，立即打开视频，tcp预连接可能会出现还没有全部建立的情况，然而，不占用任何APP启动时间。

当然，在接收到用户对待播放音视频的播放指令前，预先建立用户端到待播放音视频所在服务器的socket连接路径，还可以包括：

在互联网音视频所在APP启动时，预先建立用户端到待播放视频所在服务器的socket连接路径。

具体实施时，界面显示前启动：tcp预连接工作线程，因为只进行tcp的三次握手，不涉及应用层数据收发，理论上几乎不占用网络带宽，而且是后台工作线程与界面线程无关，不影响界面交互。所以tcp预连接工作线程可以放在APP启动时界面显示前启动，界面隐藏时停止。虽然可能占用一小部分APP启动时间，预计几毫秒，然而，APP界面显示前创建连接，保证用户在app启动后，立即打开视频使用预连接的tcp，降低播放器启动时间(即互联网音视频启动时间)。

在每次结束互联网音视频播放时，预先建立用户端到待播放视频所在服务器的socket连接路径，并保存在用户端。

具体实施时，每次结束视频播放时，进行一次tcp预连接，并保存到连接池(该连接池保存了m3u8socket连接路径和ts socket连接路径)，下一次视频播放优先使用连接池内的连接。这样降低第二次播放的启动时间。

具体实施时，预先建立待播放音视频的m3u8socket连接路径和ts socket连接路径的原理请参见上文中关于“第四，介绍直播流程”的介绍。

发明人发现：音视频用户的主观体验除了上文描述的启动时间，还可以包括：播放卡顿率、播放成功率等。网络带宽、延时、丢包率以及音视频的编解码传输方式对用户的主观体验有着重要的影响。互联网音视频尤其是实时音视频系统具有很强的时效性,音视频数据必须持续地接收。如果数据没有持续到达,那么播放将会出现卡顿，这将会极大的影响用户体验。音视频播放的启动时间和卡顿率均与网络连接TCP时间和音视频下载时间等因数有关，在网络不好的情况下，播放卡顿率指标恶化，严重影响用户体验。

由于发明人考虑到上述播放卡顿率的问题，发明人提出了下述技术方案：

在一个实施例中，预先建立的待播放音视频的socket连接路径，可以包括：

预先建立的待播放音视频的m3u8socket连接路径和ts socket连接路径。

互联网音视频播放方法还可以包括：

存储所述预先建立的待播放音视频的m3u8socket连接路径和ts socket连接路径；

在检测到有预先建立的待播放音视频的socket连接路径时，利用所述预先建立的待播放音视频的socket连接路径，下载并播放待播放音视频，可以包括：

在待播放音视频的播放过程中，在检测到存储有预先建立的待播放音视频的m3u8socket连接路径和ts socket连接路径时，利用所述预先建立的m3u8socket连接路径和ts socket连接路径，下载并播放待播放音视频的未播放部分。

具体实施时，预先建立的待播放音视频的m3u8socket连接路径和ts socket连接路径可以保存到一个连接池内，在音视频播放过程中，需要tcp连接时，检测上述连接池内是否有存储的预先建立的待播放音视频的m3u8socket连接路径和ts socket连接路径，如果有，直接使用连接池内的已连接好的路径，进行相应部分视频下载及播放即可。这样的技术方案优化了播放卡顿率指标，保证音视频播放流畅，提高了用户的体验。

基于同一发明构思，本发明实施例中还提供了一种互联网音视频播放装置，如下面的实施例。由于互联网音视频播放装置解决问题的原理与互联网音视频播放方法相似，因此互联网音视频播放装置的实施可以参考互联网音视频播放方法的实施，重复之处不再赘述。以下所使用的，术语“单元”或者“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。

图7是本发明实施例中互联网音视频播放装置的结构示意图，如图7所示，该播放装置包括：

预连接单元02，用于在接收到用户对待播放音视频的播放指令前，预先建立用户端到待播放音视频所在服务器的socket连接路径；

播放单元04，用于在检测到有预先建立的待播放音视频的socket连接路径时，利用所述预先建立的待播放音视频的socket连接路径，下载并播放待播放音视频。

在一个实施例中，预连接单元02可以具体用于：

在一个实施例中，预先建立的待播放音视频的socket连接路径，包括：预先建立的待播放音视频的m3u8socket连接路径和ts socket连接路径；

上述互联网音视频播放装置还包括：

存储单元，用于存储所述预先建立的待播放音视频的m3u8socket连接路径和tssocket连接路径；

上述播放单元还用于：在待播放音视频的播放过程中，在检测到存储有预先建立的待播放音视频的m3u8socket连接路径和ts socket连接路径时，利用所述预先建立的m3u8socket连接路径和ts socket连接路径，下载并播放待播放音视频的未播放部分。

综上，根据上述实施例的介绍，发明人经过大量的研究，得出本发明实施例提供技术方案的预先连接结果如下：

Hls协议播放视频时需要进行两次tcp连接，m3u8连接时间为0.6s，ts连接时间为0.4s。预连接是定时进行且有空闲超时重连机制，所以用户点击视频播放时，大多数情况使用预连接的tcp，某些情况下可能没有预连接的tcp，所以tcp预连接覆盖率可能达不到100％。

统计所有数据平均启动时间，只有m3u8和ts都使用预连接的绝对理想情况下，才能对启动时间降低1s。多数情况下m3u8/ts都使用预连接的tcp，降低启动时间1s；某些情况下只有m3u8使用预连接的tcp，降低启动时间0.6s。

下面再对Tcp预连接策略调整方案(即本发明实施例中采用了预连接技术的互联网音视频播放方法)再整体进行介绍，以便于理解本发明如何实施。

(1)数据分析：

1)GA数据显示，80％以上的用户会在APP打开后看视频。

2)线上数据显示，80％用户某一时间段内观看视频在两次以上，抽样数据显示80％的观看间隔在25s以内，20％观看间隔在1s以内。

(2)策略设计：

1)APP打开后，进行一次tcp预连接，这样25s内，首次打开视频的用户将节省tcp连接时间，从而降低启动时间。

2)每次结束视频播放时，进行一次tcp预连接，并保存到连接池，下一次视频播放优先使用连接池内的连接。这样降低第二次播放的启动时间。

(3)调整后结果

当前播放器平均启动时间为4s，完全使用预连接将节省m3u8和ts的tcp连接时间1s左右。

1)考虑预连接间隔小于25s且大于1s的用户占比，即80％x60％约占比48％，这一部分可以节省1s左右的启动时间。

2)播放间隔小于1s的属于视频切换行为，第一个视频播放结束和第二个视频播放开始间隔太短，tcp预连接还没完成，不能生效节省启动时间。

综上所述，tcp预连接灰度比例100％情况下，平均启动时间预估值为48％*3+52％*3.6＝3.31s，降低启动时间0.69s。考虑预连接生效取决于用户的操作行为，实际使用预连接的比例存在波动，预估值需要作一定调整，建议在0.3～0.5s之间。

本发明实施提供的技术方案的有益技术效果为：

首先，本发明实施例提供的技术方案通过在接收到用户对待播放音视频的播放指令前，预先建立用户端到待播放音视频所在服务器的socket连接路径；在检测到有预先建立的待播放音视频的socket连接路径时，利用所述预先建立的待播放音视频的socket连接路径，下载并播放待播放音视频，实现了提前将tcp连接建立好，启动时直接使用预连接socket进行http交互，进行数据收发，实现播放，有效地降低了互联网音视频播放的启动时间，提高了用户体验。

其次，本发明实施例提供的技术方案存储预先建立的待播放音视频的m3u8socket连接路径和ts socket连接路径，在待播放音视频的播放过程中，在检测到存储有预先建立的待播放音视频的m3u8socket连接路径和ts socket连接路径时，利用预先建立的m3u8socket连接路径和ts socket连接路径，下载并播放待播放音视频的未播放部分，优化了播放卡顿率指标，保证音视频播放流畅，提高了用户的体验。

显然，本领域的技术人员应该明白，上述的本发明实施例的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明实施例不限制于任何特定的硬件和软件结合。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明实施例可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims

1.一种互联网音视频播放方法，其特征在于，包括：

在接收到用户对待播放音视频的播放指令时，利用所述预先建立的待播放音视频的socket连接路径，下载并播放待播放音视频；

在接收到用户对待播放音视频的播放指令前，预先建立用户端到待播放音视频所在服务器的socket连接路径，包括：在接收到用户对待播放音视频的播放指令前，定时检测预先建立的待播放音视频的socket连接路径是否有效或空闲超时，根据检测结果，重新建立用户端到待播放视频所在服务器的socket连接路径；连接是否有效，通过poll函数判断socket是否可写；连接空闲是否超时，由AWS服务器决定超时时间；

预先建立的待播放音视频的socket连接路径，包括：预先建立的待播放音视频的m3u8socket连接路径和ts socket连接路径；

所述互联网音视频播放方法还包括：

存储所述预先建立的待播放音视频的m3u8 socket连接路径和ts socket连接路径；

在检测到有预先建立的待播放音视频的socket连接路径时，利用所述预先建立的待播放音视频的socket连接路径，下载并播放待播放音视频，包括：

在待播放音视频的播放过程中，在检测到存储有预先建立的待播放音视频的m3u8socket连接路径和ts socket连接路径时，利用所述预先建立的m3u8 socket连接路径和tssocket连接路径，下载并播放待播放音视频的未播放部分；预先建立的待播放音视频的m3u8 socket连接路径和ts socket连接路径保存到一个连接池内。

2.如权利要求1所述的互联网音视频播放方法，其特征在于，在接收到用户对待播放音视频的播放指令前，预先建立用户端到待播放音视频所在服务器的socket连接路径，包括：

3.如权利要求1所述的互联网音视频播放方法，其特征在于，在接收到用户对待播放音视频的播放指令前，预先建立用户端到待播放音视频所在服务器的socket连接路径，包括：

4.一种互联网音视频播放装置，其特征在于，包括：

播放单元，用于在检测到有预先建立的待播放音视频的socket连接路径时，利用所述预先建立的待播放音视频的socket连接路径，下载并播放待播放音视频；

所述预连接单元具体用于：在接收到用户对待播放音视频的播放指令前，定时检测预先建立的待播放音视频的socket连接路径是否有效或空闲超时，根据检测结果，重新建立用户端到待播放视频所在服务器的socket连接路径；连接是否有效，通过poll函数判断socket是否可写；连接空闲是否超时，由AWS服务器决定超时时间；

所述互联网音视频播放装置还包括：

存储单元，用于存储所述预先建立的待播放音视频的m3u8 socket连接路径和tssocket连接路径；

所述播放单元还用于：在待播放音视频的播放过程中，在检测到存储有预先建立的待播放音视频的m3u8 socket连接路径和ts socket连接路径时，利用所述预先建立的m3u8socket连接路径和ts socket连接路径，下载并播放待播放音视频的未播放部分；预先建立的待播放音视频的m3u8 socket连接路径和ts socket连接路径保存到一个连接池内。

5.如权利要求4所述的互联网音视频播放装置，其特征在于，所述预连接单元具体用于：

6.如权利要求4所述的互联网音视频播放装置，其特征在于，所述预连接单元具体用于：

7.一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现权利要求1至3任一所述方法。

8.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储的计算机程序被处理器执行时实现权利要求1至3任一所述方法。