媒体信息的播放方法和装置、存储介质、电子装置与流程

本发明涉及互联网领域，具体而言，涉及一种媒体信息的播放方法和装置、存储介质、电子装置。

背景技术：

随着互联网的发展，用户对浏览媒体信息的数量需求越来越大，商家、视频制作公司等往往需要在互联网平台、电视等媒介上投放大量的媒体推广信息，这些媒体推广信息包括但不局限于：电影、电视剧、短片、广告视频、广告图片、宣传片、动漫视频等。

相关技术中，在推送媒体信息时，采用广告软件开发工具包sdk实时向广告后台请求订单信息，从而广告后台根据请求信息去判断和抉择订单是否播放超频或者是否到达客户需求的库存量，但是每次实时请求都会造成时间延迟，会导致用户进入应用有100-200毫秒的延迟，影响了用户体验。

针对上述的问题，目前尚未提出有效的解决方案。

技术实现要素：

本发明实施例提供了一种媒体信息的播放方法和装置、存储介质、电子装置，以至少解决相关技术中播放媒体信息存在延迟的技术问题。

根据本发明实施例的一个方面，提供了一种媒体信息的播放方法，包括：获取目标媒体信息的第一播放次数，其中，第一播放次数为第一客户端在第一时刻从媒体服务器获取到的目标媒体信息的已播放次数；基于第一播放次数确定第二播放次数，其中，第二播放次数为目标媒体信息在第二时刻的已播放次数，第二时刻晚于第一时刻；在第二播放次数小于第一阈值的情况下，在第一客户端中播放目标媒体信息。

根据本发明实施例的另一方面，还提供了一种媒体信息的播放装置，包括：获取单元，用于获取目标媒体信息的第一播放次数，其中，第一播放次数为第一客户端在第一时刻从媒体服务器获取到的目标媒体信息的已播放次数；确定单元，用于基于第一播放次数确定第二播放次数，其中，第二播放次数为目标媒体信息在第二时刻的已播放次数，第二时刻晚于第一时刻；播放单元，用于在第二播放次数小于第一阈值的情况下，在第一客户端中播放目标媒体信息。

根据本发明实施例的另一方面，还提供了一种存储介质，该存储介质包括存储的程序，程序运行时执行上述的方法。

根据本发明实施例的另一方面，还提供了一种电子装置，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器通过计算机程序执行上述的方法。

在本发明实施例中，在确定待播放的媒体信息时，获取目标媒体信息的第一播放次数，第一播放次数为第一客户端在第一时刻从媒体服务器获取到的目标媒体信息的已播放次数；基于第一播放次数确定第二播放次数，第二播放次数为目标媒体信息在第二时刻的已播放次数，第二时刻晚于第一时刻；在第二播放次数小于第一阈值的情况下，在第一客户端中播放目标媒体信息，采用本申请的技术方案，可以在客户端或终端本地确认目标媒体信息的已播放次数，而不用与服务器进行交互，可以解决相关技术中播放媒体信息存在延迟的技术问题，进而达到了消除客户端或终端与服务器之间进行交互造成的延迟的技术效果。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1是根据本发明实施例的媒体信息的播放方法的硬件环境的示意图；

图2是根据本发明实施例的一种可选的媒体信息的播放方法的流程图；

图3是根据本发明实施例的一种可选的人群标签的示意图；

图4是根据本发明实施例的一种可选的媒体信息的播放的示意图；

图5是根据本发明实施例的一种可选的媒体信息预加载的架构示意图；

图6是根据本发明实施例的一种可选的媒体信息的播放方法的流程图；

图7是根据本发明实施例的一种可选的媒体信息的播放的示意图；

图8是根据本发明实施例的一种可选的媒体信息的播放装置的示意图；

图9是根据本发明实施例的一种可选的媒体信息的播放装置的示意图；

以及

图10是根据本发明实施例的一种终端的结构框图。

具体实施方式

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

需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

首先，在对本发明实施例进行描述的过程中出现的部分名词或者术语适用于如下解释：

cpm(costpermille)，每千人成本：只要向足够量级的用户展示了广告主的内容，广告主就为此付费，按此计费的广告一般是以品牌展示和产品发布为主，如新闻客户端的gd广告，曝光效果通常比较好。

cpd(costperdownload)每次下载成本：按用户完成应用下载计费，在应用商店、积分墙、流量联盟比较常见cpi(costperinstall)每安装成本。

