CN115134420A - 一种媒体播放方法、装置和电子设备 - Google Patents

Abstract

本申请实施例提供了一种媒体播放方法、装置和电子设备。该方法用于实现客户端的本地媒体服务功能，包括：接收应用的第一播放请求，第一播放请求包括第一标识；将第一地址发送给应用，第一地址为本地统一资源定位符URL地址；将服务端的第一标识对应的目标媒体资源从服务端设备缓存至客户端设备；当接收到应用程序向第一地址发送的第二播放请求时，将缓存的目标媒体资源发送给应用程序进行播放。这样，服务端设备只需向电子设备提供普通的文件传输功能，不参与和感知播放过程，因此不需要部署播放相关的服务，降低了对服务端的能力要求，从而实现了瘦设备间的媒体跨设备实时播放。

Description

一种媒体播放方法、装置和电子设备

技术领域

本申请涉及媒体播放技术领域，尤其涉及一种媒体播放方法、装置和电子设备。

背景技术

在分布式场景中，客户端设备可以通过网络与多个服务端设备连接，播放服务端设备中的媒体资源或者控制服务端设备。目前，客户端设备播放服务端设备中的媒体资源的方式可以包括本地播放和实时流传输播放。

本地播放是指在用户请求播放媒体资源时，客户端设备首先将完整的音/视频文件从服务端设备拉取到本地，然后再开始播放，由于音/视频文件通常较大，从用户请求播放到完成音/视频文件的拉去需要消耗一段时间，因此用户会感觉到播放存在明显的卡顿，无法实现实时播放，用户体验差。

实时流传输播放是指基于实时流传输协议或投屏协议，例如实时流协议(realtime streaming protocol，RTSP)、基于超文本传输协议(hypertext transfer protocol，HTTP)的实时流协议(HTTP live streaming，HLS)等，在服务端设备部署实时流传输、内容分发和/或编解码等服务，当客户端设备请求播放媒体资源时，服务端设备基于部署的服务向客户端设备发送媒体流，客户端设备一边缓存一边播放媒体流。然而，实时流传输播放方式需要在服务端设备部署服务，因此对服务端设备的能力要求较高，无法在瘦设备中实现。另外，实时流传输播放方式对网络质量也有一定的要求，如果媒体流的缓存速度过低，则播放会出现卡顿。

由此可见，对于在瘦设备间实现媒体的跨设备实时播放，目前尚无可行的解决方案。

发明内容

本申请实施例提供了一种媒体播放方法、装置和电子设备，以在瘦设备间实现媒体的跨设备实时播放。

第一方面，本申请实施例提供了一种媒体播放方法。该方法包括：客户端设备上的媒体代理服务接收客户端设备上的应用程序的第一播放请求，第一播放请求包括第一标识，第一标识对应服务端设备中的目标媒体资源；媒体代理服务根据第一标识确定是否已启动目标媒体资源的缓存传输流程；如果未启动缓存传输流程，媒体代理服务启动缓存传输流程以将目标媒体资源从服务端设备缓存至客户端设备，并将第一地址发送给应用程序，第一地址为客户端设备的用于访问缓存的目标媒体资源的本地统一资源定位符URL地址；媒体代理服务在接收到应用程序向第一地址发送的第二播放请求时，将缓存的目标媒体资源发送给应用程序进行播放。

本申请实施例提供的媒体播放方法在客户端构建了媒体代理服务，客户端设备在应用程序请求播放服务端设备的媒体资源时，可以通过媒体代理服务先将媒体资源缓存至本地，使应用程序可以直接向媒体代理服务请求从本地获取媒体资源并播放。这样，服务端设备只需向客户端设备提供普通的文件传输功能，不参与和感知播放过程，因此不需要部署播放相关的服务，降低了对服务端设备的能力要求，从而实现了瘦设备间的媒体跨设备实时播放。

在一种实现方式中，媒体代理服务确定是否已启动目标媒体资源的缓存传输流程之后，还包括：如果已启动缓存传输流程，但是缓存传输流程被挂起，媒体代理服务继续缓存传输流程以根据目标媒体资源的缓存进度继续将目标媒体资源从服务端设备缓存至客户端设备，并将第二地址发送给应用程序，第二地址为客户端设备的用于访问缓存的目标媒体资源的本地URL地址；媒体代理服务在接收到应用程序向第二地址发送的第三播放请求时，将缓存的目标媒体资源发送给应用程序进行播放。这样，当缓存传输从挂起状态恢复时，媒体代理服务可以采用增量传输的方式继续缓存目标媒体资源，不需要重新缓存。

在一种实现方式中，媒体代理服务确定是否已启动目标媒体资源的缓存传输流程之后，还包括：如果目标媒体资源已经完全缓存至客户端设备，媒体代理服务将第三地址发送给应用程序，以使应用程序从第三地址获取目标媒体资源进行播放，第三地址为目标媒体资源在客户端设备中缓存的文件路径。这样，当目标媒体资源已缓存至本地之后，应用程序可以直接访问本地存储的目标媒体资源文件进行播放，不再需要媒体代理服务生成媒体流。

在一种实现方式中，媒体代理服务确定是否已启动目标媒体资源的缓存传输流程之后，还包括：如果目标媒体资源已经完全缓存至客户端设备，媒体代理服务将第四地址发送给应用程序，第四地址为客户端设备的用于访问缓存的目标媒体资源的本地URL地址；媒体代理服务在接收到应用程序向第四地址发送的第四播放请求时，将缓存的目标媒体资源发送给应用程序进行播放。这样，当目标媒体资源已缓存至本地之后，媒体代理服务也可以继续为应用程序生成媒体流，应用程序可以接收媒体代理服务发送的媒体流并播放。

在一种实现方式中，第一地址包括客户端设备的本地网际协议IP地址和第一端口；第二播放请求为超文本传输协议HTTP请求。

在一种实现方式中，媒体代理服务在接收到应用程序向第一地址发送的第二播放请求时，将缓存的目标媒体资源发送给应用程序，包括：媒体代理服务监听本地IP地址的第一端口；媒体代理服务在监听到第二播放请求时，生成第一应答消息，第一应答消息为HTTP应答消息，第一应答消息包括根据已缓存的目标媒体资源生成的媒体流。这样，媒体代理服务和应用程序之间可以基于HTTP协议进行数据传输，例如传输媒体流等。

在一种实现方式中，该方法还包括：媒体代理服务在接收到应用程序的停止播放请求时，如果正在进行缓存传输流程，将缓存传输流程挂起，以及记录目标媒体资源的缓存进度。这样，当用户后续播放时，媒体代理服务可以基于缓存进度继续执行缓存传输流程。

第二方面，本申请实施例提供了一种媒体播放方法。该方法包括：客户端设备上的应用程序向客户端设备上的媒体代理服务发送第一播放请求，第一播放请求包括第一标识，第一标识对应服务端设备中的目标媒体资源；应用程序接收媒体代理服务发送的目标地址；如果目标地址是客户端设备的本地URL地址，应用程序向本地URL地址发送第二播放请求；应用程序接收媒体代理服务响应于第二播放请求发送的目标媒体资源并进行播放，目标媒体资源由媒体代理服务从服务端设备缓存至客户端设备。本申请实施例提供的媒体播放方法在客户端设备构建了媒体代理服务，客户端设备在应用程序请求播放服务端设备的媒体资源时，可以通过媒体代理服务先将媒体资源缓存至本地，使应用程序可以直接向媒体代理服务请求从本地获取媒体资源并播放。这样，服务端设备只需向客户端设备提供普通的文件传输功能，不参与和感知播放过程，因此不需要部署播放相关的服务，降低了对服务端设备的能力要求，从而实现了瘦设备间的媒体跨设备实时播放。

在一种实现方式中，应用程序接收媒体代理服务发送的目标地址之后，还包括：如果目标地址是客户端设备中的文件路径地址，应用程序从文件路径地址获取目标媒体资源进行播放。这样，当目标媒体资源已缓存至本地之后，应用程序可以直接访问本地存储的目标媒体资源文件进行播放，不再需要媒体代理服务生成媒体流。

在一种实现方式中，本地URL地址包括客户端设备的本地IP地址和第一端口；第二播放请求为超文本传输协议HTTP请求。

在一种实现方式中，应用程序向本地URL地址发送第二播放请求，包括：应用程序向本地IP地址的第一端口发送第二播放请求。

在一种实现方式中，应用程序接收媒体代理服务响应于第二播放请求发送的目标媒体资源，包括：应用程序接收媒体代理服务响应于第二播放请求发送的第一应答消息，第一应答消息为HTTP应答消息，第一应答消息包括媒体代理服务根据已缓存的目标媒体资源生成的媒体流。这样，媒体代理服务和应用程序之间可以基于HTTP协议进行数据传输，例如传输媒体流等。

第三方面，本申请实施例提供了一种媒体播放方装置。该装置包括：虚拟服务器，用于接收客户端设备上的应用程序的第一播放请求，第一播放请求包括第一标识，第一标识对应服务端设备中的目标媒体资源；虚拟服务器，还用于根据第一标识确定是否已启动目标媒体资源的缓存传输流程；文件缓存单元，用于如果未启动缓存传输流程，启动缓存传输流程以将目标媒体资源从服务端设备缓存至客户端设备；虚拟服务器，还用于将第一地址发送给应用程序，第一地址为客户端设备的用于访问缓存的目标媒体资源的本地统一资源定位符URL地址；虚拟服务器，还用于在接收到应用程序向第一地址发送的第二播放请求时，将缓存的目标媒体资源发送给应用程序进行播放。

