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

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

Info

Publication number
WO2022199484A1
WO2022199484A1 PCT/CN2022/081696 CN2022081696W WO2022199484A1 WO 2022199484 A1 WO2022199484 A1 WO 2022199484A1 CN 2022081696 W CN2022081696 W CN 2022081696W WO 2022199484 A1 WO2022199484 A1 WO 2022199484A1
Authority
WO
WIPO (PCT)
Prior art keywords
address
media
application
media resource
client device
Prior art date
Application number
PCT/CN2022/081696
Other languages
English (en)
French (fr)
Inventor
陈刚
Original Assignee
华为技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Priority to EP22774145.1A priority Critical patent/EP4287586A4/en
Priority to US18/283,374 priority patent/US20240171626A1/en
Publication of WO2022199484A1 publication Critical patent/WO2022199484A1/zh

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/612—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/06—Protocols specially adapted for file transfer, e.g. file transfer protocol [FTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/23406—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving management of server-side video buffer

Definitions

  • the present application relates to the technical field of media playback, and in particular, to a media playback method, apparatus, and electronic device.
  • a client device can be connected to multiple server devices through a network to play media resources in the server device or control the server device.
  • the manner in which the client device plays the media resources in the server device may include local playback and real-time streaming playback.
  • Local playback means that when a user requests to play a media resource, the client device first pulls the complete audio/video file from the server device to the local, and then starts to play. Since the audio/video file is usually large, it can be played from the user's request. It takes a while to complete the pulling of the audio/video files, so the user may feel that the playback is obviously stuck, and real-time playback cannot be achieved, resulting in poor user experience.
  • Real-time streaming playback refers to real-time streaming protocols or screen-casting protocols, such as real-time streaming protocol (RTSP), hypertext transfer protocol (HTTP)-based real-time streaming protocol (HTTP live streaming, HLS), etc., deploy services such as real-time streaming, content distribution and/or encoding and decoding on the server device.
  • RTSP real-time streaming protocol
  • HTTP hypertext transfer protocol
  • HLS real-time streaming protocol
  • the server device sends the media stream to the client device based on the deployed service, and the client device The device plays the media stream while buffering.
  • the real-time streaming playback method needs to deploy services on the server device, so the capability of the server device is relatively high and cannot be implemented in thin devices.
  • the real-time streaming playback method also has certain requirements on the network quality. If the buffering speed of the media stream is too low, the playback will be stuck.
  • Embodiments of the present application provide a media playback method, apparatus, and electronic device, so as to realize cross-device real-time playback of media between thin devices.
  • an embodiment of the present application provides a method for playing media.
  • the method includes: a media proxy service on a client device receives a first play request of an application on the client device, the first play request includes a first identifier, and the first identifier corresponds to a target media resource in the server device; the media proxy The service determines whether the buffer transmission process of the target media resource has been started according to the first identifier; if the buffer transmission process has not been started, the media proxy service starts the buffer transmission process to cache the target media resource from the server device to the client device, and the first The address is sent to the application, and the first address is the local uniform resource locator URL address of the client device used to access the cached target media resource; when the media proxy service receives the second play request sent by the application to the first address , which sends the cached target media resource to the application for playback.
  • the media playback method provided by the embodiments of the present application builds a media proxy service on the client side.
  • the client device can first cache the media resources locally through the media proxy service, so that the application program can cache the media resources locally. You can directly request the media proxy service to obtain and play media resources locally.
  • the server device only needs to provide ordinary file transfer functions to the client device, and does not participate in and perceive the playback process. Therefore, there is no need to deploy playback-related services, which reduces the capability requirements for the server device, thereby realizing the thin device between thin devices. of media is played in real-time across devices.
  • the method further includes: if the buffering transmission process has been started, but the buffering transmission process is suspended, the media proxy service continues the buffering transmission process to The cache progress of the target media resource continues to cache the target media resource from the server device to the client device, and sends the second address to the application, where the second address is the local URL of the client device for accessing the cached target media resource address; when receiving the third play request sent by the application to the second address, the media proxy service sends the cached target media resource to the application for playback. In this way, when the buffered transmission is resumed from the suspended state, the media proxy service can continue to buffer the target media resource by means of incremental transmission without re-buffering.
  • the method further includes: if the target media resource has been completely buffered in the client device, the media proxy service sends the third address to the application program, So that the application program acquires the target media resource from the third address to play, and the third address is the file path of the target media resource cached in the client device.
  • the application program can directly access the locally stored target media resource file for playback, and the media proxy service is no longer required to generate the media stream.
  • the method further includes: if the target media resource has been completely buffered to the client device, the media proxy service sends the fourth address to the application program,
  • the fourth address is the local URL address of the client device for accessing the cached target media resource; when the media proxy service receives the fourth playback request sent by the application to the fourth address, it sends the cached target media resource to the application program to play.
  • the media proxy service can continue to generate the media stream for the application, and the application can receive and play the media stream sent by the media proxy service.
  • the first address includes a local Internet Protocol IP address and a first port of the client device; and the second play request is a hypertext transfer protocol HTTP request.
  • the media proxy service sends the cached target media resource to the application when receiving the second playback request sent by the application to the first address, including: the media proxy service monitors the first address of the local IP address. port; the media proxy service generates a first response message when monitoring the second playback request, the first response message is an HTTP response message, and the first response message includes a media stream generated according to the cached target media resource.
  • the media proxy service monitors the first address of the local IP address. port
  • the media proxy service generates a first response message when monitoring the second playback request, the first response message is an HTTP response message
  • the first response message includes a media stream generated according to the cached target media resource.
  • the method further includes: when the media proxy service receives a stop playing request from the application, if the buffering transmission process is in progress, suspending the buffering transmission process, and recording the buffering progress of the target media resource. In this way, when the user subsequently plays, the media proxy service can continue to perform the buffer transmission process based on the buffer progress.
  • the embodiments of the present application provide a method for playing media.
  • the method includes: an application on a client device sends a first play request to a media proxy service on the client device, the first play request includes a first identifier, and the first identifier corresponds to a target media resource in the server device; the application Receive the target address sent by the media proxy service; if the target address is the local URL address of the client device, the application sends a second play request to the local URL address; the application receives the target media resource sent by the media proxy service in response to the second play request And play, the target media resource is cached by the media proxy service from the server device to the client device.
  • a media proxy service is constructed on the client device.
  • the client device can first cache the media resources locally through the media proxy service, so that the application Programs can directly request the media proxy service to obtain and play media resources locally.
  • the server device only needs to provide ordinary file transfer functions to the client device, and does not participate in and perceive the playback process. Therefore, there is no need to deploy playback-related services, which reduces the capability requirements for the server device, thereby realizing the thin device. of media is played in real-time across devices.
  • the application after receiving the target address sent by the media proxy service, the application further includes: if the target address is a file path address in the client device, the application program obtains the target media resource from the file path address to play. In this way, after the target media resource has been cached locally, the application program can directly access the locally stored target media resource file for playback, and the media proxy service is no longer required to generate the media stream.
  • the local URL address includes the local IP address and the first port of the client device; the second play request is a hypertext transfer protocol HTTP request.
  • the application sending the second play request to the local URL address includes: the application sending the second play request to the first port of the local IP address.
  • receiving the target media resource sent by the media proxy service in response to the second play request includes: the application receiving a first response message sent by the media proxy service in response to the second play request, the first response message For the HTTP response message, the first response message includes the media stream generated by the media proxy service according to the cached target media resource.
  • the HTTP protocol such as transmission of media streams.
  • an embodiment of the present application provides a media player device.
  • the device includes: a virtual server for receiving a first play request of an application program on a client device, the first play request includes a first identifier, and the first identifier corresponds to a target media resource in the server device; the virtual server further uses for determining whether the cache transfer process of the target media resource has been started according to the first identifier; the file cache unit is used to start the cache transfer process if the cache transfer process is not started to cache the target media resource from the server device to the client device; virtual The server is further configured to send the first address to the application program, where the first address is the local Uniform Resource Locator URL address of the client device for accessing the cached target media resource; the virtual server is further configured to receive the application program When a second play request is sent to the first address, the cached target media resource is sent to the application for playing.
  • the file cache unit is further configured to continue the cache transfer process if the cache transfer process has been started but the cache transfer process is suspended, so as to continue to transfer the target media resources from the server device according to the cache progress of the target media resources cache to the client device;
  • the virtual server is also used to send a second address to the application, where the second address is the local URL address of the client device for accessing the cached target media resource;
  • the virtual server is also used to receive When the application sends the third play request to the second address, the cached target media resource is sent to the application for playback.
  • the virtual server is further configured to send the third address to the application if the target media resource has been completely cached in the client device, so that the application obtains the target media resource from the third address for playback, and the first The third address is the file path of the target media resource cached in the client device.
  • the virtual server is further configured to send a fourth address to the application if the target media resource has been completely cached in the client device, where the fourth address is used by the client device to access the cached target media resource
  • the virtual server is further configured to send the cached target media resource to the application for playback when receiving the fourth play request sent by the application to the fourth address.
  • the first address includes a local Internet Protocol IP address and a first port of the client device; and the second play request is a hypertext transfer protocol HTTP request.
  • the virtual server is configured to send the cached target media resource to the application when receiving the second playback request sent by the application to the first address, including: a virtual server, configured to monitor the local IP address The first port of the address; the virtual server is further configured to generate a first response message when monitoring the second playback request, where the first response message is an HTTP response message, and the first response message includes a media stream.
  • the virtual server is further configured to suspend the cache transfer process and record the cache progress of the target media resource if the cache transfer process is in progress when receiving a stop playback request from the application.
  • an embodiment of the present application provides a media player device.
  • the device includes: a first sending unit configured to send a first play request to a media proxy service on a client device, where the first play request includes a first identifier, and the first identifier corresponds to a target media resource in the server device; the address is received unit, for receiving the target address sent by the media proxy service; the second sending unit, for sending the second playback request to the local URL address if the target address is the local URL address of the client device; the playback unit, for receiving the media proxy The service responds to and plays the target media resource sent by the second play request, and the target media resource is cached by the media proxy service from the server device to the client device.
  • the playing unit is further configured to obtain the target media resource from the file path address for playing if the target address is the file path address in the client device.
  • the local URL address includes the local IP address and the first port of the client device; the second play request is a hypertext transfer protocol HTTP request.
  • the second sending unit is configured to send the second play request to the local URL address, including: sending the second play request to the first port of the local IP address.
  • the playing unit is configured to receive the target media resource sent by the media proxy service in response to the second play request, including: receiving a first response message sent by the media proxy service in response to the second play request, the first response message For the HTTP response message, the first response message includes the media stream generated by the media proxy service according to the cached target media resource.
  • an embodiment of the present application provides an electronic device, including: a media proxy service module and an application program module; a media proxy service module for executing the method of the first aspect and its various implementations; an application program module for using Methods for performing the second aspect and implementations thereof.
  • the embodiments of the present application further provide a computer-readable storage medium, where instructions are stored in the computer-readable storage medium, and when the computer-readable storage medium runs on a computer, the computer executes the methods of the above aspects.
  • the embodiments of the present application further provide a computer program product including instructions, which, when executed on a computer, cause the computer to execute the methods of the above aspects.
  • an embodiment of the present application further provides a chip system, where the chip system includes a processor for supporting the foregoing apparatus or system to implement the functions involved in the foregoing aspect, for example, generating or processing the functions involved in the foregoing method. information.
  • Figure 1 is a schematic diagram of the architecture of a current distributed scenario
  • FIG. 2 is a schematic diagram of the architecture of another distributed scenario at present
  • FIG. 3 is a schematic diagram of a user playing a media resource in a server device on a client device according to an embodiment of the present application
  • FIG. 4 is a schematic diagram of a sub-page of a media resource page shown in an embodiment of the present application.
  • FIG. 5 is a schematic diagram of real-time streaming playback based on real-time streaming protocol RTSP;
  • FIG. 6 is a schematic diagram of real-time streaming playback based on the real-time streaming protocol HLS;
  • FIG. 7 is a schematic diagram of a hardware structure of a terminal device provided by an embodiment of the present application.
  • FIG. 8 is a schematic diagram of a software architecture provided by an embodiment of the present application.
  • FIG. 9 is a flowchart of a media playback method provided by an embodiment of the present application.
  • FIG. 10 is a scene diagram of an application generating a first play request shown in an embodiment of the present application
  • FIG. 11 is a scene diagram of an application generating a second play request according to an embodiment of the present application.
  • FIG. 13 is a process flow diagram illustrating a local media service starting to play a scene according to an embodiment of the present application
  • FIG. 14 is a process flow diagram illustrating a local media service terminating a playback scenario according to an embodiment of the present application
  • FIG. 15 is a hardware architecture diagram of another media playback method provided by an embodiment of the present application.
  • 16 is a schematic structural diagram of a media playback device provided by an embodiment of the present application.
  • FIG. 17 is a schematic structural diagram of a chip system provided by an embodiment of the present application.
  • Distributed scenario refers to a scenario in which multiple devices are connected through a network to interact with each other and data, so as to jointly accomplish a task goal.
  • FIG. 1 is a schematic diagram of the architecture of a current distributed scenario.
  • the distributed scenario architecture may include one or more client devices 11 and a server 12 .
  • client devices 11 are connected with a server 12 in a wide area network (WAN).
  • the client device 11 may include, for example, a mobile phone, a notebook computer, a tablet computer, a large-screen display device, a virtual/mixed/augmented reality device, a local server, etc., which is not limited in this embodiment of the present application.
  • the server 12 may include, for example, a media server, an application server, a storage server, a web server, a data center, a content distribution node, etc., which is not limited in this embodiment of the present application.
  • FIG. 2 is a schematic diagram of the architecture of another distributed scenario at present.
  • the distributed field may include multiple terminal devices 21, and the multiple terminal devices 21 may establish connections through a wide area network WAN or a local area network (local area network, LAN).
  • a local area network local area network, LAN
  • multiple terminal devices 21 can access a wireless local area network (Wireless LAN, WLAN) created by a wireless access point (wireless access point, WAP) 22, The mutual data transmission is realized by the forwarding of the wireless access point 22 .
  • WLAN wireless local area network
  • WAP wireless access point
  • the terminal device 21 here may include, for example, a mobile phone, a notebook computer, a tablet computer, a large-screen display device, a virtual/mixed/augmented reality device, a network attached storage (NAS), a router with a storage function, etc., wherein, A router can act as a wireless access point in this distributed scenario.
  • a mobile phone for example, a mobile phone, a notebook computer, a tablet computer, a large-screen display device, a virtual/mixed/augmented reality device, a network attached storage (NAS), a router with a storage function, etc.
  • NAS network attached storage
  • the distributed scene can be used to implement the function of playing media objects across devices, that is, one device plays the media resources in another device.
  • the device that plays media resources is referred to as a client device
  • the device that provides media content is referred to as a server device.
  • the manner in which the client device plays the media content may generally include local playback and real-time streaming playback.
  • local playback means that when a user requests to play a media resource, the client device first pulls the complete media file from the server device to the local, and then starts playing; screen protocol, deploy services such as real-time streaming, content distribution and/or codec on the server device.
  • the server device sends the media stream to the client device based on the deployed service, and the client device Play the media stream while buffering.
  • FIG. 3 is a schematic diagram illustrating a user performing a gesture operation in a client device to play a media resource in a server device according to an embodiment of the present application.
  • the user can operate the client device 30 to enter a distributed portal interface 31 corresponding to media playback provided by the client device 30
  • the interface can include, for example, a server device list 32
  • the server device list 32 can include Information 33 of some or all of the server devices in the distributed scenario.
  • the information 33 of the server device may include, for example, one or more of the following information: device model (such as Mate 30pro, Huawei smart screen, etc.), device name (user-defined name, such as Huawei's Huawei mobile phone, etc.) ), device type (eg: mobile phone, tablet computer, notebook, large-screen display device), device status (online/offline), device occupancy status (for example, whether it is occupied by other user devices, etc.).
  • device model such as Mate 30pro, Huawei smart screen, etc.
  • device name user-defined name, such as Huawei mobile phone, etc.
  • device type eg: mobile phone, tablet computer, notebook, large-screen display device
  • device status online/offline
  • device occupancy status for example, whether it is occupied by other
  • the client device 31 can display the media resource page 34 of the server device.
  • the media resource page 34 may display media files stored in the server device in the form of icons and/or texts, wherein the icons may be, for example, thumbnails of videos or pictures, and the texts may be, for example, the names of the media files.
  • the media resource page 34 may include multiple layers of pages.
  • the media resource page may present a first-level page 35 that includes at least one folder 36, and presents the name of each folder and the content contained in each folder. number of files.
  • Folder 36 may serve as an icon with thumbnails of one or more files it contains.
  • the media resource page 34 when the media resource page 34 is implemented, it may include fewer layers of pages (for example, only the first layer page 35 or only the second layer page 37 ), or may include more layers of pages.
  • the storage path of the file in the server device is determined, which is not limited in this embodiment of the present application.
  • the user can click 43 the icon 38 of any media file to request to play, and a file transfer can be established between the client device and the server device, and the media file in the server device is transferred to the client device.
  • the client device starts playing the media file after receiving the complete media file.
  • the access and transmission process of the media files may be implemented through a file transfer protocol (FTP) service, a Web-based distributed authoring and version control (WebDAV) service, and the like, which is not limited in this embodiment of the present application.
  • FTP file transfer protocol
  • WebDAV Web-based distributed authoring and version control
  • local playback is similar to downloading media resources from the network and then playing them. It is necessary to pull the media files from the server device to the client device before playing. Therefore, the media files are played from the user request. There will be a certain delay in starting playback, which will cause users to feel stuck in the experience. This delay is usually determined according to the file transfer speed and the size of the media file. For example, if the media file is a movie, the transfer time may be as long as tens of seconds, which seriously affects the user experience.
  • the media resource page 34 may also include multiple sub-pages, and each sub-page corresponds to a type. Switch between different sub-pages by manually operating 44 or clicking 45 on the name of the sub-page.
  • the foregoing multiple types may include, for example, pictures, videos, audios, documents, others, recent, etc., which are not limited in this embodiment of the present application.
  • FIG. 5 is a schematic diagram of real-time streaming playback based on the real-time streaming protocol RTSP.
  • the real-time streaming protocol RTSP is a network application protocol designed for use in entertainment and communication systems to control servers. This protocol is used to create and control media sessions between terminals.
  • the client connected to the server can issue commands, such as play, record and pause, in order to control the media stream from server to client or from client to server in real time.
  • the real-time streaming playback based on the real-time streaming protocol RTSP can be implemented through the following steps:
  • Step S1 the OPTIONS request process. Specifically include:
  • Step S11 the client sends an OPTIONS request message (OPTIONS request) to the server to request a request type acceptable to the server.
  • OTIONS request an OPTIONS request message
  • Step S12 the server sends an OPTIONS response message (OPTIONS response) to the client to send all the request types that it can accept to the client.
  • OTIONS response an OPTIONS response message
  • Step S2 the DESCRIBE request process. Specifically include:
  • Step S21 the client sends a DESCRIBE request message (DESCRIBE request) to the server to request to obtain media initialization description information from the server.
  • DESCRIBE request a DESCRIBE request message
  • Step S22 the server sends a DESCRIBE response message (DESCRIBE response) to the client to send the media initialization description information to the client.
  • DESCRIBE response DESCRIBE response message
  • Step S3, SETUP request flow Specifically include:
  • Step S31 the client sends a SETUP request message (SETUP request) to the server to set the attributes and transmission mode of the media session, and remind the server to establish a session.
  • SETUP request a SETUP request message
  • Step S32 the server establishes a session, and sends a SETUP response message (SETUP response) to the client, so as to send the session identifier and related information to the client.
  • SETUP response SETUP response
  • Step S4 PLAY play request process. Specifically include:
  • Step S41 the client sends a play request message (PLAY request) to the server to request to play the media resource.
  • PLAY request a play request message
  • Step S42 the server sends streaming media data (PLAY response) to the client in response to the PLAY request.
  • Step S5 TEARDOWN request flow. Specifically include:
  • Step S51 the client sends a TEARDOWN request message (TEARDOWN request) to the server to request to close the media session.
  • TEARDOWN request a TEARDOWN request message
  • Step S52 the server closes the session (TEARDOWN response) in response to the TEARDOWN request.
  • RTSP real-time streaming playback based on RTSP involves a large number of interactive processes and requires high device resources; in addition, RTSP requires the deployment of RTSP services in server devices.
  • RTSP requires the deployment of RTSP services in server devices.
  • RTSP-based real-time streaming playback is difficult to implement in the scenario shown in Figure 2; in addition, RTSP streaming media Transmission and playback are performed at the same time, so the smoothness of playback depends on the quality of the network. When the quality of the network is poor, playback may become stuttered.
  • FIG. 6 is a schematic diagram of real-time streaming playback based on the real-time streaming protocol HLS.
  • HLS is a streaming media network transmission protocol based on the hypertext transfer protocol (HTTP). It works by dividing the entire stream into small HTTP-based files to download, a few at a time. When streaming media is playing, the client can choose to download the same resource at different rates from many different alternate sources, allowing the streaming session to adapt to different data rates.
  • HTTP hypertext transfer protocol
  • the HLS in addition to the server and the client, the HLS also needs to include a content distribution end, Distribution.
  • the specific process of HLS implementing real-time streaming playback may include:
  • the server obtains the media resources, encodes the media resources to obtain the media stream, and then divides the media stream through the stream splitter to obtain multiple small video files (.ts), and generates the corresponding video files.
  • Playlist file (Index file), and finally send the obtained video file (.ts) and playlist file to the content distribution end.
  • the content distribution end is used to store video files (.ts), and can send the playlist file (Index file) to the client; the client can obtain each video according to the list file (Index file) The address where the file (.ts) is stored on the content distribution side, and then the video file (.ts) is obtained and played based on these addresses.
  • the real-time streaming playback based on HLS requires the deployment of file segmentation services and content distribution services in the server device, which requires high device resources and is also difficult to implement in the scenario shown in Figure 2; in addition, HLS streaming media Transmission and playback are also performed at the same time, so the smoothness of playback depends on the quality of the network. When the quality of the network is poor, the playback may also experience stuttering.
  • an embodiment of the present application provides a media playback method.
  • the method provided in this embodiment of the present application can be applied to the distributed scenario shown in FIG. 1 or FIG. 2 , and preferably can be applied to the distributed scenario provided by FIG. 2 and composed of thin devices.
  • FIG. 7 is a schematic diagram of a hardware structure of a terminal device provided by an embodiment of the present application.
  • the terminal device 100 may include a processor 110, a memory 120, a universal serial bus (USB) interface 130, a radio frequency circuit 140, a mobile communication module 150, a wireless communication module 160, a camera 170, a display A screen 180, a touch sensor 190, an air pressure sensor 210, a key 220, and the like.
  • USB universal serial bus
  • the processor 110 may include one or more processing units, for example, the processor 110 may include an application processor (application processor, AP), a modem processor, a graphics processor (graphics processing unit, GPU), an image signal processor (image signal processor, ISP), video codec, digital signal processor (digital signal processor, DSP), baseband processor, and/or neural-network processing unit (neural-network processing unit, NPU), etc. Wherein, different processing units may be independent devices, or may be integrated in one or more processors, such as integrated in a system on a chip (system on a chip, SoC).
  • a memory may also be provided in the processor 110 for storing instructions and data. In some embodiments, the memory in processor 110 is cache memory. This memory may hold instructions or data that have just been used or recycled by the processor 110 .
  • the processor 110 may include one or more interfaces.
  • the interface may include an integrated circuit (inter-integrated circuit, I2C) interface, an integrated circuit built-in audio (inter-integrated circuit sound, I2S) interface, a pulse code modulation (pulse code modulation, PCM) interface, a universal asynchronous transceiver (universal asynchronous transmitter) receiver/transmitter, UART) interface, mobile industry processor interface (MIPI), general-purpose input/output (GPIO) interface, subscriber identity module (SIM) interface, and / or universal serial bus (universal serial bus, USB) interface, etc.
  • I2C integrated circuit
  • I2S integrated circuit built-in audio
  • PCM pulse code modulation
  • PCM pulse code modulation
  • UART universal asynchronous transceiver
  • MIPI mobile industry processor interface
  • GPIO general-purpose input/output
  • SIM subscriber identity module
  • USB universal serial bus
  • Memory 120 may be used to store computer-executable program code, which includes instructions.
  • the memory 120 may include a stored program area and a stored data area.
  • the storage program area may store an operating system, an application program required for at least one function (such as a sound playback function, an image playback function, etc.), and the like.
  • the storage data area may store data (such as audio data, phone book, etc.) created during the use of the terminal device 100 and the like.
  • the memory 120 may include one or more storage units, for example, may include volatile memory (volatile memory), such as: dynamic random access memory (dynamic random access memory, DRAM), static random access memory (static random access memory) memory, SRAM), etc.; may also include non-volatile memory (non-volatile memory, NVM), such as: read-only memory (read-only memory, ROM), flash memory (flash memory), etc.
  • volatile memory volatile memory
  • DRAM dynamic random access memory
  • static random access memory static random access memory
  • SRAM static random access memory
  • NVM non-volatile memory
  • the processor 110 executes various functional applications and data processing of the terminal device 100 by executing the instructions stored in the memory 120 and/or the instructions stored in the memory provided in the processor.
  • the wireless communication function of the terminal device 100 may be implemented by the radio frequency circuit 140 , the mobile communication module 150 , the wireless communication module 160 , the modulation and demodulation processor, the baseband processor, and the like.
  • the radio frequency circuit 140 may include at least one antenna 141 for transmitting and receiving electromagnetic wave signals.
  • Each antenna in terminal device 100 may be used to cover a single or multiple communication frequency bands.
  • the antenna may be used in conjunction with a tuning switch.
  • the mobile communication module 150 may provide a wireless communication solution including 2G/3G/4G/5G, etc. applied on the terminal device 100 .
  • the mobile communication module 150 may include at least one filter, switch, power amplifier, low noise amplifier (LNA) and the like.
  • the mobile communication module 150 can receive electromagnetic waves through the antenna 141, filter, amplify, etc. the received electromagnetic waves, and transmit them to the modulation and demodulation processor for demodulation.
  • the mobile communication module 150 can also amplify the signal modulated by the modulation and demodulation processor, and then convert it into electromagnetic waves for radiation through the antenna 141 .
  • at least part of the functional modules of the mobile communication module 150 may be provided in the processor 110 .
  • at least part of the functional modules of the mobile communication module 150 may be provided in the same device as at least part of the modules of the processor 110 .
  • the modem processor may include a modulator and a demodulator.
  • the modulator is used to modulate the low frequency baseband signal to be sent into a medium and high frequency signal.
  • the demodulator is used to demodulate the received electromagnetic wave signal into a low frequency baseband signal. Then the demodulator transmits the demodulated low-frequency baseband signal to the baseband processor for processing.
  • the low frequency baseband signal is processed by the baseband processor and passed to the application processor.
  • the application processor outputs sound signals through audio devices (including but not limited to speakers, receivers, etc.), or displays images or videos through the display screen 180 .
  • the modem processor may be a stand-alone device.
  • the modem processor may be independent of the processor 110, and may be provided in the same device as the mobile communication module 150 or other functional modules.
  • the wireless communication module 160 may include a wireless fidelity (Wi-Fi) module, a bluetooth (BT) module, a GNSS module, a near field communication (NFC) module, an infrared (IR) module modules etc.
  • the wireless communication module 160 may be one or more devices integrating at least one of the above modules.
  • the wireless communication module 160 receives electromagnetic waves via the antenna 141 , frequency modulates and filters the electromagnetic wave signals, and sends the processed signals to the processor 110 .
  • the wireless communication module 160 can also receive the signal to be sent from the processor 110 , perform frequency modulation on it, amplify it, and convert it into electromagnetic waves for radiation through the antenna 141 .
  • the wireless communication function of the terminal device 100 may include, for example, a global system for mobile communications (GSM), a general packet radio service (GPRS), a code division multiple access (CDMA) code division multiple access (CDMA), wideband code division multiple access (WCDMA), time-division code division multiple access (TD-SCDMA), long term evolution (LTE) ), 5th generation mobile networks new radio (5G NR), BT, GNSS, WLAN, NFC, FM, and/or IR functions.
  • GSM global system for mobile communications
  • GPRS general packet radio service
  • CDMA code division multiple access
  • CDMA code division multiple access
  • WCDMA wideband code division multiple access
  • TD-SCDMA time-division code division multiple access
  • LTE long term evolution
  • 5G NR 5th generation mobile networks new radio
  • GNSS may include global positioning system (GPS), global navigation satellite system (GLONASS), Beidou navigation satellite system (BDS), quasi-zenith satellite system (quasi-zenith) satellite system, QZSS) and/or satellite based augmentation systems (SBAS).
  • GPS global positioning system
  • GLONASS global navigation satellite system
  • BDS Beidou navigation satellite system
  • QZSS quasi-zenith satellite system
  • SBAS satellite based augmentation systems
  • Camera 170 is used to capture still images or video.
  • the camera 170 includes a lens and a photosensitive element, and the object generates an optical image through the lens and projects to the photosensitive element.
  • the photosensitive element may be a charge coupled device (CCD) or a complementary metal-oxide-semiconductor (CMOS) phototransistor.
  • CMOS complementary metal-oxide-semiconductor
  • the photosensitive element converts the optical signal into an electrical signal, and then transmits the electrical signal to the ISP to convert it into a digital image signal.
  • the ISP outputs the digital image signal to the DSP for processing.
  • DSP converts digital image signals into standard RGB, YUV, RYYB and other formats of image signals.
  • the terminal device 100 may include 1 or N cameras 170 , where N is a positive integer greater than 1.
  • the NPU is a neural-network (NN) computing processor.
  • NN neural-network
  • Applications such as intelligent cognition of the terminal device 100 can be realized through the NPU, for example: image recognition, face recognition, speech recognition, text understanding, etc.
  • the display screen 180 is used to display images, videos, and the like.
  • the display screen 180 includes a display panel.
  • the display panel can be a liquid crystal display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode or an active-matrix organic light-emitting diode (active-matrix organic light).
  • LED diode AMOLED
  • flexible light-emitting diode flexible light-emitting diode (flex light-emitting diode, FLED), MiniLED, MicroLED, Micro-OLED, quantum dot light-emitting diode (quantum dot light emitting diodes, QLED) and so on.
  • the terminal device 100 may include 1 or N display screens 180 , where N is a positive integer greater than 1.
  • the touch sensor 190 is also called "touch device”.
  • the touch sensor 190 may be disposed on the display screen 180 , and the touch sensor 190 and the display screen 180 form a touch screen, which is also referred to as a “touch screen”.
  • the touch sensor 190 is used to detect a touch operation on or near it.
  • the touch sensor can pass the detected touch operation to the application processor to determine the type of touch event.
  • Visual output related to touch operations may be provided through display screen 180 .
  • the touch sensor 190 may also be disposed on the surface of the terminal device 100 , which is different from the position where the display screen 180 is located.
  • the air pressure sensor 210 is used to measure air pressure. In some embodiments, the terminal device 100 calculates the altitude through the air pressure value measured by the air pressure sensor 210 to assist in positioning and navigation.
  • the keys 220 include a power-on key, a volume key, and the like.
  • the keys 220 may be mechanical keys. It can also be a touch key.
  • the terminal device 100 may receive key input and generate key signal input related to user settings and function control of the terminal device 100 .
  • the terminal device 100 may include more or less components than those shown in the drawings, or combine some components, or separate some components, or arrange different components.
  • the illustrated components may be implemented in hardware, software or a combination of software and hardware.
  • any terminal device can be used as a server device or a client device in real-time streaming playback.
  • Whether a terminal device is a server device or a client device depends on whether it is a media resource The provider is also the player. For example: for terminal device A and terminal device B, if terminal device A plays media files in terminal device B across devices, then terminal device A is the client device and terminal device B is the server device; If the device plays the media files in terminal device A, then terminal device B is the client device, and terminal device A is the server device.
  • Each method step of the media playback method provided by the embodiments of the present application may be implemented in a client device and a server device, and is mainly implemented in a client device.
  • the embodiments of the present application also provide a software architecture of a terminal device.
  • the software architecture can be used for the client device and the server device to implement each method step of the media playback method.
  • FIG. 8 is a schematic diagram of a software architecture provided by an embodiment of the present application.
  • the software architecture includes a client part and a server part.
  • the client part may include application programs and local media services (also called media proxy services, local proxy services, etc., which are not limited in this embodiment of the present application), and the server part may include a file management function.
  • the application program may generally be an application program with file browsing and playing functions, such as a file manager application, a player application, or other media applications, which is not limited in this embodiment of the present application.
  • the application may be a system application of the client device or a third-party application, which is not limited in this embodiment of the present application.
  • the local media service is a function module newly added in the client device in the embodiment of the present application.
  • the local media service may consist of, for example, a virtual server, a file caching function, and a file transfer function.
  • the local media service can be regarded as a proxy service set between the application and the server device, which isolates the original streaming media transmission behavior from the server device to the application, and receives and caches the data from the server device. media resources, and provide the application with access to the media resources.
  • the specific functions of the local media service will be further described in the following embodiments.
  • the file management function of the server device is only required to implement conventional file storage and transmission functions, so there is no need to deploy any real-time streaming protocol related services in the server device.
  • FIG. 9 is a flowchart of a media playback method provided by an embodiment of the present application. The method can be applied to a client device having the software architecture shown in FIG. 8 . As shown in Figure 9, the method may include the following steps:
  • Step S101 the local media service acquires media resource information of the server device.
  • the media resource information of the server device may include, for example, the file identifier of the media resource stored by the server device.
  • each media file has a file identifier, and different media files have different file identifiers. Therefore, the file identifier A unique identity that can be used by client devices and server devices to identify a media file.
  • the file identifier may be a file descriptor (FD), which may be in the form of a non-negative integer, and may be generated by the server device when the media file is created, which is not done in this embodiment of the present application. limited.
  • FD file descriptor
  • the file identifier may be a path of a media file, for example, an HTTP path of an audio file in a local area network in a distributed scenario, which is not limited in this embodiment of the present application.
  • file identifier may also include other forms of file identifiers, which will not be repeated here.
  • the media resource information may further include one or more of the file name, file type, file size, thumbnail image, and creation time of each media file.
  • step S101 that is, the action of the local media service to obtain the media resource information of the server device can be triggered in various ways, which is not limited in the embodiment of the present application, as long as it can
  • the media resource information may be acquired before the application program triggers the first application request.
  • the local media service can periodically obtain the media resource information of the server device; or, when the server device detects that the media resource information has changed (for example: adding a file, deleting a file, file attributes changes), actively send the latest media resource information to the local media service; or, the local media service can trigger the behavior of acquiring the media resource information of the server device when the application is started.
  • Step S102 the application sends a first play request to the local media service, where the first play request includes a first identifier.
  • step S102 will be specifically described below with reference to a usage scenario.
  • FIG. 10 is a scene diagram of an application generating a first play request according to an embodiment of the present application.
  • the file management application in the client device is opened, and the “other devices” option is clicked 46 , the file management application can display the server device list 32 to the user.
  • the user wants to access the media resources in a server device, he can click on the server device.
  • the application detects that the user has clicked on a server device, it can obtain this service from the local media service.
  • the media resource information of the terminal device is generated, and the media resource page 35 of the server device is generated according to the media resource information.
  • the target media resource if the user wants to play a certain media resource, hereinafter referred to as the target media resource, he or she can click 48 the icon 39 of the target media resource.
  • the application detects that the user has clicked 48 the icon 39 of the target media resource, it will send a message to the local
  • the media service sends a first play request. It can be understood that the first identifier in the first play request is the media identifier of the target media resource.
  • the application can also generate the first play request in other ways, such as in response to the user's voice input, in response to the remote control input etc., which are not limited in the embodiments of the present application.
  • the communication between the application and the local media service can be achieved through a virtual server in the local media service.
  • the virtual server may be, for example, an HTTP virtual server, so that message and data transmission can be established between the application and the HTTP virtual server based on the HTTP protocol.
  • the HTTP virtual server can listen to the request of the application on the local IP address and specific port.
  • This port can be pre-agreed by the application and the local media service.
  • the local IP address may generally be 127.0.0.1, and the port may be any one or more of 1 to 65536.
  • the port is denoted by xx below.
  • the first play request may be an HTTP request sent to 127.0.0.1:xx. In this way, the local media service can receive the first playback request by monitoring 127.0.0.1:xx.
  • the local media service may first determine whether it has started the buffer transmission process of the target media resource corresponding to the first identifier. If the local media service has not started the buffer transmission process, it means that the application The target media resource has not been played before, and it is the first time that the application sends the first playback request to the local media service. In this case, the local media service and application may perform steps S103-S107.
  • the buffer transmission process is not started means that the local media service does not start the target media resource transmission process from the server device to the client device, and the client device does not locally Cache any file segment of the target media resource. This state generally corresponds to the scenario where the user requests to play the target media resource for the first time.
  • Step S103 the local media service sets the first address.
  • the first address may be an address of the client device used to access the cached target media resource, and may be used by the application to subsequently obtain the media stream corresponding to the target media resource.
  • the first address may be a local Uniform Resource Locator URL address. If the message and data transmission is established between the application and the virtual server based on the HTTP protocol, the first address is still an HTTP address, for example: http://127.0.0.1:xx/y, where y indicates that the target media resource will be stored on the client The file path cached in the end device.
  • Step S104 the local media service starts a buffer transmission process to buffer the target media resources of the server device to the client device.
  • Step S105 the local media service sends the first address to the application, and the application receives the first address.
  • step S105 may be performed by a virtual server of the local media service.
  • the HTTP virtual server may send the application program to the first address through an HTTP protocol message.
  • step S104 and step S105 may be performed synchronously, or step S105 may be performed before step S104, or step S105 may be performed after step S104.
  • the local media service can already start caching the target media resource when sending the first address to the application, but the application has not yet received the user's request to start playing the media resource.
  • the caching process and the playing process of the media resources are independent and decoupled from each other, and the caching process of the media resources may be performed before the playing process.
  • step S105 may be implemented by the file caching function and the file transmission function of the local media service.
  • the file caching function may first obtain the storage location of the target media resource based on the distributed file system formed between the client device and the server device, and the storage location may also be a URL.
  • the local area network IP address of the client device in the distributed scenario is 192.168.1.105
  • the local area network IP address of the server device is 192.168.1.107
  • the target media resources are in the server device.
  • the storage path is a/b/c, then, when the server device and the client device use the ftp protocol (only as an example, other protocols can also be used, which are not limited here) to transmit data, the storage of the target media resource
  • the location can be: ftp://192.168.1.107/a/b/c.
  • the file caching function can determine the caching strategy according to some set strategy factors.
  • the strategy factors that can be used here can include but are not limited to one or more of the following: the network capability of the server device, the network capability of the client device, the service The protocol rate between the client device and the client device, the disk I/O performance of the server device, the disk I/O performance of the client device, the disk I/O load of the server device, the disk I/O of the client device load, the processor load of the server device, the processor load of the client device, etc.
  • caching strategies that can be used here may include but are not limited to one or more of the following: cache speed, size of each file segment when file segment transmission is used, buffer health (referring to the cached progress and application The time difference between the progress of the playback) and so on.
  • the relationship between the policy factor and the caching policy is not specifically limited in the embodiment of the present application, and a person skilled in the art can reasonably determine it based on knowledge in the art. For example: the higher the network capability of the server device and the network capability of the client device, the faster the cache speed, the larger each file segment, and the smaller the buffer health; the higher the network capability of the server device and the network capability of the client device are. Low, the smaller each file segment, the greater the buffer health.
  • the file caching function can start the cross-device transmission of the target media resource according to the caching policy. For example, based on the determined caching speed, the target media resource is obtained from the storage location of the target media resource, and segmented and cached at the first address until the cached The target media resource meets the buffer health requirements.
  • Step S106 the application sends a second play request to the first address.
  • the second play request may be a request that the user wishes to start playing the media resource.
  • FIG. 11 is a scene diagram of an application generating a second play request according to an embodiment of the present application.
  • the scene shown in FIG. 11 may be a continuation of the scene shown in FIG. 10 .
  • the application when the user wants to play the target media resource and clicks the icon of the target media resource, the application can enter the play interface 51 of the target media resource. Under the play interface 51, the application can start playing the target media resource in at least two ways, one way is "do not play automatically", and the other way is "play automatically”.
  • the "No Autoplay” and “Autoplay” modes can be selected by the application as default settings. It can also be set by the user.
  • the playing interface 51 may include a start playing button 52, and the application starts playing when the application detects that the user clicks 49 the start playing button 52. Then, if the application program adopts the mode of "do not play automatically", the application program can send a second play request to the first address when detecting that the user 49 clicks the start playing button 52 .
  • the application In the "autoplay” mode, when the application detects that the user clicks on the icon of the target media resource, it enters the play interface 51 of the target media resource and directly starts playing. Then, if the application program adopts the "autoplay” mode, the application program can immediately send a second play request to the first address as long as it obtains the first address after detecting that the user clicks on the icon of the target media resource.
  • the application program may not obtain the first address in advance, and can wait until the local media service feedbacks the first address meeting, and immediately send the second playback request to the first address; if the application program The program is not playing the target media resource for the first time, and the application may have obtained the first address during the previous playback, and can immediately send a second playback request to the first address.
  • the second playback request may be an HTTP request
  • the request may be sent to a first port of the first address
  • the first port may be a port agreed in advance by the application and the local media service.
  • the application and the local media service may agree on the same port for the first playback request and the second playback request, or may agree on a different port for the first playback request and the second playback request, which is not done in this embodiment of the present application limited.
  • Step S107 When receiving the second play request, the local media service sends the cached target media resource to the application for playing.
  • step S107 may be performed by a virtual server of the local media service.
  • the virtual server may be, for example, an HTTP virtual server.
  • the virtual server can create a service socket ServerSocket for the local IP address and the first port, and monitor the HTTP request received on the first port of the local IP address through the ServerSocket. If the second playback request is monitored, the cached target media resource Send to the app for playback.
  • the local media service sends the cached target media resources to the application for playback, which may be implemented in the following manner: after monitoring the second playback request, the local media service may read the content from the first address.
  • the file fragments of the target media resources in the segment cache are processed into media streams according to the audio/video time sequence corresponding to the file fragments, and then the media streams are sent to the application for playback.
  • the media stream may be a media stream based on the HTTP protocol, and is sent to the application program by means of an HTTP response message.
  • the application program can decode and render the media stream using its configured audio/video decoder, renderer, etc., thereby generating sound or images.
  • the media playback method constructs a local media service on the client side, and when the application program requests to play the media resources of the server device, the client device can first cache the media resources through the local media service. To the local, so that the application can directly request the local media service to obtain media resources from the local and play them.
  • the server device only needs to provide ordinary file transfer functions to the client device, and does not participate in and perceive the playback process. Therefore, there is no need to deploy playback-related services, which reduces the capability requirements for the server device, thereby realizing the thin device between thin devices. of media is played in real-time across devices.
  • the application may or may not play the same target media resource in the server device for the first time, depending on the user's wishes.
  • the local media service does not start the buffer transmission process, so the client device can completely execute the methods of steps S101-S107; when the application program does not play the target media resource for the first time, the local media service The media service may have already started the buffer transmission process in the previous playback process. In this case, the client may also perform other method steps according to the buffer status of the target media resource.
  • the user may perform playback control operations such as start playback, pause playback, and terminate playback, or repeatedly play the target media resources.
  • the target media resources may be different. cache status.
  • the cache status of the target media resource may include “cache transfer process not started” and “cache transfer process started”.
  • the "cached transfer process started” may further include states such as “cached transfer pending", “cached transfer in progress”, “cached transfer completed”, etc., wherein:
  • “Cached transfer pending” means that the local media service has started the transfer process of the target media resources from the server device to the client device before this, but due to some reasons (for example, the user clicks to pause playback or temporarily closes the playback process) the transfer process is suspended, but the connection between the server device and the local media service used to transmit the target media resource and the pre-applied system resources are not released.
  • the local media service records the cache location of the target media resource on the client, the target media The overall length of the resource and the current transmitted length of the target media resource (ie, the transmission progress).
  • “Cached transmission in progress” means that the local media service has previously started the transfer process of the target media resource from the server device to the client device, and data transmission is in progress. This state generally corresponds to the user playing the target media resource, or , Pause the playback of the target media resource, but for some reasons (for example, the cached target media resource does not meet the buffer health requirement), the caching action of the target media resource is still in progress.
  • the buffered transmission is completed means that the cross-device transmission of the target media resource has been completed, and the client device has completely cached each file segment of the target media resource.
  • the local media service and the application can perform the following steps S108-S112 after step S102:
  • Step S108 the local media service sets the second address.
  • the second address may be an address of the client device for accessing the cached target media resource, and the second address and the first address may be the same or different.
  • the difference between the first address and the second address may only be the port.
  • the first address may include the local IP address and the first port
  • the second address may include the local IP address. IP address and second port.
  • both the first address and the second address can be a temporary address, and the local media service can generate such a temporary address every time it receives a first playback request, so that the application can obtain the temporary address from this temporary address later.
  • Step S109 the local media service continues the buffering transmission process to continue to buffer the target media resource from the server device to the client device according to the buffering progress of the target media resource.
  • Step S110 the local media service sends the second address to the application, and the application receives the second address.
  • Step S111 the application sends a third play request to the second address.
  • the third play request may be a request that the user wishes to continue playing the media resource.
  • Step S112 when receiving the third play request, the local media service sends the cached target media resource to the application for playing.
  • step S112 may be performed by a virtual server of the local media service.
  • the virtual server may be, for example, an HTTP virtual server.
  • the virtual server can create a service socket ServerSocket for the local IP address and the second port, and monitor the HTTP request received on the second port of the local IP address through the ServerSocket. If the third playback request is monitored, the cached target media resources Send to the app for playback.
  • FIG. 12 is a flowchart of another method for playing media according to an embodiment of the present application. This method can be applied to the situation where the local media service has already cached the target media resource locally.
  • the method may include the following steps 201-S203:
  • Step S201 the application sends a first play request to a first address.
  • Step S202 the local media service sends the third address to the application in response to the first playback request.
  • the third address may be a file path of the target media resource cached locally.
  • the first address is a local URL address, which is cached in the client device by the local IP address and port http://127.0.0.1:xx and the target media resource.
  • the file path is composed of y; different from the first address, after the target media resource is cached, the local media service does not need to transmit data from the server device, and the target media resource does not need to be occupied by the HTTP virtual server, then the target media The resource can no longer use the URL address, therefore, the third address can directly be the file path y of the target media resource cached in the client device.
  • y may be of the form: Storage (the root directory of the client device)/Movies/ShareMedia/1.mov.
  • Step S203 the application reads the target media resource from the third address to play.
  • the application program can access the target media resource file located at the third address, such as 1.mov, and play the file. This process is the same as the application program plays local media, and does not involve the streaming process.
  • the method may include the following steps 201, S204-S207:
  • Step S201 the application sends a first play request to a first address.
  • Step S204 the local media service sets a fourth address.
  • the second address may be an address of the client device used to access the cached target media resource
  • the fourth address may be the same as or different from the first address and the second address.
  • the difference between the first address, the second address and the fourth address may only be the port.
  • the first address may include the local IP address and the first address. port
  • the second address may include the local IP address and the second port
  • the fourth address may include the local IP address and the fourth port.
  • Step S205 the local media service sends the fourth address to the application, and the application receives the fourth address.
  • Step S206 the application sends a fourth play request to the fourth address.
  • the fourth play request may be a request that the user wishes to continue playing the media resource.
  • Step S207 when the local media service receives the third and fourth play requests, it sends the cached target media resources to the application for playing.
  • step S207 may be performed by a virtual server of the local media service.
  • the virtual server may be, for example, an HTTP virtual server.
  • the virtual server can create a service socket ServerSocket for the local IP address and the fourth port, and monitor the HTTP request received on the fourth port of the local IP address through the ServerSocket. If the fourth playback request is monitored, the cached target media resources Send to the app for playback.
  • FIG. 13 is a complete processing flow chart illustrating a scenario where the local media service starts playing according to an embodiment of the present application. As shown in FIG. 13 , the complete processing flow may include, for example, the following steps:
  • Step S301 the application sends a request for applying for a media stream resource corresponding to the target media resource to the local media service.
  • the application when the application detects that the user clicks the icon of the target media resource on the media resource page, the application sends a playback request to the local media service, and the request is a request for applying for a media stream resource.
  • the application when the application detects that the user clicks the resume button in the playback pause state of the target media resource, the application sends a resume request to the local media service, which is a request for applying for a media stream resource.
  • Step S302 the local media service acquires the cache state of the target media resource according to the request of the application.
  • the local media service can perform different processing flows next.
  • the local media service can perform the following steps:
  • Step S303a the local media service obtains the storage location of the target media resource in the server device.
  • Step S303b the local media service starts the process of cross-device transmission, and caches the target media resource.
  • the local media service is responsible for real-time updating and management of each file segment of the target media resource cached in the client device.
  • Step S303c the local media service generates media stream data based on the cached target media resource, and sends the data to the client device for playback.
  • the local media service can perform the following steps:
  • Step S304a the local media service releases the suspended state of buffering and transmission, and continues to buffer the target media resource.
  • the local media service may continue to cache the target media resources in an incremental transmission manner according to the cache progress of the target media resources, thereby avoiding repeated transmission of the cached target media resources.
  • the local media service is responsible for real-time updating and management of each file segment of the target media resource cached in the client device.
  • Step S304b the local media service generates media stream data based on the cached target media resources, and sends the data to the client device for playback.
  • the local media service can select the file segment of the corresponding time to generate the media stream according to the previous playback progress of the target media resource. For example, when the target media resource is last played to 10 minutes and 20 seconds, if the user clicks "continue playing", the local media service can start to generate a media stream from the file segment corresponding to 10 minutes and 20 seconds.
  • the application allows the user to choose whether to "continue playing from last played progress" or "play from the beginning” when the target media asset is not played for the first time. If the user selects "Continue to play from the progress of the last playback", the local media service can immediately start to continuously cache the target media resource from the server device, and select the file segment of the corresponding time to generate media according to the previous playback progress of the target media resource. flow. If the user selects "play from the beginning", the local media service can not continue to cache the target media resource from the server device, but generate the media stream of the target media resource from scratch, and then continue to cache the target media when the buffer health is insufficient. resource.
  • the local media service can maintain the current cache transmission action, and generate media stream data based on the cached target media resource, and send it to the client device for playback.
  • the local media service can directly generate media stream data based on the cached target media resources and send them to the client device for playback, without the need to re-cache the target media resources from the server device.
  • the local media service can perform different processing procedures according to different cache states of the target media resources, so as to realize the incremental transmission and continuous caching of the target media resources across devices, avoid repeated transmission, reduce The occupation of transmission bandwidth between small devices reduces the storage space occupation of client devices.
  • the cache status of the target media resource may also include "cache transfer not started”, “cache transfer pending”, “cache transfer in progress”, and "cache transfer completed”.
  • FIG. 14 is a process flow diagram illustrating a scenario in which the local media service terminates playback according to an embodiment of the present application. As shown in FIG. 14 , the processing flow may include the following steps, for example:
  • Step S401 the application sends a request to terminate the playback to the local media service.
  • the application program when the application program detects that the user clicks the stop playback button, the pause playback button or closes the playback interface, the application program sends a playback termination request to the local media service.
  • Step S402 the local media service acquires the cache state of the target media resource according to the request of the application.
  • the local media service can perform different processing flows next.
  • the local media service can perform the following steps:
  • Step S403 the local media service releases the resources pre-applied for in the cross-device transmission process.
  • These resources include, for example, storage space pre-allocated for caching target media resources, network resources pre-allocating for transmitting target media resources, processor resources pre-allocating for local media service-related processes, and the like.
  • the local media service can perform the following steps:
  • Step S404 the local media service updates the cache state to a "cache transmission pending" state.
  • the local media service can perform the following steps:
  • Step S405 the local media service clears the cache usage flag of the target media resource.
  • the cache usage flag can be used to identify the cache status of the target media resource.
  • the cache usage flag can be cleared.
  • the local media service can merge each file fragment of the target media resource into a complete The media files are available for subsequent local playback by the application.
  • the local media service can perform different processing procedures according to different cache states of the target media resources, such as changing the cache state to facilitate the user to perform other playback actions later, or clearing the cache usage flag to facilitate The application then performs local playback, etc.
  • the media playback method provided by the above embodiments of the present application builds a local media service on the client side, and decouples the process of media resource caching and media streaming playback through the local media service, so that the server device does not need to deploy the streaming media service, and Participating in the perceptual playback process reduces the capability requirements for server-side devices, thereby enabling real-time playback of media across thin devices across devices.
  • the local media service can also be built on other devices between the server device and the client device link, such as built in a wireless access point .
  • FIG. 15 is a hardware architecture diagram of another media playback method provided by an embodiment of the present application.
  • the client device 61 and the server device 62 are located in the same local area network through the router 63 .
  • the local media service can be constructed in the router 63, corresponding to a local area network address.
  • the application program of the client device 61 When the application program of the client device 61 detects that the target media resource is intended to be played, the application program may send a first play request including the first identifier to the local area network address of the local media service.
  • the local media service located in the router 63 associates the first address with the first identifier in response to the first playback request.
  • the first address may be a local area network address, such as http://192.168.1.101:xx/y , where xx represents the port, and y represents the file path of the target media resource to be cached in the router.
  • the router may include a built-in or external memory 64 in order to realize the ability to cache media, and the router 63 may be The memory 64 allocates a local area network IP address, for example, 192.168.1.101, it can be seen that the first address can be determined according to the local area network IP address of the memory 64 .
  • the local media service of the router 63 sends the first address to the application of the client device 61, and starts the process of caching the first address of the target media resource.
  • the application program of the client device 61 can send a second play request to the first address, and when the local media service of the router 63 receives the second play request, it generates a media stream based on the cached target media resource and sends it to the client The application of the device 61 is played.
  • the media playback method shown in FIG. 15 configures the local media service in the router, which is separated from the client device. In this way, the client device no longer performs the process of buffering media resources and generating media streams, which further reduces the capability requirements for the client device.
  • this method can enable multiple client devices to play media resources of the same server device across devices at the same time.
  • the router's local media service can send the image stream to the large-screen display device for display, and send the audio stream to different audio devices according to different channels to achieve stereo playback effect.
  • each device such as the above-mentioned client device and access point device, includes corresponding hardware structures and/or software modules for executing each function.
  • the present application can be implemented in hardware or a combination of hardware and computer software with the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein. Whether a function is performed by hardware or computer software driving hardware depends on the specific application and design constraints of the technical solution. Skilled artisans may implement the described functionality using different methods for each particular application, but such implementations should not be considered beyond the scope of this application.
  • FIG. 16 is a schematic structural diagram of a media playback apparatus provided by an embodiment of the present application.
  • the client device may implement corresponding functions through the software device shown in FIG. 16 .
  • the media playback apparatus may include: a local media service module and an application module.
  • the local service module may include: a virtual server 701, configured to receive a first play request of an application on a client device, where the first play request includes a first identifier, and the first identifier corresponds to a target media resource in the server device;
  • the virtual server 701 is further configured to determine whether the cache transfer process of the target media resource has been started according to the first identifier; the file cache unit 702 is used to start the cache transfer process if the cache transfer process has not been started to transfer the target media resource from the server device.
  • the virtual server 701 is further configured to send the first address to the application, where the first address is the local uniform resource locator URL address of the client device for accessing the cached target media resource; the virtual server 701 , and is also used to send the cached target media resource to the application for playback when the second playback request sent by the application to the first address is received.
  • the file cache unit 702 is further configured to continue the cache transfer process if the cache transfer process has been started but the cache transfer process is suspended, so as to continue to transfer the target media resource from the server according to the cache progress of the target media resource
  • the device is cached to the client device; the virtual server 701 is also used to send a second address to the application, where the second address is the local URL address of the client device used to access the cached target media resource; the virtual server 701 is also used to When receiving the third play request sent by the application to the second address, the cached target media resource is sent to the application for playback.
  • the virtual server 701 is further configured to send the third address to the application if the target media resource has been completely cached in the client device, so that the application obtains the target media resource from the third address and plays it,
  • the third address is the file path of the target media resource cached in the client device.
  • the virtual server 701 is further configured to send a fourth address to the application if the target media resource has been completely cached in the client device, where the fourth address is the target media used by the client device to access the cache The local URL address of the resource; the virtual server 701 is further configured to send the cached target media resource to the application for playback when receiving the fourth play request sent by the application to the fourth address.
  • the first address includes a local Internet Protocol IP address and a first port of the client device; and the second play request is a hypertext transfer protocol HTTP request.
  • the virtual server 701 is configured to send the cached target media resource to the application when receiving the second playback request sent by the application to the first address, including: the virtual server 701 for monitoring The first port of the local IP address; the virtual server 701 is further configured to generate a first response message when monitoring the second playback request, the first response message is an HTTP response message, and the first response message includes the target media according to the cached target media.
  • the media stream generated by the resource including: the virtual server 701 for monitoring The first port of the local IP address; the virtual server 701 is further configured to generate a first response message when monitoring the second playback request, the first response message is an HTTP response message, and the first response message includes the target media according to the cached target media.
  • the media stream generated by the resource including: the virtual server 701 for monitoring The first port of the local IP address; the virtual server 701 is further configured to generate a first response message when monitoring the second playback request, the first response message is an HTTP response message, and the first response message includes the target media according to the cached target
  • the virtual server 701 is further configured to suspend the cache transfer process and record the cache progress of the target media resource if the cache transfer process is in progress when receiving a stop playing request from the application.
  • the application module may include: a first sending unit 703, configured to send a first play request to the media proxy service on the client device, where the first play request includes a first identifier, and the first identifier corresponds to the target media in the server device resource; the address receiving unit 704 is used to receive the target address sent by the media proxy service; the second sending unit 705 is used to send a second playback request to the local URL address if the target address is the local URL address of the client device; the playback unit 706, for receiving and playing the target media resource sent by the media proxy service in response to the second play request, where the target media resource is cached by the media proxy service from the server device to the client device.
  • a first sending unit 703 configured to send a first play request to the media proxy service on the client device, where the first play request includes a first identifier, and the first identifier corresponds to the target media in the server device resource
  • the address receiving unit 704 is used to receive the target address sent by the media proxy service
  • the second sending unit 705
  • the playing unit 706 is further configured to obtain the target media resource from the file path address for playing if the target address is the file path address in the client device.
  • the local URL address includes the local IP address and the first port of the client device; the second play request is a hypertext transfer protocol HTTP request.
  • the second sending unit 705 is configured to send the second play request to the local URL address, including: sending the second play request to the first port of the local IP address.
  • the playing unit 706 is configured to receive the target media resource sent by the media proxy service in response to the second play request, including: receiving a first response message sent by the media proxy service in response to the second play request, the first response The message is an HTTP response message, and the first response message includes the media stream generated by the media proxy service according to the cached target media resource.
  • Embodiments of the present application further provide a computer-readable storage medium, where instructions are stored in the computer-readable storage medium, when the computer-readable storage medium runs on a computer, the computer executes the methods of the above aspects.
  • Embodiments of the present application also provide a computer program product containing instructions, which, when run on a computer, cause the computer to execute the methods of the above aspects.
  • FIG. 17 is a schematic structural diagram of the chip system.
  • the chip system includes a processor 801 for supporting the above-mentioned apparatus to implement the functions involved in the above-mentioned aspects, for example, generating or processing the information involved in the above-mentioned methods.
  • the chip system further includes a memory 802 for storing computer instructions 803 and data necessary for the long-term connection device.
  • the chip system may be composed of chips, or may include chips and other discrete devices.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

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