根据本发明实施例的一方面，提供了一种媒体信息的播放方法的方法实施例。

可选地，在本实施例中，上述媒体信息的播放方法可以应用于如图1所示的由服务器101和终端103所构成的硬件环境中。如图1所示，服务器101通过网络与终端103进行连接，上述网络包括但不限于：广域网、城域网或局域网，终端103可以为移动终端，可在终端103上或独立于终端103设置数据库105，用于为终端103提供数据存储服务(如存储媒体信息的播放次数)，并不限定于pc、手机、平板电脑、可穿戴设备等。本发明实施例的媒体信息的播放方法可以由终端103来执行。其中，终端103执行本发明实施例的媒体信息的播放方法也可以是由安装在其上的客户端来执行。

图2是根据本发明实施例的一种可选的媒体信息的播放方法的流程图，如图2所示，该方法可以包括以下步骤：

步骤s202，终端获取目标媒体信息的第一播放次数，第一播放次数为第一客户端在第一时刻从媒体服务器获取到的目标媒体信息的已播放次数。

上述的媒体信息可以为推广信息，即用于推广某个对象的信息，该对象可以为虚拟或者实体的对象，如推广的商品、推广某种思想或道德理念、电影、教学内容等。

上述的第一客户端包括但不局限于：即时通讯应用、社交应用、微博应用、视频类应用、网页应用、图片分享应用、音乐分享应用等的客户端。

第一播放次数可以为所有客户端对目标媒体信息的播放次数，也可为第一客户端对目标媒体信息的播放次数。

步骤s204，终端基于第一播放次数确定第二播放次数，第二播放次数为目标媒体信息在第二时刻的已播放次数，第二时刻晚于第一时刻。

例如，第二时刻为客户端启动的当前时刻，第一时刻为第二时刻之前的某个时刻。

第一播放次数可以为所有客户端对目标媒体信息的播放次数，此时，步骤s204相当于根据之前某个时刻的第一播放次数来确认当前时刻的第二播放次数；第一播放次数也可为第一客户端对目标媒体信息的播放次数，由于第一时刻为第二时刻之前使用第一客户端的时刻，中间由于没有开启客户端，因此，确定了在第一时刻的第一播放次数就相当于确定了第二时刻的播放次数。

步骤s206，终端在第二播放次数小于第一阈值的情况下，在第一客户端中播放目标媒体信息。

上述的第一阈值可以为预定的目标媒体信息的播放次数，如商家在第一客户端上购买的用于推广目标媒体信息的次数。

通过上述步骤s202至步骤s206，在确定待播放的媒体信息时，获取目标媒体信息的第一播放次数，第一播放次数为第一客户端在第一时刻从媒体服务器获取到的目标媒体信息的已播放次数；基于第一播放次数确定第二播放次数，第二播放次数为目标媒体信息在第二时刻的已播放次数，第二时刻晚于第一时刻；在第二播放次数小于第一阈值的情况下，在第一客户端中播放目标媒体信息，采用本申请的技术方案，可以在客户端或终端本地确认目标媒体信息的已播放次数，而不用与服务器进行交互，可以解决相关技术中播放媒体信息存在延迟的技术问题，进而达到了消除客户端或终端与服务器之间进行交互造成的延迟的技术效果。

随着互联网的发展，用户花在移动端的时间已经超过花在电脑网页上的时间了，而且花在移动端的时间还在增长中，为了看这些记载在移动终端上的网页内容，用户不得不耐心等待网页加载，市场调研报告显示，3秒延迟之后，40％的用户会干脆把网页关掉，可见对于移动端的应用而言，及时的加载信息是非常必要的。

而本申请的技术方案恰恰可以达到及时加载信息的目的，在步骤s202提供的技术方案中，当用户启动第一客户端之后，终端不用与媒体信息服务器进行交互，转而直接获取本地保存的目标媒体信息的第一播放次数，第一播放次数为第一客户端在第一时刻从媒体服务器获取到的目标媒体信息的已播放次数，或第一客户端的播放次数。

在步骤s204提供的技术方案中，终端基于第一播放次数确定第二播放次数，第二播放次数为目标媒体信息在第二时刻的已播放次数，第二时刻晚于第一时刻。

可选地，若第一播放次数为第一客户端对目标媒体信息的播放次数，可以将第一播放次数作为第二播放次数。

可选地，若第一播放次数为所有客户端对目标媒体信息的播放次数，基于第一播放次数确定第二播放次数可包括如下步骤1-步骤2：

步骤1，客户端获取预先保存的第一方式，并按照第一方式确定第三播放次数，第三播放次数为对目标媒体信息的播放时间在第一时刻与第二时刻之间的播放次数，第一方式为在第二时刻之前保存在第一客户端上的。

第一方式可以是预先保存的算法，可以通过该算法确定目标媒体信息在任意时间段的播放次数，这样在按照第一方式确定第三播放次数包括：可以按照第一方式在第一播放周期中第三时刻与第四时刻之间的第四播放次数，从而可以根据第四播放次数确定第三播放次数，第三时刻在第一播放周期中的位置与第一时刻在第二播放周期中的位置相同，第四时刻在第一播放周期中的位置与第二时刻在第二播放周期中的位置相同，第一阈值次目标媒体信息被指定在第二播放周期内播放。

例如，第一时刻为当日10点，第二时刻为11点，第三时刻为前一日的10点，第四时刻为前一日的11点，例如，前一日在10点和11点之间的播放次数为100次，那么在根据第四播放次数确定第三播放次数时，可以将预估的100作为当日10点至11点播放的次数。

步骤2，将第一播放次数与第三播放次数之和作为第二播放次数。

很多企业还没有让他们的网页适配移动端，需要很长时间去加载，这会给人们带来不好的体验，还会出现网站废弃、错过生意和不准确的估量。此处的加载包括两个阶段，其一是在服务器上去实时请求还可播放的广告素材(即目标媒体信息)，其二是在查找到之后，利用该广告素材的标识去相应的服务器获取广告素材的内容。

利用本申请的步骤s206提供的技术方案中，终端在第二播放次数小于第一阈值的情况下，在第一客户端中播放目标媒体信息，可减少上述两个阶段中的至少之一，将广告素材预加载，将目标网页重定向降至最少，减少代码和压缩文件等各种改进措施都是将提升广告的体验，比如闪屏广告。

可选地，上述第一阈值可以为设置的所有客户端对目标媒体信息的播放上限次数，也可为第一客户端对目标媒体信息的播放上限次数。

可选地，上述第一阈值也可为第一客户端对目标媒体信息的播放上限次数，客户a在视频客户端投放闪屏广告，频次上限为全周期3次；此时在整个广告投放周期内，同一个用户最多看到3次客户a的闪屏广告，换言之，只要小于3，则可以继续播放该广告，否则不播放该广告。

例如，用户alice已经在某视频客户端上观看了2(如上述第五播放次数)次客户a的闪屏广告，当前打开应用客户端后看到了第三次该广告，广告系统收到sdk的请求后，将云端存储的用户alice观看a广告的次数置为3次。当alice下次打开视频应用时，广告系统可以发现该用户已经达到a广告的频次上限(也即第二阈值，如3次)，此时及以后就不再为alice展示a广告。订单投放结束后，将云端数据落地，即可得到所有用户对于订单a的观看次数。发送至第三方公司的请求同样用于统计所有用户对于订单的观看次数，客户从而可以得到一份第三方的频次控制数据，用于与广告系统的数据进行对比。

可选地，上述第一阈值可以为设置的所有客户端对目标媒体信息的播放上限次数，本申请技术方案的初衷在于，进行媒体信息的播放频次控制，频次控制可通过对用户的每次观看计数来实现，在第二播放次数小于第一阈值的情况下，在第一客户端中播放目标媒体信息可包括：在第二播放次数小于第一阈值且第五播放次数小于第二阈值的情况下，在第一客户端中播放目标媒体信息，第五播放次数为第一客户端在第二播放周期内对目标媒体信息的已播放次数。

换言之，上述实施例考虑了两个变量，其一是所有客户端对目标媒体信息的播放上限次数第一阈值，另外一个时第一客户端对目标媒体信息的播放上限次数第二阈值，究其原因在于，不可能严格预估每个用户开启客户端的次数，因此预估的总用户量可能会稍大，假设一个客户预定了600次广告推送，待推送用户群为具备标签“上海、女性”的用户，若每个人一天只能看3次，那么只需要200人就可以，但是实际上如果向200个用户的客户端推送，可能存在达不到600次的目的，因此，最终确认的用户可能为300人，故此时就可以按照上述两个变量进行控制，既可以保证推广量也不会使得单个客户端播放次数过多。

上述目标媒体信息可包括多个媒体信息，在第二播放次数小于第一阈值且第五播放次数小于第二阈值的情况下，在第一客户端中播放目标媒体信息可包括：获取多个媒体信息中的第一媒体信息，第一媒体信息为多个媒体信息中第二播放次数小于对应的第一阈值且播放次数小于对应的第二阈值的媒体信息；在第一客户端中播放从媒体服务器获取的第一媒体信息。

可选地，在第一客户端中播放从媒体服务器获取的第一媒体信息时，如第一媒体信息为多个，则可使用随机算法从多个第一媒体信息中选取出一个第二媒体信息；在第一客户端中播放从媒体服务器获取的第二媒体信息。

可选地，在第一客户端中播放从媒体服务器获取的第二媒体信息包括：在第一客户端启动后、且在第一客户端显示业务界面之前，从媒体服务器获取并播放第二媒体信息，其中，业务界面为第一客户端所提供的业务的交互界面。

也即上述第二媒体信息可以为“闪屏广告”，是在应用开启时加载，展示固定时间(如5秒)，展示完毕后自动关闭并进入应用主页面，由于展现在应用刚刚开启时，用户的注意力非常集中，适合广告主进行品牌宣传和产品推广。

上述的第二媒体信息可以在加载时从服务器获取，也可预先保存在客户端本地，在播放时从客户端本地获取，若第二媒体信息为“闪屏广告”，即属于预加载类型广告，为了曝光的充足与稳定，应用客户端可提前下发广告素材，当用户有wifi或者有网络时候，提前把广告素材下载到手机客户端本地，进而客户以在客户端启动时直接从本地加载。

可选地，在播放第二媒体信息之后，可将所播放的第二媒体信息的标识上报给媒体服务器，其中，媒体服务器用于根据接收到的上报的第二媒体信息的标识确定第二媒体信息的已播放次数。

可选地，在客户端关闭的过程中或关闭之前，可从媒体服务器获取并保存目标媒体信息在第五时刻的播放次数；还可获取用于根据目标媒体信息在第五时刻的播放次数计算目标媒体信息在第六时刻的播放次数的第二方式，第六时刻晚于第五时刻。

本申请技术方案的初衷在于，进行媒体信息的播放频次控制，频次控制可通过对用户的每次观看计数来实现，频次的含义为同一个用户看到指定广告的次数。频次上限即为广告客户希望的同一个用户看到其广告的上限次数。

当每一个用户成功观看广告媒体之后，视频客户端会可向广告系统及第三方监测公司同时发送一个请求，请求中包含用户信息，用户设备信息及成功观看的广告。广告系统收到请求后，会将用户观看了一次该广告的累计信息(也即第五播放次数)写入云端存储，用于广告系统下次选择订单时做出是否能选中该订单的依据。

作为一种可选的实施例，下面以将本申请的技术方案应用于广告推广为例，也即目标媒体信息为广告，进行详细说明。

相关技术中，采用广告sdk实时向广告后台请求订单信息，从而广告后台根据请求信息去判断和抉择订单是否播放超频或者是否到达客户需求的库存量，但是每次实时请求都有时间延迟，会导致用户进入应用有100-200毫秒的延迟，影响了用户体验。

若采用流量轮播切换投放，该技术方案为通过预加载请求下发cpd订单素材，不需要实时请求，但是本身的投放支持范围非常有限，只能支持cpd轮播投放，不能支持cpm的散投，目前已经不满足广告主的要求。

若采用预加载广告(闪屏广告)，虽然支持cpm投放，但是该技术方案为首先通过预加载请求下发订单素材，实际播放时由sdk发起实时请求，投放引擎决定当前应该播放哪个预加载订单素材，该方案支持cpd包段投放及cpm散投，可以满足广告主需求，但是存在用户体验上的问题，由于实时请求存在时间延迟，会导致用户进入应用客户端有100-200毫秒的延迟，对用户体验有一定的破坏。

预加载广告(闪屏广告)从开始到现在，历时几年的不同技术能力和售卖能力阶段，在初始阶段，可以实现流量轮播切换、cpd包断、素材预加载以及无广告实时请求；但是只能包断，无法提升流量变现效率和最大化；后来，可以实现cpm包断、散买、第一刷以及素材预加载，有广告实时请求；cpm售卖流量变现灵活；超频控少，超播少，媒体节约流量，但有实时广告请求，会让用户打开应用的速度加慢，因此会延迟进入应用首页，导致体验不是最好。

而在本申请的技术方案本案中，介绍了一种新的技术方案，可以实现cpm包断、散买、第一刷、素材预加载以及无广告实时请求，广告后台可只对应用用户uv(uv是uniquevisitor的简写，是指通过互联网访问、浏览这个网页的自然人)等数据进行预判，去做超频控少、超播少的控制。

假设一个客户预定了500cpm，可以根据如图3所示的人群标签确定推送用户群以及推送次数，上海、女性、每个人一天只能看3次，一种可选的广告如图4所示。有广告实时请求，广告后台可以根据设备信息，如即时通讯应用信息，订单信息随时知道，用户已经看了几次，是否达到了2次还是3次，是否订单整体已经消耗了500cpm还是400cpm；随时来调控播放策略，cpm总量和单一频次控制，从而不多给客户播cpm，也不多给用户看这个广告超过3次。因为超过3次，广告主不为第4次付钱，超过500cpm，广告主不为501个cpm付钱。

本案重点解决在预加载广告(闪屏广告)播放过程，广告sdk无需实时广告请求，广告后台在无任何前端数据支持的前提下，通过闪屏预加载uv数量与广告曝光量之间是线性转化关系，用订单当前预加载uv量预估实际播放量，并进行在线投放优化。

线性拟合得到的闪屏预加载到曝光的平均转化率在18％左右，即一个预加载uv大概能转化出0.18个曝光，该研究结果将应用到在线cpm投放逻辑中，从而在无实时广告请求的条件下，保证cpm订单尽量不超频不超播，为媒体节省流量资源，争取最大化的体验提升和收益提升。

本方案在支持cpm投放的前提下，通过预加载过程中对于预加载控制的优化，实现废除实时请求同时可以保证订单的播放量及频次的目的，为媒体节省流量资源，争取最大化的体验提升和收益提升。

预加载广告(闪屏广告)过程的技术架构如图5所示，架构中的主要模块有投放引擎，sdk，订单投放系统及预加载控制模块。

订单投放系统，负责预加载广告(闪屏广告)订单的投放，包括订单素材，定向内容等在投放系统中都得到确认；并将有效的预加载订单信息传递至投放引擎。

投放引擎，投放引擎是中心处理模块，负责从订单投放系统取到有效的预加载订单，并结合预加载控制模块给出的预加载控制信息进行预加载数据上报、预加载订单，选单过程在sdk发送预加载请求时实时进行。

选单数据及预加载控制模块，该模块整体负责接收投放引擎的预加载数据上报，并结合订单的预订量数据进行预加载控制信息的计算。存放选单数据的介质可以随意选择，如redis(一个开源的使用ansic语言编写、支持网络、可基于内存亦可持久化的日志型、key-value数据库，并提供多种语言的api)或druid(一个高效的数据查询系统，主要解决的是对于大量的基于时序的数据进行聚合查询，数据可以实时摄入，进入到druid后立即可查，同时数据是几乎是不可变通常是基于时序的事实事件，事实发生后进入druid，外部系统就可以对该事实进行查询)。

可选地，选单数据保存模块，可以使用不用的数据保存介质来保存及处理投放引擎上报的选单数据。例如可以通过redis等非关系型数据库储存原始数据，或者通过导入至druid等分布式数据系统进行数据聚合及分析。无论数据如何储存，是否经过聚合及预处理，都可以被预加载控制模块使用。

预加载控制模块中，可以使用不同的控制算法。例如可以为预加载订单计算分天的优先级及预载概率，通过优先级和概率体系指导投放引擎选单；或者通过选单数据预测到的订单覆盖率，判断订单是否应该停止预加载等。储存及聚合的选单数据，可以在预加载控制模块中套用多种算法，达到控制预加载订单的下发，使预加载下发更合理的目的。

前端sdk，负责在适当的时机向投放引擎发起预加载请求，得到订单返回后前往素材cdn服务器拉取相应素材，如向服务器发送素材请求，接收器返回的素材。

该技术方案的主要工作流如图6所示：

步骤s602，通过订单投放系统投放未来的预加载广告(闪屏广告)订单，确认闪屏订单的素材，预订量，定向内容等信息。

对预加载进行控制的核心目标是在有限的预加载广告(闪屏广告)库存中尽量满足所有订单的投放目的，避免闪屏订单出现缺量或者超播。

步骤s604，在适当的时机(如后台拉起应用进程时)，sdk向投放引擎发起预加载请求。

