具体实施方式
以下描述中,为了说明而不是为了限定,提出了诸如特定系统结构、技术之类的具体细节,以便透彻理解本申请实施例。然而,本领域的技术人员应当清楚,在没有这些具体细节的其它实施例中也可以实现本申请。在其它情况中,省略对众所周知的系统、装置、电路以及方法的详细说明,以免不必要的细节妨碍本申请的描述。
应当理解,当在本申请说明书和所附权利要求书中使用时,术语“包括”指示所描述特征、整体、步骤、操作、元素和/或组件的存在,但并不排除一个或多个其它特征、整体、步骤、操作、元素、组件和/或其集合的存在或添加。
还应当理解,在本申请说明书和所附权利要求书中使用的术语“和/或”是指相关联列出的项中的一个或多个的任何组合以及所有可能组合,并且包括这些组合。
如在本申请说明书和所附权利要求书中所使用的那样,术语“若”可以依据上下文被解释为“当...时”或“一旦”或“响应于确定”或“响应于检测到”。类似地,短语“若确定”或“若检测到[所描述条件或事件]”可以依据上下文被解释为意指“一旦确定”或“响应于确定”或“一旦检测到[所描述条件或事件]”或“响应于检测到[所描述条件或事件]”。
另外,在本申请说明书和所附权利要求书的描述中,术语“第一”、“第二”等仅用于区分描述,而不能理解为指示或暗示相对重要性。
在本申请说明书中描述的参考“一个实施例”等意味着在本申请的一个或多个实施例中包括结合该实施例描述的特定特征、结构或特点。由此,在本说明书中的不同之处出现的语句“在一个实施例中”等不是必然都参考相同的实施例,而是意味着“一个或多个但不是所有的实施例”,除非是以其他方式另外特别强调。术语“包括”、“包含”、“具有”及它们的变形都意味着“包括但不限于”,除非是以其他方式另外特别强调。
实施例一:
为了解决现有技术中,根据用户的播放记录进行多媒体推送时,无法确定播放记录是否有效,从而导致推送决策的准确性较低的问题,本申请实施例提供了一种多媒体数据的推送系统。图1示出了本申请一实施例提供的多媒体数据的推送系统的结构示意图。参见图1所示,该多媒体数据的推送系统包括服务器、终端设备以及耳机,该耳机包括但不限于:线控耳机、蓝牙耳机或骨传导耳机等。其中,服务器与终端设备之间可以建立有通信链路,通过上述通信链路进行数据交互,例如终端设备可以通过通信链路上传播放记录,而服务器还可以通过通信链路推送多媒体数据;耳机与终端设备之间可以建立有通信链路,通过上述通信链路进行传输多媒体数据,并通过耳机进行播放。
参见图2所示,图2示出了本申请一实施例提供的多媒体数据的推送系统的交互流程图,详述如下:
在S21中,终端设备若处于多媒体播放状态,则获取耳机状态信息。
在本实施例中,终端设备具体为可以执行多媒体数据的播放操作的设备,举例性地,该终端设备可以为智能手机、手提电脑、平板电脑、智能音箱等移动设备,还可以为计算机电脑、服务器设备、智能冰箱等智能设备。终端设备可以通过读取本地的多媒体数据库获取多媒体文件进行播放操作,还可以通过与云端服务器进行连接,从云端服务器下载所需播放的多媒体数据进行播放。可选地,终端设备可以安装有多媒体的播放程序,该播放程序可以与对应的云端服务器建立通信连接,接收云端服务器反馈的多媒体数据,在接收到多媒体数据后,通过该播放程序输出上述多媒体数据。
在本实施例中,该多媒体数据包括但不限于:音乐文件、视频文件、游戏文件以及动态图片文件等。在上述多媒体数据播放的过程中,包含有音频信号,该音频信号可以通过与终端设备对应的耳机部件进行播放。
在本实施例中,终端设备可以与耳机部件建立通信链路,通过该通信链路将多媒体数据中的音频信号传输给耳机部件,通过耳机部件输出音频信号。具体地,该耳机部件与终端设备之间通信连接可以为有线连接,在该情况下,终端设备可以通过耳机接口与耳机部件相连,特别地,该耳机接口具体为AUX(Auxiliary)接口,可以为3.5mmAUX接口,若终端设备配置有type-C接口,且该type-C接口具有音频数据的传输协议,则上述耳机接口还可以为type-C接口,对于IOS系统的设备,上述耳机接口还可以为Lightning接口,在此不对耳机接口的接口类型进行限定。
在一种可能的实现方式中,耳机部件与终端设备之间的通信链接可以为无线通信链接。该无线通信链接包括但不限于蓝牙无线通信、WiFi无线通信、紫蜂ZigBee通信、红外通信等。以蓝牙无线通信为例进行说明,终端设备可以配置有蓝牙通信模块,通过启动蓝牙通信模块搜索当前环境内包含的蓝牙设备,例如具有蓝牙通信功能的耳机部件,终端设备通过蓝牙通信模块向具有蓝牙通信功能的耳机部件发送连接请求,耳机部件在接收到终端设备返送的连接请求后,可以向终端设备反馈一个连接应答信息,并建立与终端设备之间的基于蓝牙协议的无线通信链路,继而终端设备在接收到该连接应答信息后,可以识别该无线通信链路已建立,并通过该无线通信链路向耳机部件发送多媒体数据。
在本实施例中,终端设备可以接收用户输入的播放指令,选取播放指令对应的多媒体数据并进行播放;终端设备还可以接收服务器发送的推送数据,从推送数据中提取服务器推送的多媒体数据并进行播放。终端设备在播放多媒体数据时,即为处于多媒体播放状态。
在本实施例中,耳机部件可以向终端设备反馈耳机状态信息,该耳机状态信息可以包括有佩戴状态标识,还可以包括有佩戴时长、音频播放音量等信息。具体地,耳机部件可以通过用“1”表示耳机处于已佩戴状态,用“0”标识耳机处于未佩戴状态。终端设备可以读取佩戴状态标识的位值,确定耳机部件的佩戴状态。
在一种可能的实现方式中,获取耳机部件的佩戴时长的方式可以为:耳机部件可以以预设的反馈周期向终端设备发送在反馈时刻对应的耳机佩戴状态,终端设备基于各个反馈时刻对应的耳机佩戴状态以及耳机反馈周期的周期时长,计算得到耳机部件对应的佩戴时长。具体地,终端设备可以统计佩戴状态标识为第一位值(第一位值用于表示耳机部件处于佩戴状态)的佩戴周期个数,并基于佩戴周期个数以及周期时长,确定耳机部件的佩戴时长。举例性地,若终端设备接收到某一耳机部件反馈的佩戴状态标识构成的序列为[0111100],而反馈周期的周期时长为10s,即耳机部件每10秒向终端设备发送一个佩戴状态标识,通过上述序列可以统计得到的处于第一位值的佩戴周期个数为4个,即可以计算得到耳机部件的佩戴时长为4*10s=40s。
在一种可能的实现方式中,获取耳机部件的佩戴时长的方式可以为:耳机部件可以每播放完成一个多媒体数据后,向终端设备反馈一次耳机状态信息。在该情况下,耳机部件可以通过内置的传感器(例如距离传感器或磁传感器等)确定耳机部件的佩戴状态,并在多媒体数据开始播放时,记录耳机部件的初始状态,并在耳机部件每一次改变时,记录变更时间,生成关于耳机部件的状态变更波形图。在多媒体数据播放完毕时刻,根据状态变更波形图确定耳机佩戴状态的持续时长或未佩戴状态的持续时长,并将上述两个时长的任一时长封装到耳机状态信息内,并反馈给终端设备。可选地,若上述耳机部件记录的时长为未佩戴状态的持续时长,耳机部件可以根据当前播放的目标多媒体的总播放时长与未佩戴状态的持续时长之差,计算得到佩戴状态的持续时长。同理,可以计算当前播放的目标多媒体的总播放时长与未佩戴状态的持续时长之差,确定未佩戴状态的持续时长,具体根据终端设备所需反馈的数据类型确定。
进一步地,作为本申请的另一实施例,图3示出了本申请S21的具体实现方式,参见图3所示,相当于图2所示实施例,本实施例中的S21还可以包括S211以及S212,具体详述如下:
在S211中,终端设备记录耳机在所述目标多媒体的播放过程中的耳机佩戴时长。
在本实施例中,终端设备可以与耳机部件建立通信连接,并接收耳机部件反馈的佩戴状态信息。其中,耳机部件内可以配置有传感器,通过传感器可以确定当前耳机的佩戴状态,例如当前处于佩戴状态或是未佩戴状态,根据各个状态的持续时长,终端设备可以确定耳机部件在目标多媒体播放的过程中对应的耳机佩戴时长,或者未佩戴时长。
在一种可能的实现方式中,若耳机部件与终端设备之间可以通过有线方式进行连接。示例性地,图4示出了本申请一实施例提供的终端设备与耳机部件之间的连接示意图。参见图4所示,该终端设备为一智能手机,该智能手机配置有耳机接口,耳机部件可以通过耳机接口与智能手机连接。其中,耳机部件在挂耳部件处可以配置有传感器,传感器可以采集对应的感应值,通过与终端设备之间的耳机接口发送给终端设备,终端设备通过解析该感应值确定耳机的佩戴状态。
在一种可能的实现方式中,若耳机部件与终端设备之间可以通过无线方式进行连接。示例性地,图5示出了本申请一实施例提供的终端设备与耳机部件之间的连接示意图。参见图5所示,该终端设备为一智能手机,该智能手机配置有无线通信模块,该无线通信模块具体可以为蓝牙通信模块,并通过无线通信模块发射无线信号,耳机部件也可以内置有无线通信模块,同样地,可以通过无线通信模块发射无线信号。终端设备可以通过无线通信模块搜索耳机部件发送的无线信号,并加入到耳机部件的无线局域网内,从而建立了无线通信链路。其中,耳机部件在挂耳部件处同样可以配置有传感器,传感器可以采集对应的感应值,通过与终端设备之间的耳机接口发送给终端设备,终端设备通过解析该感应值确定耳机的佩戴状态。
在本实施例中,耳机部件可以在音频数据结束时,将记录得到的耳机佩戴时长反馈给终端设备,从而终端设备可以获取得到与目标多媒体对应的耳机佩戴时长;耳机部件可以以预设的时间间隔反馈耳机佩戴标识,终端设备可以根据在目标多媒体的播放过程中接收到的耳机佩戴标识,确定对应的佩戴时长。例如,在目标多媒体播放开始时,耳机部件反馈的耳机状态标识为已佩戴状态,且在目标多媒体播放完成时,耳机部件的佩戴状态并非发生改变,均为已佩戴状态,此时可以将目标多媒体的播放时长作为耳机佩戴时长;若在目标多媒体播放的某一时刻,该耳机部件有已佩戴状态变更为未佩戴状态,且在目标多媒体播放完成时,耳机部件依然为未佩戴状态,则可以计算目标多媒体的开始时刻至状态变更时刻之间的差值,确定耳机佩戴时长。
示例性地,图6示出了本申请一实施例提供的耳机佩戴状态的波形图。参见图6所示,耳机部件可以以预设的时间间隔向终端设备发送佩戴状态标识,其中0表示未佩戴状态,1表示已佩戴状态,终端设备可以统计1在整个目标多媒体播放过程中的总持续时长,从而得到耳机佩戴时长,即为30s+20s+20s=70s。
在一种可能的实现方式中,获取耳机部件的佩戴状态标识的方式可以为:耳机部件在左右挂耳部件上配置有距离传感器,耳机部件可以通过距离传感器获取左右挂耳部件之间的距离值。若距离值在预设的佩戴距离范围内,则识别耳机部件处于佩戴状态;反之,若距离值在佩戴距离范围外,则识别耳机部件处于未佩戴状态。由于人体双耳之间的距离会存在一定的距离范围,若耳机部件的左右挂耳之间的距离值大于或小于该距离范围,则可以表示耳机部件并未佩戴;反之,若距离值在该距离范围内,则表示用户正在佩戴着耳机部件,因此,可以通过耳机部件内的距离传感器反馈的距离值,判断耳机部件的佩戴状态标识。耳机部件可以根据佩戴状态标识的持续时长,确定耳机佩戴时长。
在一种可能的实现方式中,终端设备在检测到耳机部件内左右挂耳之间的距离值在预设的距离范围内,可以获取该距离范围的维持时间,若该维持时间大于预设的有效阈值,则开始记录耳机部件的佩戴时长,反之,若该维持时间小于或等于有效阈值,则不记录耳机部件的佩戴时长。由于耳机部件在未佩戴状态下进行移动或摆动的过程中,可能某一个时刻或某几个时刻左右挂耳之间的距离值会在上述的距离范围内,但维持时间较短,并不能认为该耳机部件处于佩戴状态。基于此,终端设备可以确定上述距离值的维持时间,从而更为准确地确定耳机部件是否处于佩戴状态,继而提高了推送操作的准确性。
在S212中,终端设备基于所述目标多媒体对应的耳机佩戴时长生成所述耳机状态信息;所述目标多媒体对应的耳机佩戴时长用于确定所述目标多媒体对应的播放记录的推送贡献权重。
在本实施例中,终端设备可以将上述的耳机佩戴时长添加到耳机状态信息内,其中该耳机佩戴时长的数值越大,则该耳机状态信息对应播放记录的推送贡献权重越大;反之,若该耳机状态信息对应播放记录的数值越小,对应的推送贡献权重越小。需要说明的是,终端设备每播放一个目标多媒体数据,会分别记录各个目标多媒体数据对应的耳机佩戴时长,并基于各个目标多媒体数据对应的耳机佩戴时长,确定该目标多媒体数据的播放记录对应的推送贡献权重。
在本申请实施例中,通过获取在多媒体数据在播放过程中的耳机佩戴时长,从而根据耳机佩戴时长动态调整推送贡献权重,能够提高权重值的准确性,继而提高后续推送决策的准确性。
在S22中,终端设备基于所述耳机状态信息生成当前播放的目标多媒体的播放记录。
在本实施例中,终端设备在接收到耳机状态信息后,在生成当前播放的目标多媒体数据的播放记录时,可以将上述耳机状态信息添加到上述的播放记录内。具体地,该播放记录可以包括有当前播放的目标多媒体数据的文件标识、终端设备所属用户的用户标识(也可以是终端设备的设备标识或终端设备所安装的播放程序的程序标识)以及耳机状态信息,可选地,该播放记录可以包含有当前播放的目标多媒体的播放时间、文件时长、文件类型以及文件标签等信息。
示例性地,现有技术中,终端设备在播放多媒体数据时,并不会记录耳机的播放状态。而终端设备可以根据服务器推送的多媒体数据持续执行播放操作。若用户在终端设备持续播放多个多媒体数据的过程中摘下耳机,用户并不会收听摘下耳机状态下播放的多媒体数据,同样无法确定用户对摘下耳机状态下播放的多媒体数据是否感兴趣,若在该情况下,终端设备识别用户对所有存在播放记录的多媒体数据均为感兴趣,并基于所有播放记录确定用户的推送决策,则必然会降低推送决策的准确性。因此,终端设备可以将耳机状态信息添加到播放记录中,通过耳机状态信息确定用户是否有观看或收听当前播放的目标多媒体,从而确定该播放记录的有效性,选取有效的播放记录生成用户的推送决策,从而能够提高推送决策的准确性。
在本实施例中,终端设备可以在目标多媒体播放完毕后,生成关于该目标多媒体的播放记录。可选地,若当前播放的目标多媒体不满足生成播放记录的生成条件,终端设备可以不生成该目标多媒体的播放记录;反之,若当前播放的目标多媒体满足预设的播放记录的生成条件,则执行S22的操作。具体地,终端设备可以记录目标多媒体的播放时长,若该播放时长大于预设的有效阈值,则识别满足播放记录的生成条件。可选地,该有效阈值可以根据目标多媒体的总播放时长进行调整,具体地,该有效阈值与目标多媒体的总部时长之间的比值满足预设比例,例如50%,即播放时长要超过目标多媒体的总时长的一半,才生成目标多媒体的播放记录。
在S23中,终端设备上传所述播放记录至所述目标多媒体对应的服务器;所述播放记录用于所述服务器根据所述播放记录内的所述耳机状态信息对所述目标多媒体进行推送。
在本实施例中,终端设备与目标多媒体对应的服务器可以建立有通信链路,通过上述通信链路将关于终端设备的播放记录上传给服务器。具体地,若终端设备可以安装有服务器对应的客户端程序,可以通过客户端程序与服务器建立上述的通信链路,具体地,客户端程序可以通过关联的通信接口生成一个连接请求,该连接请求包含有客户端程序的客户端编号以及预先约定的授权码,服务器在接收到上述的连接请求后,可以判断该客户端编号是否为合法客户端程序,若是,则对授权码进行校验,从而识别该连接请求是否为合法请求。若该授权码通过预设的校验算法,则识别该连接请求为合法的连接请求,在该情况下,服务器会向终端设备反馈一个连接确认指令,此时,终端设备与服务器之间的通信链路则建立完成。服务器可以通过上述通信链路向终端设备发送多媒体数据,以及接收终端设备上传的播放记录。
在一种可能的实现方式中,目标多媒体发布与多个数据平台,每个数据平台可以对应不同的服务器以及客户端程序。终端设备可以对播放记录进行多平台的共享,从而能够提高推送决策的准确性。具体地,终端设备在获取了关于目标多媒体的播放记录后,可以检测本地安装有的多媒体播放程序,若存在多个多媒体播放程序,则可以判断上述目标多媒体是否存储于其他多媒体播放程序的服务器内,若存在,则通过其他多媒体程序生成关于该目标多媒体的播放记录,通过各个多媒体的播放程序分别向各个服务器发送对应的播放记录。举例性地,终端设备安装有“QQ音乐”以及“AppleMusic”两个音乐播放程序。终端设备通过“QQ音乐”程序播放了一首“My Heart Will Go On”,则通过QQ音乐程序生成关于“MyHeart Will Go On”的播放记录,此时,终端设备识别本地也安装有“AppleMusic”这一音乐播放程序,则且“AppleMusic”对应的服务器也存储有“My Heart Will Go On”这一多媒体数据,此时可以通过“AppleMusic”生成关于上述歌曲的播放记录,将各个播放记录上传到对应程序的服务器。
在本实施例中,上述生成的播放记录可以包含有终端设备所属用户的用户标识。该用户标识可以为用户账户的账户名、账户编号等用于标示用户身份的信息。通过上述用户标识,用户可以在多个不同的终端设备上播放目标多媒体,并将所有播放记录上传到目标多媒体的服务器,服务器可以根据用户标识,将各个不同终端设备上传的播放记录存储到与用户标识关联的存储区域,并生成推送决策,从而能够使得在不同设备上的播放记录能够根据用户标识进行统一管理,提高了播放记录的管理效率。由于用户标识相同,即便在不同终端设备上进行操作,但所属的实体用户是相同的,具有相同的关注领域或相同偏好,因此,基于用户标识对播放记录进行管理,能够提高后续推送决策的准确性。
在一种可能的实现方式中,在不同的终端设备上,相同的用户具有对应的操作习惯或多媒体的播放模式,而上述终端设备之间的差异可能会影响推送操作的准确性。例如,用户在通过手机观看视频时,往往处于较为嘈杂且快速移动的场景下,此时用户可能更偏向于观看短视频,而当用户通过台式电脑观看视频时,用户可以处于较为安静且不需频繁移动的场景下,此时用户可能更偏向于观看剧集。基于此,虽然上述的手机以及台式电脑对应的实体用户相同,理应具有相同的观看习惯以及多媒体类型的偏好,但对应不同类型的终端设备,上述习惯以及偏好也会有一定的调整,基于此,终端设备在上传播放记录时,除了获取用户的用户标识外,还可以添加有终端设备的设备类型,服务器在执行推送操作时,可以根据所需推送的设备类型,动态调整各个播放记录的设备权重值,从而能够提高后续推送操作的准确性。举例性地,服务器在生成手机的推送决策时,可以将所有通过手机类型上传播放记录的权重值调整为0.5,而将所有通过台式电脑上传的播放记录的权重值调整为0.3;对应地,服务器在生成台式电脑的推送决策时,可以将所有台式电脑上传的播放记录的权重值调整为0.5,而手机类型上传的播放记录的权重值调整为0.3,即对应所需推送的设备不同,同一播放记录的设备权重值可以动态调整。
在S24中,服务器根据所述终端设备上传的关于目标多媒体的播放记录内的所述耳机状态信息,确定所述播放记录的推送贡献权重。
在本实施例中,服务器可以接收各个终端设备上传的播放记录,并将所有播放记录存储于数据库内,该数据库可以为服务器的本地数据库,也可以通过分布式存储的方式,将所有播放记录存储于多个分布式的数据库节点,在需要进行推送决策时,可以从多个不同的数据库节点获取关联的播放记录,并生成对应的播放决策。
在本实施例中,服务器在接收到播放记录后,可以提取播放记录内包含的耳机状态信息,并根据耳机状态信息确定该播放记录对应的推送贡献权重。具体地,若该推送贡献权重越高,则在后续的推送决策中该播放记录的参考价值越高;反之,若该推送权重值越低,则在后续的推送决策中该播放记录的参考价值越低。特别地,若该推送权重值为0时,则识别该播放记录为无效记录,在后续推送决策中不将该播放记录作为参考。
在一种可能的实现方式中,服务器可以根据耳机状态信息中的播放音量确定播放记录的推送贡献权重,具体地,终端设备可以配置有播放音量与推送贡献权重之间的转换算法,并基于上述的转换算法计算各个播放音量对应的推送贡献权重。可选地,若推送贡献权重为二值化的权重值,即分为1和0,用于区别有效播放记录以及无效播放记录,在该情况下,终端设备将播放音量小于或等于预设的音量阈值的播放记录,识别为无效播放记录;而将播放音量大于音量阈值的播放记录识别为有效播放记录。具体地,该音量阈值可以为0,即音量大于0的播放记录为有效记录,而将播放音量为0的播放记录识别为无效记录。
进一步地,作为本申请的另一实施例,图7示出了本申请S24的具体实现方式,参见图7所示,相当于图2所示实施例,本实施例中的S24还可以包括S71~S74,具体详述如下:
在S72中,若所述耳机状态信息为未佩戴状态,则服务器将所述播放记录的所述推送贡献权重设置为0。
在本实施例中,终端设备发送的耳机状态信息中包含有佩戴标识,服务器可以通过获取该佩戴标识,确定目标多媒体在播放过程中,耳机是处于已佩戴状态或是处于未佩戴状态。若该目标多媒体在播放过程中,耳机处于未佩戴状态,则执行S71的操作;反之,若该目标多媒体在播放过程中,耳机处于已佩戴状态,则执行S72的操作。需要说明的是,在目标多媒体在播放过程中耳机处于未佩戴状态,则表示终端设备的所属用户并未完整收听或收看该目标多媒体,并不能认为用户对该目标多媒体感兴趣,因此会将该播放记录的推送贡献权重设置为0,则在后续推送决策时,不会产生任何影响,即为无效的播放记录。
作为示例而非限定,以以下场景对用户未佩戴耳机播放多媒体进行解释说明。用户在使用手机的过程中,终端设备可以基于预设的播放列表播放内的各个多媒体数据,用户通过佩戴耳机来接收多媒体数据播放过程中的音频信号,用户在播放过程中,由于某些事情放下手机,但忘记点击播放暂停按钮,此时,手机会保持播放状态,根据预设的播放次序,播放各个多媒体数据,由于用户并没有携带手机以及耳机,用户并没有处于观看或收听多媒体数据的状态,因此,用户并非对当前播放的多媒体数据感兴趣,因此并不能基于在该状态下生成的播放记录作为推送决策的依据,需要识别该类型的播放记录为无效播放记录,因此,将上述类型的推送贡献权重设置为0,从而能够避免在后续推送决策的影响。
在S74中,若所述耳机状态信息为已佩戴状态,则服务器将所述播放记录的所述推送贡献权重设置为1。
在本实施例中,在目标多媒体在播放过程中耳机处于已佩戴状态,则表示终端设备的所属用户收听或收看该目标多媒体,可以认为用户对该目标多媒体感兴趣,因此会将该播放记录的推送贡献权重设置为1,则在后续推送决策时,根据用户感兴趣的多媒体数据进行生成推送决策,即将已佩戴状态的播放记录作为有效的播放记录。
在本申请实施例中,根据耳机状态信息的佩戴标识,确定该播放记录的推送贡献权重,从而能够筛选出有效的播放记录,即推送贡献权重为1的播放记录,并基于有效播放记录进行推送决策,提高了推送准确性。
进一步地,作为本申请的另一实施例,若所述耳机状态信息包含耳机佩戴时长,则在S72之前,还可以包括S71;
在S71中,若所述耳机佩戴时长与所述目标多媒体的播放总时长之间的比值小于或等于所述有效阈值,则服务器识别所述播放记录的所述耳机状态信息为所述未佩戴状态。
在本实施例中,服务器可以获取播放记录对应的目标多媒体的播放总时长。具体地,播放记录内可以携带有目标多媒体的文件标识,该文件标识可以为文件名或者文件编号等,服务器可以通过上述的文件标识从文件数据库中进行查找,获取得到该文件标识对应的文件信息,该文件信息可以包含有目标多媒体的播放总时长。在一种可能的实现方式中,该播放记录中该可以记录有目标多媒体的播放总时长,在该情况下,服务器可以直接从播放记录中提取得到播放总时长即可。
在本实施例中,服务器可以计算播放记录的耳机佩戴时长与目标多媒体的播放总时长之间的比值,若该比值小于或等于有效阈值,则执行S71的操作;反之,若该比值大于有效阈值,则执行S73的操作。由于当两者之间的比值较小时(即比值小于或等于有效阈值),则表示用户在目标多媒体播放的过程中,大部分时间是处于未佩戴耳机状态,并没有收看或收听该目标多媒体,此时可以识别耳机处于未佩戴状态。
进一步地,作为本申请的另一实施例,在S74之前,还可以包括S73;
在S73中,若所述耳机佩戴时长与所述目标多媒体的播放总时长之间的比值大于预设的有效阈值,则服务器识别所述播放记录的所述耳机状态信息为所述已佩戴状态。
在本实施例中,由于当两者之间的比值较大时(即比值大于有效阈值),则表示用户在目标多媒体播放的过程中,大部分时间是处于佩戴耳机状态,即收看或收听该目标多媒体,此时可以识别耳机处于已佩戴状态。
在一种可能的实现方式中,该有效阈值为1/3,即用户收看或收听的时间超过目标多媒体的播放总时长的三分之一,则表示对目标多媒体感兴趣,因此会将耳机状态信息配置为已佩戴状态。
在本申请实施例中,通过获取耳机佩戴时长,并根据耳机佩戴时长与目标多媒体的播放总时长之间的比值,确定该播放记录是否有效,从而能够提高播放记录的有效识别的准确性。例如,用户在整个目标多媒体数据的开始一个较短时间段佩戴了耳机,而后续所有播放时间内均没有佩戴耳机,并不能判断用户对该目标多媒体感兴趣,通过设置有效阈值,能够提高有效识别的准确性。
进一步地,作为本申请的另一实施例,图8示出了本申请S24的具体实现方式,参见图8所示,相当于图2所示实施例,本实施例中的S24具体为S81,具体详述如下:
在S81中,服务器根据所述耳机状态信息的所述耳机佩戴时长,确定所述推送贡献权重。
在本实施例中,服务器可以存储有推送贡献权重的转换算法,将播放记录中耳机状态信息的耳机佩戴时长导入到上述的转换算法中,计算得到该播放记录关联的推送贡献权重。具体地,该耳机佩戴时长的数值越大,对应的推送贡献权重越高;反之,若该耳机佩戴时长的数值越小,对应的推送贡献权重越小。
示例性地,上述的推送贡献权重的转换算法具体可以为:
其中,Recommend为上述的推送贡献权重;WearTime为上述的耳机佩戴时长;TotalTime为播放记录中目标多媒体的播放总时长;ξ为加权调整系数。
在一种可能的实现方式中,若耳机状态信息中包含的是未佩戴时长,则上述推送贡献权重的转换算法具体可以为:
其中,Recommend为上述的推送贡献权重;UnwearTime为上述的未佩戴时长;TotalTime为播放记录中目标多媒体的播放总时长;ξ为加权调整系数。
在本申请实施例中,根据耳机佩戴时长动态调整推送贡献权重,能够实现推送贡献权重的多样性,除了通过二值化的方式识别出无效的播放记录外,还可以根据用户的实际观看时长,确定该播放记录的权重大小,进一步提高了推送决策的准确性。
在S25中,服务器根据所述播放记录的所述推送贡献权重确定所述目标多媒体的目标对象。
在本实施例中,服务器在确定各个播放记录对应的推送贡献权重后,可以对所有推送贡献权重值进行加权运算,从而能够确定目标多媒体对应的目标对象。
在一种可能的实现方式中,确定目标对象的方式可以为:服务器从播放记录中提取用户标识,并获取用户标识对应的用户信息,从用户信息中确定在多个预设的用户维度的用户参量,分别根据各个播放记录对应的推送贡献权重,对各个用户参量进行加权运算,得到关于目标多媒体对应的用户特征值,根据用户特征值与用户数据库内的各个已有用户进行匹配,选取匹配度较高的已有用户作为目标用户。
举例性地,对各个播放记录的推送贡献权重以及用户参量进行加权运算后,得到了以下多个用户维度的用户特征值:{年龄,20.1岁}、{性别,男性}、{学历,中专至研究生}、{地域,亚洲}。服务器可以根据上述多个用户维度从用户数据库中获取匹配的已有用户,并将上述已有用户识别为目标用户。
进一步地,作为本申请的另一实施例,图9示出了本申请S25的具体实现方式,参见图9所示,相当于图2所示实施例,本实施例中的S25具体为S91~S92,具体详述如下:
在S91中,服务器根据各个所述播放记录的所述推送贡献权重,确定与所述目标多媒体的关联多媒体。
在本实施例中,服务器可以基于多媒体之间的关联性生成推送决策。终端设备可以根据各个播放记录内包含的关于多媒体数据的文件标识以及推送贡献权重,分别计算目标多媒体与其他多媒体之间的关联系数,若关联系数大于预设的关联阈值,则识别该其他多媒体为目标多媒体的关联多媒体。
在一种可能的实现方式中,计算任意两个多媒体数据之间的关联系数的方式可以为:服务器可以将同一用户播放过的多个多媒体数据之间识别为共现多媒体。例如用户A播放过音乐A以及音乐B,则音乐A与音乐B对于用户A而言,上述两个多媒体数据为共现多媒体;而用户B播放过音乐A、音乐C以及音乐D,则音乐A、音乐C以及音乐D对于用户B而言,属于共现多媒体。服务器可以统计任意两个多媒体数据之间的共现次数,以及获取为共现多媒体时对应播放记录的推送贡献权重,对所有推送贡献权重进行加权叠加,将加权值识别为两者之间的关联系数。
作为示例而非限定,表1示出了本申请一实施例提供的播放记录统计表。参见表1所示,该播放记录统计表中,通过“×”标识是否播放过该歌曲,通过对于播放过的歌曲,则可以根据该歌曲的播放记录的推送贡献权重值,配置表格内关联的数值。例如,歌曲A与歌曲B同时存在用户D以及用户E的播放记录内,即该歌曲A与歌曲B之间的共现次数为2。对于歌曲B与歌曲C而言只存在用户A的播放记录内,即歌曲B和歌曲C之间的共现次数为1。在计算关联系数时,可以通过每次共现对应的推送贡献权重,计算两者之间的关联系数,举例性地,对于歌曲A与歌曲B而言,共现次数为2,两次共现对应的播放记录的推送贡献权重为(1+1)/2+(0.5+0.5)/2=1.5,则两者之间的关联系数为1.5。在本实施例中,可以将不同歌曲对应的播放共现权重的均值,作为同时播放过上述两个歌曲的用户对应的关联因子,将所有用户的关联因子进行叠加,可以得到上述的关联系数。
用户编号 |
歌曲A |
歌曲B |
歌曲C |
歌曲D |
歌曲E |
歌曲F |
用户A |
× |
1 |
1 |
× |
1 |
0.8 |
用户B |
1 |
× |
1 |
× |
1 |
1 |
用户C |
1 |
× |
0.5 |
1 |
1 |
0.8 |
用户D |
1 |
1 |
× |
× |
1 |
1 |
用户E |
0.5 |
0.5 |
× |
0.6 |
0.6 |
0.7 |
表1
在一种可能的实现方式中,若同一用户播放了一个多媒体数据多次,则该多媒体数据存在多个播放记录,则可以对多个播放记录的推送贡献权重进行叠加,得到该多媒体数据关于该用户的推送贡献权重。例如,用户A播放了3次歌曲A,每个播放记录对应的推送贡献权重分为1、0.5以及0.8,则服务器将上述3次推送贡献权重进行叠加,将歌曲A的推送贡献权重配置为2.3。
在一种可能的实现方式中,服务器确定目标多媒体的关联多媒体的方式可以为:终端设备可以获取包含目标多媒体的所有用户的播放记录,确定包含目标多媒体的各个用户对应的播放列表。服务器根据各个播放列表内包含的多媒体数据的出现次数以及对应的播放记录的推送贡献权重,计算得到各个多媒体数据的关联系数,选取关联系数大于预设的关联阈值的多媒体数据作为目标多媒体的关联媒体。
在S92中,服务器将所述关联多媒体的历史播放对象作为所述目标多媒体对应的所述目标对象。
在本实施例中,服务器在确定了目标多媒体的关联多媒体后,可以识别播放过关联多媒体的历史播放对象,作为目标多媒体的目标对象,即播放过关联多媒体的用户大概率有兴趣播放目标多媒体,因此可以对上述目标对象推送目标多媒体。
在一种可能的实现方式中,服务器可以获取关联多媒体的历史播放对象的播放列表,判断该播放列表内是否包含目标多媒体,若是,则识别为已推送对象,不对该对象推送目标多媒体;反之,该播放列表内不包含目标多媒体,则识别该历史播放对象为目标对象,执行推送操作。
在本申请实施例中,以多媒体数据为基准,确定不同多媒体数据之间的关联性,确定了目标多媒体的关联多媒体,并将关联多媒体的历史播放对象作为目标多媒体的目标对象,实现了自动识别目标对象,并在确定目标对象时,可以根据各个播放记录的推荐贡献权重进行加权运算,提高了目标对象的识别准确性。
进一步地,作为本申请的另一实施例,图10示出了本申请S25的具体实现方式,参见图10所示,相当于图2所示实施例,本实施例中的S25具体为S101~S102,具体详述如下:
在S101中,服务器根据各个候选对象的播放列表,确定所述播放记录所属用户对应的关联对象;所述播放列表根据所述候选对象的播放记录的推送贡献权重生成的。
在本实施例中,服务器可以基于用户之间的关联性生成推送决策。服务器可以存储由用户数据库,从用户数据库中提取各个候选对象的播放记录,根据各个播放记录包含的多媒体数据,生成关于候选对象的播放列表。其中,播放列表中各个多媒体数据的推荐系数可以根据关联的播放记录的推荐贡献权重确定。需要说明的是,若该多媒体数据包含多个播放记录,则可以将各个播放记录的推荐贡献权重进行叠加,从而得到多媒体数据对应的推荐系数。服务器可以根据任意两个候选对象的播放列表,计算两个候选对象之间的关联系数,若关联系数大于预设的关联阈值,则识别该候选对象为所述播放记录所属用户的关联对象。
在一种可能的实现方式中,计算候选对象与所述播放记录所属用户之间的关联系数的方式可以为:服务器可以将识别候选对象的第一播放列表与所述播放记录所属用户的第二播放列表之间相同的多媒体数据的个数,并根据各个相同的多媒体数据对应的推荐系数,计算上述两个对象之间的关联系数。举例性地,用户A的播放列表中包含有歌曲A以及歌曲B,且对应的推荐系数分为1和0.8,而用户B的播放列表中包含有歌曲A、歌曲B以及歌曲C,且对应的推荐系数分别为0.8、0.8以及1,则上述用户A与用户B之间的关联系数具体为(1+0.8)/2+(0.8+0.8)/2=1.7,若该关联系数大于预设的关联阈值,则识别该候选对象对播放记录所属用户的关联对象;反之,则识别上述两个用户并非关联账户。
作为示例而非限定,表2示出了本申请一实施例提供的播放记录统计表。参见表2所示,该播放记录统计表中,通过“×”标识是否播放过该歌曲,通过播放记录统计表,可以得到各个用户的播放列表,每个歌曲可以根据关联的播放记录确定歌曲对应的推送贡献权重。参见表2可以确定,用户A的播放列表为{歌曲B、歌曲C、歌曲E、歌曲F},对应的推送贡献权重为{1,1,1,0.8},而用户B的播放列表为{歌曲A、歌曲C、歌曲E、歌曲F},对应的推送贡献权重为{1,1,1,1,},相同的歌曲为歌曲E以及歌曲F,通过相同歌曲的推送贡献权重,可以计算得到上述两个用户之间的关联系数,即为(1+1)/2+(1+0.8)/2=1.9。
用户编号 |
歌曲A |
歌曲B |
歌曲C |
歌曲D |
歌曲E |
歌曲F |
用户A |
× |
1 |
1 |
× |
1 |
0.8 |
用户B |
1 |
× |
1 |
× |
1 |
1 |
用户C |
1 |
× |
0.5 |
1 |
1 |
0.8 |
用户D |
1 |
1 |
× |
× |
1 |
1 |
用户E |
0.5 |
0.5 |
× |
0.6 |
0.6 |
0.7 |
表2
在S102中,服务器将所述关联对象作为所述目标多媒体对应的所述目标对象。
在本实施例中,服务器在确定了播放记录所属用户的关联对象后,可以识别该关联对象作为目标多媒体的目标对象,即关联对象与播放记录所属用户之间具有相同的观看兴趣,因此与播放过目标多媒体的用户存在关联关系的关联对象大概率有兴趣播放目标多媒体,因此可以对上述目标对象推送目标多媒体。
在一种可能的实现方式中,服务器可以获取关联对象的播放列表,判断该播放列表内是否包含目标多媒体,若是,则识别为已推送对象,不对该关联对象推送目标多媒体;反之,该播放列表内不包含目标多媒体,则识别该关联对象为目标对象,执行推送操作。
在本申请实施例中,以用户为基准,通过播放列表确定用户之间的关联性,确定了播放过目标多媒体的用户的关联对象,并将关联对象作为播放过目标多媒体的用户的目标对象,实现了自动识别目标对象,并在确定目标对象时,可以根据各个播放记录的推荐贡献权重进行加权运算,提高了目标对象的识别准确性。
在S26中,服务器向所述目标对象的关联设备推送所述目标多媒体。
在本实施例中,服务器可以通过识别各个目标对象的对象标识,并通过对象标识确定关联设备,向关联设备推送目标多媒体。其中,该对象标识可以为用户账户,服务器可以识别该用户账户的登录状态,若该登录状态为已登录状态,则确定登录该用户账户对应的关联设备的通信地址,并向该通信地址发送上述确定的目标多媒体;若该登录状态为未登录状态,则可以将该目标多媒体添加该用户账户关联的待推送列表中,当该用户账户登录后,可以依次向登录该用户账户的终端设备依次推送待推送列表内的各个目标多媒体。
在一种可能的实现方式中,服务器可以接收终端设备发送的推送请求。终端设备在播放完成一个多媒体或者用户点击自动推送指令时,可以向服务器发送一个推送请求,终端设备在接收到推送请求后,可以将该终端设备的用户识别为目标对象的多媒体数据,发送给终端设备,从而实现响应该终端设备的推送请求。特别地,若服务器配置有该目标对象的待推送列表,则可以根据待推送列表内包含的多媒体数据发送给目标对象的终端设备,以响应目标对象的推送请求。
进一步地,作为本申请的另一实施例,在S26之后还可以包括S27,具体详述如下:
在S27中,终端设备接收所述服务器推送的关联多媒体,并播放关联多媒体;所述关联多媒体是基于所述播放记录确定的。
在本实施例中,终端设备在播放完成一个多媒体数据或者打开播放应用程序执行多媒体推送模式下,可以接收服务器推送的关联多媒体。该关联多媒体可以根据终端设备上传的所有播放记录确定,其中,确定关联多媒体的方式可以参见S25的相关描述,即采用基于多媒体数据为基准的方式确定,或者基于用户为基准的方式确定,在此不再赘述。
在本申请实施例中,终端设备可以接收服务器反馈的关联多媒体,能够通过播放记录内的耳机状态信息,精准生成推送决策,从而提高了用户的使用体验。
在本申请实施例中通过在生成播放记录时,获取耳机状态信息,基于耳机状态信息确定该播放记录的有效性,从而根据包含耳机状态信息的播放记录,生成对应的推送决策,并将各个多媒体数据推送至对应的目标用户,从而能够提高推送准确性。
实施例二:
在本申请实施例中,流程的执行主体为终端设备。该终端设备可以为手机、平板电脑、可穿戴设备、车载设备、增强现实(augmented reality,AR)/虚拟现实(virtualreality,VR)设备、笔记本电脑、超级移动个人计算机(ultra-mobile personal computer,UMPC)、上网本、个人数字助理(personal digital assistant,PDA)等终端设备,还可以为数据库、服务器以及基于终端人工智能的服务响应系统,本申请实施例对终端设备的具体类型不作任何限制。
例如,所述终端设备可以是WLAN中的站点(STAION,ST),可以是蜂窝电话、无绳电话、会话启动协议(Session InitiationProtocol,SIP)电话、无线本地环路(WirelessLocal Loop,WLL)站、个人数字处理(Personal Digital Assistant,PDA)设备、具有无线通信功能的手持设备、计算设备或连接到无线调制解调器的其它处理设备、电脑、膝上型计算机、手持式通信设备、手持式计算设备、和/或用于在无线系统上进行通信的其它设备以及下一代通信系统,例如,5G网络中的移动终端或者未来演进的公共陆地移动网络(PublicLand Mobile Network,PLMN)网络中的移动终端等。
作为示例而非限定,当所述终端设备为可穿戴设备时,该可穿戴设备还可以是应用穿戴式技术对日常穿戴进行智能化设计、开发出可以穿戴的设备的总称,如配置有自适应学习算法的眼镜、手套、手表、服饰及鞋等。可穿戴设备即直接穿在身上,或是整合到用户的衣服或配件的一种便携式设备,通过附着与用户身上,用于记录用户行进过程中的行为数据,并根据行为数据以及预设的混合精度的神经网络,输出相应的处理结果。可穿戴设备不仅仅是一种硬件设备,更是通过软件支持以及数据交互、云端交互来实现强大的功能。广义穿戴式智能设备包括功能全、尺寸大、可不依赖智能手机实现完整或者部分的功能,如智能手表或智能眼镜等,以及只专注于某一类应用功能,需要和其它设备如智能手机配合使用,如各类进行具有显示屏的智能手表、智能手环等。
以所述终端设备为手机为例。图11示出的是与本申请实施例提供的手机的部分结构的框图。参考图1,手机包括:射频(Radio Frequency,RF)电路1110、存储器1120、输入单元1130、显示单元1140、传感器1150、音频电路1160、近场通信模块1170、处理器1180、以及电源1190等部件。本领域技术人员可以理解,图11中示出的手机结构并不构成对手机的限定,可以包括比图示更多或更少的部件,或者组合某些部件,或者不同的部件布置。
下面结合图11对手机的各个构成部件进行具体的介绍:
RF电路1110可用于收发信息或通话过程中,信号的接收和发送,特别地,将基站的下行信息接收后,给处理器1180处理;另外,将设计上行的数据发送给基站。通常,RF电路包括但不限于天线、至少一个放大器、收发信机、耦合器、低噪声放大器(Low NoiseAmplifier,LNA)、双工器等。此外,RF电路1110还可以通过无线通信与网络和其他设备通信。上述无线通信可以使用任一通信标准或协议,包括但不限于全球移动通讯系统(GlobalSystem of Mobile communication,GSM)、通用分组无线服务(General Packet RadioService,GPRS)、码分多址(Code Division Multiple Access,CDMA)、宽带码分多址(Wideband Code Division Multiple Access,WCDMA)、长期演进(Long Term Evolution,LTE))、电子邮件、短消息服务(Short Messaging Service,SMS)等。特别地,该手机可以通过RF电路接收服务器推送的多媒体数据,并播放接收到的多媒体数据。
存储器1120可用于存储软件程序以及模块,处理器1180通过运行存储在存储器1120的软件程序以及模块,从而执行手机的各种功能应用以及数据处理,例如将目标网络模型存储于存储器1120的缓存区域内,并根据手机使用过程中产生的数据,通过目标网络模型输出处理结果,还可以根据用户对于处理结果的响应操作,识别处理结果的准确率,基于上述准确率对目标网络模型内的权重进行调整。存储器1120可主要包括存储程序区和存储数据区,其中,存储程序区可存储操作系统、至少一个功能所需的应用程序(比如声音播放功能、图像播放功能等)等;存储数据区可存储根据手机的使用所创建的数据(比如音频数据、电话本等)等。此外,存储器1120可以包括高速随机存取存储器,还可以包括非易失性存储器,例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。特别地,服务器推送的多媒体数据可以存储于手机内的存储器1120内。
输入单元1130可用于接收输入的数字或字符信息,以及产生与手机1100的用户设置以及功能控制有关的键信号输入。具体地,输入单元1130可包括触控面板1131以及其他输入设备1132。触控面板1131,也称为触摸屏,可收集用户在其上或附近的触摸操作(比如用户使用手指、触笔等任何适合的物体或附件在触控面板1131上或在触控面板1131附近的操作),并根据预先设定的程式驱动相应的连接装置。
显示单元1140可用于显示由用户输入的信息或提供给用户的信息以及手机的各种菜单,例如输出调整后的校正图像。显示单元1140可包括显示面板1141,可选的,可以采用液晶显示器(Liquid Crystal Display,LCD)、有机发光二极管(Organic Light-Emitting Diode,OLED)等形式来配置显示面板1141。进一步的,触控面板1131可覆盖显示面板1141,当触控面板1131检测到在其上或附近的触摸操作后,传送给处理器1180以确定触摸事件的类型,随后处理器180根据触摸事件的类型在显示面板1141上提供相应的视觉输出。虽然在图11中,触控面板1131与显示面板1141是作为两个独立的部件来实现手机的输入和输入功能,但是在某些实施例中,可以将触控面板1131与显示面板1141集成而实现手机的输入和输出功能。特别地,多媒体数据包含有视频信号或图像信号,则可以通过显示单元1140进行输出。
手机1100还可包括至少一种传感器1150,比如光传感器、运动传感器以及其他传感器。具体地,光传感器可包括环境光传感器及接近传感器,其中,环境光传感器可根据环境光线的明暗来调节显示面板1141的亮度,接近传感器可在手机移动到耳边时,关闭显示面板1141和/或背光。作为运动传感器的一种,加速计传感器可检测各个方向上(一般为三轴)加速度的大小,静止时可检测出重力的大小及方向,可用于识别手机姿态的应用(比如横竖屏切换、相关游戏、磁力计姿态校准)、振动识别相关功能(比如计步器、敲击)等;至于手机还可配置的陀螺仪、气压计、湿度计、温度计、红外线传感器等其他传感器,在此不再赘述。
手机1100还可以包括摄像头1160。可选地,摄像头在手机1100的上的位置可以为前置的,也可以为后置的,本申请实施例对此不作限定。
终端设备可以通过近场通信模块1170可以接收其他设备发送的通信数据,例如该近场通信模块1170集成有蓝牙通信模块,通过蓝牙通信模块与其他手机配件建立通信连接,例如通过近场通信模块1170与蓝牙耳机连接,并向蓝牙耳机发送多媒体数据以及接收蓝牙耳机反馈的耳机状态信息。虽然图1示出了近场通信模块1170,但是可以理解的是,其并不属于手机1100的必须构成,完全可以根据需要在不改变申请的本质的范围内而省略。
处理器1180是手机的控制中心,利用各种接口和线路连接整个手机的各个部分,通过运行或执行存储在存储器1120内的软件程序和/或模块,以及调用存储在存储器1120内的数据,执行手机的各种功能和处理数据,从而对手机进行整体监控。可选的,处理器1180可包括一个或多个处理单元;优选的,处理器1180可集成应用处理器和调制解调处理器,其中,应用处理器主要处理操作系统、用户界面和应用程序等,调制解调处理器主要处理无线通信。可以理解的是,上述调制解调处理器也可以不集成到处理器1180中。
手机1100还包括给各个部件供电的电源1190(比如电池),优选的,电源可以通过电源管理系统与处理器1180逻辑相连,从而通过电源管理系统实现管理充电、放电、以及功耗管理等功能。
手机1100还包括音频电路、扬声器,传声器可提供用户与手机之间的音频接口。音频电路可将接收到的音频数据转换后的电信号,传输到扬声器,由扬声器转换为声音信号输出;另一方面,传声器将收集的声音信号转换为电信号,由音频电路接收后转换为音频数据,再将音频数据输出处理器1180处理后,经RF电路1110以发送给比如另一手机,或者将音频数据输出至存储器1120以便进一步处理。
图12是本申请实施例的手机1100的软件结构示意图。以手机1100操作系统为Android系统为例,在一些实施例中,将Android系统分为四层,分别为应用程序层、应用程序框架层(framework,FWK)、系统层以及硬件抽象层,层与层之间通过软件接口通信。
如图12所示,所述应用程序层可以一系列应用程序包,应用程序包可以包括短信息,日历,相机,视频,导航,图库,通话等应用程序。
应用程序框架层为应用程序层的应用程序提供应用编程接口(applicationprogramming interface,API)和编程框架。应用程序框架层可以包括一些预先定义的函数,例如用于接收应用程序框架层所发送的事件的函数。具体地,本实施例生成的神经网络可以部署于应用程序框架层,并通过对应的变成语言,生成与神经网络对应的编程框架。
如图12所示,应用程序框架层可以包括窗口管理器、资源管理器以及通知管理器等。
窗口管理器用于管理窗口程序。窗口管理器可以获取显示屏大小,判断是否有状态栏,锁定屏幕,截取屏幕等。内容提供器用来存放和获取数据,并使这些数据可以被应用程序访问。所述数据可以包括视频,图像,音频,拨打和接听的电话,浏览历史和书签,电话簿等。
资源管理器为应用程序提供各种资源,比如本地化字符串,图标,图片,布局文件,视频文件等等。
通知管理器使应用程序可以在状态栏中显示通知信息,可以用于传达告知类型的消息,可以短暂停留后自动消失,无需用户交互。比如通知管理器被用于告知下载完成,消息提醒等。通知管理器还可以是以图表或者滚动条文本形式出现在系统顶部状态栏的通知,例如后台运行的应用程序的通知,还可以是以对话窗口形式出现在屏幕上的通知。例如在状态栏提示文本信息,发出提示音,电子设备振动,指示灯闪烁等。
应用程序框架层还可以包括:
视图系统,所述视图系统包括可视控件,例如显示文字的控件,显示图片的控件等。视图系统可用于构建应用程序。显示界面可以由一个或多个视图组成的。例如,包括短信通知图标的显示界面,可以包括显示文字的视图以及显示图片的视图。
电话管理器用于提供手机1100的通信功能。例如通话状态的管理(包括接通,挂断等)。
系统层可以包括多个功能模块。例如:传感器服务模块,物理状态识别模块,三维图形处理库(例如:OpenGL ES)等。
传感器服务模块,用于对硬件层各类传感器上传的传感器数据进行监测,确定手机1100的物理状态;
物理状态识别模块,用于对用户手势、人脸等进行分析和识别;
三维图形处理库用于实现三维图形绘图,图像渲染,合成,和图层处理等。
系统层还可以包括:
表面管理器用于对显示子系统进行管理,并且为多个应用程序提供了2D和3D图层的融合。
媒体库支持多种常用的静态图像文件,视频格式回放和录制,以及音频等。媒体库可以支持多种音视频编码格式,例如:MPEG4,H.264,MP3,AAC,AMR,JPG,PNG等。
硬件抽象层是硬件和软件之间的层。硬件抽象层可以包括显示驱动、摄像头驱动、传感器驱动、麦克风驱动等,用于驱动硬件层的相关硬件,如显示屏、摄像头、传感器以及麦克风等。
图13示出了本申请一实施例提供的终端设备侧的播放记录的上传方法的实现流程图,详述如下:
在S131中,终端设备若处于多媒体播放状态,则获取耳机状态信息。
在S132中,终端设备基于所述耳机状态信息生成当前播放的目标多媒体的播放记录。
在S133中,终端设备上传所述播放记录至所述目标多媒体对应的服务器;所述播放记录用于所述服务器根据所述播放记录内的所述耳机状态信息对所述目标多媒体进行推送。
由于S131~S133的具体实现过程与S21~S23的实现方式完全相同,具体描述可以参见S21~S23的相关描述,在此不再赘述。
进一步地,作为本申请另一实施例,所述终端设备获取耳机状态信息,包括:
终端设备记录耳机在所述目标多媒体的播放过程中的耳机佩戴时长;
终端设备基于所述耳机佩戴时长生成所述耳机状态信息;所述耳机佩戴时长用于确定所述播放记录的推送贡献权重。
由于上述步骤的具体实现过程与S211~S213的实现方式完全相同,具体描述可以参见S211~S213的相关描述,在此不再赘述。
进一步地,作为本申请另一实施例,终端设备在所述上传所述播放记录至所述目标多媒体对应的服务器之后,还包括:
终端设备接收所述服务器推送的关联多媒体;所述关联多媒体是基于所述播放记录确定的。
由于上述步骤的具体实现过程与S27的实现方式完全相同,具体描述可以参见S27的相关描述,在此不再赘述。
对应于上文实施例所述的播放记录的上传方法,图14示出了本申请实施例提供的播放记录的上传设备的结构框图,为了便于说明,仅示出了与本申请实施例相关的部分。
参照图14,该播放记录的上传设备包括:
耳机状态信息获取单元141,用于若处于多媒体播放状态,则获取耳机状态信息;
播放记录生成单元142,用于基于所述耳机状态信息生成当前播放的目标多媒体的播放记录;
播放记录上传单元143,用于上传所述播放记录至所述目标多媒体对应的服务器;所述播放记录用于所述服务器根据所述播放记录内的所述耳机状态信息对所述目标多媒体进行推送。
可选地,所述耳机状态信息获取单元141包括:
耳机佩戴时长获取单元,用于记录耳机在所述目标多媒体的播放过程中的耳机佩戴时长;
耳机佩戴时长封装单元,用于基于所述耳机佩戴时长生成所述耳机状态信息;所述耳机佩戴时长用于确定所述播放记录的推送贡献权重。
可选地,所述播放记录的上传设备还包括:
关联多媒体接收单元,用于接收所述服务器推送的关联多媒体;所述关联多媒体是基于所述播放记录确定的。
实施本申请实施例同样可以通过在生成播放记录时,获取耳机状态信息,基于耳机状态信息确定该播放记录的有效性,从而根据包含耳机状态信息的播放记录,生成对应的推送决策,并将各个多媒体数据推送至对应的目标用户,从而能够提高推送准确性。
图15为本申请一实施例提供的终端设备的结构示意图。如图15所示,该实施例的终端设备15包括:至少一个处理器150(图15中仅示出一个)处理器、存储器151以及存储在所述存储器151中并可在所述至少一个处理器150上运行的计算机程序152,所述处理器150执行所述计算机程序152时实现上述任意各个多媒体数据的推送方法实施例中的步骤。
所述终端设备15可以是桌上型计算机、笔记本、掌上电脑及云端终端设备等计算设备。该终端设备可包括,但不仅限于,处理器150、存储器151。本领域技术人员可以理解,图15仅仅是终端设备15的举例,并不构成对终端设备15的限定,可以包括比图示更多或更少的部件,或者组合某些部件,或者不同的部件,例如还可以包括输入输出设备、网络接入设备等。
所称处理器150可以是中央处理单元(Central Processing Unit,CPU),该处理器150还可以是其他通用处理器、数字信号处理器(Digital Signal Processor,DSP)、专用集成电路(Application Specific Integrated Circuit,ASIC)、现成可编程门阵列(Field-Programmable Gate Array,FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。
所述存储器151在一些实施例中可以是所述终端设备15的内部存储单元,例如终端设备15的硬盘或内存。所述存储器151在另一些实施例中也可以是终端设备15的外部存储设备,例如所述终端设备15上配备的插接式硬盘,智能存储卡(Smart Media Card,SMC),安全数字(Secure Digital,SD)卡,闪存卡(Flash Card)等。进一步地,所述存储器151还可以既包括所述终端设备15的内部存储单元也包括外部存储设备。所述存储器151用于存储操作系统、应用程序、引导装载程序(BootLoader)、数据以及其他程序等,例如所述计算机程序的程序代码等。所述存储器151还可以用于暂时地存储已经输出或者将要输出的数据。
需要说明的是,上述装置/单元之间的信息交互、执行过程等内容,由于与本申请方法实施例基于同一构思,其具体功能及带来的技术效果,具体可参见方法实施例部分,此处不再赘述。
需要说明的是,上述装置/单元之间的信息交互、执行过程等内容,由于与本申请方法实施例基于同一构思,其具体功能及带来的技术效果,具体可参见方法实施例部分,此处不再赘述。
所属领域的技术人员可以清楚地了解到,为了描述的方便和简洁,仅以上述各功能单元、模块的划分进行举例说明,实际应用中,可以根据需要而将上述功能分配由不同的功能单元、模块完成,即将所述装置的内部结构划分成不同的功能单元或模块,以完成以上描述的全部或者部分功能。实施例中的各功能单元、模块可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中,上述集成的单元既可以采用硬件的形式实现,也可以采用软件功能单元的形式实现。另外,各功能单元、模块的具体名称也只是为了便于相互区分,并不用于限制本申请的保护范围。上述系统中单元、模块的具体工作过程,可以参考前述方法实施例中的对应过程,在此不再赘述。
本申请实施例还提供了一种网络设备,该网络设备包括:至少一个处理器、存储器以及存储在所述存储器中并可在所述至少一个处理器上运行的计算机程序,所述处理器执行所述计算机程序时实现上述任意各个方法实施例中的步骤。
本申请实施例还提供了一种计算机可读存储介质,所述计算机可读存储介质存储有计算机程序,所述计算机程序被处理器执行时实现可实现上述各个方法实施例中的步骤。
本申请实施例提供了一种计算机程序产品,当计算机程序产品在移动终端上运行时,使得移动终端执行时实现可实现上述各个方法实施例中的步骤。
实施例四:
在本申请实施例中,流程的执行主体为服务器。图16示出了本申请一实施例提供的服务器侧的多媒体数据的推送方法的实现流程图,详述如下:
在S161中,所述服务器根据所述终端设备上传的关于目标多媒体的播放记录内的所述耳机状态信息,确定所述播放记录的推送贡献权重。
在S162中,所述服务器根据所述播放记录的所述推送贡献权重确定所述目标多媒体的目标对象。
在S163中,所述服务器向所述目标对象的关联设备推送所述目标多媒体。
由于S161~S163的具体实现过程与S24~S26的实现方式完全相同,具体描述可以参见S21~S23的相关描述,在此不再赘述。
进一步地,作为本申请另一实施例,所述服务器根据所述终端设备上传的关于目标多媒体的播放记录内的所述耳机状态信息,确定所述播放记录的推送贡献权重,包括:
若所述耳机状态信息为未佩戴状态,则将所述播放记录的所述推送贡献权重设置为0;
若所述耳机状态信息为已佩戴状态,则将所述播放记录的所述推送贡献权重设置为1。
由于上述步骤的具体实现过程与S72以及S74的实现方式完全相同,具体描述可以参见S72以及S74的相关描述,在此不再赘述。
进一步地,作为本申请另一实施例,若所述耳机状态信息包含耳机佩戴时长,则所述服务器根据所述终端设备上传的关于目标多媒体的播放记录内的所述耳机状态信息,确定所述播放记录的推送贡献权重,包括:
若所述耳机佩戴时长与所述目标多媒体的播放总时长之间的比值大于预设的有效阈值,则识别所述播放记录的所述耳机状态信息为所述已佩戴状态;
若所述比值小于或等于所述有效阈值,则识别所述播放记录的所述耳机状态信息为所述未佩戴状态。
由于上述步骤的具体实现过程与S71以及S73的实现方式完全相同,具体描述可以参见S71以及S73的相关描述,在此不再赘述。
进一步地,作为本申请另一实施例,所述服务器根据所述终端设备上传的关于目标多媒体的播放记录内的所述耳机状态信息,确定所述播放记录的推送贡献权重,包括:
根据所述耳机状态信息的所述耳机佩戴时长,确定所述推送贡献权重。
由于上述步骤的具体实现过程与S81的实现方式完全相同,具体描述可以参见S81的相关描述,在此不再赘述。
进一步地,作为本申请另一实施例,所述服务器根据所述播放记录的所述推送贡献权重确定所述目标多媒体的目标对象,包括:
根据各个所述播放记录的所述推送贡献权重,确定与所述目标多媒体的关联多媒体;
将所述关联多媒体的历史播放对象作为所述目标多媒体对应的所述目标对象。
由于上述步骤的具体实现过程与S91~S92的实现方式完全相同,具体描述可以参见S91~S92的相关描述,在此不再赘述。
进一步地,作为本申请另一实施例,所述服务器根据所述播放记录的所述推送贡献权重确定所述目标多媒体的目标对象,包括:
根据各个候选对象的播放列表,确定所述播放记录所属用户对应的关联对象;所述播放列表根据所述候选对象的播放记录的推送贡献权重生成的;
将所述关联用户关联对象作为所述目标多媒体对应的所述目标对象。
由于上述步骤的具体实现过程与S101~S102的实现方式完全相同,具体描述可以参见S101~S102的相关描述,在此不再赘述。
对应于上文实施例所述的多媒体数据的推送方法,图17示出了本申请实施例提供的多媒体数据的推送设备的结构框图,为了便于说明,仅示出了与本申请实施例相关的部分。
参照图17,该多媒体数据的推送设备包括:
推送贡献权重确定单元171,用于根据所述终端设备上传的关于目标多媒体的播放记录内的所述耳机状态信息,确定所述播放记录的推送贡献权重;
目标对象识别单元172,用于根据所述播放记录的所述推送贡献权重确定所述目标多媒体的目标对象;
目标对象数据推送单元173,用于向所述目标对象的关联设备推送所述目标多媒体。
可选地,多媒体数据的推送装置还包括:
查询预测模型调整单元,用于所述服务器根据所述电子设备基于所述定位查询请求反馈的位置信息,调整查询预测模型;所述查询预测模型用于输出所述查询预测信息。
可选地,推送贡献权重确定单元171包括:
未佩戴状态权重配置单元,用于若所述耳机状态信息为未佩戴状态,则将所述播放记录的所述推送贡献权重设置为0;
已佩戴状态权重配置单元,用于若所述耳机状态信息为已佩戴状态,则将所述播放记录的所述推送贡献权重设置为1。
可选地,推送贡献权重确定单元171包括:
未佩戴状态识别单元,用于若所述耳机佩戴时长与所述目标多媒体的播放总时长之间的比值大于预设的有效阈值,则识别所述播放记录的所述耳机状态信息为所述已佩戴状态;
已佩戴状态识别单元,用于若所述比值小于或等于所述有效阈值,则识别所述播放记录的所述耳机状态信息为所述未佩戴状态。
可选地,所述推送贡献权重确定单元171包括:
耳机佩戴时长转换单元,用于根据所述耳机状态信息的所述耳机佩戴时长,确定所述推送贡献权重。
可选地,所述目标对象识别单元172包括:
关联多媒体识别单元,用于根据各个所述播放记录的所述推送贡献权重,确定与所述目标多媒体的关联多媒体;
第一目标对象识别单元,用于将所述关联多媒体的历史播放对象作为所述目标多媒体对应的所述目标对象。
可选地,所述目标对象识别单元172包括:
关联对象识别单元,用于根据各个候选对象的播放列表,确定所述播放记录所属用户对应的关联对象;所述播放列表根据所述候选对象的播放记录的推送贡献权重生成的;
第二目标对象识别单元,用于将所述关联对象作为所述目标多媒体对应的所述目标对象。
实施本申请实施例同样可以通过在生成播放记录时,获取耳机状态信息,基于耳机状态信息确定该播放记录的有效性,从而根据包含耳机状态信息的播放记录,生成对应的推送决策,并将各个多媒体数据推送至对应的目标用户,从而能够提高推送准确性。
图18为本申请一实施例提供的服务器的结构示意图。如图18所示,该实施例的服务器18包括:至少一个处理器180(图18中仅示出一个)处理器、存储器181以及存储在所述存储器181中并可在所述至少一个处理器180上运行的计算机程序182,所述处理器180执行所述计算机程序182时实现上述任意各个多媒体数据的推送方法实施例中的步骤。
所述服务器18可以是桌上型计算机、笔记本、掌上电脑及云端服务器等计算设备。该服务器可包括,但不仅限于,处理器180、存储器181。本领域技术人员可以理解,图18仅仅是服务器18的举例,并不构成对服务器18的限定,可以包括比图示更多或更少的部件,或者组合某些部件,或者不同的部件,例如还可以包括输入输出设备、网络接入设备等。
所称处理器180可以是中央处理单元(Central Processing Unit,CPU),该处理器180还可以是其他通用处理器、数字信号处理器(Digital Signal Processor,DSP)、专用集成电路(Application Specific Integrated Circuit,ASIC)、现成可编程门阵列(Field-Programmable Gate Array,FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。
所述存储器181在一些实施例中可以是所述服务器18的内部存储单元,例如服务器18的硬盘或内存。所述存储器181在另一些实施例中也可以是服务器18的外部存储设备,例如所述服务器18上配备的插接式硬盘,智能存储卡(Smart Media Card,SMC),安全数字(Secure Digital,SD)卡,闪存卡(Flash Card)等。进一步地,所述存储器181还可以既包括所述服务器18的内部存储单元也包括外部存储设备。所述存储器181用于存储操作系统、应用程序、引导装载程序(BootLoader)、数据以及其他程序等,例如所述计算机程序的程序代码等。所述存储器181还可以用于暂时地存储已经输出或者将要输出的数据。
需要说明的是,上述装置/单元之间的信息交互、执行过程等内容,由于与本申请方法实施例基于同一构思,其具体功能及带来的技术效果,具体可参见方法实施例部分,此处不再赘述。
所属领域的技术人员可以清楚地了解到,为了描述的方便和简洁,仅以上述各功能单元、模块的划分进行举例说明,实际应用中,可以根据需要而将上述功能分配由不同的功能单元、模块完成,即将所述装置的内部结构划分成不同的功能单元或模块,以完成以上描述的全部或者部分功能。实施例中的各功能单元、模块可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中,上述集成的单元既可以采用硬件的形式实现,也可以采用软件功能单元的形式实现。另外,各功能单元、模块的具体名称也只是为了便于相互区分,并不用于限制本申请的保护范围。上述系统中单元、模块的具体工作过程,可以参考前述方法实施例中的对应过程,在此不再赘述。
本申请实施例还提供了一种网络设备,该网络设备包括:至少一个处理器、存储器以及存储在所述存储器中并可在所述至少一个处理器上运行的计算机程序,所述处理器执行所述计算机程序时实现上述任意各个方法实施例中的步骤。
本申请实施例还提供了一种计算机可读存储介质,所述计算机可读存储介质存储有计算机程序,所述计算机程序被处理器执行时实现可实现上述各个方法实施例中的步骤。
本申请实施例提供了一种计算机程序产品,当计算机程序产品在移动终端上运行时,使得移动终端执行时实现可实现上述各个方法实施例中的步骤。
所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本申请实现上述实施例方法中的全部或部分流程,可以通过计算机程序来指令相关的硬件来完成,所述的计算机程序可存储于一计算机可读存储介质中,该计算机程序在被处理器执行时,可实现上述各个方法实施例的步骤。其中,所述计算机程序包括计算机程序代码,所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质至少可以包括:能够将计算机程序代码携带到拍照装置/服务器的任何实体或装置、记录介质、计算机存储器、只读存储器(ROM,Read-Only Memory)、随机存取存储器(RAM,Random AccessMemory)、电载波信号、电信信号以及软件分发介质。例如U盘、移动硬盘、磁碟或者光盘等。在某些司法管辖区,根据立法和专利实践,计算机可读介质不可以是电载波信号和电信信号。
在上述实施例中,对各个实施例的描述都各有侧重,某个实施例中没有详述或记载的部分,可以参见其它实施例的相关描述。
本领域普通技术人员可以意识到,结合本文中所公开的实施例描述的各示例的单元及算法步骤,能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行,取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能,但是这种实现不应认为超出本申请的范围。
在本申请所提供的实施例中,应该理解到,所揭露的装置/网络设备和方法,可以通过其它的方式实现。例如,以上所描述的装置/网络设备实施例仅仅是示意性的,例如,所述模块或单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通讯连接可以是通过一些接口,装置或单元的间接耦合或通讯连接,可以是电性,机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
以上所述实施例仅用以说明本申请的技术方案,而非对其限制;尽管参照前述实施例对本申请进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围,均应包含在本申请的保护范围之内。