在一种实现方式中，文件缓存单元，还用于如果已启动缓存传输流程，但是缓存传输流程被挂起，继续缓存传输流程以根据目标媒体资源的缓存进度继续将目标媒体资源从服务端设备缓存至客户端设备；虚拟服务器，还用于将第二地址发送给应用程序，第二地址为客户端设备的用于访问缓存的目标媒体资源的本地URL地址；虚拟服务器，还用于在接收到应用程序向第二地址发送的第三播放请求时，将缓存的目标媒体资源发送给应用程序进行播放。

在一种实现方式中，虚拟服务器，还用于如果目标媒体资源已经完全缓存至客户端设备，将第三地址发送给应用程序，以使应用程序从第三地址获取目标媒体资源进行播放，第三地址为目标媒体资源在客户端设备中缓存的文件路径。

在一种实现方式中，虚拟服务器，还用于如果目标媒体资源已经完全缓存至客户端设备，将第四地址发送给应用程序，第四地址为客户端设备的用于访问缓存的目标媒体资源的本地URL地址；虚拟服务器，还用于在接收到应用程序向第四地址发送的第四播放请求时，将缓存的目标媒体资源发送给应用程序进行播放。

在一种实现方式中，第一地址包括客户端设备的本地网际协议IP地址和第一端口；第二播放请求为超文本传输协议HTTP请求。

在一种实现方式中，虚拟服务器用于在接收到应用程序向第一地址发送的第二播放请求时，将缓存的目标媒体资源发送给应用程序时，包括：虚拟服务器，用于监听本地IP地址的第一端口；虚拟服务器，还用于在监听到第二播放请求时，生成第一应答消息，第一应答消息为HTTP应答消息，第一应答消息包括根据已缓存的目标媒体资源生成的媒体流。

在一种实现方式中，虚拟服务器，还用于在接收到应用程序的停止播放请求时，如果正在进行缓存传输流程，将缓存传输流程挂起，以及记录目标媒体资源的缓存进度。

第四方面，本申请实施例提供了一种媒体播放方装置。该装置包括：第一发送单元，用于向客户端设备上的媒体代理服务发送第一播放请求，第一播放请求包括第一标识，第一标识对应服务端设备中的目标媒体资源；地址接收单元，用于接收媒体代理服务发送的目标地址；第二发送单元，用于如果目标地址是客户端设备的本地URL地址，向本地URL地址发送第二播放请求；播放单元，用于接收媒体代理服务响应于第二播放请求发送的目标媒体资源并进行播放，目标媒体资源由媒体代理服务从服务端设备缓存至客户端设备。

在一种实现方式中，播放单元，还用于如果目标地址是客户端设备中的文件路径地址，从文件路径地址获取目标媒体资源进行播放。

在一种实现方式中，本地URL地址包括客户端设备的本地IP地址和第一端口；第二播放请求为超文本传输协议HTTP请求。

在一种实现方式中，第二发送单元用于向本地URL地址发送第二播放请求，包括：向本地IP地址的第一端口发送第二播放请求。

在一种实现方式中，播放单元用于接收媒体代理服务响应于第二播放请求发送的目标媒体资源，包括：接收媒体代理服务响应于第二播放请求发送的第一应答消息，第一应答消息为HTTP应答消息，第一应答消息包括媒体代理服务根据已缓存的目标媒体资源生成的媒体流。

第五方面，本申请实施例提供了一种电子设备，包括：媒体代理服务模块和应用程序模块；媒体代理服务模块，用于执行第一方面及其各实现方式的方法；应用程序模块，用于执行第二方面及其各实现方式的方法。

第六方面，本申请实施例还提供一种计算机可读存储介质，计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机执行上述各方面的方法。

第七方面，本申请实施例还提供了一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行上述各方面的方法。

第八方面，本申请实施例还提供了一种芯片系统，该芯片系统包括处理器，用于支持上述装置或系统实现上述方面中所涉及的功能，例如，生成或处理上述方法中所涉及的信息。

附图说明

图1是目前一种分布式场景的架构示意图；

图2是目前另一种分布式场景的架构示意图；

图3是本申请实施例示出的用户在客户端设备播放服务端设备中的媒体资源的示意图；

图4是本申请实施例示出的媒体资源页的子页面示意图；

图5是基于实时流协议RTSP的实时流传输播放的示意图；

图6是基于实时流协议HLS的实时流传输播放的示意图；

图7是本申请实施例提供的终端设备的硬件结构示意图；

图8是本申请实施例提供的软件架构的示意图；

图9是本申请实施例提供的媒体播放方法的流程图；

图10是本申请实施例示出的应用程序生成第一播放请求的场景图；

图11是本申请实施例示出的应用程序生成第二播放请求的场景图；

图12是本申请实施例示出的另一种媒体播放方法的流程图；

图13是本申请实施例示出本地媒体服务在开始播放场景的处理流程图；

图14是本申请实施例示出本地媒体服务在终止播放场景的处理流程图；

图15是本申请实施例提供的另一种媒体播放方法的硬件架构图；

图16是本申请实施例提供的一种媒体播放装置的结构示意图；

图17是本申请实施例提供的芯片系统的结构示意图。

具体实施方式

分布式场景式是指多个设备通过网络连接，彼此相互信息、数据以进行交互，从而共同完成一个任务目标的场景。

图1是目前一种分布式场景的架构示意图。如图1所示，该分布式场景架构可以包括一个或者多个客户端设备11、以及服务器12。其中，一个或者多个客户端设备11与广域网(wide area network，WAN)中的服务器12连接。客户端设备11例如可以包括：手机、笔记本电脑、平板电脑、大屏显示设备、虚拟/混合/增强现实设备、本地服务器等，本申请实施例对此不做限定。根据分布式场景执行的任务的不同，服务器12例如可以包括媒体服务器、应用程序服务器、存储服务器、网页服务器、数据中心、内容分发节点等，本申请实施例对此不做限定。

图2是目前另一种分布式场景的架构示意图。如图2所示，该分布式场可以包括多个终端设备21，多个终端设备21可以通过广域网WAN或者局域网(local area network，LAN)建立连接。例如，当多个终端设备21通过局域网WAN建立连接时，多个终端设备21可以接入到由无线接入点(wireless access point，WAP)22创建的无线局域网络(WirelessLAN，WLAN)中，彼此间的数据传输通过无线接入点22的转发实现。这里的终端设备21例如可以包括手机、笔记本电脑、平板电脑、大屏显示设备、虚拟/混合/增强现实设备、网络附加存储器(network attached storage，NAS)、带有存储器功能的路由器等，其中，路由器可以即可以作为该分布式场景中的无线接入点。

作为一种实现方式，分布式场景可以用于实现媒体对象的跨设备播放功能，即一个设备播放另一个设备中的媒体资源。这里为便于描述，将播放媒体资源的设备称作客户端设备，将提供媒体内容的设备称作服务端设备。那么，客户端设备播放媒体内容的方式一般可以包括本地播放和实时流传输播放。其中，本地播放是指在用户请求播放媒体资源时，客户端设备首先将完整的媒体文件从服务端设备拉取到本地，然后再开始播放；实时流传输播放是指基于实时流传输协议或投屏协议，在服务端设备部署实时流传输、内容分发和/或编解码等服务，当客户端设备请求播放媒体资源时，服务端设备基于部署的服务向客户端设备发送媒体流，客户端设备一边缓存一边播放媒体流。

图3是本申请实施例示出的用户在客户端设备中执行手势操作以播放服务端设备中的媒体资源的示意图。

下面结合图3对本地播放流程进行示例性说明。

如图3所示，用户可以操作客户端设备30进入到客户端设备30提供的媒体播放对应的分布式入口界面31，该界面例如可以包括服务端设备列表32，该服务端设备列表32可以包括该分布式场景中的部分或者全部服务端设备的信息33。其中，服务端设备的信息33例如可以包括以下信息中的一种或者多种：设备型号(例如Mate 30pro、华为智慧屏等)、设备名称(用户自定义的名称，例如：小明的华为手机等)、设备类型(如：手机、平板电脑、笔记本、大屏显示设备)、设备状态(在线/离线)、设备占用状态(例如是否被其他用户设备占用等)。

进一步如图3所示，当用户点击41服务端设备列表32的任一服务端设备的信息33时，客户端设备31可以显示该服务端设备的媒体资源页面34。媒体资源页面34可以通过图标和/或者文字的方式展示服务端设备中已存储的媒体文件，其中，图标例如可以是视频或者图片的缩略图，文字例如可以是媒体文件的名称。

在一种实现方式中，媒体资源页面34可以包括多层页面。例如，当用户进入媒体资源页面34时，媒体资源页面可以展示第一层页面35，第一层页面35包括至少一个文件夹36，并且展示每个文件夹的名称和每个文件夹中包含的文件数量。这些文件夹可以是用户创建的、可以是本地自动创建的、也可以是本地程序中的应用程序创建的，用于将媒体文件按照来源等进行分类。文件夹36可以以其包含的一个或者多个文件的缩略图作为图标。当用户在第一层页面35点击42任一文件夹36时，客户端设备31展示该文件夹36对应的第二层页面37，第二层页面37中可以包括该文件夹36中的各个媒体文件的图标38和名称等信息。可以理解的是，媒体资源页面34在实现时，可以包括更少层页面(例如仅包括第一层页面35或者仅包括第二层页面37)也可以包括更多层页面，具体可以是根据媒体文件在服务端设备中的存储路径确定的，本申请实施例对此不做限定。

接下来，用户可以点击43任一媒体文件的图标38以请求播放，客户端设备和服务端设备之间即可以建立文件传输，将服务端设备中的该媒体文件传输给客户端设备。客户端设备在接收到完整的媒体文件之后，再开始播放媒体文件。其中，媒体文件的访问传输过程可以通过文件传输协议(file transfer protocol，FTP)服务、基于Web的分布式编写和版本控制(WebDAV)服务等实现，本申请实施例对此不做限定。

可以理解的是，本地播放类似于用于从网络中下载媒体资源然后再进行播放，需要先将媒体文件从服务端设备拉取到客户端设备，再进行播放，因此从用户请求播放到媒体文件开始播放会存在一定的延时，导致用户在体验上感觉到卡顿感。这个延时通常根据文件传输速度和媒体文件大小确定，例如，如果媒体文件是一部电影，那么传输时间可能会长达几十秒，严重影响用户体验。

在一种实现方式中，如图4所示，当服务端设备中的媒体文件包括多种类型时，媒体资源页面34还可以包括多个子页面，每个子页面对应一种类型，用户可以通过划动操作44或者点击45子页面名称的方式在不同的子页面之间切换。其中，上述多种类型例如可以包括：图片、视频、音频、文档、其他、最近等，本申请实施例对此不做限定。

图5是基于实时流协议RTSP的实时流传输播放的示意图。实时流协议RTSP是一种网络应用协议，专为娱乐和通信系统的使用，以控制服务端。该协议用于创建和控制终端之间的媒体会话。与服务端连接的客户端可以发布命令，例如播放、录制和暂停等，以便于实时控制从服务端到客户端或从客户端到服务端的媒体流。如图4所示，基于实时流协议RTSP实现实时流传输播放可以通过以下步骤实现：

步骤S1，OPTIONS请求流程。具体包括：

步骤S11，客户端向服务端发送OPTIONS请求消息(OPTIONS request)，以请求服务端可接受的请求类型。

步骤S12，服务端向客户端发送OPTIONS应答消息(OPTIONS response)，以将其可接受的所有的请求类型发送给客户端。

步骤S2，DESCRIBE请求流程。具体包括：

步骤S21，客户端向服务端发送DESCRIBE请求消息(DESCRIBE request)，以请求从服务端获得媒体初始化描述信息。

步骤S22，服务端向客户端发送DESCRIBE应答消息(DESCRIBE response)，以将媒体初始化描述信息发送给客户端。

步骤S3，SETUP请求流程。具体包括：

步骤S31，客户端向服务端发送SETUP请求消息(SETUP request)，以设置媒体会话的属性和传输模式，并且提醒服务端建立会话。

步骤S32，服务端建立会话，向客户端发送SETUP应答消息(SETUP response)，以将会话标识符和相关信息发送给客户端。

步骤S4，PLAY播放请求流程。具体包括：

步骤S41，客户端向服务端发送播放请求消息(PLAY request)，以请求播放媒体资源。

步骤S42，服务端响应于PLAY request，向客户端发送流媒体数据(PLAYresponse)。

步骤S5，TEARDOWN请求流程。具体包括：

步骤S51，客户端向服务端发送TEARDOWN请求消息(TEARDOWN request)，以请求关闭媒体会话。

步骤S52，服务端响应于TEARDOWN request，关闭会话(TEARDOWN response)。

由此可见，基于RTSP的实时流传输播放需要涉及到大量的交互流程对设备资源要求较高；此外，RTSP要求在服务端设备中部署RTSP服务，一般来说，对于服务端等胖设备，部署RTSP服务是可行的，而对于手机、平板电脑等瘦设备来说，部署RTSP服务存在性能瓶颈，因此基于RTSP的实时流传输播放难以在图2示出的场景中实现；另外，RTSP的流媒体传输和播放是同时进行的，因此播放的流畅性取决于网络质量，当网络质量不佳时，播放可能出现卡顿。

图6是基于实时流协议HLS的实时流传输播放的示意图。HLS是一种基于超文本传输协议(hypertext transfer protocol，HTTP)的流媒体网络传输协议。它的工作原理是把整个流分成一个个小的基于HTTP的文件来下载，每次只下载一些。当流媒体正在播放时，客户端可以选择从许多不同的备用源中以不同的速率下载同样的资源，允许流媒体会话适应不同的数据速率。为实现上述HLS的相应功能，如图6所示，HLS除了包括服务端和客户端以外，还需要包括内容分发端Distribution。结合图5，HLS实现实时流传输播放具体流程可以包括：

在服务端中：服务端获取媒体资源，对媒体资源进行编码得到媒体流，然后通过流分割器对媒体流进行分割，得到多个小的视频文件(.ts)，并且生成这些视频文件对应的播放列表文件(Index file)，最后将得到的视频文件(.ts)和播放列表文件发送给内容分发端。

在内容分发端和客户端：内容分发端用于存储视频文件(.ts)，并且可以将播放列表文件(Index file)发送给客户端；客户端根据列表文件(Index file)可以获取到各个视频文件(.ts)在内容分发端存储的地址，然后根据这些地址获取视频文件(.ts)并播放。

由此可见，基于HLS的实时流传输播放需要在服务端设备中部署文件分割服务和内容分发服务，对设备资源要求较高，同样难以在图2示出的场景中实现；另外HLS的流媒体传输和播放也是同时进行的，因此播放的流畅性取决于网络质量，当网络质量不佳时，播放也可能出现卡顿。

另外，还有一些投屏方案可能用于实现分布式场景的实时流传输播放，但这些方案同样需要在服务端部署媒体解码编码服务，并且流媒体传输和播放也是同时进行的，因此同样存在RTSP和HLS方案所存在的问题。

为了解决上述问题，实现在瘦设备间的实时流传输播放，提升流媒体播放的流畅性，本申请实施例提供了一种媒体播放方法。

本申请实施例提供的方法可以应用于图1或者图2示出的分布式场景，优选可以应用于图2提供的由瘦设备组成的分布式场景。

图7是本申请实施例提供的终端设备的硬件结构示意图。如图7所示，终端设备100可以包括处理器110，存储器120，通用串行总线(universal serial bus，USB)接口130，射频电路140，移动通信模块150，无线通信模块160，摄像头170，显示屏180，触摸传感器190，气压传感器210和按键220等。

处理器110可以包括一个或多个处理单元，例如：处理器110可以包括应用处理器(application processor，AP)，调制解调处理器，图形处理器(graphics processingunit，GPU)，图像信号处理器(image signal processor，ISP)，视频编解码器，数字信号处理器(digital signal processor，DSP)，基带处理器，和/或神经网络处理器(neural-network processing unit，NPU)等。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中，例如集成在系统芯片(system on a chip，SoC)中。处理器110中还可以设置存储器，用于存储指令和数据。在一些实施例中，处理器110中的存储器为高速缓冲存储器。该存储器可以保存处理器110刚用过或循环使用的指令或数据。

在一些实施例中，处理器110可以包括一个或多个接口。接口可以包括集成电路(inter-integrated circuit，I2C)接口，集成电路内置音频(inter-integrated circuitsound，I2S)接口，脉冲编码调制(pulse code modulation，PCM)接口，通用异步收发传输器(universal asynchronous receiver/transmitter，UART)接口，移动产业处理器接口(mobile industry processor interface，MIPI)，通用输入输出(general-purposeinput/output，GPIO)接口，用户标识模块(subscriber identity module，SIM)接口，和/或通用串行总线(universal serial bus，USB)接口等。

存储器120可以用于存储计算机可执行程序代码，可执行程序代码包括指令。存储器120可以包括存储程序区和存储数据区。其中，存储程序区可存储操作系统、至少一个功能所需的应用程序(比如声音播放功能，图像播放功能等)等。存储数据区可存储终端设备100使用过程中所创建的数据(比如音频数据，电话本等)等。此外，存储器120可以包括一个或者多个存储单元，例如可以包括易失性存储器(volatile memory)，如：动态随机存取存储器(dynamic random access memory，DRAM)、静态随机存取存储器(static randomaccess memory，SRAM)等；还可以包括非易失性存储器(non-volatile memory，NVM)，如：只读存储器(read-only memory，ROM)、闪存(flash memory)等。处理器110通过运行存储在存储器120的指令，和/或存储在设置于处理器中的存储器的指令，执行终端设备100的各种功能应用以及数据处理。

终端设备100的无线通信功能可以通过射频电路140、移动通信模块150、无线通信模块160、调制解调处理器以及基带处理器等实现。

射频电路140可以包括至少一个天线141，用于发射和接收电磁波信号。终端设备100中的每个天线可用于覆盖单个或多个通信频带。在一些实施例中，天线可以和调谐开关结合使用。

移动通信模块150可以提供应用在终端设备100上的包括2G/3G/4G/5G等无线通信的解决方案。移动通信模块150可以包括至少一个滤波器，开关，功率放大器，低噪声放大器(low noise amplifier，LNA)等。移动通信模块150可以由天线141接收电磁波，并对接收的电磁波进行滤波，放大等处理，传送至调制解调处理器进行解调。移动通信模块150还可以对经调制解调处理器调制后的信号放大，经天线141转为电磁波辐射出去。在一些实施例中，移动通信模块150的至少部分功能模块可以被设置于处理器110中。在一些实施例中，移动通信模块150的至少部分功能模块可以与处理器110的至少部分模块被设置在同一个器件中。

调制解调处理器可以包括调制器和解调器。其中，调制器用于将待发送的低频基带信号调制成中高频信号。解调器用于将接收的电磁波信号解调为低频基带信号。随后解调器将解调得到的低频基带信号传送至基带处理器处理。低频基带信号经基带处理器处理后，被传递给应用处理器。应用处理器通过音频设备(包括但不限于扬声器，受话器等)输出声音信号，或通过显示屏180显示图像或视频。在一些实施例中，调制解调处理器可以是独立的器件。在另一些实施例中，调制解调处理器可以独立于处理器110，与移动通信模块150或其他功能模块设置在同一个器件中。

无线通信模块160可以包括无线保真(wireless fidelity，Wi-Fi)模块，蓝牙(bluetooth，BT)模块、GNSS模块、近距离无线通信技术(near field communication，NFC)模块、红外(infrared，IR)模块等。无线通信模块160可以是集成上述至少一个模块的一个或多个器件。无线通信模块160经由天线141接收电磁波，将电磁波信号调频以及滤波处理，将处理后的信号发送到处理器110。无线通信模块160还可以从处理器110接收待发送的信号，对其进行调频，放大，经天线141转为电磁波辐射出去。

本申请实施例中，终端设备100的无线通信功能例如可以包括全球移动通讯系统(global system for mobile communications，GSM)，通用分组无线服务(general packetradio service，GPRS)，码分多址接入(code division multiple access，CDMA)，宽带码分多址(wideband code division multiple access，WCDMA)，时分码分多址(time-divisioncode division multiple access，TD-SCDMA)，长期演进(long term evolution，LTE)，第五代移动通信技术新空口(5th generation mobile networks new radio，5G NR)，BT，GNSS，WLAN，NFC，FM，和/或IR等功能。GNSS可以包括全球卫星定位系统(globalpositioning system，GPS)，全球导航卫星系统(global navigation satellite system，GLONASS)，北斗卫星导航系统(beidou navigation satellite system，BDS)，准天顶卫星系统(quasi-zenith satellite system，QZSS)和/或星基增强系统(satellite basedaugmentation systems，SBAS)。

摄像头170用于捕获静态图像或视频。摄像头170包括镜头和感光元件，物体通过镜头生成光学图像投射到感光元件。感光元件可以是电荷耦合器件(charge coupleddevice，CCD)或互补金属氧化物半导体(complementary metal-oxide-semiconductor，CMOS)光电晶体管。感光元件把光信号转换成电信号，之后将电信号传递给ISP转换成数字图像信号。ISP将数字图像信号输出到DSP加工处理。DSP将数字图像信号转换成标准的RGB，YUV，RYYB等格式的图像信号。在一些实施例中，终端设备100可以包括1个或N个摄像头170，N为大于1的正整数。

NPU为神经网络(neural-network，NN)计算处理器，通过借鉴生物神经网络结构，例如借鉴人脑神经元之间传递模式，对输入信息快速处理，还可以不断的自学习。通过NPU可以实现终端设备100的智能认知等应用，例如：图像识别，人脸识别，语音识别，文本理解等。

显示屏180用于显示图像，视频等。显示屏180包括显示面板。显示面板可以采用液晶显示屏(liquid crystal display，LCD)，有机发光二极管(organic light-emittingdiode，OLED)，有源矩阵有机发光二极体或主动矩阵有机发光二极体(active-matrixorganic light emitting diode的，AMOLED)，柔性发光二极管(flex light-emittingdiode，FLED)，MiniLED，MicroLED，Micro-OLED，量子点发光二极管(quantum dot lightemitting diodes，QLED)等。在一些实施例中，终端设备100可以包括1个或N个显示屏180，N为大于1的正整数。

触摸传感器190，也称“触控器件”。触摸传感器190可以设置于显示屏180，由触摸传感器190与显示屏180组成触摸屏，也称“触控屏”。触摸传感器190用于检测作用于其上或附近的触摸操作。触摸传感器可以将检测到的触摸操作传递给应用处理器，以确定触摸事件类型。可以通过显示屏180提供与触摸操作相关的视觉输出。在另一些实施例中，触摸传感器190也可以设置于终端设备100的表面，与显示屏180所处的位置不同。

气压传感器210用于测量气压。在一些实施例中，终端设备100通过气压传感器210测得的气压值计算海拔高度，辅助定位和导航。

按键220包括开机键，音量键等。按键220可以是机械按键。也可以是触摸式按键。终端设备100可以接收按键输入，产生与终端设备100的用户设置以及功能控制有关的键信号输入。

可以理解的是，本申请实施例示意的结构并不构成对终端设备100的具体限定。在本申请另一些实施例中，终端设备可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以以硬件，软件或软件和硬件组合实现。

在图2示出的分布式场景中，任意终端设备均可以作为实时流传输播放中的服务端设备或者客户端设备，一个终端设备具体是服务端设备还是客户端设备，取决于它是媒体资源的提供者还是播放者。例如：对于终端设备A和终端设备B，如果终端设备A跨设备播放终端设备B中的媒体文件，那么终端设备A就是客户端设备，终端设备B就是服务端设备；反之，如果终端设备B跨设备播放终端设备A中的媒体文件，那么终端设备B就是客户端设备，终端设备A就是服务端设备。

本申请实施例提供的媒体播放方法的各方法步骤可以在客户端设备和服务端设备中实现，主要是在客户端设备中实现。本申请实施例还提供了一种终端设备的软件架构。该软件架构可用于客户端设备和服务端设备实现媒体播放方法的各方法步骤。

图8是本申请实施例提供的软件架构的示意图。如图8所示，该软件架构包括客户端部分和服务端部分。其中，客户端部分可以包括应用程序和本地媒体服务(也可以称作媒体代理服务、本地代理服务等，本申请实施例对此不做限定)，服务端部分可以包括文件管理功能。

应用程序一般可以是具备文件浏览和播放功能应用程序，例如文件管理器应用、播放器应用或者其他媒体类应用等，本申请实施例对此不做限定。应用程序可以是客户端设备的系统应用也可以是第三方应用，本申请实施例对此亦不做限定。

本地媒体服务是本申请实施例在客户端设备中新增的功能模块。本地媒体服务例如可以包括虚拟服务器、文件缓存功能和文件传输功能组成。其中，本地媒体服务可以视作在应用程序和服务端设备之间设置的代理服务，将原有的从服务端设备到应用程序之间的流媒体传输行为隔离开，接收和缓存来自服务端设备的媒体资源，并且向应用程序提供媒体资源的访问功能。本地媒体服务的具体功能将在以下实施例中进一步展开说明。

服务端设备的文件管理功能仅被要求实现常规的文件存储和传输功能，因此在服务端设备中不需要部署任何实时流传输协议的相关服务。

图9是本申请实施例提供的媒体播放方法的流程图。该方法可以应用于具有图8所示软件架构的客户端设备。如图9所示，该方法可以包括以下步骤：

步骤S101，本地媒体服务获取服务端设备的媒体资源信息。

服务端设备的媒体资源信息例如可以包括服务端设备存储的媒体资源的文件标识，在服务端设备中，每个媒体文件都具有一个文件标识，不同的媒体文件具有不同的文件标识，因此文件标识可以用于客户端设备和服务端设备识别某个媒体文件的唯一身份。

在一种实现方式中，文件标识可以是文件描述符(file descriptor，FD)，其形式可以是一个非负整数，可以是服务端设备在创建媒体文件时生成，本申请实施例对此不做限定。

在一种实现方式中，文件标识可以是媒体文件的路径path，例如是音频文件在分布式场景中的局域网中的HTTP路径等，本申请实施例对此不做限定。

可以理解的是，文件标识除了上述示出的FD和path以外，还可以包括其他形式的文件标识，此处不再赘述。

在一种实现方式中，媒体资源信息还可以包括各个媒体文件的文件名称、文件类型、文件大小、缩略图、创建时间中的一个或者多个。

这里需要补充说明的是，在本申请实施例中，步骤S101，即本地媒体服务获取服务端设备的媒体资源信息的动作可以通过多种方式触发，本申请实施例对此不做限定，只要能在应用程序在触发第一应用请求之前获取到媒体资源信息即可。例如：在本地媒体服务运行期间，本地媒体服务可以定时获取服务端设备的媒体资源信息；或者，当服务端设备检测到媒体资源信息发生变化时(例如：增加了文件、删除了文件、文件属性发生变化时)，主动将最新的媒体资源信息发送给本地媒体服务；或者，本地媒体服务可以在应用程序启动时，触发获取服务端设备的媒体资源信息的行为。

步骤S102，应用程序向本地媒体服务发送第一播放请求，第一播放请求包括第一标识。

下面结合一个使用场景对步骤S102的实现方式进行具体说明。

图10是本申请实施例示出的应用程序生成第一播放请求的场景图。

如图10所示，当打开客户端设备中的文件管理应用，点击46“其他设备”选项时，文件管理应用可以向用户展示服务端设备列表32。

接下来，用户如果想要访问某个服务端设备中的媒体资源，则可以点击这个服务端设备，应用程序在检测到用户点击47了某个服务端设备时，可以从本地媒体服务获取这个服务端设备的媒体资源信息，并且根据媒体资源信息生成这个服务端设备的媒体资源页面35。

接下来，用户如果想要播放某个媒体资源，以下称作目标媒体资源，则可以点击48目标媒体资源的图标39，应用程序在检测到用户点击48了目标媒体资源的图标39时，向本地媒体服务发送第一播放请求。可以理解的是，第一播放请求中的第一标识即为目标媒体资源的媒体标识。

这里需要补充说明的是，应用程序除了响应于用户的触控输入生成第一播放请求之外，还可以通过其他的方式生成第一播放请求，例如响应于用户的语音输入，响应于遥控器输入等，本申请实施例对此不做限定。

在一种实现方式中，应用程序与本地媒体服务之间的通信可以通过本地媒体服务中的虚拟服务器实现。虚拟服务器例如可以是HTTP虚拟服务器，这样，应用程序与HTTP虚拟服务器之间可以基于HTTP协议建立消息和数据传输。

具体实现中，HTTP虚拟服务器可以在本地IP地址和特定端口上监听应用程序的请求。该端口可以由应用程序和本地媒体服务事先协定。示例地，本地IP地址一般可以是127.0.0.1，端口可以是1～65536中的任一一个或者多个，为便于描述以下将端口以xx表示。相应地，第一播放请求可以是一个向127.0.0.1:xx发送的HTTP请求。这样，本地媒体服务通过监听127.0.0.1:xx，就能够接收到第一播放请求。

本申请实施例中，本地媒体服务在接收到第一标识之后可以首先确定其是否已经启动了第一标识对应的目标媒体资源的缓存传输流程，如果本地媒体服务未启动缓存传输流程，说明应用程序之前没有播放过目标媒体资源，应用程序是第一次向本地媒体服务发送第一播放请求。在这种情况下，本地媒体服务和应用程序可以执行步骤S103-S107。

这里需要补充说明的是，在本申请实施例中，“未启动缓存传输流程”是指本地媒体服务没有启动从服务端设备到客户端设备的目标媒体资源传输流程，这时客户端设备本地未缓存目标媒体资源的任何文件片段，该状态一般对应用户第一次请求播放目标媒体资源的场景。

步骤S103，本地媒体服务设置第一地址。

其中，第一地址可以是客户端设备的用于访问缓存的目标媒体资源的地址，可以用于应用程序后续获取目标媒体资源对应的媒体流。

在一种实现方式中，第一地址可以是本地统一资源定位符URL地址。如果应用程序与虚拟服务器之间基于HTTP协议建立消息和数据传输，那么第一地址还是一个HTTP地址，例如：http://127.0.0.1:xx/y，其中，y表示目标媒体资源将要在客户端设备中缓存的文件路径。

步骤S104，本地媒体服务启动缓存传输流程以将服务端设备的目标媒体资源缓存至客户端设备。

步骤S105，本地媒体服务将第一地址发送给应用程序，应用程序接收第一地址。

具体实现中，步骤S105可以由本地媒体服务的虚拟服务器执行，当虚拟服务器是HTTP虚拟服务器，HTTP虚拟服务器可以通过HTTP协议消息将第一地址发送个应用程序。

具体实现中，即步骤S104和步骤S105可以是同步进行的，或者步骤S105是可以在步骤S104之前进行的，或者，步骤S105可以是在步骤S104之后进行的。这也就意味着，本地媒体服务在发送第一地址给应用程序的同时，就已经可以开始缓存目标媒体资源了，而这时应用程序还没有接收到用户要开始播放媒体资源的请求。可见，在本申请实施例中，媒体资源的缓存过程和播放过程是相互独立、相互解耦的，媒体资源的缓存过程可以先于播放过程进行。

在一种实现方式中，步骤S105可以由本地媒体服务的文件缓存功能和文件传输功能实现。具体实现中，文件缓存功能可以首先基于客户端设备与服务端设备设置之间的形成的分布式文件系统获取目标媒体资源的存储位置，该存储位置可以同样可以是一个URL。

以图2示出的分布式场景为例，假设客户端设备在分布式场景中的局域网IP地址为192.168.1.105、服务端设备的局域网IP地址192.168.1.107、目标媒体资源在服务端设备中的存储路径为a/b/c，那么，当服务端设备于客户端设备之间采用ftp协议(仅作为示例，也可以采用其他协议，此处不构成限定)传输数据时，目标媒体资源的存储位置可以是：ftp://192.168.1.107/a/b/c。

接下来，文件缓存功能可以根据一些设定的策略因子确定缓存策略，这里可以采用的策略因子可以包括但不限于以下一个或者多个：服务端设备的网络能力、客户端设备的网络能力、服务端设备与客户端设备之间的协议速率、服务端设备的磁盘I/O性能、客户端设备的磁盘I/O性能、服务端设备的磁盘I/O负载、客户端设备的磁盘I/O负载、服务端设备的处理器负载、客户端设备的处理器负载等。

另外，这里可以采用的缓存策略可以包括但不限于以下一个或者多个：缓存速度、采用文件分段传输时每个文件片段的大小、缓冲健康度buffer health(指已缓存的进度与应用程序已播放的进度之间的时间差)等。

关于策略因子与缓存策略之间的关系，本申请实施例不做具体限定，本领域技术人员可以基于本领域认知合理确定。例如：服务端设备的网络能力和客户端设备的网络能力越高，缓存速度越快、每个文件片段越大、缓冲健康度越小；服务端设备的网络能力和客户端设备的网络能力越低，每个文件片段越小、缓冲健康度越大。

接下来，文件缓存功能可以根据缓存策略启动目标媒体资源的跨设备传输，例如：基于确定的缓存速度从目标媒体资源的存储位置获取目标媒体资源，并分段缓存在第一地址，直到缓存的目标媒体资源满足缓冲健康度的要求。

步骤S106，应用程序向第一地址发送第二播放请求。

其中，第二播放请求可以是用户希望开始播放媒体资源的请求。

图11是本申请实施例示出的应用程序生成第二播放请求的场景图。

图11示出的场景可以是图10示出的场景的延续。如图11所示，在用户想要播放目标媒体资源，并且点击目标媒体资源的图标时，应用程序可以进入到该目标媒体资源的播放界面51。在播放界面51下，应用程序至少可以有两种方式来开始播放目标媒体资源，一种方式是“不自动播放”，另一种方式是“自动播放”。“不自动播放”和“自动播放”模式可以由应用程序择一默认设置。也可以由用户设置。

在“不自动播放”方式下，播放界面51可以包括一个开始播放按钮52，当应用程序检测到用户点击49开始播放按钮52时，即开始播放。那么，如果应用程序采用了“不自动播放”方式，则应用程序可以在检测到用户49点击开始播放按钮52时，向第一地址发送第二播放请求。

在“自动播放”方式下，应用程序在检测到用户点击目标媒体资源的图标时，进入到该目标媒体资源的播放界面51并且直接开始播放。那么，如果应用程序采用了“自动播放”方式，则应用程序可以在检测到用户点击目标媒体资源的图标之后，只要获取到第一地址，就立刻向第一地址发送第二播放请求。其中，如果应用程序是第一次播放目标媒体资源，应用程序可能预先未得到第一地址，则可以等到本地媒体服务反馈第一地址会后，立刻向第一地址发送第二播放请求；如果应用程序不是第一次播放目标媒体资源，应用程序可能在之前播放时已经得到了第一地址，则可以立刻向第一地址发送第二播放请求。

在一种实现方式中，第二播放请求可以是HTTP请求，该请求可以向第一地址的第一端口发送，第一端口可以是应用程序和本地媒体服务事先协定的端口。其中，应用程序和本地媒体服务可以为第一播放请求和第二播放请求协定相同的端口，也可以为第一播放请求和第二播放请求协定相不同的端口，本申请实施例对此不做限定。

步骤S107，本地媒体服务在接收到第二播放请求时，将缓存的目标媒体资源发送给应用程序进行播放。

具体实现中，步骤S107可以由本地媒体服务的虚拟服务器执行。虚拟服务器例如可以是HTTP虚拟服务器。虚拟服务器可以针对本地IP地址和第一端口创建服务套接字ServerSocket，通过ServerSocket监听在本地IP地址的第一端口接收到的HTTP请求，如果监听到第二播放请求，则将缓存的目标媒体资源发送给应用程序进行播放。

在一种实现方式中，本地媒体服务将缓存的目标媒体资源发送给应用程序进行播放，具体可以通过以下方式实现：本地媒体服务在监听到第二播放请求之后，可以从第一地址读取分段缓存的目标媒体资源的文件片段，按照文件片段对应的音/视频时间的先后顺序，将文件片段处理成媒体流，然后将媒体流发送给应用程序进行播放。其中，媒体流可以是基于HTTP协议的媒体流，通过HTTP应答消息的方式发送给应用程序。

进一步地，应用程序在接收到媒体流之后，可以使用其配置的音/视频解码器、渲染器等对媒体流进行解码和渲染，从而产生声音或者图像。

由以上技术方案可知，本申请实施例提供的媒体播放方法在客户端构建了本地媒体服务，客户端设备在应用程序请求播放服务端设备的媒体资源时，可以通过本地媒体服务先将媒体资源缓存至本地，使应用程序可以直接向本地媒体服务请求从本地获取媒体资源并播放。这样，服务端设备只需向客户端设备提供普通的文件传输功能，不参与和感知播放过程，因此不需要部署播放相关的服务，降低了对服务端设备的能力要求，从而实现了瘦设备间的媒体跨设备实时播放。

可以理解的是，在媒体跨设备实时播放的场景中，对于服务端设备中的同一个目标媒体资源，应用程序可能是第一次播放，也可能不是第一次播放，这取决于用户的意愿。当应用程序是第一次播放目标媒体资源时，本地媒体服务未启动缓存传输流程，因此客户端设备可以完整执行步骤S101-S107的方法；当应用程序不是第一次播放目标媒体资源时，本地媒体服务可能已经在之前的播放过程中已经启动了缓存传输流程，在这种情况下，客户端可以还可以根据目标媒体资源的缓存状态，执行其他的方法步骤。

具体来说，在媒体跨设备实时播放的场景中，用户可能会执行开始播放、暂停播放、终止播放等播放控制操作，或者重复播放目标媒体资源，在这种情况下，目标媒体资源可以有不同的缓存状态。以“开始播放”场景为例，目标媒体资源的缓存状态可以包括“未启动缓存传输流程”和“已启动缓存传输流程”。“已启动缓存传输流程”又进一步可以包括“缓存传输挂起”、“缓存传输进行中”、“缓存传输完成”等状态，其中：

“缓存传输挂起”是指本地媒体服务在此之前已经启动了从服务端设备到客户端设备的目标媒体资源传输流程，但因为一些原因(例如用户点击了暂停播放或者暂时关闭播放)传输流程被暂停了，但是服务端设备与本地媒体服务之间用于传输目标媒体资源的连接和预申请的系统资源并未释放，这时本地媒体服务记录了目标媒体资源在客户端的缓存位置、目标媒体资源的整体长度和目标媒体资源当前已传输长度(即传输进度)。

“缓存传输进行中”是指本地媒体服务在此之前已经启动了从服务端设备到客户端设备的目标媒体资源传输流程，并且正在进行数据传输，该状态一般对应用户正在播放目标媒体资源，或者，暂停播放目标媒体资源，但是因为一些原因(例如缓存的目标媒体资源没有达到buffer health要求)目标媒体资源的缓存动作还在进行。

“缓存传输完成”是指目标媒体资源的跨设备传输已经完成，客户端设备已经完整地缓存了目标媒体资源的各个文件片段。

进一步如图9所示，当本地媒体服务已经启动了缓存传输流程，但是缓存传输流程被挂起时，本地媒体服务和应用程序可以在步骤S102之后执行以下步骤S108-步骤S112：

步骤S108，本地媒体服务设置第二地址。

其中，第二地址可以是客户端设备的用于访问缓存的目标媒体资源的地址，第二地址与第一地址可以相同也可以不同。当第一地址和第二地址均是HTTP地址时，第一地址和第二地址的区别可以仅在于端口不同，例如：第一地址可以包括本地IP地址和第一端口，第二地址可以包括本地IP地址和第二端口。

这里需要补充说明的是，第一地址和第二地址均可以是一个临时地址，本地媒体服务每接收到一次第一播放请求都可以生成一个这样的临时地址，以便应用程序后续从这个临时地址获取目标媒体资源对应的媒体流。

步骤S109，本地媒体服务继续缓存传输流程以根据目标媒体资源的缓存进度继续将目标媒体资源从服务端设备缓存至客户端设备。

步骤S110，本地媒体服务将第二地址发送给应用程序，应用程序接收第二地址。

步骤S111，应用程序向第二地址发送第三播放请求。

其中，第三播放请求可以是用户希望继续播放媒体资源的请求。

步骤S112，本地媒体服务在接收到第三播放请求时，将缓存的目标媒体资源发送给应用程序进行播放。

具体实现中，步骤S112可以由本地媒体服务的虚拟服务器执行。虚拟服务器例如可以是HTTP虚拟服务器。虚拟服务器可以针本地IP地址和第二端口创建服务套接字ServerSocket，通过ServerSocket监听在本地IP地址的第二端口接收到的HTTP请求，如果监听到第三播放请求，则将缓存的目标媒体资源发送给应用程序进行播放。

图12是本申请实施例示出的另一种媒体播放方法的流程图。该方法可以适用于本地媒体服务已经将目标媒体资源缓存到了本地的情况。

在一种实现方式中，如图12所示，该方法可以包括以下步骤201-S203：

步骤S201，应用程序向第一地址发送第一播放请求。

步骤S202，本地媒体服务响应于第一播放请求，将第三地址发送给应用程序。

其中，第三地址可以是目标媒体资源在本地缓存的文件路径。

下面对第一地址和第三地址的区别进行说明：第一地址是一个本地URL地址，由本地IP地址和端口http://127.0.0.1:xx以及目标媒体资源在客户端设备中缓存的文件路径y组成；与第一地址有所不同，在目标媒体资源完成缓存之后，本地媒体服务不需要再从服务端设备传输数据，目标媒体资源就不需要再被HTTP虚拟服务器占用，那么目标媒体资源就可以不再使用URL地址，因此，第三地址直接可以是目标媒体资源在客户端设备中缓存的文件路径y。

示例地，y可以是以下形式：Storage(客户端设备的根目录)/Movies/ShareMedia/1.mov。

步骤S203，应用程序从第三地址读取目标媒体资源以播放。

应用程序可以访问位于第三地址的目标媒体资源文件，例如1.mov，并播放该文件，这一过程就和应用程序播放本地媒体一样，不涉及流传输过程。

在另一种实现方式中，如图12所示，该方法可以包括以下步骤201、S204-S207：

步骤S201，应用程序向第一地址发送第一播放请求。

步骤S204，本地媒体服务设置第四地址。

其中，第二地址可以是客户端设备的用于访问缓存的目标媒体资源的地址，第四地址与第一地址和第二地址可以相同也可以不同。当第一地址、第二地址和第四地址均是HTTP地址时，第一地址、第二地址和第四地址的区别可以仅在于端口不同，例如：第一地址可以包括本地IP地址和第一端口，第二地址可以包括本地IP地址和第二端口、第四地址可以包括本地IP地址和第四端口。

步骤S205，本地媒体服务将第四地址发送给应用程序，应用程序接收第四地址。

步骤S206，应用程序向第四地址发送第四播放请求。

其中，第四播放请求可以是用户希望继续播放媒体资源的请求。

步骤S207，本地媒体服务在接收到第三四播放请求时，将缓存的目标媒体资源发送给应用程序进行播放。

具体实现中，步骤S207可以由本地媒体服务的虚拟服务器执行。虚拟服务器例如可以是HTTP虚拟服务器。虚拟服务器可以针本地IP地址和第四端口创建服务套接字ServerSocket，通过ServerSocket监听在本地IP地址的第四端口接收到的HTTP请求，如果监听到第四播放请求，则将缓存的目标媒体资源发送给应用程序进行播放。

图13是本申请实施例示出本地媒体服务在开始播放场景的完整处理流程图。如图13所示，该完整处理流程例如可以包括以下步骤：

步骤S301，应用程序向本地媒体服务发送申请目标媒体资源对应的媒体流资源的请求。

在一种实现方式中，当应用程序检测到用户在媒体资源页面点击了目标媒体资源的图标时，应用程序会向本地媒体服务发送播放请求，该请求即为申请媒体流资源的请求。

在一种实现方式中，当应用程序检测到用户在目标媒体资源播放暂停状态点击继续播放按钮时，应用程序会向本地媒体服务发送继续播放请求，该请求即为申请媒体流资源的请求。

步骤S302，本地媒体服务根据应用程序的请求获取目标媒体资源的缓存状态。

根据缓存状态的不同，本地媒体服务接下来可以执行不同处理流程。

在“未启动缓存传输”的状态下，本地媒体服务可以执行以下步骤：

步骤S303a，本地媒体服务获取目标媒体资源在服务端设备中的存储位置。

步骤S303b，本地媒体服务启动跨设备传输流程，缓存目标媒体资源。

在目标媒体资源的跨设备传输过程中，本地媒体服务负责实时更新和管理在客户端设备中缓存的目标媒体资源的各个文件片段。

步骤S303c，本地媒体服务基于缓存的目标媒体资源生成媒体流数据，发送给客户端设备进行播放。

在“缓存传输挂起”的状态下，本地媒体服务可以执行以下步骤：

步骤S304a，本地媒体服务解除缓存传输挂起状态，继续缓存目标媒体资源。

具体实现中，本地媒体服务可以根据目标媒体资源的缓存进度，以增量传输的方式接续缓存目标媒体资源，从而避免已缓存的目标媒体资源被重复传输。在目标媒体资源的跨设备传输过程中，本地媒体服务负责实时更新和管理在客户端设备中缓存的目标媒体资源的各个文件片段。

步骤S304b，本地媒体服务基于缓存的目标媒体资源生成媒体流数据，发送给客户端设备进行播放。

其中，如果步骤S301用户在目标媒体资源播放暂停状态点击继续播放按钮时触发的，那么本地媒体服务可以根据目标媒体资源之前的播放进度选择相应时间的文件片段生成媒体流。例如，当目标媒体资源上一次播放到10分20秒时，如果用户点击了“继续播放”，则本地媒体服务可以从10分20秒对应的文件片段开始生成媒体流。

在一些实现方式中，应用程序允许用户在非第一次播放目标媒体资源时选择是“从上次播放的进度继续播放”还是“从头播放”。如果用户选择的是“从上次播放的进度继续播放”，则本地媒体服务可以立即开始从服务端设备接续缓存目标媒体资源，并且根据目标媒体资源之前的播放进度选择相应时间的文件片段生成媒体流。如果用户选择的是“从头播放”则本地媒体服务可以先不从服务端设备接续缓存目标媒体资源，而是从头开始生成目标媒体资源的媒体流，等到buffer health不足时，再开始接续缓存目标媒体资源。

在“缓存传输进行中”的状态下，本地媒体服务可以维持当前的缓存传输动作，并且基于已缓存的目标媒体资源生成媒体流数据，发送给客户端设备进行播放。

在“缓存传输完成”的状态下，本地媒体服务可以直接基于已缓存的目标媒体资源生成媒体流数据，发送给客户端设备进行播放，不需要再重新从服务端设备缓存目标媒体资源。

根据上述方案，在“开始播放”场景中，本地媒体服务可以根据目标媒体资源的不同缓存状态执行不同的处理流程，以实现目标媒体资源的跨设备增量传输和接续缓存，避免重复传输，减小设备间传输带宽的占用，减小客户端设备存储空间的占用。

接下来，以“终止播放”场景为例，目标媒体资源的缓存状态同样可以包括“未启动缓存传输”、“缓存传输挂起”、“缓存传输进行中”、“缓存传输完成”。

图14是本申请实施例示出本地媒体服务在终止播放场景的处理流程图。如图14所示，该处理流程例如可以包括以下步骤：

步骤S401，应用程序向本地媒体服务发送终止播放请求。

在一种实现方式中，当应用程序检测到用户点击停止播放按钮、暂停播放按钮或者关闭播放界面时，应用程序会向本地媒体服务发送终止播放请求。

步骤S402，本地媒体服务根据应用程序的请求获取目标媒体资源的缓存状态。

根据缓存状态的不同，本地媒体服务接下来可以执行不同处理流程。

在“未启动缓存传输”和“缓存传输挂起”的状态下，本地媒体服务可以执行以下步骤：

步骤S403，本地媒体服务释放为跨设备传输流程预申请的资源。

这些资源例如包括：为缓存目标媒体资源预分配的存储空间、为传输目标媒体资源预分配的网络资源，为本地媒体服务相关进程预分配的处理器资源等。

在“缓存传输进行中”的状态下，本地媒体服务可以执行以下步骤：

步骤S404，本地媒体服务将缓存状态更新为“缓存传输挂起”状态。

在“缓存传输完成”的状态下，本地媒体服务可以执行以下步骤：

步骤S405，本地媒体服务清除目标媒体资源的缓存使用标志。

其中，缓存使用标志可以用于标识目标媒体资源的缓存状态，当用户停止播放并且缓存传输完成时，可以清除缓存使用标志，这时，本地媒体服务可以将目标媒体资源的各个文件片段合并成完整的媒体文件，供应用程序后续进行本地播放。

根据上述方案，在“终止播放”场景中，本地媒体服务可以根据目标媒体资源的不同缓存状态执行不同的处理流程，例如改变缓存状态以利于用户后续执行其他播放动作，或者清除缓存使用标志以利于应用程序后续进行本地播放等。

可以理解的是，本申请实施例提供的技术方案除了用于实现媒体资源的跨设备实时传输和播放以外，还可以用于分布式场景中的其他任一数据的跨设备传输，例如分布式文件协作编辑、分布式文件存储等，本申请实施例对此不做限定。

本申请以上实施例提供的媒体播放方法在客户端构建了本地媒体服务，通过本地媒体服务将媒体资源的缓存和媒体流播放的过程解耦，使得服务端设备不需要再部署流媒体服务，不参与感知播放过程，降低了对服务端设备的能力要求，从而实现了瘦设备间的媒体跨设备实时播放。然而，可以理解的是，为实现与上述实施例相同的技术效果，本地媒体服务也可以构建在服务端设备与客户端设备链路之间的其他设备之上，例如构建在无线接入点中。

图15是本申请实施例提供的另一种媒体播放方法的硬件架构图。如图15所示，客户端设备61与服务端设备62通过路由器63位于同一局域网内。本地媒体服务可以构建路由器63中，对应一个局域网地址。

当客户端设备61的应用程序检测到用于想要播放目标媒体资源时，应用程序可以向本地媒体服务的局域网地址发送包含第一标识的第一播放请求。

接下来，位于路由器63中的本地媒体服务响应于第一播放请求为第一标识关联第一地址，这时，第一地址可以是一个局域网地址，例如http://192.168.1.101:xx/y，其中，xx表示端口、y表示目标媒体资源将要在路由器中缓存的文件路径，在一种实现方式中，路由器为了实现缓存媒体的能力，可以包括内置的或者外接的存储器64，路由器63可以为该存储器64分配一个局域网IP地址，例如192.168.1.101，由此可见第一地址是可以根据存储器64的局域网IP地址确定的。

接下来，路由器63的本地媒体服务将第一地址发送给客户端设备61的应用程序，并且，启动将目标媒体资源缓存第一地址的流程。

接下来，客户端设备61的应用程序可以将第一地址发送第二播放请求，当路由器63的本地媒体服务接收到第二播放请求时，基于缓存的目标媒体资源生成媒体流，发送给客户端设备61的应用程序进行播放。

图15示出的媒体播放方法，将本地媒体服务配置在路由器中，与客户端设备分离。这样，客户端设备不再执行缓存媒体资源和生成媒体流的流程，进一步降低了对客户端设备的能力要求。另外，由于路由器一般支持与多个客户端设备进行数据传输，因此，该方法可以实现多个客户端设备同时跨设备播放同一个服务端设备的媒体资源，例如当路由器与大屏显示设备和多个音响设备连接时，路由器的本地媒体服务可以将图像流发送给大屏显示设备进行显示，将音频流按照声道不同发送给不同的音响设备，实现立体声的播放效果。

上述本申请提供的实施例中，分别从客户端设备本身、以及从客户端设备与服务端设备之间交互的角度对本申请提供的媒体播放方法的各方案进行了介绍。可以理解的是，各个设备，例如上述客户端设备和接入点设备为了实现上述功能，其包含了执行各个功能相应的硬件结构和/或软件模块。本领域技术人员应该很容易意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，本申请能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

图16是本申请实施例提供的一种媒体播放装置的结构示意图。在一个实施例中，客户端设备可以通过图16所示的软件装置实现相应的功能。如图16所示，该媒体播放装置可以包括：本地媒体服务模块和应用模块。

其中，本地服务模块可以包括：虚拟服务器701，用于接收客户端设备上的应用程序的第一播放请求，第一播放请求包括第一标识，第一标识对应服务端设备中的目标媒体资源；虚拟服务器701，还用于根据第一标识确定是否已启动目标媒体资源的缓存传输流程；文件缓存单元702，用于如果未启动缓存传输流程，启动缓存传输流程以将目标媒体资源从服务端设备缓存至客户端设备；虚拟服务器701，还用于将第一地址发送给应用程序，第一地址为客户端设备的用于访问缓存的目标媒体资源的本地统一资源定位符URL地址；虚拟服务器701，还用于在接收到应用程序向第一地址发送的第二播放请求时，将缓存的目标媒体资源发送给应用程序进行播放。

在一种实现方式中，文件缓存单元702，还用于如果已启动缓存传输流程，但是缓存传输流程被挂起，继续缓存传输流程以根据目标媒体资源的缓存进度继续将目标媒体资源从服务端设备缓存至客户端设备；虚拟服务器701，还用于将第二地址发送给应用程序，第二地址为客户端设备的用于访问缓存的目标媒体资源的本地URL地址；虚拟服务器701，还用于在接收到应用程序向第二地址发送的第三播放请求时，将缓存的目标媒体资源发送给应用程序进行播放。

在一种实现方式中，虚拟服务器701，还用于如果目标媒体资源已经完全缓存至客户端设备，将第三地址发送给应用程序，以使应用程序从第三地址获取目标媒体资源进行播放，第三地址为目标媒体资源在客户端设备中缓存的文件路径。

在一种实现方式中，虚拟服务器701，还用于如果目标媒体资源已经完全缓存至客户端设备，将第四地址发送给应用程序，第四地址为客户端设备的用于访问缓存的目标媒体资源的本地URL地址；虚拟服务器701，还用于在接收到应用程序向第四地址发送的第四播放请求时，将缓存的目标媒体资源发送给应用程序进行播放。

在一种实现方式中，第一地址包括客户端设备的本地网际协议IP地址和第一端口；第二播放请求为超文本传输协议HTTP请求。

在一种实现方式中，虚拟服务器701用于在接收到应用程序向第一地址发送的第二播放请求时，将缓存的目标媒体资源发送给应用程序时，包括：虚拟服务器701，用于监听本地IP地址的第一端口；虚拟服务器701，还用于在监听到第二播放请求时，生成第一应答消息，第一应答消息为HTTP应答消息，第一应答消息包括根据已缓存的目标媒体资源生成的媒体流。

在一种实现方式中，虚拟服务器701，还用于在接收到应用程序的停止播放请求时，如果正在进行缓存传输流程，将缓存传输流程挂起，以及记录目标媒体资源的缓存进度。

其中，应用模块可以包括：第一发送单元703，用于向客户端设备上的媒体代理服务发送第一播放请求，第一播放请求包括第一标识，第一标识对应服务端设备中的目标媒体资源；地址接收单元704，用于接收媒体代理服务发送的目标地址；第二发送单元705，用于如果目标地址是客户端设备的本地URL地址，向本地URL地址发送第二播放请求；播放单元706，用于接收媒体代理服务响应于第二播放请求发送的目标媒体资源并进行播放，目标媒体资源由媒体代理服务从服务端设备缓存至客户端设备。

在一种实现方式中，播放单元706，还用于如果目标地址是客户端设备中的文件路径地址，从文件路径地址获取目标媒体资源进行播放。

在一种实现方式中，本地URL地址包括客户端设备的本地IP地址和第一端口；第二播放请求为超文本传输协议HTTP请求。

在一种实现方式中，第二发送单元705用于向本地URL地址发送第二播放请求，包括：向本地IP地址的第一端口发送第二播放请求。

在一种实现方式中，播放单元706用于接收媒体代理服务响应于第二播放请求发送的目标媒体资源，包括：接收媒体代理服务响应于第二播放请求发送的第一应答消息，第一应答消息为HTTP应答消息，第一应答消息包括媒体代理服务根据已缓存的目标媒体资源生成的媒体流。

本申请实施例还提供一种计算机可读存储介质，该计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机执行上述各方面的方法。

本申请实施例还提供了一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行上述各方面的方法。

本申请实施例还提供了一种芯片系统，图17为该芯片系统的结构示意图。该芯片系统包括处理器801，用于支持上述装置实现上述方面中所涉及的功能，例如，生成或处理上述方法中所涉及的信息。在一种可能的设计中，芯片系统还包括存储器802，用于保存长连接装置必要的计算机指令803和数据。该芯片系统，可以由芯片构成，也可以包含芯片和其他分立器件。

以上的具体实施方式，对本申请实施例的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上仅为本申请实施例的具体实施方式而已，并不用于限定本申请实施例的保护范围，凡在本申请实施例的技术方案的基础之上，所做的任何修改、等同替换、改进等，均应包括在本申请实施例的保护范围之内。

Claims (25)

1.一种媒体播放方法，其特征在于，包括：

客户端设备上的媒体代理服务接收所述客户端设备上的应用程序的第一播放请求，所述第一播放请求包括第一标识，所述第一标识对应服务端设备中的目标媒体资源；

所述媒体代理服务根据所述第一标识确定是否已启动所述目标媒体资源的缓存传输流程；

如果未启动所述缓存传输流程，所述媒体代理服务启动所述缓存传输流程以将所述目标媒体资源从所述服务端设备缓存至所述客户端设备，并将第一地址发送给所述应用程序，所述第一地址为所述客户端设备的用于访问缓存的所述目标媒体资源的本地统一资源定位符URL地址；

所述媒体代理服务在接收到所述应用程序向所述第一地址发送的第二播放请求时，将缓存的所述目标媒体资源发送给所述应用程序进行播放。

2.根据权利要求1所述的方法，其特征在于，所述媒体代理服务确定是否已启动所述目标媒体资源的缓存传输流程之后，还包括：

如果已启动所述缓存传输流程，但是所述缓存传输流程被挂起，所述媒体代理服务继续所述缓存传输流程以根据所述目标媒体资源的缓存进度继续将所述目标媒体资源从所述服务端设备缓存至所述客户端设备，并将第二地址发送给所述应用程序，所述第二地址为所述客户端设备的用于访问缓存的所述目标媒体资源的本地URL地址；

所述媒体代理服务在接收到所述应用程序向所述第二地址发送的第三播放请求时，将缓存的所述目标媒体资源发送给所述应用程序进行播放。

3.根据权利要求1或2所述的方法，其特征在于，所述媒体代理服务确定是否已启动所述目标媒体资源的缓存传输流程之后，还包括：

如果所述目标媒体资源已经完全缓存至所述客户端设备，所述媒体代理服务将第三地址发送给所述应用程序，以使所述应用程序从所述第三地址获取所述目标媒体资源进行播放，所述第三地址为所述目标媒体资源在所述客户端设备中缓存的文件路径。

4.根据权利要求1或2所述的方法，其特征在于，所述媒体代理服务确定是否已启动所述目标媒体资源的缓存传输流程之后，还包括：

如果所述目标媒体资源已经完全缓存至所述客户端设备，所述媒体代理服务将所述第四地址发送给所述应用程序，所述第四地址为所述客户端设备的用于访问缓存的所述目标媒体资源的本地URL地址；

所述媒体代理服务在接收到所述应用程序向所述第四地址发送的第四播放请求时，将缓存的所述目标媒体资源发送给所述应用程序进行播放。

5.根据权利要求1所述的方法，其特征在于，

所述第一地址包括所述客户端设备的本地网际协议IP地址和第一端口；

所述第二播放请求为超文本传输协议HTTP请求。

6.根据权利要求5所述的方法，其特征在于，所述媒体代理服务在接收到所述应用程序向所述第一地址发送的第二播放请求时，将缓存的所述目标媒体资源发送给所述应用程序，包括：

所述媒体代理服务监听所述本地IP地址的所述第一端口；

所述媒体代理服务在监听到所述第二播放请求时，生成第一应答消息，所述第一应答消息为HTTP应答消息，所述第一应答消息包括根据已缓存的所述目标媒体资源生成的媒体流。

7.根据权利要求1或2所述的方法，其特征在于，还包括：

所述媒体代理服务在接收到所述应用程序的停止播放请求时，如果正在进行所述缓存传输流程，将缓存传输流程挂起，以及记录所述目标媒体资源的缓存进度。

8.一种媒体播放方法，其特征在于，

客户端设备上的应用程序向所述客户端设备上的媒体代理服务发送第一播放请求，所述第一播放请求包括第一标识，所述第一标识对应服务端设备中的目标媒体资源；

所述应用程序接收所述媒体代理服务发送的目标地址；

如果所述目标地址是所述客户端设备的本地URL地址，所述应用程序向所述本地URL地址发送第二播放请求；

所述应用程序接收所述媒体代理服务响应于所述第二播放请求发送的所述目标媒体资源并进行播放，所述目标媒体资源由所述媒体代理服务从所述服务端设备缓存至所述客户端设备。

9.根据权利要求8所述的方法，其特征在于，所述应用程序接收所述媒体代理服务发送的目标地址之后，还包括：

如果所述目标地址是所述客户端设备中的文件路径地址，所述应用程序从所述文件路径地址获取所述目标媒体资源进行播放。

10.根据权利要求8所述的方法，其特征在于，

所述本地URL地址包括所述客户端设备的本地IP地址和第一端口；

所述第二播放请求为超文本传输协议HTTP请求。

11.根据权利要求10所述的方法，其特征在于，所述应用程序向所述本地URL地址发送第二播放请求，包括：

所述应用程序向所述本地IP地址的所述第一端口发送所述第二播放请求。

12.根据权利要求10或11所述的方法，其特征在于，所述应用程序接收所述媒体代理服务响应于所述第二播放请求发送的所述目标媒体资源，包括：

所述应用程序接收所述媒体代理服务响应于所述第二播放请求发送的第一应答消息，所述第一应答消息为HTTP应答消息，所述第一应答消息包括所述媒体代理服务根据已缓存的所述目标媒体资源生成的媒体流。

13.一种媒体播放装置，其特征在于，包括：

虚拟服务器，用于接收所述客户端设备上的应用程序的第一播放请求，所述第一播放请求包括第一标识，所述第一标识对应服务端设备中的目标媒体资源；

所述虚拟服务器，还用于根据所述第一标识确定是否已启动所述目标媒体资源的缓存传输流程；

文件缓存单元，用于如果未启动所述缓存传输流程，启动所述缓存传输流程以将所述目标媒体资源从所述服务端设备缓存至所述客户端设备；

所述虚拟服务器，还用于将第一地址发送给所述应用程序，所述第一地址为所述客户端设备的用于访问缓存的所述目标媒体资源的本地统一资源定位符URL地址；

所述虚拟服务器，还用于在接收到所述应用程序向所述第一地址发送的第二播放请求时，将缓存的所述目标媒体资源发送给所述应用程序进行播放。

14.根据权利要求13所述的装置，其特征在于，

所述文件缓存单元，还用于如果已启动所述缓存传输流程，但是所述缓存传输流程被挂起，继续所述缓存传输流程以根据所述目标媒体资源的缓存进度继续将所述目标媒体资源从所述服务端设备缓存至所述客户端设备；

所述虚拟服务器，还用于将第二地址发送给所述应用程序，所述第二地址为所述客户端设备的用于访问缓存的所述目标媒体资源的本地URL地址；

所述虚拟服务器，还用于在接收到所述应用程序向所述第二地址发送的第三播放请求时，将缓存的所述目标媒体资源发送给所述应用程序进行播放。

15.根据权利要求13或14所述的装置，其特征在于，

所述虚拟服务器，还用于如果所述目标媒体资源已经完全缓存至所述客户端设备，将第三地址发送给所述应用程序，以使所述应用程序从所述第三地址获取所述目标媒体资源进行播放，所述第三地址为所述目标媒体资源在所述客户端设备中缓存的文件路径。

16.根据权利要求13或14所述的装置，其特征在于，

所述虚拟服务器，还用于如果所述目标媒体资源已经完全缓存至所述客户端设备，将所述第四地址发送给所述应用程序，所述第四地址为所述客户端设备的用于访问缓存的所述目标媒体资源的本地URL地址；

所述虚拟服务器，还用于在接收到所述应用程序向所述第四地址发送的第四播放请求时，将缓存的所述目标媒体资源发送给所述应用程序进行播放。

17.根据权利要求13所述的装置，其特征在于，

所述第一地址包括所述客户端设备的本地网际协议IP地址和第一端口；

所述第二播放请求为超文本传输协议HTTP请求。

18.根据权利要求17所述的装置，其特征在于，所述虚拟服务器用于在接收到所述应用程序向所述第一地址发送的第二播放请求时，将缓存的所述目标媒体资源发送给所述应用程序时，包括：

所述虚拟服务器，用于监听所述本地IP地址的所述第一端口；

所述虚拟服务器，还用于在监听到所述第二播放请求时，生成第一应答消息，所述第一应答消息为HTTP应答消息，所述第一应答消息包括根据已缓存的所述目标媒体资源生成的媒体流。

19.根据权利要求13或14所述的装置，其特征在于，

所述虚拟服务器，还用于在接收到所述应用程序的停止播放请求时，如果正在进行所述缓存传输流程，将缓存传输流程挂起，以及记录所述目标媒体资源的缓存进度。

20.一种媒体播放装置，其特征在于，包括：

第一发送单元，用于向所述客户端设备上的媒体代理服务发送第一播放请求，所述第一播放请求包括第一标识，所述第一标识对应服务端设备中的目标媒体资源；

地址接收单元，用于接收所述媒体代理服务发送的目标地址；

第二发送单元，用于如果所述目标地址是所述客户端设备的本地URL地址，向所述本地URL地址发送第二播放请求；

播放单元，用于接收所述媒体代理服务响应于所述第二播放请求发送的所述目标媒体资源并进行播放，所述目标媒体资源由所述媒体代理服务从所述服务端设备缓存至所述客户端设备。

21.根据权利要求20所述的装置，其特征在于，

所述播放单元，还用于如果所述目标地址是所述客户端设备中的文件路径地址，从所述文件路径地址获取所述目标媒体资源进行播放。

22.根据权利要求20所述的装置，其特征在于，

所述本地URL地址包括所述客户端设备的本地IP地址和第一端口；

所述第二播放请求为超文本传输协议HTTP请求。

23.根据权利要求22所述的装置，其特征在于，所述第二发送单元用于向所述本地URL地址发送第二播放请求，包括：向所述本地IP地址的所述第一端口发送所述第二播放请求。

24.根据权利要求22或23所述的装置，其特征在于，所述播放单元用于接收所述媒体代理服务响应于所述第二播放请求发送的所述目标媒体资源，包括：接收所述媒体代理服务响应于所述第二播放请求发送的第一应答消息，所述第一应答消息为HTTP应答消息，所述第一应答消息包括所述媒体代理服务根据已缓存的所述目标媒体资源生成的媒体流。

25.一种电子设备，其特征在于，包括：媒体代理服务模块和应用程序模块；

所述媒体代理服务模块，用于执行权利要求1-7任一项所述的方法；

所述应用程序模块，用于执行权利要求8-12任一项所述的方法。

Images