步骤s606，投放引擎从订单投放系统获取到有效的预加载订单，结合从控制模块获取到的订单的选单依据信息，选取适合未来播放的订单及其素材地址，分天或者整体返回至sdk，同时将选单信息上报到选单数据。

投放引擎上报预加载选单数据时，可以将预加载的订单号记录到pv或者uv级别，针对不同的记录方式可以得到不同的控制效果。预加载控制的方法可以有很多种，例如可以维护所有订单的预加载优先级及预加载概率，通过订单已经预加载的pv/uv数量及订单的预订量来调整订单优先级和概率，并在必要的时候停止某些订单的预加载，以防止订单超播。

步骤s608，sdk得到预加载订单及其素材地址后，去指定地址(素材服务器)将素材缓存下来，供广告素材展示使用，一种可选的广告素材展示如图7所示。

针对同一块预加载内容的多次sdk请求，投放引擎可独立进行选单，上一次预加载的订单，如果当前已经无效，可以通过这样的机制替换掉，sdk向投放引擎发起请求时，可以携带已经预加载好的订单号，投放引擎可以尽量选择保留其中仍然有效的订单，通过减少无意义的预加载订单替换减少带宽使用。

相关技术方案之所以需要实时请求过程，是因为订单预加载比较粗放，如果不在播放时进行预加载请求，很容易出现订单的超播与超频，本方案不需要预加载的主要原因在于投放引擎选单受预加载控制信息节制，在预加载控制信息中，每个订单对于每个用户是否进行了下发，下发次数，以及整体的订单预加载下发次数都能得到体现，通过绝对下发量以及用户下发量的控制，投放引擎可以有效的在预加载阶段避免订单超播与超频。

在本申请的技术方案中，无实时广告请求下，新的技术创新为媒体节省流量，提升体验和收益最大化；通过废除广告请求，为媒体节省了流量，提升了用户体验。通过优化预加载控制的分配机制，减少了素材加载使用的带宽量，实现了广告收益最大化。

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

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到根据上述实施例的方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如rom/ram、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。

根据本发明实施例的另一个方面，还提供了一种用于实施上述媒体信息的播放方法的媒体信息的播放装置。图8是根据本发明实施例的一种可选的媒体信息的播放装置的示意图，如图8所示，该装置可以包括：获取单元801、确定单元803以及播放单元805。

获取单元801，用于获取目标媒体信息的第一播放次数，其中，第一播放次数为第一客户端在第一时刻从媒体服务器获取到的目标媒体信息的已播放次数；

确定单元803，用于基于第一播放次数确定第二播放次数，其中，第二播放次数为目标媒体信息在第二时刻的已播放次数，第二时刻晚于第一时刻；

播放单元805，用于在第二播放次数小于第一阈值的情况下，在第一客户端中播放目标媒体信息。

需要说明的是，该实施例中的获取单元801可以用于执行本申请实施例中的步骤s202，该实施例中的确定单元803可以用于执行本申请实施例中的步骤s204，该实施例中的播放单元805可以用于执行本申请实施例中的步骤s206。

此处需要说明的是，上述模块与对应的步骤所实现的示例和应用场景相同，但不限于上述实施例所公开的内容。需要说明的是，上述模块作为装置的一部分可以运行在如图1所示的硬件环境中，可以通过软件实现，也可以通过硬件实现。

通过上述模块，在确定待播放的媒体信息时，获取目标媒体信息的第一播放次数，第一播放次数为第一客户端在第一时刻从媒体服务器获取到的目标媒体信息的已播放次数；基于第一播放次数确定第二播放次数，第二播放次数为目标媒体信息在第二时刻的已播放次数，第二时刻晚于第一时刻；在第二播放次数小于第一阈值的情况下，在第一客户端中播放目标媒体信息，采用本申请的技术方案，可以在客户端或终端本地确认目标媒体信息的已播放次数，而不用与服务器进行交互，可以解决相关技术中播放媒体信息存在延迟的技术问题，进而达到了消除客户端或终端与服务器之间进行交互造成的延迟的技术效果。

上述确定单元可包括：第一确定模块，用于将第一播放次数作为第二播放次数；第二确定模块，用于按照第一方式确定第三播放次数，并将第一播放次数与第三播放次数之和作为第二播放次数，其中，第三播放次数为对目标媒体信息的播放时间在第一时刻与第二时刻之间的播放次数，其中，第一方式为在第二时刻之前保存在第一客户端上的。

可选地，第一确定模块还可用于：根据第四播放次数确定第三播放次数，其中，第四播放次数为媒体信息在第一播放周期中第三时刻与第四时刻之间的播放次数，第三时刻在第一播放周期中的位置与第一时刻在第二播放周期中的位置相同，第四时刻在第一播放周期中的位置与第二时刻在第二播放周期中的位置相同，第一阈值次目标媒体信息被指定在第二播放周期内播放。

上述播放单元还可用于：在第二播放次数小于第一阈值且第五播放次数小于第二阈值的情况下，在第一客户端中播放目标媒体信息，其中，第五播放次数为第一客户端在第二播放周期内对目标媒体信息的已播放次数。

可选地，上述目标媒体信息可包括多个媒体信息，其中，上述播放单元可包括：获取模块，用于获取多个媒体信息中的第一媒体信息，其中，第一媒体信息为多个媒体信息中第二播放次数小于对应的第一阈值且播放次数小于对应的第二阈值的媒体信息；播放模块，用于在第一客户端中播放从媒体服务器获取的第一媒体信息。

上述播放模块还可用于：在第一媒体信息为多个的情况下，从多个第一媒体信息中选取出一个第二媒体信息；在第一客户端中播放从媒体服务器获取的第二媒体信息。

上述播放模块还可用于：在第一客户端启动后、且在第一客户端显示业务界面之前，从媒体服务器获取并播放第二媒体信息，其中，业务界面为第一客户端所提供的业务的交互界面。

可选地，如图9所示，本申请的装置还可包括：上报单元807，用于在播放第二媒体信息之后，将所播放的第二媒体信息的标识上报给媒体服务器，其中，媒体服务器用于根据接收到的上报的第二媒体信息的标识确定第二媒体信息的已播放次数。

可选地，本申请的装置还可包括：信息获取单元，用于在客户端关闭的过程中或关闭之前，从媒体服务器获取并保存目标媒体信息在第五时刻的播放次数；和/或，获取用于根据目标媒体信息在第五时刻的播放次数计算目标媒体信息在第六时刻的播放次数的第二方式，其中，第六时刻晚于第五时刻。

相关技术方案之所以需要实时请求过程，是因为订单预加载比较粗放，如果不在播放时进行预加载请求，很容易出现订单的超播与超频，本方案不需要预加载的主要原因在于投放引擎选单受预加载控制信息节制，在预加载控制信息中，每个订单对于每个用户是否进行了下发，下发次数，以及整体的订单预加载下发次数都能得到体现，通过绝对下发量以及用户下发量的控制，投放引擎可以有效的在预加载阶段避免订单超播与超频。

在本申请的技术方案中，无实时广告请求下，新的技术创新为媒体节省流量，提升体验和收益最大化；通过废除广告请求，为媒体节省了流量，提升了用户体验。通过优化预加载控制的分配机制，减少了素材加载使用的带宽量，实现了广告收益最大化。

此处需要说明的是，上述模块与对应的步骤所实现的示例和应用场景相同，但不限于上述实施例所公开的内容。需要说明的是，上述模块作为装置的一部分可以运行在如图1所示的硬件环境中，可以通过软件实现，也可以通过硬件实现，其中，硬件环境包括网络环境。

根据本发明实施例的另一个方面，还提供了一种用于实施上述媒体信息的播放方法的服务器或终端。

图10是根据本发明实施例的一种终端的结构框图，如图10所示，该终端可以包括：一个或多个(图10中仅示出一个)处理器1001、存储器1003、以及传输装置1005(如上述实施例中的发送装置)，如图10所示，该终端还可以包括输入输出设备1007。

其中，存储器1003可用于存储软件程序以及模块，如本发明实施例中的媒体信息的播放方法和装置对应的程序指令/模块，处理器1001通过运行存储在存储器1003内的软件程序以及模块，从而执行各种功能应用以及数据处理，即实现上述的媒体信息的播放方法。存储器1003可包括高速随机存储器，还可以包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，存储器1003可进一步包括相对于处理器1001远程设置的存储器，这些远程存储器可以通过网络连接至终端。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

上述的传输装置1005用于经由一个网络接收或者发送数据，还可以用于处理器与存储器之间的数据传输。上述的网络具体实例可包括有线网络及无线网络。在一个实例中，传输装置1005包括一个网络适配器(networkinterfacecontroller，nic)，其可通过网线与其他网络设备与路由器相连从而可与互联网或局域网进行通讯。在一个实例中，传输装置1005为射频(radiofrequency，rf)模块，其用于通过无线方式与互联网进行通讯。

其中，具体地，存储器1003用于存储应用程序。

处理器1001可以通过传输装置1005调用存储器1003存储的应用程序，以执行下述步骤：

获取目标媒体信息的第一播放次数，其中，第一播放次数为第一客户端在第一时刻从媒体服务器获取到的目标媒体信息的已播放次数；

基于第一播放次数确定第二播放次数，其中，第二播放次数为目标媒体信息在第二时刻的已播放次数，第二时刻晚于第一时刻；

在第二播放次数小于第一阈值的情况下，在第一客户端中播放目标媒体信息。

处理器1001还用于执行下述步骤：

根据第四播放次数确定第三播放次数，其中，第四播放次数为媒体信息在第一播放周期中第三时刻与第四时刻之间的播放次数，第三时刻在第一播放周期中的位置与第一时刻在第二播放周期中的位置相同，第四时刻在第一播放周期中的位置与第二时刻在第二播放周期中的位置相同，第一阈值次目标媒体信息被指定在第二播放周期内播放。

采用本发明实施例，在确定待播放的媒体信息时，获取目标媒体信息的第一播放次数，第一播放次数为第一客户端在第一时刻从媒体服务器获取到的目标媒体信息的已播放次数；基于第一播放次数确定第二播放次数，第二播放次数为目标媒体信息在第二时刻的已播放次数，第二时刻晚于第一时刻；在第二播放次数小于第一阈值的情况下，在第一客户端中播放目标媒体信息，采用本申请的技术方案，可以在客户端或终端本地确认目标媒体信息的已播放次数，而不用与服务器进行交互，可以解决相关技术中播放媒体信息存在延迟的技术问题，进而达到了消除客户端或终端与服务器之间进行交互造成的延迟的技术效果。

可选地，本实施例中的具体示例可以参考上述实施例中所描述的示例，本实施例在此不再赘述。

本领域普通技术人员可以理解，图10所示的结构仅为示意，终端可以是智能手机(如android手机、ios手机等)、平板电脑、掌上电脑以及移动互联网设备(mobileinternetdevices，mid)、pad等终端设备。图10其并不对上述电子装置的结构造成限定。例如，终端还可包括比图10中所示更多或者更少的组件(如网络接口、显示装置等)，或者具有与图10所示不同的配置。

本领域普通技术人员可以理解上述实施例的各种方法中的全部或部分步骤是可以通过程序来指令终端设备相关的硬件来完成，该程序可以存储于一计算机可读存储介质中，存储介质可以包括：闪存盘、只读存储器(read-onlymemory，rom)、随机存取器(randomaccessmemory，ram)、磁盘或光盘等。

本发明的实施例还提供了一种存储介质。可选地，在本实施例中，上述存储介质可以用于执行媒体信息的播放方法的程序代码。

可选地，在本实施例中，上述存储介质可以位于上述实施例所示的网络中的多个网络设备中的至少一个网络设备上。

可选地，在本实施例中，存储介质被设置为存储用于执行以下步骤的程序代码：

s12，获取目标媒体信息的第一播放次数，其中，第一播放次数为第一客户端在第一时刻从媒体服务器获取到的目标媒体信息的已播放次数；

s14，基于第一播放次数确定第二播放次数，其中，第二播放次数为目标媒体信息在第二时刻的已播放次数，第二时刻晚于第一时刻；

s16，在第二播放次数小于第一阈值的情况下，在第一客户端中播放目标媒体信息。

可选地，存储介质还被设置为存储用于执行以下步骤的程序代码：

s22，根据第四播放次数确定第三播放次数，其中，第四播放次数为媒体信息在第一播放周期中第三时刻与第四时刻之间的播放次数，第三时刻在第一播放周期中的位置与第一时刻在第二播放周期中的位置相同，第四时刻在第一播放周期中的位置与第二时刻在第二播放周期中的位置相同，第一阈值次目标媒体信息被指定在第二播放周期内播放。

可选地，本实施例中的具体示例可以参考上述实施例中所描述的示例，本实施例在此不再赘述。

可选地，在本实施例中，上述存储介质可以包括但不限于：u盘、只读存储器(rom，read-onlymemory)、随机存取存储器(ram，randomaccessmemory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

上述实施例中的集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在上述计算机可读取的存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在存储介质中，包括若干指令用以使得一台或多台计算机设备(可为个人计算机、服务器或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。

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

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

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

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

以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。