The present invention relates to communications technologies, and in particular, to a media playing method, apparatus, and system.
The Digital Living Network Alliance (DLNA) defines a set of standard solutions for facilitating digital home entertainment and living of people. In media playing and sharing, a digital media server (DMS), a digital media controller (DMC), a digital media player (DMP), and a digital media renderer (DMR) are involved. The DMS is configured to store and manage media resources, so that another device may acquire media content conveniently through a network. The DMC is configured to browse media information of the DMS, acquire metadata information of media from the DMS, and instruct the DMR to play selected media content. The DMR is a media player that does not have a DMC function, whereas the DMP is a media player that has a DMC function.
However, the existing DLNA technology provides only a unicast transport and playing technology and cannot implement synchronous playing, by multiple players, of same media content, that is, implementing synchronous video playing, synchronous photo pushing and sharing, and the like in different areas of a home.
Embodiments of the present invention provide a media playing method, apparatus, and system to implement synchronous playing of same media content by multiple players.
A first aspect of embodiments of the present invention provides a media playing method, including separately sending a connection preparation message to a media server and at least one media renderer that supports multicast, so as to instruct the media server and each media renderer to configure a multicast protocol address according to the connection preparation message; and sending a media transport identifier and a play message to the media server, so as to instruct the media server to transmit, on the multicast protocol address according to the play message, a media stream of a to-be-played media file identified by the media transport identifier, so that each media renderer receives the media stream on the multicast protocol address and plays the to-be-played media file locally.
Another aspect of embodiments of the present invention provides another media playing method, including receiving a connection preparation message sent by a media controller, and configuring a multicast protocol address according to the connection preparation message; and receiving a media transport identifier and a play message that are sent by the media controller, and transmitting, on the multicast protocol address according to the play message, a media stream of a to-be-played media file identified by the media transport identifier, so that at least one media renderer supporting multicast separately receives the media stream on the multicast protocol address and plays the to-be-played media file locally.
Still another aspect of embodiments of the present invention provides still another media playing method, including receiving a connection preparation message sent by a media controller, and configuring a multicast protocol address according to the connection preparation message; and receiving a media stream of a to-be-played media file on the multicast protocol address, and playing the to-be-played media file locally; where the media stream of the to-be-played media file is transmitted on the multicast protocol address after a media server receives a media transport identifier and a play message that are sent by the media controller, and the to-be-played media file is identified by the media transport identifier.
Still another aspect of embodiments of the present invention provides a media controller, including a connection instructing module configured to separately send a connection preparation message to a media server and at least one media renderer that supports multicast, so as to instruct the media server and each media renderer to configure a multicast protocol address according to the connection preparation message; and a play instructing module configured to send a media transport identifier and a play message to the media server, so as to instruct the media server to transmit, on the multicast protocol address according to the play message, a media stream of a to-be-played media file identified by the media transport identifier, so that each media renderer receives the media stream on the multicast protocol address and plays the to-be-played media file.
Still another aspect of embodiments of the present invention provides a media server, including a first receiving module configured to receive a connection preparation message sent by a media controller, and configure a multicast protocol address according to the connection preparation message; a second receiving module configured to receive a media transport identifier and a play message that are sent by the media controller; and a sending module configured to transmit, on the multicast protocol address according to the play message, a media stream of a to-be-played media file identified by the media transport identifier, so that at least one media renderer supporting multicast separately receives the media stream on the multicast protocol address and plays the to-be-played media file locally.
Still another aspect of embodiments of the present invention provides a media renderer, including a fourth receiving module configured to receive a connection preparation message sent by a media controller, and configure a multicast protocol address according to the connection preparation message; and a playing module configured to receive a media stream of a to-be-played media file on the multicast protocol address, and play the to-be-played media file locally; where the media stream of the to-be-played media file is transmitted on the multicast protocol address after a media server receives a media transport identifier and a play message that are sent by the media controller, and the to-be-played media file is identified by the media transport identifier.
Still another aspect of embodiments of the present invention provides a media player, including the foregoing media controller and media renderer.
Still another aspect of embodiments of the present invention provides a media playing system, including the foregoing media controller, media server, and at least one media renderer.
The embodiments of the present invention have the following technical effects. A connection preparation message is sent to a media server and at least one media player separately, so that the media server and each media player configure a multicast protocol address; then a media transport identifier and a play message are sent to the media server, so as to instruct the media server to transmit a media stream of a to-be-played media file on the multicast protocol address, and each media player receives the media stream on the multicast protocol address and plays the to-be-played media file locally on each media player. The embodiments implement synchronous playing, by multiple players, of same media content, without the need of using a manner of requesting by multiple media players one by one, thereby saving network bandwidth for transmitting a media stream.
To describe the technical solutions in the embodiments of the present invention or in the prior art more clearly, the following briefly introduces the accompanying drawings required for describing the embodiments or the prior art. Apparently, the accompanying drawings in the following description show some embodiments of the present invention, and a person of ordinary skill in the art may still derive other drawings from these accompanying drawings without creative efforts.
To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the following clearly describes the technical solutions in the embodiments of the present invention with reference to the accompanying drawings in the embodiments of the present invention. The described embodiments are a part rather than all of the embodiments of the present invention. All other embodiments obtained by a person of ordinary skill in the art based on the embodiments of the present invention without creative efforts shall fall within the protection scope of the present invention.
Step 201: Separately send a connection preparation message to a media server and at least one media renderer that supports multicast, so that the media server and each media renderer configure a multicast protocol address according to the connection preparation message.
In this embodiment, the media controller may be a DMC or a mobile digital media controller (M-DMC), the media server may be a DMS or a mobile digital media server (M-DMS), and the media renderer may be a DMR or a DMP. This embodiment is an improvement in a media playing solution of a DLNA three-box model in the prior art and is not limited to a single DMC, DMS, and DMR network element. In this embodiment, there may be more than one DMR.
This step is that the media controller sends a connection preparation message to the media server and the media server prepares a media transport connection after receiving the connection preparation message. A transport address may be configured as a multicast protocol address according to the connection preparation message, and subsequently, the media server transmits a related media stream on the multicast protocol address. The media controller further separately sends a connection preparation message to at least one media renderer that supports multicast. Each media renderer prepares a media transport connection after receiving the connection preparation message. A transport address may be configured as a multicast protocol address according to the connection preparation message, and subsequently, each media renderer receives a media stream on the multicast protocol address.
Step 202: Send a media transport identifier and a play message to the media server, so as to instruct the media server to transmit, on the multicast protocol address according to the play message, a media stream of a to-be-played media file identified by the media transport identifier, so that each media renderer receives the media stream on the multicast protocol address and plays the to-be-played media file locally.
After the media server and each media renderer complete preparations of media transport connections, the media controller sends a media transport identifier and a play message to the media server, and instructs, by using the play message, the media server to transmit the media stream of the to-be-played media file on the multicast protocol address. The to-be-played media file is a media file identified by the media transport identifier. It may be that a user selects, by using a display interface of the media controller, a media file that needs to be played, and the media controller generates a media transport identifier according to the selection of the user. After receiving the play message, the media server transmits the media stream of the to-be-played media file on the previously acquired multicast protocol address. Each media renderer receives the media stream on the previously acquired multicast protocol address. After receiving the media stream, each media renderer may play the to-be-played media file locally, thereby achieving an effect of synchronously playing same-source media at multiple points.
Further, the media playing method provided by this embodiment may further include the following step. Acquire device information of the media server and the media renderer through a device automatic discovery process, where the device information includes service information of all services that are supported by the media server and the media renderer. Before playing the media, the media controller needs to acquire device information of the media server and each media renderer through the device automatic discovery process, where the device information includes service information of all services that are supported by each device. Herein the service information may be a uniform resource locator to service description (SCPDURL) corresponding to each service, a uniform resource locator for control (controlURL), and a uniform resource locator for eventing (eventSubURL). A uniform resource locator (URL) specified by the SCPDURL defines a capability set of the service, which includes a service state table (serviceStateTable) and an action list (actionList). The serviceStateTable includes all internal state variables of the service, and the actionList describes an action interface provided by the service for an external system. The controlURL defines a target URL when a control point (CP) of the service submits an Action, and a service subsystem where the URL is located is responsible for executing the Action. The eventSubURL defines a URL for subscribing to an eventing. In this embodiment, services supported by the media server include a CDS, a connection management service (CMS), and an audio video transport service (AVTS), and the CDS service needs to support a browse action or a search action. A service supported by the media renderer includes a CMS, and an AVTS and a rendering control service (RCS) may also be supported.
The connection preparation message sent by the media controller in step 201 in this embodiment may be PrepareForConnection in the CMS service, that is, the DMC commands, by using CM:: PrepareForConnection, the DMS to prepare a media transport connection and commands, by using CM:: PrepareForConnection, each DMR to prepare a media transport connection. The media transport identifier and the play message that are sent by the media controller in step 202 in this embodiment may be SetAVTransportURI and Play in the AVTS service, that is, the DMC commands, by using AVT:: SetAVTransportURI and AVT::Play, the DMS to start to send, through a multicast media transport protocol, the media stream of the to-be-played media file that has been streamed.
This embodiment provides a media playing method, in which a connection preparation message is sent to a media server and at least one media renderer separately, so that the media server and each media renderer configure a multicast protocol address; then a media transport identifier and a play message are sent to the media server, so as to instruct the media server to transmit a media stream of a to-be-played media file on the multicast protocol address, so that each media renderer receives the media stream on the multicast protocol address and plays the to-be-played media file locally. Because the media renderer in this embodiment is included in a media player, this embodiment implements synchronous playing, by multiple players, of same media content, without the need of using a manner of requesting by multiple media players one by one, thereby causing no waste of resources.
Step 401: Receive a connection preparation message sent by a media controller, and configure a multicast protocol address according to the connection preparation message.
This step is that a media server receives a connection preparation message sent by the media controller, and the media server prepares a media transport connection after receiving the connection preparation message. A transport address may be configured as a multicast protocol address according to the connection preparation message, and subsequently, the media server transmits a related media stream on the multicast protocol address.
Step 402: Receive a media transport identifier and a play message sent by the media controller, and transmit, on the multicast protocol address according to the play message, a media stream of a to-be-played media file identified by the media transport identifier, so that at least one media renderer supporting multicast separately receives the media stream on the multicast protocol address and plays the to-be-played media file locally.
After the media server completes the preparation of the media transport connection, the media server continues to receive the media transport identifier and the play message that are sent by the media controller, and the media server transmits, according to the play message, the media stream of the to-be-played media file on the multicast protocol address. The to-be-played media file is a media file identified by the media transport identifier. It may be that a user selects, by using a display interface of the media controller, a media file that needs to be played, and the media controller generates a media transport identifier according to the selection of the user. After receiving the play message, the media server transmits the media stream of the to-be-played media file on the previously acquired multicast protocol address. Each media renderer receives the media stream on the previously acquired multicast protocol address. After receiving the media stream, each media renderer may play the to-be-played media file locally, thereby achieving an effect of synchronously playing same-source media at multiple points. The media renderer in this step is a media renderer that is selected by the user and supports multicast.
Further, the media playing method provided by this embodiment may further include the following steps. The media server receives a play control message sent by the media controller; and the media server controls play progress and a play speed of the to-be-played media file according to the play control message.
This embodiment provides a media playing method, in which a multicast protocol address is configured according to a received connection preparation message, a media stream of a to-be-played media file is transmitted on the multicast protocol address according to a received play message, each media renderer receives the media stream on the multicast protocol address, and plays the to-be-played media file locally. This embodiment implements synchronous playing, by multiple players, of same media content, without the need of using a manner of requesting by multiple media players one by one, thereby causing no waste of resources.
Step 501: Receive a connection preparation message sent by a media controller, and configure a multicast protocol address according to the connection preparation message.
This step is that a media renderer receives a connection preparation message sent by the media controller and the media renderer prepares a media transport connection after receiving the connection preparation message. A transport address may be configured as a multicast protocol address according to the connection preparation message, and subsequently, the media renderer receives a media stream on the multicast protocol address.
Step 502: Receive a media stream of a to-be-played media file on the multicast protocol address, and play the to-be-played media file locally.
This step is that the media renderer receives the media stream on the previously acquired multicast protocol address and, after receiving the media stream, the media renderer may play the to-be-played media file locally, thereby achieving an effect of synchronously playing same-source media at multiple points. The media stream of the to-be-played media file is transmitted on the multicast protocol address after a media server receives a media transport identifier and a play message that are sent by the media controller, and the to-be-played media file is identified by the media transport identifier. It may be that a user selects, by using a display interface of the media controller, a media file that needs to be played, and the media controller generates a media transport identifier according to the selection of the user. The media renderer in this step is a media renderer that is selected by the user and supports multicast.
Further, the media playing method provided by this embodiment may further include the following steps. After receiving the connection preparation message, the media renderer checks whether a media transport protocol of the media server, which is acquired by the media controller, is a multicast media transport protocol, that is, checks whether the media controller supports the multicast media transport protocol. If the media transport protocol of the media server is the multicast media transport protocol, the media renderer joins a multicast address group identified by the multicast protocol address.
Further, the media playing method provided by this embodiment may further include the following steps. The media renderer receives an effect control message sent by the media controller; and the media renderer controls a play effect of the to-be-played media file according to the effect control message.
This embodiment provides a media playing method, in which a multicast protocol address is configured according to a received connection preparation message, a media stream of a to-be-played media file is received on the multicast protocol address, and the to-be-played media file is played locally, where the media stream of the to-be-played media file is transmitted on the multicast protocol address after a media server receives a media transport identifier and a play message that are sent by a media controller, and the to-be-played media file is identified by the media transport identifier. This embodiment implements synchronous playing, by multiple players, of same media content, without the need of using a manner of requesting by multiple media players one by one, thereby causing no waste of resources.
Step 601: A DMC sends a browse action command to a DMS.
In this embodiment, before the DMC controls playing, by the DMS, of a media file, the DMC first sends the browse action command to the DMS. The browse action command in this embodiment may be Browse in a CDS service.
Step 602: The DMC acquires, from a media information base of the DMS, a media information list of a media file available for selection by a user.
After receiving the browse action command, the DMS may return the media information base of the DMS to the DMC. The DMC may acquire, from the media information base of the DMS, the media information list of the media file available for selection by the user. Each media information entry in the media information list includes a media transport protocol and a media format of each media file. In this embodiment, when the DMS generates a media information entry in the media information base, each media file may correspond to multiple media information entries, that is, each media file may include multiple media transport protocols and media formats. In this embodiment, at least one media information entry of a multicast media transport protocol needs to be generated for each media file. In this embodiment, the DMC may browse the media information base of the DMS by using CDS::Browse, thereby displaying, on a display interface, all media information lists available for selection by the user. Or, the DMC may also search the media information base of the DMS by using CDS::Search, thereby directly displaying, on the display interface, a media information list that is found in the media information base and is available for selection by the user.
In this embodiment, media content information in the media information base of the DMS is generated by the DMS for each media file by using the CDS service. At least one media information entry may be generated for a same media file, and each media information entry defines a manner of accessing a media source. In this embodiment, the media information entry may be marked with Res. For a program “/sdcard/media/If You Are The One.mpeg”, a media information entry generated by the DMS for the program by using the CDS may be as follows:
The protocolInfo is formed of the following strings: <protocol>:<network>:<contentFormat>:<additionalInfo>. The protocol defines a transport protocol for a streaming media client to acquire streaming media content, and the contentFormat defines key information such as a media format.
Step 603: The DMC acquires a media transport protocol and a media format of a to-be-played media file according to the media information list.
In this embodiment, the user may select, by using the display interface, a media file requiring synchronous playing at multiple points, that is, the to-be-played media file. The DMC may acquire the media transport protocol and the media format of the to-be-played media file according to a media information entry corresponding to the to-be-played media file in the media information list. In this embodiment, the DMS is required to support transmission of media content of the media file through the multicast media transport protocol.
Step 604: The DMC separately sends a protocol information acquiring command to at least one DMR selected by the user.
In this embodiment, the user may select multiple DMRs to synchronously play the to-be-played media file. This step is that the DMC separately sends the protocol information acquiring command to at least one DMR selected by the user. The protocol information acquiring command in this embodiment may be GetProtocolInfo in the CMS service.
Step 605: Each DMR returns a multicast-based media transport protocol and media format that are supported by each DMR to the DMC.
After each DMR receives the protocol information acquiring command of the DMC, each DMR returns the multicast-based media transport protocol and media format that are supported by each DMR to the DMC. The DMC may acquire, by using CM::GetProtocolInfo, the multicast-based media transport protocol and media format that are supported by each DMR, where one DMR may support multiple media transport protocols and media formats. In this embodiment, each DMR is required to support the multicast media transport protocol. Herein the multicast media transport protocol may be a Real-time Transport Protocol over User Datagram Protocol over multicast (RTP-UDP-mc), a HyperText Transfer Protocol streaming over User Datagram Protocol over multicast (httpu-mc), and the like. In this embodiment, protocol information acquired by the DMC from the DMR may be, for example, protocolInfo=“RTP-UDP-mc:224.0.0.xxx:video/h264:*”, or protocolInfo=“httpu-mc:224.0.0.xxx:video/h264:*”. An acquired media transport protocol of the DMR is a multicast media transport protocol RTP-UDP-mc or httpu-mc, where the multicast protocol address is 224.0.0.xxx/24, that is, a media stream is transmitted by multicast only in a local network.
Step 606: The DMC matches the media transport protocol and the media format of the to-be-played media file with the multicast-based media transport protocol and media format that are supported by each DMR to obtain a multicast-based media transport protocol and media format that are supported by the DMS and each DMR.
After the media transport protocol and the media format of the to-be-played media file and the multicast-based media transport protocol and media format that are supported by each DMR are acquired, matching is performed according to the media transport protocol and the media format of the to-be-played media file and the multicast-based media transport protocol and media format that are supported by each DMR, so as to obtain an optimum media transport protocol and media format. Herein the optimum media transport protocol and media format are a multicast-based media transport protocol and media format that are supported by the DMS and each DMR. In this embodiment, the preferred optimum media transport protocol is a multicast media transport protocol, and at least one DMR supporting multicast is acquired. When none of the DMRs support the multicast media transport protocol, the user is prompted with a play failure.
Step 607: The DMC sends a connection preparation message to the DMS.
The connection preparation message in this embodiment may be PrepareForConnection in a CMS. This step may be that the DMC commands, by using CM::PrepareForConnection, the DMS to prepare a media transport connection.
Step 608: The DMS configures a multicast protocol address according to the connection preparation message.
After receiving the connection preparation message sent by the DMC, the DMS prepares a media transport connection according to the connection preparation message and configures a transport address as a multicast protocol address. For example, the DMS prepares a multicast protocol address of RTP-UDP-mc:224.0.0.xxx or httpu-mc:224.0.0.xxx to establish a media transport connection.
Step 609: The DMC sends a connection preparation message to each DMR.
The connection preparation message in this embodiment may be PrepareForConnection in the CMS. This step may be that the DMC commands, by using CM::PrepareForConnection, each DMR supporting multicast to prepare a media transport connection.
Step 610: Each DMR configures a multicast protocol address according to the connection preparation message.
After receiving the connection preparation message sent by the DMC, each DMR prepares a media transport connection according to the connection preparation message and configures a transport address as a multicast protocol address. For example, each DMR prepares a multicast protocol address of RTP-UDP-mc:224.0.0.xxx or httpu-mc:224.0.0.xxx to receive a media stream.
Step 611: The DMC sends a media transport identifier to the DMS.
This step is that the DMC sends a media transport identifier to the DMS, where the media transport identifier is used to identify the to-be-played media file and may be SetAVTransportURI in an AVTS service. This step may be that the DMC notifies the DMS of the to-be-played media file by using AVT::SetAVTransportURI, that is, notifies the DMS of the media file that is selected by the user and needs to be played.
Step 612: The DMS returns a reception success response to the DMC.
After receiving the media transport identifier, the DMS may return a reception success response to the DMC, indicating that the media transport identifier sent by the DMC is sent successfully and that the DMS has acquired the to-be-played media file.
Step 613: The DMC sends a play message to the DMS.
This step is that the DMC sends a play message to the DMS, where the play message may be Play in the AVTS service. This step may be that the DMC instructs, by using AVT::Play, the DMS to play the to-be-played media file. Herein the playing is as follows. The DMS sends, through the multicast media transport protocol, a media stream of the to-be-played media file that has been streamed.
Step 614: The DMS returns a reception success response to the DMC.
After receiving the play message, the DMS may return a reception success response to the DMC, indicating that the play message sent by the DMC is sent successfully.
Step 615: The DMS transmits, on the multicast protocol address according to the play message, the media stream of the to-be-played media file identified by the media transport identifier.
The transmitting, by the DMS on the multicast protocol address according to the play message, the media stream of the to-be-played file identified by the media transport identifier may be, for example, transmitting, on 224.0.0.xxx, the media stream of the to-be-played media file identified by SetAVTransportURI.
Step 616: Each DMR receives the media stream on the multicast protocol address and plays the to-be-played media file locally.
Each DMR supporting multicast receives the media stream on the multicast protocol address and after receiving the media stream, locally plays the media stream in real time, thereby implementing synchronous playing of the same media file on the multiple DMRs.
Step 617: The DMC sends a play control message to the DMS.
In this embodiment, in the process of synchronously playing same-source media at multiple points, the DMC may further perform synchronous control over the media file played on the multiple DMRs. Herein the control may be controlling a play process and play progress of the media file, including stop, pause, start, seek, and the like. This step is that the DMC sends a play control message to the DMS, where the play control message may be Stop, Pause, Start, and Seek in the AVTS service.
Step 618: The DMS controls play progress and a play speed of the to-be-played media file according to the play control message.
After receiving the play control message sent by the DMC, the DMS controls the play progress and the play speed of the to-be-played media file according to the play control message. In this embodiment, the DMC controls, by using commands such as AVT:: (Stop, Pause, Start, and Seek), performing uniform control, by the DMS, over the play progress, the play speed, and the like of the media file played on each DMR, such as play stop and play pause.
Step 619: The DMC sends an effect control message to each DMR.
In this embodiment, the DMC may not only perform uniform control over the play progress of the media file, but also uniformly control a play effect of the media file. This step is as follows. The DMC sends an effect control message to each DMR, where the effect control message may be SetVolume, SetBrightness, and the like in an RCS service.
Step 620: The DMR controls a play effect of the to-be-played media file according to the effect control message.
After receiving the effect control message sent by the DMC, each DMR controls the play effect of the to-be-played media file according to the effect control message. In this embodiment, the DMC performs, by using commands such as RCS:: (SetVolume, SetBrightness), uniform control over a play rendering effect of the media file played on each DMR, for example, sets volume and sets brightness of a picture.
In addition, in this embodiment, the DMC may further repeat or play, by using AVT::SetAVTransportURI and AVT::Play, other media content that can be played.
Persons of ordinary skill in the art may understand that all or a part of the steps of the method embodiments may be implemented by a program instructing relevant hardware. The program may be stored in a computer readable storage medium. When the program runs, the steps of the method embodiments are performed. The foregoing storage medium includes any medium that can store program code, such as a read-only memory (ROM), a random-access memory (RAM), a magnetic disk, or an optical disc.
Further, the media controller provided by this embodiment may further include a first play control module 805 and a first effect control module 806. The first play control module 805 is configured to send a play control message to the media server, so that the media server controls a play process of the to-be-played media file according to the play control message. The first effect control module 806 is configured to send an effect control message to each media renderer, so that each media renderer controls a play effect of the to-be-played media file according to the effect control message.
Further, the media controller provided by this embodiment may further include a fourth acquiring module 807. The fourth acquiring module 807 is configured to acquire device information of the media server and the media renderer through a device automatic discovery process, where the device information includes service information of all services that are supported by the media server and the media renderer. Services supported by the media server include a content directory service, a connection management service, and an audio video transport service, and a service supported by the media renderer includes a connection management service.
This embodiment provides a media controller, which separately sends a connection preparation message to a media server and at least one media renderer, so that the media server and each media renderer configure a multicast protocol address, and then sends a media transport identifier and a play message to the media server, so as to instruct the media server to transmit, on the multicast protocol address, a media stream of a to-be-played media file, so that each media renderer receives the media stream on the multicast protocol address and plays the to-be-played media file locally. This embodiment implements synchronous playing, by multiple players, of same media content, without the need of using a manner of requesting by multiple media players one by one, thereby causing no waste of resources.
This embodiment provides a media server, which configures a multicast protocol address according to a received connection preparation message and transmits a media stream of a to-be-played media file on the multicast protocol address according to a received play message, so that each media renderer receives the media stream on the multicast protocol address and plays the to-be-played media file locally. This embodiment implements synchronous playing, by multiple players, of same media content, without the need of using a manner of requesting by multiple media players one by one, thereby causing no waste of resources.
Further, the media renderer provided by this embodiment may further include a fifth receiving module 1203 and a second effect control module 1204. The fifth receiving module 1203 is configured to receive an effect control message sent by the media controller. The second effect control module 1204 is configured to control a play effect of the to-be-played media file according to the effect control message.
This embodiment provides a media renderer, which configures a multicast protocol address according to a received connection preparation message, receives a media stream of a to-be-played media file on the multicast protocol address, and plays the to-be-played media file locally, where the media stream of the to-be-played media file is transmitted on the multicast protocol address after a media server receives a media transport identifier and a play message that are sent by a media controller, and the to-be-played media file is identified by the media transport identifier. This embodiment implements synchronous playing, by multiple players, of same media content, without the need of using a manner of requesting by multiple media players one by one, thereby causing no waste of resources.
This embodiment further provides a media player, which may include the media controller shown in the foregoing
This embodiment further provides a media playing system, which may include the media controller shown in the foregoing
Finally, it should be noted that the foregoing embodiments are merely intended for describing the technical solutions of the present invention, but not for limiting the present invention. Although the present invention is described in detail with reference to the foregoing embodiments, persons of ordinary skill in the art should understand that they may still make modifications to the technical solutions described in the foregoing embodiments or make equivalent replacements to some or all technical features thereof, without departing from the scope of the technical solutions of the embodiments of the present invention.
Number | Date | Country | Kind |
---|---|---|---|
201210143499.2 | May 2012 | CN | national |
This application is a continuation of International Application No. PCT/CN2012/088103, filed on Dec. 31, 2012, which claims priority to Chinese Patent Application No. 201210143499.2, filed on May 10, 2012, both of which are hereby incorporated by reference in their entireties.
Number | Date | Country | |
---|---|---|---|
Parent | PCT/CN2012/088103 | Dec 2012 | US |
Child | 14536850 | US |