Description

一种媒体播放方法、装置和电子设备
本申请要求于2021年3月24日提交到国家知识产权局、申请号为202110312246.2、发明名称为“一种媒体播放方法、装置和电子设备”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及媒体播放技术领域，尤其涉及一种媒体播放方法、装置和电子设备。
背景技术
在分布式场景中，客户端设备可以通过网络与多个服务端设备连接，播放服务端设备中的媒体资源或者控制服务端设备。目前，客户端设备播放服务端设备中的媒体资源的方式可以包括本地播放和实时流传输播放。
本地播放是指在用户请求播放媒体资源时，客户端设备首先将完整的音/视频文件从服务端设备拉取到本地，然后再开始播放，由于音/视频文件通常较大，从用户请求播放到完成音/视频文件的拉去需要消耗一段时间，因此用户会感觉到播放存在明显的卡顿，无法实现实时播放，用户体验差。
实时流传输播放是指基于实时流传输协议或投屏协议，例如实时流协议(real time 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创建的无线局域网络(Wireless LAN，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，向客户端发送流媒体数据(PLAY response)。
步骤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 processing unit，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 circuit sound，I2S)接口，脉冲编码调制(pulse code modulation，PCM)接口，通用异步收发传输器(universal asynchronous receiver/transmitter，UART)接口，移动产业处理器接口(mobile industry processor interface，MIPI)，通用输入输出(general-purpose input/output，GPIO)接口，用户标识模块(subscriber identity module，SIM)接口，和/或通用串行总线(universal serial bus，USB)接口等。
存储器120可以用于存储计算机可执行程序代码，可执行程序代码包括指令。存储器120可以包括存储程序区和存储数据区。其中，存储程序区可存储操作系统、至少一个功能所需的应用程序(比如声音播放功能，图像播放功能等)等。存储数据区可存储终端设备100使用过程中所创建的数据(比如音频数据，电话本等)等。此外，存储器120可以包括一个或者多个存储单元，例如可以包括易失性存储器(volatile memory)，如：动态随机存取存储器(dynamic random access memory，DRAM)、静态随机存取存储器(static random access 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 packet radio service，GPRS)，码分多址接入(code division multiple access，CDMA)，宽带码分多址(wideband code division multiple access，WCDMA)，时分码分多址(time-division code division multiple access，TD-SCDMA)，长期演进(long term evolution，LTE)，第五代移动通信技术新空口(5th generation mobile networks new radio，5G NR)，BT，GNSS，WLAN，NFC，FM，和/或IR等功能。GNSS可以包括全球卫星定位系统(global positioning system，GPS)，全球导航卫星系统(global navigation satellite system，GLONASS)，北斗卫星导航系统(beidou navigation satellite system，BDS)，准天顶卫星系统(quasi-zenith satellite system，QZSS)和/或星基增强系统(satellite based augmentation systems，SBAS)。
摄像头170用于捕获静态图像或视频。摄像头170包括镜头和感光元件，物体通过镜头生成光学图像投射到感光元件。感光元件可以是电荷耦合器件(charge coupled device，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-emitting diode，OLED)，有源矩阵有机发光二极体或主动矩阵有机发光二极体(active-matrix organic light emitting diode的，AMOLED)，柔性发光二极管(flex light-emitting diode，FLED)，MiniLED，MicroLED，Micro-OLED，量子点发光二极管(quantum dot light emitting 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任一项所述的方法。
PCT/CN2022/081696 2021-03-24 2022-03-18 一种媒体播放方法、装置和电子设备 WO2022199484A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP22774145.1A EP4287586A4 (en) 2021-03-24 2022-03-18 MEDIA PLAYBACK METHOD AND APPARATUS AND ELECTRONIC DEVICE
US18/283,374 US20240171626A1 (en) 2021-03-24 2022-03-18 Media playing method and apparatus, and electronic device

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202110312246.2 2021-03-24
CN202110312246.2A CN115134420A (zh) 2021-03-24 2021-03-24 一种媒体播放方法、装置和电子设备

Publications (1)

Publication Number Publication Date
WO2022199484A1 true WO2022199484A1 (zh) 2022-09-29

Family

ID=83375008

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/081696 WO2022199484A1 (zh) 2021-03-24 2022-03-18 一种媒体播放方法、装置和电子设备

Country Status (4)

Country Link
US (1) US20240171626A1 (zh)
EP (1) EP4287586A4 (zh)
CN (1) CN115134420A (zh)
WO (1) WO2022199484A1 (zh)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090003600A1 (en) * 2007-06-29 2009-01-01 Widevine Technologies, Inc. Progressive download or streaming of digital media securely through a localized container and communication protocol proxy
CN106657162A (zh) * 2017-03-01 2017-05-10 北京东大正保科技有限公司 一种在线流媒体播放方法、流媒体下载和离线播放方法
CN106973302A (zh) * 2016-01-14 2017-07-21 腾讯科技（深圳）有限公司 一种下载视频数据的方法、装置及系统

Family Cites Families (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101309203B (zh) * 2007-05-17 2011-03-16 中兴通讯股份有限公司 一种网络媒体服务方法
CN102055789B (zh) * 2009-11-09 2013-10-09 华为技术有限公司 实现基于http的流媒体业务的方法、系统和网络设备
CN102497359B (zh) * 2011-12-02 2014-06-04 山东大学 一种基于瘦客户端流媒体服务系统的运行方法
CN102497452B (zh) * 2011-12-28 2014-07-30 山东大学 一种基于嵌入式终端的在线流媒体服务方法
CN103348657B (zh) * 2012-02-06 2015-09-30 华为技术有限公司 流媒体播放方法、设备及系统
US20140199044A1 (en) * 2013-01-15 2014-07-17 Qualcomm Incorporated Supporting transport diversity and time-shifted buffers for media streaming over a network
EP2954685A4 (en) * 2013-02-07 2016-09-14 Opanga Networks Inc TRANSPARENT MULTIMEDIA ELEMENT DISTRIBUTION AND REPRESENTATIVE
CN104394475A (zh) * 2014-11-28 2015-03-04 乐视致新电子科技（天津）有限公司 一种流媒体文件的播放方法及媒体播放器
CN104581207A (zh) * 2014-12-23 2015-04-29 乐视致新电子科技（天津）有限公司 在线播放视频的方法、系统和播放应用代理设备
US9749293B2 (en) * 2015-04-20 2017-08-29 Shoelace Wireless, Inc. Systems for improved mobile internet performance and security
CN104796796B (zh) * 2015-04-21 2018-03-16 范文鲜 提高Android平台的HLS流播放器容错的方法
US10506262B2 (en) * 2015-12-29 2019-12-10 Telefonaktiebolaget Lm Ericsson (Publ) Method and system for optimized media delivery
CN106507181B (zh) * 2016-11-30 2019-11-05 北京酷我科技有限公司 一种获取并存储在线视频数据的方法
CN106888385A (zh) * 2017-01-17 2017-06-23 武汉噢易云计算股份有限公司 客户端在虚拟化环境下的视频播放方法及系统
CN107911712B (zh) * 2017-11-30 2020-10-09 歌尔科技有限公司 数据缓冲方法和电子设备
CN109874028A (zh) * 2017-12-01 2019-06-11 深圳市雷鸟信息科技有限公司 一种hls流媒体的播放方法、系统及存储介质
CN109963171B (zh) * 2017-12-14 2021-01-05 腾讯科技（深圳）有限公司 多媒体信息传输方法、传输设备及存储介质
CN108322772A (zh) * 2018-01-30 2018-07-24 北京奇艺世纪科技有限公司 一种视频文件处理方法、装置及电子设备
CN111314794A (zh) * 2020-03-18 2020-06-19 浩云科技股份有限公司 一种流媒体播放地址生成方法

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090003600A1 (en) * 2007-06-29 2009-01-01 Widevine Technologies, Inc. Progressive download or streaming of digital media securely through a localized container and communication protocol proxy
CN106973302A (zh) * 2016-01-14 2017-07-21 腾讯科技（深圳）有限公司 一种下载视频数据的方法、装置及系统
CN106657162A (zh) * 2017-03-01 2017-05-10 北京东大正保科技有限公司 一种在线流媒体播放方法、流媒体下载和离线播放方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP4287586A4

Also Published As

Publication number Publication date
CN115134420A (zh) 2022-09-30
EP4287586A1 (en) 2023-12-06
EP4287586A4 (en) 2024-07-10
US20240171626A1 (en) 2024-05-23

Similar Documents

Publication Publication Date Title
WO2020014880A1 (zh) 一种多屏互动方法及设备
US11496532B2 (en) Offering media services through network edge
WO2022100304A1 (zh) 应用内容跨设备流转方法与装置、电子设备
CN111092898B (zh) 报文传输方法及相关设备
US9019372B2 (en) Remote controlled studio camera system
CN113141523B (zh) 资源传输方法、装置、终端及存储介质
WO2021249318A1 (zh) 一种投屏方法和终端
CN113141524B (zh) 资源传输方法、装置、终端及存储介质
WO2022135527A1 (zh) 一种视频录制方法及电子设备
JP7181990B2 (ja) データ伝送方法及び電子デバイス
EP3059945A1 (en) Method and system for video surveillance content adaptation, and central server and device
WO2014154108A1 (zh) 媒体流的转移方法和用户设备
WO2023051243A1 (zh) 视频码率切换方法、装置、电子设备及存储介质
CN115349248A (zh) 利用实时上行链路流式传输框架(flus)和5g应用功能(af)的基于网络的媒体处理(nbmp)部署
WO2021155702A1 (zh) 通信处理方法、装置、终端、服务器及存储介质
US20220095020A1 (en) Method for switching a bit rate, and electronic device
JP6583653B2 (ja) ストリーミングメディア送信方法及びシステム、ユーザ機器及びサーバ
WO2015077983A1 (zh) 在家庭网络中播放媒体的装置和方法
WO2022199484A1 (zh) 一种媒体播放方法、装置和电子设备
WO2023134509A1 (zh) 视频推流方法、装置、终端设备及存储介质
WO2021114950A1 (zh) 一种多路http通道复用的方法及终端
CN116264619A (zh) 资源处理方法、装置、服务器、终端、系统及存储介质
WO2016177257A1 (zh) 一种数据分享的方法和装置
WO2024007998A1 (zh) 一种数据传输的方法、电子设备和通信系统
KR102419087B1 (ko) 미디어 스트리밍 제어 장치 및 방법

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22774145

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2022774145

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 2022774145

Country of ref document: EP

Effective date: 20230829

WWE Wipo information: entry into national phase

Ref document number: 18283374

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE