WO2011147352A1 - 一种在动态http流传输方案中支持时移回看的方法和装置 - Google Patents

一种在动态http流传输方案中支持时移回看的方法和装置 Download PDF

Info

Publication number
WO2011147352A1
WO2011147352A1 PCT/CN2011/075284 CN2011075284W WO2011147352A1 WO 2011147352 A1 WO2011147352 A1 WO 2011147352A1 CN 2011075284 W CN2011075284 W CN 2011075284W WO 2011147352 A1 WO2011147352 A1 WO 2011147352A1
Authority
WO
WIPO (PCT)
Prior art keywords
mpd
media
time
client
media presentation
Prior art date
Application number
PCT/CN2011/075284
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 EP11786124.5A priority Critical patent/EP2592809B1/en
Priority to PL11786124T priority patent/PL2592809T3/pl
Priority to ES11786124.5T priority patent/ES2524001T3/es
Publication of WO2011147352A1 publication Critical patent/WO2011147352A1/zh
Priority to US13/768,002 priority patent/US8683071B2/en
Priority to US14/162,153 priority patent/US8984570B2/en

Links

Classifications

    • 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/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/262—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists
    • H04N21/26258—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists for generating a list of items to be played back in a given order, e.g. playlist, or scheduling item distribution according to such list
    • 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
    • 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
    • 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/23424—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving splicing one content stream with another content stream, e.g. for inserting or substituting an advertisement
    • 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/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
    • H04N21/458—Scheduling content for creating a personalised stream, e.g. by combining a locally stored advertisement with an incoming stream; Updating operations, e.g. for OS modules ; time-related management operations
    • 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/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
    • H04N21/462—Content or additional data management, e.g. creating a master electronic program guide from data received from the Internet and a Head-end, controlling the complexity of a video stream by scaling the resolution or bit-rate based on the client capabilities
    • H04N21/4622—Retrieving content or additional data from different sources, e.g. from a broadcast channel and the Internet

Definitions

  • HTTP streaming HTTP Streaming
  • the media segment matching the available bandwidth can be dynamically selected according to the available bandwidth (Bandwidth) between the client and the server in the process of playing to provide Give users the highest possible playback experience, so there is also a scheme called HTTP Adaptive Streaming (HAS) or Dynamic HTTP Streaming (Adaptive HTTP Streaming).
  • HTTP Adaptive Streaming HAS
  • Dynamic HTTP Streaming Adaptive HTTP Streaming
  • the HTTP dynamic streaming scheme can be further divided into static mode (Static Mode) and dynamic mode (Dynamic Mode) according to Content-Preparation Modes: static content preparation (content preparation) Mode: The media content transmitted via HTTP is used as static content. The HTTP server does not need to prepare the content in any way. Instead, the content preparation is completed ahead of time.
  • Dynamic content service mode The HTTP streaming server dynamically serves the client based on the client's request. Tailor the stream content.
  • the content, and the exact end time of the live broadcast may not be known, and therefore it is not possible to provide media presentation description information for a long period of time in the future.
  • the live media shows that the media presentation description information in the future time period may not be provided all at once in the client access as the on-demand content, but needs to gradually add follow-up to the MPD over time.
  • the media of the time segment displays the description information, so that the client needs to continuously obtain the updated MPD, so as to obtain the media presentation description information of the subsequent time period, and then the corresponding URL can obtain the media segment and play.
  • MPD updates can be done in two different ways: (a) In the MPD, including all time-line media presentation descriptions since the beginning of the live broadcast, but one problem with this approach is that over time As time goes by, the time period included in the MPD is getting longer and longer. Accordingly, the MPD includes more and more description information, the MPD size will gradually increase, and the client needs to obtain the MPD every time it requests the updated MPD. A bigger MPD. Therefore, this method is more suitable for live media presentations with shorter durations; (b) Sliding window update: Each time in the updated MPD, only the description of the media segment of the time period near the current time point is included.
  • the media presentation description information of the beginning part of the time period when the client wants to drag back to an earlier time (such as time shift or lookback function), it will not be possible.
  • the HTTP streaming server provides the MPD, it needs to weigh how long the media description information should be included in the MPD:
  • the total length of the time period included in the MPD will affect the client's broadcast pause and Seek operation in the live session. the behavior of.
  • the longer the total length of time the longer the list will be included, the longer the client will be able to pause without losing its position in the live list, and the longer the client will be able to seek.
  • the MPD which includes a longer period of time, will bring a greater network burden. Since the client needs to update the MPD frequently, although each MPD file is usually small, the update is very impressive.
  • FIG. 1 is a flowchart of a method for supporting time-shifting back and watching in a dynamic HTTP stream transmission scheme according to an embodiment of the present invention
  • FIG. 2 is a flowchart of a method for supporting time-shifting back and watching in a dynamic HTTP streaming solution according to an embodiment of the present invention
  • FIG. 3 is a basic block diagram of a client according to an embodiment of the present invention
  • FIG. 4 is a basic block diagram of a media server according to an embodiment of the present invention.
  • FIG. 5 is a flowchart of a specific implementation of a method for supporting time-shifting back and watching in a dynamic HTTP stream transmission scheme according to an embodiment of the present invention
  • FIG. 6 is a flowchart of a specific implementation of a method for supporting time-shifting back when a time shift range is exceeded in a dynamic HTTP stream transmission scheme according to an embodiment of the present invention
  • FIG. 7 is a flowchart of a specific implementation of a method for seamlessly switching between live broadcast and on-demand in a dynamic HTTP streaming solution according to an embodiment of the present invention
  • FIG. 8 is a flowchart of a specific implementation of a method for seamlessly switching between live broadcast and on-demand in a dynamic HTTP streaming solution according to an embodiment of the present invention. detailed description
  • Embodiment 1 is a diagrammatic representation of Embodiment 1:
  • a method for supporting seamless handover of a time-shifting or live-on-demand in a dynamic HTTP streaming solution includes:
  • A1 Send a live media presentation description MPD request message to the media server.
  • the client requests to obtain a live MPD, for example, obtaining an address according to the URL of the live MPD. Since this MPD is often updated, this step can be repeated as many times as needed.
  • the client can be set in a mobile terminal, or a set top box, and other user terminals that receive media streams.
  • A2 receiving, by the media server, a response message of the MPD that includes the current time period, where the MPD further includes media presentation information of other time periods;
  • the media server returns the current latest MPD
  • the client processes the MPD to obtain the corresponding playlist and obtains the URL address of the media segment
  • the MPD also includes media presentations of other time segments.
  • Information, other time periods here can be subdivided into two situations:
  • the client creates a local playlist based on the latest MPD currently acquired, and the time interval other than the time interval [a, b] included in the current MPD, for example, is usually before the time point a for the live broadcast;
  • the local playlist created by the client can be based on the latest MPD currently acquired, and can also be based on the time period included in the previously acquired MPD. For a client that accesses after the live broadcast starts, it can only create a playlist from the first MPD received from it to all the time ranges included in the current latest MPD, assuming time interval [a ,, b] (where a, ⁇ a ) , then for periods other than the interval [a,, b] (eg ⁇ a, ).
  • the local playlist maintained by it has a total duration limit (such as LocalListDuration ) , then its maintenance time interval is [b-LocalListDuration, b], and other times outside this interval belong to other time periods.
  • A3. Determine, according to the media presentation information of the other time period, the media presentation information that needs to be requested by the media segment.
  • the client first determines whether the time at which the media shard is requested has exceeded the current time range. For example, the time range of the playlist maintained by the client is [a, b], if the requested media sharding start time is c (c ⁇ a ) , then exceeds the time range; if the requested media sharding start time is d ( a ⁇ d ⁇ b ), then the time range is not exceeded.
  • the example of the actual application may further include: determining, by the MPD, whether the plurality of media presentation information corresponding to the time period including the requesting the media sharding time is present, and if there are multiple, the client may obtain the information from the multiple MPDs according to the selection policy. Choose one of them.
  • the selection policy may include one or a combination of the following conditions: (1) If the MPD information further includes an accessible time (such as availablilityStart, availabilityEnd is optional), the current time needs to meet the access time requirement; (2) If there is a repetition of the time period included in the media presentation information, the one of the media presentation information in which the MPD time period coincides with the local playlist time period maintained by the client may be selected to be the smallest; (3) if several MPDs are played locally If the list time periods are not coincident or the coincidence degree is the same, one can be randomly selected, for example, the first one that satisfies the condition, or the start time is closest to the time of requesting the media slice time, or the farthest from the current time, etc.; 4) Other possible selection strategies.
  • an accessible time such as availablilityStart, availabilityEnd is optional
  • A4 Obtain a corresponding MPD according to the media presentation information corresponding to the currently required media fragment, and request, according to the acquired MPD, the media fragment that needs to be requested currently.
  • the client obtains the URL address of the MPD from the media presentation information, and requests the MPD of the corresponding time period from the server; the server returns the corresponding MPD.
  • the client processes the obtained MPD, obtains the URL address of the corresponding playlist and the media slice, and adds the obtained playlist to (or replaces) the locally maintained playlist, and the client requests the media slice corresponding to the MPD. Construct a media shard request and send it to the server.
  • the method may further include: the client receiving the media fragment corresponding to the request returned by the server; the client then requesting the subsequent media fragmentation in sequence, until the user performs other playback control operations or media fragments in the playlist. Request and play completed or encounter an MPD update.
  • the first embodiment adopts sending the live broadcast MPD request information to the media server; receiving the response message of the MPD containing the current time period returned by the server, the MPD further includes media presentation information of other time periods; determining that the media fragment currently required to be requested exceeds The time range corresponding to the MPD is determined according to the MPD information of the other time period, and the media presentation information corresponding to the currently required media segment is determined; according to the media exhibition corresponding to the media slice requested by the current request
  • the current information which includes the URL address of the desired MPD, obtains the corresponding MPD, and obtains the corresponding corresponding according to the
  • MPD requests the media server for the media fragment that currently needs to be requested.
  • Embodiment 2 is a diagrammatic representation of Embodiment 1:
  • a second embodiment of the present invention provides a method for supporting seamless handover of a time-shifted or live broadcast in a dynamic HTTP streaming solution, where the method includes:
  • the client obtains the URL address of the MPD from the media presentation information, and requests the MPD of the corresponding time period from the server; B4, according to the client MPD request message, sends the corresponding MPD to the client, so that the client can respond according to the corresponding
  • the MPD gets the media shards needed.
  • the second embodiment adopts a live broadcast MPD request message sent by the receiving client, and sends a response message to the client that includes the MPD of the current time period, where the MPD further includes media presentation information of other time periods;
  • the MPD request message is out of the time range; according to the client MPD request message, the corresponding MPD is sent to the client, so that the client obtains the required media segment according to the corresponding MPD, so that the client supports the client.
  • the time-lapse and lookback of the long-term range can keep the size of the MPD within an acceptable range.
  • Embodiment 3 is a diagrammatic representation of Embodiment 3
  • a third embodiment of the present invention provides a client, where the client can be set in a user terminal (for example, a mobile terminal, a fixed terminal set-top box, etc.); the client includes:
  • the sending module 301 is configured to send a live MPD request message to the media server, where the client requests to obtain a live MPD, for example, obtaining an address according to a URL of the live MPD. Since MPDs often need to be updated, this step can be repeated as many times as needed.
  • the receiving module 302 is configured to receive a response message that is returned by the media server and includes an MPD of the current time period, where the MPD further includes media presentation information corresponding to other time segments; this step is described in detail in A2, and is not described herein.
  • the determining module 303 is configured to determine that a time when the media slice needs to be requested is exceeded, and the time range corresponding to the MPD is exceeded. Determining, according to the media presentation information of the other time period, the media presentation information corresponding to the media fragment currently required to be requested; this step has been described in detail in A3, and is not described here.
  • the obtaining module 304 is configured to obtain a corresponding MPD according to the media presentation information corresponding to the media fragment that is currently requested, and request the media fragment that needs to be requested from the media server according to the obtained corresponding MPD. This step has been described in detail in A4 and is not mentioned here.
  • the client may further include: a selection module 305, configured to determine whether there are multiple media presentation information that meets a time period including a request for a media sharding time in the MPD, if there are multiple, the client The terminal may select one of the plurality of media presentation information according to the selection policy; the specific selection policy may include one or a combination of the following: if the media presentation information includes an accessible time, the current moment needs to satisfy the accessible time.
  • the one of the time segments in the MPD and the local playlist time period maintained by the client may be selected to be the smallest; if there are several MPDs and the local playlist time period are not coincident Or if the coincidence is the same, randomly select one.
  • the third embodiment adopts the sending module 301 to send a live MPD request message to the media server; the receiving module 302 receives the response message of the MPD containing the current time period returned by the server; the determining module 303 determines that the time of the current media fragment that needs to be requested exceeds the MPD. And determining, according to the media presentation information of the other time period, the media presentation information that is required to be requested by the media segment; the obtaining module 304 is configured to obtain the media presentation information corresponding to the media segment that is currently required to be requested. Corresponding MPD, and according to the obtained corresponding MPD, request the media server to request the media fragment currently requested. This allows the client to support time shifts and lookbacks over a longer period of time while maintaining the MPD size within an acceptable range.
  • Embodiment 4 is a diagrammatic representation of Embodiment 4:
  • a second embodiment of the present invention provides a media server, where the media server includes:
  • the receiving module 401 is configured to receive a live media presentation description MPD request message sent by the client; because the MPD needs to be updated frequently, the step may be repeated as many times as needed.
  • the receiving module is further configured to receive an MPD request message sent by the client; when the client obtains the URL address of the MPD from the MPD information returned by the server and saves, the receiving module receives the MPD request of the corresponding time period;
  • the sending module 402 is configured to send, to the client, a response message that includes an MPD of a current time period, where the MPD further includes media presentation information of other time periods; this step has been described in detail in A2, and is not described herein.
  • the sending module 402 is further configured to send the MPD corresponding to the MPD request message to the client according to the MPD request message sent by the client, so that the client obtains the corresponding media content according to the MPD, and the step is detailed in A4. Description, not to repeat here.
  • the fourth embodiment adopts the receiving module 401 to receive the live media presentation description information MPD request message sent by the client.
  • the sending module 402 sends a response message to the client that includes the MPD of the current time period, where the response message includes other time segments.
  • the media presentation information the receiving module 401 receives the MPD media presentation information request message sent by the client; the sending module 402 sends the MPD corresponding to the MPD request message to the client according to the MPD request message, so as to facilitate the client> According to the MPD, the corresponding media content is obtained, so that the client supports time shifting and reviewing for a longer period of time, and the size of the MPD can be kept within an acceptable range.
  • Embodiment 5 is a diagrammatic representation of Embodiment 5:
  • an embodiment of the present invention provides a method for more effectively supporting time shifting in a dynamic HTTP streaming scheme, including a client and a media server, and the specific steps are as follows:
  • the client sends a live MPD request message to the media server.
  • the client requests to obtain a live MPD, for example, constructing a request message according to the URL address of the live MPD; and sending the constructed MPD request message to the media server.
  • the server returns the current latest MPD.
  • the MPD also includes media presentation information of other time periods, and other time periods can be subdivided into two cases:
  • the client creates a local playlist based on the latest MPD currently acquired, and other time periods other than the time interval [a, b] included in the current MPD, for example, the live broadcast is generally before the time point a.
  • the local playlist created by the client can be based on the latest MPD currently acquired, and can also be based on the time period included in the previously acquired MPD. For a client that accesses after the live broadcast starts, it can only create a playlist from the first MPD received from it to all the time ranges included in the current latest MPD, assuming time interval [a ,, b] (where a, ⁇ a ), then for other time periods than the interval [a,, b] (for example, ⁇ a,). Or, although a live client is already connected at the beginning of the live broadcast, the local playlist maintained by it has a total duration limit (such as
  • the client requests media fragmentation from the server.
  • the client processes the MPD to obtain the corresponding playlist and obtains the URL address of the media slice; and requests the media fragment from the server according to the URL address.
  • the server returns a media fragment corresponding to the request to the client.
  • 501 and 502, 503 and 504 can be repeated several times depending on the implementation.
  • the client requests a media segment that is within a time shift range but is not included in the current MPD, and media according to other time periods. Demonstrate information, and determine media presentation information that needs to be requested by the media segment;
  • the client when the client requests the live broadcast server to support the media fragmentation in the time shift range but the current latest MPD does not include the other time period of the time period, for example, only the last 10 minutes are included in the current MPD.
  • the media displays the description information, but the client wants to watch the time shift from the current 20 minutes, and for the client that only creates the playlist according to the current MPD, or can create a playlist based on all received MPDs.
  • the technology solution that has just been connected to the live broadcast cannot be implemented.
  • the client determines whether the requested media fragment is included in the current MPD (for the case where the local playlist is not only created according to the currently updated MPD, it may be determined whether the requested media fragment is included in the local playlist). For example, the time range of the playlist maintained by the client is [a, b]. If the requested media sharding start time is c (c ⁇ a ), the time range is exceeded; if the requested media sharding start time is d ( a ⁇ d ⁇ b ), there is no time range.
  • the 602 Determine whether the media presentation information of the MPD in the time shift range except the time period including the time period in the current MPD is provided in the MPD. For example, for a time c that exceeds the current MPD time range, if there is a time range [e, f] covered by the media presentation information, and the condition e ⁇ c ⁇ f is satisfied, it is considered that such media presentation information is provided in the MPD. The following processing flow is continued. Otherwise, it is considered that the MPD information that satisfies the condition is not provided, and the client prompts the user that the media fragment 606 of the requested time cannot be supported.
  • the client selects one 604 from the multiple MPD information according to the selection policy. This may distinguish between multiple situations: (1) If the MPD information also includes an accessible time (such as availablilityStart, availabilityEnd is optional), the current time needs to meet the access time requirement; (2) If there is a time period between the MPDs Repeat, you can choose the one with the smallest overlap between the time period in the MPD and the local playlist time period maintained by the client; (3) If several MPDs and the local playlist time period are not coincident or the coincidence degree is the same, then Choose one randomly, such as the first one that satisfies the condition, or the start time that is closest to the requested media slice time, or the farthest from the current time, etc.; (4) Other possible selection strategies.
  • an accessible time such as availablilityStart, availabilityEnd is optional
  • the latest MPD includes a media presentation description information that is 10 minutes from the start of the live broadcast for 50 minutes to 60 minutes.
  • the live server support time extension is 30 minutes.
  • the additional MPD information included in the MPD is provided by the XML element ⁇ previousMPD>.
  • each MPD in the previous time period includes only the media presentation description information of the 10-minute time period, the information of the two previous MPDs needs to be included, as follows:
  • the client obtains the URL address of the corresponding MPD according to the media presentation information.
  • the client requests, according to the URL address of the MPD obtained in step 505, the MPD of the corresponding time period.
  • the client according to the URL address of the MPD obtained from the above step 505, and requests the MPD of the corresponding time period from the server;
  • the server returns an MPD corresponding to the request to the client.
  • the client processes the received MPD, obtains the corresponding playlist and obtains the URL address of the media slice, and adds the obtained playlist to the locally maintained playlist (or replaces the locally maintained playlist).
  • the client requests media fragmentation from the server.
  • the client first constructs a corresponding media fragmentation request and sends it to the server according to the time required to request the media fragmentation in step 505.
  • the server returns a corresponding media fragment to the client.
  • the server returns the media shard corresponding to the request.
  • the client may then request subsequent media shards in the media shards until all other playback control operations of the user or media shards in the local playlist are all requested and played or MPD updates are encountered, steps 508 and 509. It can be repeated several times depending on the implementation.
  • the fifth embodiment adopts sending the live broadcast MPD request information to the media server; receiving the response message of the MPD of the current time period returned by the server, where the MPD further includes media presentation information of other time segments within the time shift range; determining that the current request is required Determining, according to the media presentation information of the other time period, the media presentation information corresponding to the media segment that needs to be requested according to the media presentation information of the other time segments; The corresponding media presentation information is obtained, and the corresponding MPD is obtained, and the media fragment that needs to be requested is requested from the media server according to the obtained corresponding MPD.
  • the live broadcast server provides time shift support for a long period of time, but only a small portion of the time period of the media presentation description information is included in the MPD, and the MPD acquisition information including the media fragment description information of other time periods is included in the MPD.
  • the media shows the information.
  • the media presentation information can be used to obtain the MPD of the corresponding time period. This allows for longer time shifts and lookbacks while maintaining the MPD size within acceptable limits.
  • the above embodiment provides the media presentation information in the other time period of the time period that the MPD provides the live broadcast time shift and the current latest MPD does not include, so that the MPD provided by the live server can support the time shift of a larger time range, and at the same time It is not necessary to include the media presentation description information in all time periods in the MPD for all time periods in the MPD, which realizes time shifting to support a larger time range, and does not significantly increase the MPD size and the network overhead of the client processing, for example, reducing the client update. Handle the network burden of the MPD.
  • the MPD of the previous time period and the corresponding media fragments may be provided by the live broadcast server, and the content preparation server provides these additional MPD information in the updated MPD.
  • the live server may no longer be able to provide media content outside of its maintained time-shift range, which needs to be provided by the on-demand (VoD, Video on Demand) server. Media fragmentation of the time shift range.
  • the live broadcast since the live broadcast has not been completely completed at this time, it is not possible to provide the complete on-demand service of the corresponding media display.
  • the already broadcasted parts can be divided according to the duration and several different on-demand programs are provided.
  • the MPD acquisition information of the on-demand program is included in the MPD, and the client can seamlessly switch from the live broadcast to the on-demand according to the MPD acquisition information of the on-demand programs.
  • an embodiment of the present invention provides a method for seamlessly switching between live broadcast and on-demand in a dynamic HTTP streaming solution, including a client, a live server, and an on-demand server.
  • the specific steps are as follows:
  • the client sends a live MPD request message to the live server.
  • the client requests to obtain a live MPD, for example, constructing an MPD request message according to the URL acquisition address of the live MPD;
  • the live server returns the current latest MPD.
  • the MPD also includes MPD information of other time periods, where other time periods can be subdivided into two cases: (1) The client completely creates a local playlist based on the latest MPD currently acquired, then the time interval included in the current MPD Other time periods other than [a, b], other time periods, for example, the live broadcast is usually before the time point a; (2) The local playlist created by the client can be obtained based on the previous MPD based on the current acquired MPD. The time period included in the MPD.
  • a client For a client that accesses after the live broadcast starts, it can only create a playlist from the first MPD received from it to all the time ranges included in the current latest MPD, assuming time interval [a ,, b] (where a, ⁇ a ), then for other time periods than the interval [a,, b] (for example, ⁇ a,).
  • the local playlist maintained by it has a total duration limit (such as
  • the client requests media fragmentation from the live server.
  • the client processes the live MPD to obtain the corresponding playlist and obtain the URL address of the media slice; and requests the media slice according to the URL address.
  • the live server returns media fragments to the client.
  • 701 and 702, 703 and 704 can be repeated multiple times depending on the implementation.
  • the client requests the media fragment that exceeds the time-lapse duration of the live server, determining the current need according to the media presentation information of the MPD on the MPD in addition to the time shift range, including other time segments that need to request the media slice time. Requesting the media presentation information corresponding to the media segment;
  • the live server may no longer provide the media segmentation of the time range of its maintenance.
  • the media segment that exceeds the live time shift range needs to be provided by the corresponding on-demand server.
  • the live broadcast has not yet completely ended, it is not possible to provide the complete on-demand service of the corresponding media.
  • the already broadcasted parts can be divided according to the duration and provided as several different on-demand programs.
  • the media presentation information of the on-demand program is included in the live MPD, and the client can seamlessly switch from the live broadcast to the on-demand according to the media presentation information of the on-demand programs.
  • the client determines whether the media presentation information of the on-demand MPD is included in the MPD other than the time shift range, and if the media presentation information that satisfies the condition is not provided, the user is prompted to support the request time. If there is an eligible media presentation information, it is determined whether there are multiple media presentation information that meet the conditions in the live MPD. If there are multiple media presentation information that meet the conditions, the client selects multiple media from the media according to the selection policy.
  • Select one of the presentation information which may distinguish between multiple situations: (1) If included in the media presentation information Accessible time (such as availablilityStart, availabilityEnd optional), the current time needs to meet the access time requirements (for example, the on-demand display including the complete program can not be provided when the live broadcast is not finished, so its access time can not meet the requirements at present); 2) If there is a repetition of the time period corresponding to the plurality of media presentation information, the one of the media presentation time corresponding period and the local playlist time period maintained by the client may be selected to be the smallest; (3) if several media presentation information If the corresponding time period and the local playlist time period are not coincident or coincident, one can be randomly selected, for example, the first one that satisfies the condition, or the start time is closest to the requested media slice time, or the current time is the most Far, etc.; (4) other possible selection strategies;
  • the client obtains the corresponding URL address of the on-demand MPD, and the client can further obtain the corresponding on-demand MPD by using the obtained URL.
  • the live server provides a 30-minute time shift
  • the content of the time period before the 30-minute time shift has corresponding on-demand provision
  • the included additional media presentation information may be provided by the XML element ⁇ relatedVoD>, in live broadcast.
  • an example of on-demand media presentation information from the start time of the live broadcast to the 60-minute time period is as follows:
  • the total duration of live media presentation is 4 hours (the start time is "2010-05-01T18:00:00Z"), and it can also provide the corresponding on-demand media presentation information including the entire live media, but need to include the access time.
  • An example is as follows:
  • the live and on-demand servers can be deployed separately as needed, but they can also be deployed on the same server.
  • the client requests the MPD of the corresponding time period from the on-demand server.
  • the on-demand server returns an MPD corresponding to the request to the client.
  • the client processes the received on-demand MPD, obtains the corresponding playlist and obtains the URL address of the media slice, and adds the obtained playlist to the locally maintained playlist (or replaces the updated locally maintained playlist).
  • the client requests media fragmentation from the on-demand server.
  • the client first constructs a corresponding media fragmentation request and sends it to the on-demand server according to the time required to request the media fragmentation in step 705.
  • the on-demand server returns a media fragment corresponding to the request to the client.
  • the on-demand server returns the media fragment corresponding to the request.
  • the client may then request subsequent media shards in the media shards until the user encounters other playback control operations or media shards in the playlist all requests and plays complete or encounters MPD updates, etc., therefore step 708 And 709 can be repeated several times depending on the implementation.
  • the live broadcast MPD request information is sent to the live server; the response message of the MPD containing the current time period returned by the live server is received, and the MPD further includes the on-demand media presentation information of other time periods; The time of the slice exceeds the time range corresponding to the live MPD, and the media presentation information corresponding to the media segment that needs to be requested is determined according to the on-demand media presentation information of the other time period; Corresponding media presentation information, obtaining a corresponding on-demand MPD, and requesting, from the on-demand server, the media fragment that needs to be requested according to the obtained corresponding MPD. This allows the client to support a longer range of lookbacks while maintaining the MPD size within an acceptable range.
  • Another embodiment 8a is that the live media presentation information in the MPD is provided for other time periods within the time range of the live broadcast and the time period not included in the latest MPD, and can also provide the live broadcast media, including the time shift range, and the live media.
  • the on-demand media presentation information of the corresponding previous time period is displayed (ie, the ⁇ previousMPD> element and the ⁇ relatedVoD> are included in the MPD), and the client can request the media presentation that meets the time period requirement according to the time required to request the media segmentation according to the requirement. Information, get the corresponding MPD, request and play the corresponding media fragment.
  • the flow of the embodiment can be combined with the above-described Embodiment 6 and Embodiment 7, and will not be redundant here.
  • the client can switch to the on-demand service to continue watching. Please refer to the description of the following embodiments for details.
  • the embodiment of the present invention provides a method for seamlessly switching between live broadcast and on-demand in a dynamic HTTP streaming solution, including a client, a live server, and an on-demand server.
  • the specific steps are as follows:
  • the client sends a live MPD request message to the live server.
  • the client requests to obtain a live MPD, for example, constructing an MPD request message according to the URL address of the live MPD;
  • the live server returns the current latest MPD
  • the MPD also includes on-demand media presentation information of other time periods, and other time periods can be subdivided into two cases:
  • the client creates a local playlist based on the latest MPD currently acquired, and other time periods other than the time interval [a, b] included in the current MPD, for example, the live broadcast is generally before the time point a.
  • the local playlist created by the client can be included in the MPD obtained based on the latest acquired MPD. Time period. For a client that is accessed after the live broadcast starts, it can only create the first one received from it.
  • the MPD to the playlist in all time ranges included in the current latest MPD assuming the time interval [a,, b] (where a, ⁇ a), then for the outside of the interval [a,, b] Other time periods of time (eg ⁇ a,).
  • the local playlist maintained by it has a total duration limit (such as
  • the client requests media fragmentation from the live server.
  • the client processes the live MPD to obtain the corresponding playlist and obtain the URL address of the media slice; request the media fragment according to the URL address.
  • the live server returns media fragments to the client.
  • 801 and 802, 803 and 804 can be repeated multiple times depending on the implementation.
  • the media presentation information of the MPDs in the MPD is determined.
  • the detailed processing steps are very similar to step 705 in Figure 7 above, with the following differences:
  • the client's media shard request is no longer directly related to the live broadcast progress (because the live broadcast has ended), and the media shard request will be directly related to the media presentation, that is, the offset time value from the media presentation start time; (2) If the on-demand media presentation information for the full media presentation is included in the MPD, a full media presentation is now available.
  • the client requests an on-demand MPD of the corresponding time period from the on-demand server.
  • the on-demand server returns an MPD corresponding to the request to the client.
  • the client processes the received on-demand MPD, obtains the corresponding playlist and obtains the URL address of the media slice, and adds the obtained playlist to the locally maintained playlist (or replaces the updated locally maintained playlist).
  • the client requests media fragmentation from the on-demand server.
  • the client first constructs a corresponding media fragmentation request and sends it to the on-demand server according to the time required to request the media fragmentation in step 805.
  • the on-demand server returns a media fragment corresponding to the request to the client.
  • the on-demand server returns the media fragment corresponding to the request.
  • the client may then request subsequent media sharding in sequence by the media shard until it encounters other playback control operations of the user or all media shards in the playlist and completes the playback or encounters an MPD update.
  • Steps 808 and 809 can be repeated multiple times depending on the implementation.
  • Embodiment 8 is configured to send a live broadcast MPD request message to the live media server, and receive a response message of the MPD that includes the current time period returned by the live broadcast server, where the MPD further includes on-demand media presentation information of other time segments;
  • the media presentation time of the media segment that needs to be requested is determined according to the on-demand media presentation information of the other time period, and the current media presentation information corresponding to the media segment that needs to be requested is determined.
  • the media presentation information corresponding to the requested media fragment is obtained, and the corresponding on-demand MPD is obtained, and the media fragment that needs to be requested is requested from the media server according to the obtained corresponding MPD.
  • the client can seamlessly switch from live broadcast to on-demand after the deadline for providing services by the live server due to pause or time shift operations, and the media service can continue to be provided.
  • all or part of the steps of the foregoing embodiment can be implemented by a program to instruct related hardware, and the program can be stored in a computer readable manner.
  • the storage medium when the program is executed, the method includes the steps of the foregoing method embodiment, such as: ROM/RAM, magnetic disk, optical disk, and the like.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Business, Economics & Management (AREA)
  • Marketing (AREA)
  • Information Transfer Between Computers (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Description

一种在动态 HTTP流传输方案中支持时移回看的方法和装置 本申请要求 2010年 08月 17日递交的申请号为 201010255566.0»发明名称为 "一种在动 态 HTTP流传输方案中支持时移回看的方法和装置" 的中国专利申请的优先权， 其全部内容 通过引用结合在本申请中。 技术领域 本发明涉及通信技术领域， 尤其涉及一种在动态 HTTP流传输方案中支持时移回看的方 法的方法和装置。
背景技术
用户使用终端设备获取多媒体内容并进行播放的方式有多种， 典型的有通过 HTTP文件 下载或者 P2P文件下载到本地磁盘后播放、 传统的流媒体方式（数据传输的 RTP/RTCP和 播放控制 RTSP )、 P2P流媒体方式的在线直播 /点播、 HTT渐进式下载（HTTP Progressive Download )等等。 在 HTTP渐进式下载的基础上， 又发展了一种增强型的基于 HTTP协议 的流化媒体传输的方式， 称之为 HTTP流（HTTP Streaming )传输方案。 由于该方案支持动 态码率适配， 即在播放的过程中可实时根据客户端到服务器之间可用带宽 （Bandwidth ) 的 大小， 动态地选择与可用带宽相匹配码率的媒体分片， 以提供给用户尽可能高质量的播放 体验，因此也有把这种方案称作 HTTP动态流 ( HTTP Adaptive Streaming, HAS )或动态 HTTP 流（ Adaptive HTTP Streaming )的。 在 3GPP SA4 R9标准中， HTTP动态流方案又可才艮据内 容准备模式（ Content-Preparation Modes )进一步划分为静态模式（Static Mode )和动态模 式（ Dynamic Mode ) 两种： 静态内容准备 ( content preparation )模式： 将通过 HTTP传输 的媒体内容作为静态内容， HTTP服务器不需要以任何方式准备内容， 相反， 内容准备是提 前完成的； 动态内容服务模式： HTTP流服务器基于客户端的请求动态地为客户端裁剪 ( tailor ) 流内容。
在直播的过程中， 由于后面时间的媒体分片还没有产生， 因此在媒体展现描述（MPD, Media Presentation Description )或 playlist (为简单起见， 后续只提及 MPD , 但也同样适用 于 playlist )中无法包括后面时间段的媒体分片获取信息如 URL等。但如果知道这段时间内 媒体分片的相关信息如内容编码格式、 封装格式、 分辨率、 码率和语言等等信息， 并且能 提前为后面一小段时间的媒体分片分配对应的获取 URL地址， 也是有可能适当提前一些时 间给出未来一段时间媒体分片的描述信息。 但由于后续可能需要在直播中插播其他来源的 内容、 以及可能无法得知直播的确切结束时间， 因此也无法提供未来太久时间段的媒体展 现描述信息。 这就带来一个问题： 直播媒体展现未来时间段的媒体展现描述信息很可能无 法像点播内容那样在客户端接入时一次性全部提供， 而是需要随着时间的推移逐步向 MPD 中添加后续时间段的媒体展现描述信息， 这样客户端需要不断去获取更新后的 MPD, 以便 取得后续时间段的媒体展现描述信息， 进而才能有相应的 URL去获取媒体分片并播放。
MPD的更新可以有两种不同的方式： （a)在 MPD中包括从直播开始以来所有时间段 ( time-line )的媒体展现描述信息， 但这种方式带来的一个问题就是随着时间的推移， MPD 中包括的时间段越来越长， 相应地， MPD包括的描述信息也就越来越多， MPD的大小将逐 渐增加， 而且客户端每次请求更新的 MPD时都需要获取比前一次更大的 MPD。 因此这种 方式较适合那些时长较短的直播媒体展现； （b)采用滑动窗（Sliding window )方式更新： 每 次在更新的 MPD中只包括当前时间点附近的时间段的媒体分片的描述信息，例如典型的可 以只包括最近 10分钟到 1小时节目的媒体展现描述信息， 超过这个时间段的媒体展现描述 信息将不再被包括在更新后的 MPD中。在这种方式下，如果客户端从直播开始时就已接入， 那么可以在本地创建一个播放列表，将不同 MPD中所包括的时间段依次添加到本地播放列 表中， 同样能得到一份从直播开始到当前 MPD中包括时间段的完整播放列表， 这将达到与 上述方式 (a)等同的效果。 对于上述方式 (b), 如果客户端是在直播开始以后某个时间才接入 的话 , 其获取到的更新 MPD中只包括接入时间点附近时间段的媒体展现描述信息， 可能并 不包括直播开始部分时间段的媒体展现描述信息。 那么当客户端想拖动 （seek back )到较 早时间时 （如时移或回看功能）， 将无法实现。 这样， HTTP流服务器在提供 MPD时， 就 需要权衡在 MPD中究竟应该包括多长时间段媒体描述信息： MPD中包括的时间段总长将 会影响到直播会话中客户端做播^暂停和 Seek操作的行为。 时间总长越长， 包括的列表将 越长， 客户端能够暂停且不丢失它在直播列表中的位置的时间就越长， 客户端能够 Seek的 时间范围就越大。 但权衡就是包括更长时间段总长的 MPD将带来更大网络负担， 由于客户 端需要经常更新 MPD, 因此尽管每个 MPD文件一般很小 , 但每次更新累加起来也非常可 观。
发明内容
附图说明
图 1为本发明实施例提供的一种在动态 HTTP流传输方案中支持时移回看的方法的流程 图；
图 2为本发明实施例提供的一种在动态 HTTP流传输方案中支持时移回看的方法的流程 图； 图 3为本发明实施例提供的一种客户端的基本框图；
图 4为本发明实施例提供的一种媒体服务器的基本框图；
图 5为本发明实施例提供的一种在动态 HTTP流传输方案中支持时移回看的方法的具体 实现流程图；
图 6为本发明实施例提供的一种在动态 HTTP流传输方案中超出时移范围时支持时移回 看的方法的具体实现流程图；
图 7为本发明实施例提供的一种在动态 HTTP流传输方案中直播点播无缝切换的方法的 具体实现流程图；
图 8为本发明实施例提供的一种在动态 HTTP流传输方案中直播点播无缝切换的方法的 具体实现流程图。 具体实施方式
实施例一：
参阅图 1 , 本发明实施例一提供的一种在动态 HTTP流传输方案中支持时移回看或直播 点播无缝切换的方法， 该方法包括：
A1、 向媒体服务器发送直播媒体展现描述 MPD请求消息；
客户端请求获取直播 MPD, 例如根据直播 MPD的 URL获取地址。 由于该 MPD经常 需更新， 此步骤根据需要可重复多次。 该客户端， 可以设置于移动终端， 或者机顶盒， 以及 其他接收媒体流的用户终端等。
A2、接收媒体服务器返回的包含当前时间段的 MPD的响应消息，所述 MPD中还包含 其它时间段的媒体展现信息；
假定当前时间段为时间区间 [a， b] ,媒体服务器返回当前最新的 MPD,客户端处理 MPD 得到相应的播放列表及获取媒体分片的 URL地址， 同时 MPD中还包括其它时间段的媒体展现 信息， 这里其它时间段可以细分为两种情况：
( 1 )客户端完全基于当前获取的最新 MPD来创建本地播放列表， 那么当前 MPD所包括 的时间区间 [a, b]之外的其他时间段， 例如对直播一般为时间点 a之前；
( 2 )客户端创建的本地播放列表除了基于当前获取的最新的 MPD, 还能基于前面所获 取的 MPD中包括的时间段。 对于一个在直播开始以后才接入的客户端， 它最多只能创建从其 接收到的第一个 MPD到当前最新的 MPD所包括的所有时间段范围内的播放列表，假设为时间 区间 [a，， b] (其中 a，≤a ) , 那么对于超出区间 [a，， b]之外的其它时间段（例如 <a， ) 。 又或者， 虽然一个直播客户端在直播开始就已经接入， 但其维护的本地播放列表有总时长限制 （如 LocalListDuration ) , 那么其维护的时间区间为 [b-LocalListDuration, b], 这个区间之外的其他 时间都属于其它时间段。
A3、 确定当前需要请求的媒体分片的时刻超出所述 MPD所对应的时间范围， 根据所 述其它时间段的媒体展现信息， 确定当前需要请求媒体分片对应的媒体展现信息。
客户端首先判断请求媒体分片的时刻是否已超出当前时间范围， 例如， 客户端维护的 播放列表的时间范围是 [a, b] , 若请求的媒体分片开始时间为 c ( c < a ), 则超出时间范围； 若 请求的媒体分片开始时间为 d ( a≤ d≤ b ) ,则没有超出时间范围。 判断 MPD中是否提供了包 括请求媒体分片时间的时间段所对应的媒体展现信息 , 例如对于一个超出时间范围的时间 c, 若存在一个媒体展现信息覆盖的时间范围 [e, f] , 并满足条件 e < c < f , 则认为存在这样的媒体 展现信息。 实际应用的实例中进一步可包括， 判断 MPD中是否存在多个满足包括请求媒体 分片时刻的时间段所对应的媒体展现信息， 若存在多个， 客户端可以根据选择策略从多个 MPD获取信息中选择一个。实际应用的实例中 ,该选择策略可以包括以下情况之一或者组合： ( 1 )如果 MPD信息中还包括可访问时间 （如 availablilityStart, availabilityEnd可选）， 则当前 时间需满足可访问时间的要求； （ 2 )如果媒体展现信息包括的时间段存在重复， 则可以选择 媒体展现信息中 MPD时间段与客户端维护的本地播放列表时间段重合度最小的一个； （ 3 ) 如果几个 MPD与本地播放列表时间段都没有重合或者重合度都一样， 则可以随机选择一个， 例如满足条件的第一个， 或开始时间最接近请求媒体分片时间的， 或距离当前时间最远的， 等等； （4 )其他可能的选择策略。
A4、根据所述当前需要请求的媒体分片所对应的媒体展现信息， 获取对应的 MPD, 并根 据所述获取到的 MPD, 向媒体服务器请求当前需要请求的媒体分片。
客户端从媒体展现信息中获取 MPD的 URL地址，向服务器请求所述相应时间段的 MPD; 服务器返回对应的 MPD。客户端处理获取到的 MPD,得到相应的播放列表及媒体分片的 URL 地址， 并把得到的播放列表添加到 （或者替换）本地维护的播放列表中， 客户端请求 MPD 对应的媒体分片， 构造媒体分片请求并发送给服务器。 进一步可以包括： 客户端接收服务器 返回的与请求对应的媒体分片； 客户端接着该媒体分片依次请求后续的媒体分片， 直到遇到 用户其他播放控制操作或者播放列表中的媒体分片全部请求并播放完成或者遇到 MPD更新。
实施例一采用向媒体服务器发送直播 MPD请求信息； 接收服务器返回的包含当前时间 段的 MPD的响应消息， 所述 MPD中还包含其它时间段的媒体展现信息； 确定当前需要请求 的媒体分片超出所述 MPD所对应的时间范围， 根据所述其它时间段的 MPD信息， 确定当前 需要请求的媒体分片对应的媒体展现信息； 根据所述当前需要请求的媒体分片对应的媒体展 现信息， 其中包含所需 MPD的 URL地址， 获取对应的 MPD, 并根据所述获取到的对应的
MPD, 向媒体服务器请求当前需要请求的媒体分片。
使得客户端支持更长时间范围的时移和回看， 同时可将 MPD的大小保持在可接受的范围内。
实施例二：
参阅图 2, 本发明实施例二提供一种在动态 HTTP流传输方案中支持时移回看或直播点 播无缝切换的方法， 该方法包括：
B 1、 接收客户端发送的直播 MPD请求消息；
由于 MPD经常需更新， 此步骤根据需要可重复多次。
B2、 向所述客户端发送包含当前时间段的 MPD的响应消息， 所述 MPD中包含其它时间 段的媒体展现信息；
此步骤已在 A2详细描述， 这里不在赞述。
B3、 接收所述客户端发送的超出时间范围的 MPD请求消息；
客户端从媒体展现信息中获取 MPD的 URL地址，向服务器请求相应时间段的 MPD; B4、根据所述客户端 MPD请求消息 , 将对应的 MPD发送给客户端 , 以便于客户端根据 所述对应的 MPD获取所需要的媒体分片。
此步骤已在 A4详细描述， 这里不在赞述。
实施例二采用接收客户端发送的直播 MPD请求消息； 向所述客户端发送包含当前时间 段的 MPD的响应消息， 所述 MPD中还包含其它时间段的媒体展现信息； 接收所述客户端发 送的超出时间范围的 MPD请求消息； 根据所述客户端 MPD请求消息， 将对应的 MPD发送 给客户端， 以便于客户端根据所述对应的 MPD获取所需要的媒体分片， 使得客户端支持更 长时间范围的时移和回看 , 同时可将 MPD的大小保持在可接受的范围内。
实施例三：
参阅图 3, 本发明实施例三提供一种客户端， 该客户端可以设置在用户终端 （例如， 可 以包括移动终端 , 固定终端机顶盒等）设备中； 该客户端包括：
发送模块 301 , 用于向媒体服务器发送直播 MPD请求消息； 客户端请求获取直播 MPD, 例如根据直播 MPD的 URL获取地址。 由于 MPD经常需更新， 此步骤根据需要可重复多次。
接收模块 302, 用于接收媒体服务器返回的包含当前时间段的 MPD的响应消息， 所述 MPD中还包含其它时间段所对应的媒体展现信息；此步骤已在 A2详细描述，这里不在赘述。
确定模块 303,用于确定当前需要请求媒体分片的时刻超出所述 MPD所对应的时间范围， 根据所述其它时间段的媒体展现信息， 确定当前需要请求媒体分片对应的媒体展现信息； 此 步骤已在 A3详细描述， 这里不在赞述。
获取模块 304, 用于根据所述当前需要请求的媒体分片对应的媒体展现信息， 获取对应的 MPD, 并根据所述获取到的对应的 MPD, 向媒体服务器请求当前需要请求的媒体分片。 此步 骤已在 A4详细描述， 这里不在赞述。
在实际应用的实例中所述客户端还可以进一步包括： 选择模块 305用于判断 MPD中 是否存在多个满足包括请求媒体分片时刻的时间段所对应的媒体展现信息， 若存在多个， 客 户端可以 >据选择策略从多个媒体展现信息中选择一个； 具体的选择策略可以包括下述之一 或其组合： 如媒体展现信息中包括可访问时间， 则所述当前时刻需满足可访问时间要求； 如 媒体展现信息对应的时间段存在重复， 则可以选择 MPD中时间段与客户端维护的本地播放 列表时间段重合度最小的一个； 如存在几个 MPD与本地播放列表时间段都没有重合或者重 合度一样， 则随机选择一个。
实施例三采用发送模块 301向媒体服务器发送直播 MPD请求消息； 接收模块 302接收 服务器返回的包含当前时间段的 MPD的响应消息； 确定模块 303确定当前需要请求的媒体 分片的时刻超出所述 MPD所对应的时间范围， 根据所述其它时间段的媒体展现信息， 确定 当前需要请求媒体分片对应的媒体展现信息； 获取模块 304根据所述当前需要请求的媒体分 片对应的媒体展现信息， 获取对应的 MPD, 并根据所述获取到的对应的 MPD, 向媒体服务 器请求当前需要请求的媒体分片。 这使得客户端支持更长时间范围的时移和回看， 同时可将 MPD的大小保持在可接受的范围内。
实施例四：
参阅图 4, 本发明实施例二提供一种媒体服务器， 该媒体服务器包括：
接收模块 401 , 用于接收客户端发送的直播媒体展现描述 MPD请求消息； 由于 MPD经 常需更新， 此步骤根据需要可重复多次。 所述接收模块还用于接收所述客户端发送的 MPD 请求消息； 当客户端从服务器返回的 MPD信息中获取 MPD的 URL地址并保存， 所述接收 模块接收相应时间段的 MPD请求；
发送模块 402, 用于向所述客户端发送包含当前时间段的 MPD的响应消息， 所述 MPD 中还包含其它时间段的媒体展现信息； 此步骤已在 A2详细描述， 这里不在赘述， 所述发送 模块 402还用于根据客户端发来的 MPD请求消息， 将所述 MPD请求消息对应的 MPD发送 给客户端， 以便于客户端根据所述 MPD获取相应的媒体内容， 此步骤已在 A4详细描述， 这 里不在赘述。 实施例四采用接收模块 401接收客户端发送的直播媒体展现描述信息 MPD请求消息； 发送模块 402向所述客户端发送包含当前时间段的 MPD的响应消息， 所述响应消息中包含 其它时间段的媒体展现信息； 接收模块 401接收所述客户端发送的 MPD媒体展现信息请求 消息； 发送模块 402根据所述 MPD请求消息， 将所述 MPD请求消息对应的 MPD发送给客 户端 , 以便于客户端 >据所述 MPD获取相应的媒体内容， 使得客户端支持更长时间范围的 时移和回看 , 同时可将 MPD的大小保持在可接受的范围内。
实施例五：
参阅图 5, 本发明实施例提供一种在动态 HTTP流传输方案中更有效支持时移的方法， 包括客户端和媒体服务器， 具体步骤为：
501、 客户端向媒体服务器发送直播 MPD请求消息；
客户端请求获取直播 MPD, 例如根据直播 MPD的 URL地址构造请求消息； 向媒 体服务器发送构造后的 MPD请求消息。
502、 服务器返回当前最新的 MPD;
同时在 MPD中还包括其它时间段的媒体展现信息， 这里其它时间段可以细分为两 种情况：
( 1 )客户端完全基于当前获取的最新 MPD来创建本地播放列表， 那么当前 MPD所包括 的时间区间 [a, b]之外的其他时间段其它时间段， 例如对直播一般为时间点 a之前； （ 2 )客户 端创建的本地播放列表除了基于当前获取的最新的 MPD,还能基于前面所获取的 MPD中包括 的时间段。 对于一个在直播开始以后才接入的客户端， 它最多只能创建从其接收到的第一个 MPD到当前最新的 MPD所包括的所有时间段范围内的播放列表， 假设为时间区间 [a，， b] (其 中 a，≤a ) , 那么对于超出区间 [a，，b]之外的其他时间其它时间段（例如 <a，） 。 又或者， 虽然一 个直播客户端在直播开始就已经接入， 但其维护的本地播放列表有总时长限制 （如
LocalListDuration ) , 那么其维护的时间区间为 [b-LocalListDuration, b], 这个区间之外的其他 时间都属于其它时间段。
503、 客户端向服务器请求媒体分片；
客户端处理 MPD得到相应的播放列表及获取媒体分片的 URL地址； 并根据 URL 地址向服务器请求媒体分片。
504、 服务器向客户端返回与请求对应的媒体分片；
这里 501和 502, 503和 504可 >据实施情况重复多次。
505、 客户端请求时移范围内、 但当前 MPD不包括的媒体分片， 根据其它时间段的媒体 展现信息， 确定当前需要请求媒体分片对应的媒体展现信息；
如图 6所示， 当客户端请求直播服务器支持时移范围内、但当前最新 MPD中并不包 括时间段的其他时间段中媒体分片时， 例如， 在当前 MPD中只包括了最近 10分钟的媒体展 现描述信息，但客户端却想从距离现在 20分钟的地方开始时移观看，而对于只 >据当前 MPD 创建播放列表的客户端 , 或者虽可根据所有接收到的 MPD创建播放列表但刚刚接入直播的 客户端， 现有技术方案就无法实现。
601 : 客户端判断请求媒体分片是否包括在当前 MPD中 （对于本地播放列表不只根 据当前更新的 MPD创建的情况， 可改为判断请求的媒体分片是否包括在本地播放列表中）。 例如， 客户端维护的播放列表的时间范围是 [a, b] , 若请求的媒体分片开始时间为 c ( c < a ), 则超出时间范围； 若请求的媒体分片开始时间为 d ( a≤ d≤ b )，则没有超出时间范围。
602: 判断 MPD中是否提供时移范围内除当前 MPD中包括时间段之外的其他时间 段 MPD的媒体展现信息。 例如对于一个超出当前 MPD时间范围的时间 c, 若存在一个媒体 展现信息覆盖的时间范围 [e, f] , 并满足条件 e < c < f , 则认为在 MPD中提供了这样的媒体展 现信息， 继续下面的处理流程， 否则认为没有提供满足条件的 MPD信息， 客户端提示用户 无法支持所述请求时间的媒体分片 606。
603: 判断 MPD中是否存在多个满足包括请求媒体分片时刻的时间段对应的媒体展 现信息， 若存在多个， 客户端根据选择策略从多个 MPD信息中选择一个 604。 这可能要区分 多种情况： ( 1 )如果 MPD信息中还包括可访问时间（如 availablilityStart, availabilityEnd可选）， 则当前时间需满足可访问时间的要求； （2 )如果 MPD之间存在时间段的重复， 则可以选择 MPD中时间段与客户端维护的本地播放列表时间段重合度最小的一个； （ 3 )如果几个 MPD 与本地播放列表时间段都没有重合或者重合度都一样 , 则可以随机选择一个， 例如满足条件 的第一个， 或开始时间最接近请求媒体分片时间的， 或距离当前时间最远的， 等等； （4 )其 他可能的选择策略。
例如，当前最新的 MPD中包括距离直播开始 50~60分钟共 10分钟的媒体展现描述信息， 直播服务器时移支持时长为 30 分钟， 则 MPD 中所包括的附加 MPD信息用 XML元素 <previousMPD>提供， 提供距离直播开始时间 30~50分钟其他时间段的媒体展现信息的一个 示例: ^下：
<previousMPD>
<MPDInfo>
<interval>
<startTime>PT30M</startTime>
<endTime>PT50M</endTime> </interval>
Figure imgf000011_0001
/MPDAddress>
</MPDInfo>
</previousMPD>
或者先前时间段的每个 MPD中只包括 10分钟时间段的媒体展现描述信息， 则需要包括 两个前面 MPD的信息， 示例如下：
<previousMPD>
<MPDInfo>
<interval>
<startTime>PT30M</startTime>
<endTime>PT40M</endTime>
</interval>
<MPDAddress> h t tp ://wviiv. movie. co /Experience/exampleL i ve__preMPDl__ URL pd </MPDAddress>
</MPDInfo>
<MPDInfo>
<interval>
<startTime>PT40M</startTime>
<endTime>PT50M</endTime>
</interval>
<MPDAddress> h t t ://wviiv. movie. com/Experience/exampleL i ve__preMPD2__ URL mpd </MPDAddress>
</MPDInfo>
</previousMPD>
605: 客户端根据媒体展现信息获取对应 MPD的 URL地址。
506、 客户端根据上述步骤 505所得到的 MPD的 URL地址， 向服务器请求相应时间段 的 MPD;
客户端根据从上述步骤 505中得到的 MPD的 URL地址， 并向服务器请求相应时间段的 MPD;
507、 服务器向客户端返回与请求相应的 MPD;
客户端处理接收的 MPD, 得到相应的播放列表及获取媒体分片的 URL地址， 并把 得到的播放列表添加到本地维护的播放列表中 （或替换本地维护的播放列表）。
508、 客户端向服务器请求媒体分片；
客户端首先根据步骤 505时所需要请求媒体分片的时刻，构造相应媒体分片请求并 发送给服务器。
509、 服务器向客户端返回对应的媒体分片。
服务器返回与请求对应的媒体分片。 然后客户端可接着该媒体分片依次请求后续的媒体分片，直到遇到用户其他播放控 制操作或者本地播放列表中的媒体分片全部请求并播放完成或者遇到 MPD更新等，步骤 508 和 509可根据实施重复多次。
实施例五采用向媒体服务器发送直播 MPD请求信息； 接收服务器返回的包含当前时间 段的 MPD的响应消息， 所述 MPD中还包含时移范围内其它时间段的媒体展现信息； 确定当 前需要请求的媒体分片的时刻超出所述 MPD所对应的时间范围， 根据所述其它时间段的媒 体展现信息， 确定当前需要请求的媒体分片对应的媒体展现信息； 根据所述当前需要请求的 媒体分片对应的媒体展现信息， 获取对应的 MPD, 并根据所述获取到的对应的 MPD, 向媒 体服务器请求当前需要请求的媒体分片。 使得直播服务器提供较长时间段的时移支持， 但在 MPD中只需包括一小部分时间段的媒体展现描述信息，而将包括其他时间段的媒体分片描述 信息的 MPD获取等信息包括在媒体展现信息中。 在客户端需要时 , 可以通过这些的媒体展 现信息去获取对应时间段的 MPD。使得既能支持更长时间范围的时移和回看，同时又将 MPD 的大小保持在可接受的范围内。
上述实施例给出在 MPD提供直播时移范围内、 当前最新 MPD不包括的时间段的其他 时间段的媒体展现信息， 这样直播服务器提供的 MPD 即可支持较大时间范围的时移， 同时 又不必在 MPD 中包括时移时长内所有时间段的媒体展现描述信息， 实现了支持更大时间范 围的时移、 同时不显著增加 MPD 大小和客户端处理的网络开销， 例如， 减小客户端更新处 理 MPD的网络负担。 在该实施例中， 可以由直播服务器来提供所需的先前时间段的 MPD以 及相应的媒体分片， 内容准备服务器在更新的 MPD中提供这些附加的 MPD信息。
实施例七：
对于客户端回看超过服务器时移范围的时间段的媒体内容， 直播服务器可能已无法再 提供其维护的时移范围之外的媒体内容， 需要由点播（VoD, Video on Demand )服务器来提供 超出时移范围的媒体分片。 另外， 由于这时直播尚未完全结束， 因此暂时还无法提供相应媒 体展现的完整点播服务， 在这种情况下， 可以将已经播出的部分， 按照时长进行划分， 提供 几个不同的点播节目 , 并将点播节目的 MPD获取信息包括在 MPD中， 客户端可根据这些点播 节目的 MPD获取信息从直播无缝切换到点播。
参阅图 7, 本发明实施例提供一种在动态 HTTP流传输方案中直播点播无缝切换的方法， 包括客户端， 直播服务器和点播服务器， 具体步骤为：
701、 客户端向直播服务器发送直播 MPD请求消息； 客户端请求获取直播 MPD, 例如根据直播 MPD的 URL获取地址构造 MPD请求 消息；
702、 直播服务器返回当前最新的 MPD;
同时 MPD中还包括其它时间段的 MPD信息， 这里其它时间段可以细分为两种情况： ( 1 )客户端完全基于当前获取的最新 MPD来创建本地播放列表， 那么当前 MPD所包括 的时间区间 [a, b]之外的其他时间段其它时间段， 例如对直播一般为时间点 a之前； （ 2 )客户 端创建的本地播放列表除了基于当前获取的最新的 MPD,还能基于前面所获取的 MPD中包括 的时间段。 对于一个在直播开始以后才接入的客户端， 它最多只能创建从其接收到的第一个 MPD到当前最新的 MPD所包括的所有时间段范围内的播放列表， 假设为时间区间 [a，， b] (其 中 a，≤a ) , 那么对于超出区间 [a，，b]之外的其他时间其它时间段（例如 <a，） 。 又或者， 虽然一 个直播客户端在直播开始就已经接入， 但其维护的本地播放列表有总时长限制 （如
LocalListDuration ) , 那么其维护的时间区间为 [b-LocalListDuration, b], 这个区间之外的其他 时间都属于其它时间段。
703、 客户端向直播服务器请求媒体分片；
客户端处理直播 MPD得到相应的播放列表及获取媒体分片的 URL地址； 并根据 URL地址请求媒体分片。
704、 直播服务器向客户端返回媒体分片；
这里 701和 702, 703和 704可以 据实施情况重复多次。
705、 客户端请求超出直播服务器支持时移时长范围的媒体分片时， 根据 MPD中提供时 移范围之外、 包括需要请求媒体分片时刻的其他时间段点播 MPD 的媒体展现信息， 确定当 前需要请求媒体分片对应的媒体展现信息； 当客户端需回看超过直播时移范围的其他时 间段的媒体分片， 直播服务器可能已无法再提供其维护的时移范围之夕卜的媒体分片， 需要由 相应的点播服务器来提供超出直播时移范围的媒体分片。 但由于这时直播尚未完全结束， 因 此暂时还无法提供相应媒体展现的完整点播服务， 在这种情况下， 可以将已经播出的部分， 按照时长进行划分， 作为几个不同的点播节目提供， 并将所述点播节目的媒体展现信息包括 在直播 MPD中 , 客户端可根据这些点播节目的媒体展现信息从直播无缝切换到点播。
客户端判断 MPD 中是否提供时移范围之外、 包括需要请求媒体分片时刻的其他时间段 点播 MPD 的媒体展现信息， 如果没有提供满足条件的媒体展现信息， 则提示用户无法支持 所述请求时间的媒体分片； 如有符合条件的媒体展现信息， 则判断直播 MPD 中是否存在多 个满足条件的媒体展现信息， 若存在多个满足条件的媒体展现信息则客户端根据选择策略从 多个媒体展现信息中选择一个， 这可能要区分多种情况： （ 1 )如果在媒体展现信息中还包括 可访问时间（如 availablilityStart, availabilityEnd可选），则当前时间需满足可访问时间要求（例 如包括完整节目的点播展现在直播没有结束时就无法提供， 因此其可访问时间目前无法满足 要求）； （2 )如果多个媒体展现信息所对应的时间段存在重复， 则可以选择媒体展现信息对应 时间段与客户端维护的本地播放列表时间段重合度最小的一个； （ 3 )如果几个媒体展现信息 所对应的时间段与本地播放列表时间段都没有重合或者重合度一样 , 则可以随机选择一个， 例如满足条件的第一个， 或开始时间最接近请求媒体分片时间的， 或距离当前时间最远的， 等等； （4 )其他可能的选择策略；
客户端获取该点播 MPD的相应 URL地址， 利用获取的 URL, 客户端可以进一步获取到 与之相应的点播 MPD。
一个实施例中 , 假如直播服务器提供 30分钟时移时长， 如果 30分钟时移时长之前时间 段的内容也有相应的点播提供，则包括的附加媒体展现信息可用 XML元素 <relatedVoD>提供， 在直播进行了 90分钟之后， 提供距直播开始时间到 60分钟时间段的点播媒体展现信息的一 个示例如下：
<relatedVoD>
<MPDInfo>
<interval>
<startTime> PTOS</startTime>
<endTime>PT60M</endTime>
</interval>
<MPDAddress> h t tp ://www. movie. com/Experience/ example VoD—preMPD— URL. pd</ MPDAddress>
</MPDInfo>
</relatedVoD>
或者在每个点播 MPD中只包括 30分钟时间段的媒体展现描述信息， 则需要包括两个前 面时间段的媒体展现信息 , 示例如下：
<relatedVoD>
<MPDInfo>
<interval>
<startTime> PTOS</startTime>
<endTime> PT 30 M</endTime>
</interval>
<MPDAddress> ht tp : //www, movie. CAm/Experience/exampleVoD preMPDl URL. mpd< /MPDAddress>
</MPDInfo>
<MPDInfo>
<interval>
<startTime>PT30M</startTime>
<endTime> PT60 M</endTime> </interval>
<MPDAddress> h t tp ://www. movie. com/Experience/ example VoD preMPD2 URL. mpd< /MPDAddress>
</MPDInfo>
</relatedVoD>
假设直播媒体展现的总时长为 4 小时 （其开始时间为" 2010-05-01T18:00:00Z" ), 也可同 时提供包括整个直播媒体展现相应的点播媒体展现信息， 但需要包括可访问时间， 一个示例 如下：
<relatedVoD>
<MPDInfo>
<interval>
<startTime> PTOS</startTime>
<endTime>PT60M</endTime>
</interval>
<MPDAddress >http ://wv/w. movie. com/Experience/exampleVoD preMPD URL, mpd</ MPDAddress>
</MPDInfo>
<MPDInfo availablilityStart= "2010-05-01 T22: 00: 00Z">
<interval>
<startTime> PTOS</startTime>
<endTime>PT4H</endTime>
</interval>
<MPDAddress> http : //wv/w. movie. com/Experience/exampleCompleteVoD MPD URL. mpd</MPDAddress>
</MPDInfo>
</relatedVoD>
直播服务器和点播服务器可根据需要分开部署， 但也可部署在同一台服务器上。
706、 客户端向点播服务器请求相应时间段的 MPD;
707、 点播服务器向客户端返回与请求相应的 MPD;
客户端处理接收的点播 MPD, 得到相应的播放列表及获取媒体分片的 URL地址， 并把得到的播放列表添加到本地维护的播放列表中 （或替换更新本地维护的播放列表）。
708、 客户端向点播服务器请求媒体分片；
客户端首先根据步骤 705时所需要请求媒体分片的时刻，构造相应媒体分片请求并 发送给点播服务器。
709、 点播服务器向客户端返回与请求对应的媒体分片。
点播服务器返回与请求对应的媒体分片。
然后客户端可接着该媒体分片依次请求后续的媒体分片，直到遇到用户其他播放控 制操作或者播放列表中的媒体分片全部请求并播放完成或者遇到 MPD更新等， 因此步骤 708 和 709可 >据实施情况重复多次。
实施例七采用向直播服务器发送直播 MPD请求信息； 接收直播服务器返回的包含当前 时间段的 MPD的响应消息， 所述 MPD中还包含其它时间段的点播媒体展现信息； 确定当前 需要请求的媒体分片的时刻超出所述直播 MPD所对应的时间范围， 根据所述其它时间段的 点播媒体展现信息， 确定当前需要请求的媒体分片对应的媒体展现信息； 根据所述当前需要 请求的媒体分片对应的媒体展现信息 , 获取相应的点播 MPD, 并根据所述获取到的对应的 MPD, 向点播服务器请求当前需要请求的媒体分片。 使得客户端支持更长时间范围的回看， 同时可将 MPD的大小保持在可接受的范围内。 另一个实施例八 a为， 在 MPD中既提供直播时移范围内、 当前最新 MPD不包括的时间段 的其他时间段的直播媒体展现信息， 也能提供包括时移范围之外、 与直播媒体展现相应的前 面时间段的点播媒体展现信息 （即在 MPD中同时包括 <previousMPD>元素和 <relatedVoD> ), 客户端可以根据需要请求媒体分片对应的时刻， 来选择满足时间段要求的媒体展现信息， 获 取相应 MPD, 请求并播放相应的媒体分片。 实施例的流程可综合上述实施例六和实施例 7, 这里不再冗述。
实施例八：
在另外一个实际应用过程中， 例如， 在直播过程中， 用户由于暂停或者时移等操作， 等 到恢复观看时 , 已经超出了直播服务器提供业务的截止时间 , 直播服务器已无法继续提供服 务， 这时， 通过在 MPD中包括相关点播媒体展现信息， 客户端可以切换到点播服务继续观看。 具体请参看下述实施例描述。
参阅图 8, 本发明实施例提供一种在动态 HTTP流传输方案中直播点播无缝切换的方法， 包括客户端， 直播服务器和点播服务器， 具体步骤为：
801、 客户端向直播服务器发送直播 MPD请求消息；
客户端请求获取直播 MPD, 例如根据直播 MPD的 URL地址构造 MPD请求消息；
802、 直播服务器返回当前最新的 MPD;
同时 MPD中还包括其它时间段的点播媒体展现信息， 这里其它时间段可以细分为 两种情况：
( 1 )客户端完全基于当前获取的最新 MPD来创建本地播放列表， 那么当前 MPD所包括 的时间区间 [a, b]之外的其他时间段其它时间段， 例如对直播一般为时间点 a之前； （ 2 )客户 端创建的本地播放列表除了基于当前获取的最新的 MPD,还能基于前面所获取的 MPD中包括 的时间段。 对于一个在直播开始以后才接入的客户端， 它最多只能创建从其接收到的第一个
MPD到当前最新的 MPD所包括的所有时间段范围内的播放列表， 假设为时间区间 [a，， b] (其 中 a，≤a ) , 那么对于超出区间 [a，，b]之外的其他时间其它时间段（例如≤a，）。 又或者， 虽然一 个直播客户端在直播开始就已经接入， 但其维护的本地播放列表有总时长限制 （如
LocalListDuration ) , 那么其维护的时间区间为 [b-LocalListDuration, b], 这个区间之外的其他 时间都属于其它时间段。
803、 客户端向直播服务器请求媒体分片；
客户端处理直播 MPD得到相应的播放列表及获取媒体分片的 URL地址；根据 URL 地址请求媒体分片。
804、 直播服务器向客户端返回媒体分片；
这里 801和 802, 803和 804可以 据实施情况重复多次。
805、 客户端暂停或时移后， 再次请求媒体分片时超出直播服务的截止时间， 根据 MPD 中提供其他时间段 MPD的媒体展现信息， 确定当前需要请求媒体分片对应的媒体展现信息； 其详细处理步骤与上述图 7中的步骤 705非常类似， 区别之处为：
( 1 )客户端的媒体分片请求不再与直播进度直接相关 （因为直播已经结束）， 媒体分片 请求将与媒体展现直接相关， 即距离该媒体展现开始时间的偏移时间值； （2 )如果在 MPD 中包括了完整媒体展现的点播媒体展现信息， 现在已有完整的媒体展现可供使用。
806、 客户端向点播服务器请求相应时间段的点播 MPD;
807、 点播服务器向客户端返回与请求相应的 MPD;
客户端处理接收的点播 MPD, 得到相应的播放列表及获取媒体分片的 URL地址， 并把得到的播放列表添加到本地维护的播放列表中 （或替换更新本地维护的播放列表）。
808、 客户端向点播服务器请求媒体分片；
客户端首先根据步骤 805时所需要请求媒体分片的时刻，构造相应媒体分片请求并 发送给点播服务器。
809、 点播服务器向客户端返回与请求对应的媒体分片。
点播服务器返回与请求对应的媒体分片。
然后客户端可接着该媒体分片依次请求后续的媒体分片，直到遇到用户其他播放控 制操作或者播放列表中的媒体分片全部请求并播放完成或者遇到 MPD更新等。 步骤 808和 809可根据实施情况重复多次。
实施例八采用向直播媒体服务器发送直播 MPD请求消息； 接收直播服务器返回的包含 当前时间段的 MPD的响应消息， 所述 MPD中还包含其它时间段的点播媒体展现信息； 确定 当前需要请求媒体分片时已超出所述 MPD所对应的直播服务截止时间， 根据所述其它时间 段的点播媒体展现信息， 确定当前需要请求的媒体分片对应的媒体展现信息； 根据所述当前 需要请求的媒体分片对应的媒体展现信息， 获取对应的点播 MPD, 并根据所述获取到的对应 的 MPD, 向媒体服务器请求当前需要请求的媒体分片。 使得客户端由于暂停或时移等操作， 在超出直播服务器提供服务的截止时间后， 能从直播无缝切换到点播， 仍可继续提供媒体服 务。 通过以上的实施方式的描述， 本领域普通技术人员可以理解： 实现上述实施例方法中的 全部或部分步骤是可以通过程序来指令相关的硬件来完成， 所述的程序可以存储于一计算机 可读取存储介质中， 该程序在执行时， 包括如上述方法实施例的步骤， 所述的存储介质， 如： ROM/RAM, 磁磔、 光盘等。
以上所述， 仅为本发明的具体实施方式， 但本发明的保护范围并不局限于此， 任何熟悉 本技术领域的技术人员在本发明揭露的技术范围内， 可轻易想到变化或替换， 都应涵盖在本 发明的保护范围之内。 因此， 本发明的保护范围应以权利要求的保护范围为准。

Claims

权利要求书
1、 一种在动态 HTTP流传输方案中支持时移回看方法， 其特征在于，
向媒体服务器发送直播媒体展现描述 MPD请求消息；
接收媒体服务器返回的包含当前时间段的 MPD的响应消息， 所述 MPD中还包含其它时 间段的媒体展现信息；
确定当前需要请求媒体分片的时刻超出所述 MPD所对应的时间范围， 根据所述其他时 间段的媒体展现信息， 确定当前需要请求媒体分片对应的媒体展现信息；
根据所述当前需要请求的媒体分片对应的媒体展现信息， 获取对应的 MPD, 并 >据所述 获取到的 MPD, 向媒体服务器请求当前需要请求的媒体分片。
2、 如权利要求 1所述的方法， 其特征在于， 所述其它时间段包括至少下述情况之一： 在当前时间段之外且在媒体服务器维护的时移范围之内的时间段；
从直播媒体展现开始后且在直播服务器维护的时移范围之夕卜的时间段； 以及
暂停恢复播放后或时移观看过程中超出了提供直播服务的最后截止时间。
3、如权利要求 1所述的方法，其特征在于，所述其它时间段所对应的媒体展现信息包括： 所述 MPD所对应的时间段信息， 所述 MPD的获取地址， 还可包括所述 MPD的可访问 时间。
4、 如权利要求 1所述的方法， 其特征在于， 如果其它时间段所对应的媒体展现信息存在 多个， 所述的方法进一步包括：
判断 MPD中是否存在满足所述需要请求的媒体分片的时间要求的多个其它时间段所对 应的媒体展现信息；
若存在， 则根据选择策略从所述其它时间段所对应的媒体展现信息中选择一个。
5、 如权利要求 4所述的方法， 其特征在于， 所述根据选择策略从所述其它时间段所对 应的媒体展现信息中选择一个包括：
如媒体展现信息中包括可访问时间 , 则所述当前时间段需满足可访问时间要求； 如媒体展现信息对应的时间段存在重复， 则可以选 ^某体展现信息中时间段与客户端维 护的本地播放列表时间段重合度最小的一个；
如存在几个媒体展现信息对应时间段与本地播放列表时间段都没有重合或者重合度一 样， 则随机选择一个。
6、 如权利要求 1所述的方法， 其特征在于， 所述获取相应的 MPD具体为：
从直播服务器获取的、 在当前 MPD对应时间段之夕卜且在媒体服务器维护的时移范围之 内的其他时间段直播 MPD; 和 /或，
从点播服务器获取的、 超出直播服务器维护的时间范围之夕卜的其他时间段的点播 MPD;
7、如权利要求 6所述的方法，其特征在于，所述与当前直播媒体展现相对应的点播 MPD, 具体为： 包括直播媒体展现部分时间段的点播 MPD;
或者，
包括媒体展现全部时间范围的完整点播 MPD。
8、 一种在动态 HTTP流传输方案中支持时移回看的方法， 其特征在于，
接收客户端发送的直播 MPD请求消息；
向所述客户端发送包含当前时间段的 MPD的响应消息， 所述 MPD中包含其它时间段的 媒体展现信息；
接收所述客户端发送超出所述 MPD对应时间段的其他时间段 MPD请求消息； 根据所述媒体展现信息 , 将所述媒体展现信息对应的 MPD发送给客户端 , 以便于客户 端根据所述媒体展现信息对应的 MPD获取相应的媒体分片。
9、 如权利要求 8所述的方法， 其特征在于， 所述媒体展现信息至少包括，
所述 MPD所对应的时间段信息， 所述 MPD的获取地址；
所述媒体展现信息进一步包括所述 MPD的可访问时间。
10、 一种客户端， 其特征在于， 所述客户端包括，
发送模块， 用于向媒体服务器发送 MPD请求消息；
接收模块， 用于接收媒体服务器返回的包含当前时间段的 MPD的响应消息， 所述 MPD 中还包含其它时间段的媒体展现信息；
确定模块， 用于确定当前需要请求媒体分片的时刻超出所述 MPD所对应的时间范围， 根据所述其它时间段的媒体展现信息， 确定当前需要请求媒体分片对应的媒体展现信息； 获取模块， 用于根据所述当前需要请求的媒体分片对应的媒体展现信息， 获取对应的 MPD, 并根据所述获取到的 MPD, 向媒体服务器请求当前需要请求的媒体分片。
11、 如权利要求 10所述的客户端， 所述客户端进一步包括，
选择模块， 用于： 如媒体展现信息中包括可访问时间， 则所述当前时间段需满足可访问 时间要求； 如媒体展现信息对应的时间段存在重复， 则可以选 ^某体展现信息对应的时间段 与客户端维护的本地播放列表时间段重合度最小的一个； 如存在几个媒体展现信息对应的时 间段与本地播放列表时间段都没有重合或者重合度一样， 则随机选择一个。
12、 一种媒体服务器， 其特征在于， 所述媒体服务器包括， 接收所述客户端发送的 MPD 信息请求消息；
接收模块， 用于接收客户端发送的 MPD请求消息；
发送模块， 用于向所述客户端发送包含当前时间段的 MPD 的响应消息， 所述响应消息 中包含其它时间段的媒体展现信息； 根据所述媒体展现消息， 将与所述媒体展现消息对应的 MPD发送给客户端， 以便于客户端根据所述对应的 MPD获取相应的媒体分片。
PCT/CN2011/075284 2010-08-17 2011-06-03 一种在动态http流传输方案中支持时移回看的方法和装置 WO2011147352A1 (zh)

Priority Applications (5)

Application Number Priority Date Filing Date Title
EP11786124.5A EP2592809B1 (en) 2010-08-17 2011-06-03 Method and device for supporting time shift review in dynamic hypertext transfer protocol streaming transmission solution
PL11786124T PL2592809T3 (pl) 2010-08-17 2011-06-03 Sposób i urządzenie do wspierania przeglądania z przesunięciem czasowym w rozwiązaniu transmisji strumieniowej protokołu dynamicznego przesyłania hipertekstu
ES11786124.5T ES2524001T3 (es) 2010-08-17 2011-06-03 Método y dispositivo para soportar un análisis de desplazamiento temporal en una solución de transmisión en tiempo real del protocolo de transferencia de hipertexto dinámico
US13/768,002 US8683071B2 (en) 2010-08-17 2013-02-15 Method and apparatus for supporting time shift playback in adaptive HTTP streaming transmission solution
US14/162,153 US8984570B2 (en) 2010-08-17 2014-01-23 Method and apparatus for supporting time shift playback in adaptive HTTP streaming transmission solution

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN2010102555660A CN102130936B (zh) 2010-08-17 2010-08-17 一种在动态http流传输方案中支持时移回看的方法和装置
CN201010255566.0 2010-08-17

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US13/768,002 Continuation US8683071B2 (en) 2010-08-17 2013-02-15 Method and apparatus for supporting time shift playback in adaptive HTTP streaming transmission solution

Publications (1)

Publication Number Publication Date
WO2011147352A1 true WO2011147352A1 (zh) 2011-12-01

Family

ID=44268824

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2011/075284 WO2011147352A1 (zh) 2010-08-17 2011-06-03 一种在动态http流传输方案中支持时移回看的方法和装置

Country Status (8)

Country Link
US (2) US8683071B2 (zh)
EP (3) EP3029909B1 (zh)
CN (1) CN102130936B (zh)
ES (3) ES2646562T3 (zh)
HU (1) HUE027786T2 (zh)
NO (1) NO3029909T3 (zh)
PL (2) PL2592809T3 (zh)
WO (1) WO2011147352A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104125516A (zh) * 2013-04-24 2014-10-29 华为技术有限公司 媒体文件接收、媒体文件发送方法和装置及系统

Families Citing this family (40)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9712891B2 (en) * 2011-11-01 2017-07-18 Nokia Technologies Oy Method and apparatus for selecting an access method for delivery of media
US9270718B2 (en) * 2011-11-25 2016-02-23 Harry E Emerson, III Internet streaming and the presentation of dynamic content
US20130182643A1 (en) * 2012-01-16 2013-07-18 Qualcomm Incorporated Method and system for transitions of broadcast dash service receptions between unicast and broadcast
CN102547481B (zh) * 2012-02-10 2014-08-20 中国联合网络通信集团有限公司 移动流媒体在线播放列表设置以及内容的快速切换方法及系统
KR101667950B1 (ko) * 2012-10-29 2016-10-28 알까뗄 루슨트 모바일 ｈｔｔｐ 적응형 스트리밍을 갖는 무선 네트워크들에서의 정체 관리를 위한 방법들 및 장치들
US9357239B2 (en) 2012-11-16 2016-05-31 Adobe Systems Incorporated Converting live streaming content to video-on-demand streaming content
WO2014113603A2 (en) * 2013-01-16 2014-07-24 Huawei Technologies Co., Ltd. Storing and transmitting content for downloading and streaming
KR20140118667A (ko) 2013-03-29 2014-10-08 삼성전자주식회사 디스플레이장치 및 그 제어방법
US20140298393A1 (en) * 2013-03-29 2014-10-02 Samsung Electronics Co., Ltd. Display apparatus and control method thereof
CA2916878A1 (en) * 2013-07-19 2015-01-22 Sony Corporation Information processing device and method
US9432427B2 (en) * 2013-07-25 2016-08-30 Futurewei Technologies, Inc. System and method for effectively controlling client behavior in adaptive streaming
CN104462128B (zh) * 2013-09-22 2018-04-13 腾讯科技（深圳）有限公司 多媒体文件处理的方法、装置和终端设备
CN103533444A (zh) * 2013-10-25 2014-01-22 乐视网信息技术（北京）股份有限公司 一种支持时移播放的方法及装置
CN103699583B (zh) * 2013-12-05 2018-08-03 乐视网信息技术（北京）股份有限公司 一种实现直播时移的方法及电子设备
CN104717555B (zh) * 2013-12-11 2018-01-02 华为技术有限公司 视频码流的获取方法及装置
CN103747285A (zh) * 2013-12-27 2014-04-23 乐视网信息技术（北京）股份有限公司 一种节目播放方法和服务端、客户端
CN103813185B (zh) * 2014-01-26 2019-01-25 中兴通讯股份有限公司 一种分段节目快速分发的方法、服务器及客户端
US9900362B2 (en) 2014-02-11 2018-02-20 Kiswe Mobile Inc. Methods and apparatus for reducing latency shift in switching between distinct content streams
US9432431B2 (en) * 2014-03-18 2016-08-30 Accenture Global Servicse Limited Manifest re-assembler for a streaming video channel
US9866608B2 (en) 2014-03-24 2018-01-09 Qualcomm Incorporated Processing continuous multi-period content
CN105025330B (zh) * 2014-04-30 2018-04-10 深圳Tcl新技术有限公司 基于dash协议的媒体文件播控方法和装置
US10057618B2 (en) * 2014-06-06 2018-08-21 Microsoft Technology Licensing, Llc System for filtering media manifests using manifest attributes
US10185467B2 (en) 2014-08-28 2019-01-22 Nagravision S.A. Intelligent content queuing from a secondary device
US9894130B2 (en) * 2014-09-23 2018-02-13 Intel Corporation Video quality enhancement
CN104506924B (zh) * 2014-12-23 2018-09-11 成都德芯数字科技股份有限公司 一种高集成度的iptv系统及其工作方法
WO2016110324A1 (en) * 2015-01-07 2016-07-14 Telefonaktiebolaget Lm Ericsson (Publ) An improved method and apparatus for trick-play in abr streaming
US10565248B2 (en) * 2015-03-09 2020-02-18 Verizon Patent And Licensing Inc. Time-shifted playback for over-the-top linear streaming
CN104883625B (zh) * 2015-06-12 2018-03-09 腾讯科技（北京）有限公司 信息展示方法、终端设备、服务器和系统
CN104935595B (zh) * 2015-06-16 2019-10-15 华为技术有限公司 内容项聚合方法和相关装置及通信系统
CN105872721A (zh) * 2015-12-14 2016-08-17 乐视云计算有限公司 起播速度的处理方法及装置
CN107566854B (zh) * 2016-06-30 2020-08-07 华为技术有限公司 一种媒体内容的获取和发送方法及装置
CN107959862B (zh) * 2016-10-14 2020-05-22 上海交通大学 基于广播系统的媒体点播模式控制方法
CN107483974B (zh) * 2017-08-29 2020-04-24 深圳市茁壮网络股份有限公司 一种服务处理方法及系统
CN108419136A (zh) * 2018-03-09 2018-08-17 青岛海信电器股份有限公司 一种网络直播流的seek实现方法及装置
CN110858910B (zh) * 2018-08-23 2022-05-27 广州虎牙信息科技有限公司 直播视频的显示方法、装置、设备及存储介质
CN109729387B (zh) * 2019-01-07 2021-05-14 烽火通信科技股份有限公司 基于hls协议的网络直播在故障恢复后的播放方法及系统
FR3094167B1 (fr) * 2019-03-18 2021-04-23 Ateme Procédé de gestion de contenus multimédia et dispositif pour la mise en œuvre du procédé
US11265586B2 (en) * 2019-05-06 2022-03-01 Apple Inc. Skipping segments in playlists
CN112788353B (zh) * 2020-12-28 2022-06-14 未来电视有限公司 直播时移处理方法、装置、电子设备和可读存储介质
CN113038196A (zh) * 2021-03-17 2021-06-25 大陆投资(中国)有限公司 在通信网络中传输媒体数据的发送方设备和接收方设备

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101552796A (zh) * 2008-03-31 2009-10-07 华为技术有限公司 一种时移操作方法和装置
CN101588473A (zh) * 2009-06-18 2009-11-25 北京浪弯融科科技有限责任公司 多媒体时移播放方法及系统
CN102055789A (zh) * 2009-11-09 2011-05-11 华为技术有限公司 实现基于http的流媒体业务的方法、系统和网络设备

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9380096B2 (en) * 2006-06-09 2016-06-28 Qualcomm Incorporated Enhanced block-request streaming system for handling low-latency streaming
US9432433B2 (en) * 2006-06-09 2016-08-30 Qualcomm Incorporated Enhanced block-request streaming system using signaling or block creation
US9386064B2 (en) * 2006-06-09 2016-07-05 Qualcomm Incorporated Enhanced block-request streaming using URL templates and construction rules
US9209934B2 (en) * 2006-06-09 2015-12-08 Qualcomm Incorporated Enhanced block-request streaming using cooperative parallel HTTP and forward error correction
CN100568956C (zh) * 2006-11-15 2009-12-09 中兴通讯股份有限公司 一种流媒体快速播放的方法
CN101459809B (zh) * 2008-11-26 2010-06-23 北京惠信博思技术有限公司 一种数字电视节目播放的方法和系统
US9917874B2 (en) * 2009-09-22 2018-03-13 Qualcomm Incorporated Enhanced block-request streaming using block partitioning or request controls for improved client-side handling
US20110096828A1 (en) * 2009-09-22 2011-04-28 Qualcomm Incorporated Enhanced block-request streaming using scalable encoding
CN102055773B (zh) * 2009-11-09 2013-10-09 华为技术有限公司 实现基于http的流媒体业务的方法、系统和网络设备
US9319448B2 (en) * 2010-08-10 2016-04-19 Qualcomm Incorporated Trick modes for network streaming of coded multimedia data
EP2614653A4 (en) * 2010-09-10 2015-04-15 Nokia Corp METHOD AND APPARATUS FOR ADAPTIVE CONTINUOUS DIFFUSION
EP2661866A4 (en) * 2011-01-07 2014-10-15 Nokia Corp METHOD AND DEVICE FOR PRESENTING SIGNALING

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101552796A (zh) * 2008-03-31 2009-10-07 华为技术有限公司 一种时移操作方法和装置
CN101588473A (zh) * 2009-06-18 2009-11-25 北京浪弯融科科技有限责任公司 多媒体时移播放方法及系统
CN102055789A (zh) * 2009-11-09 2011-05-11 华为技术有限公司 实现基于http的流媒体业务的方法、系统和网络设备

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
"HTTP streaming - text change to S4-100185 S4-AHI176", 3GPP, 23 February 2010 (2010-02-23), Retrieved from the Internet <URL:http://www.3gpp.org/ftp/tsg sa/WG4 CODEC/Ad-hoc MBS/Dos AHI> *
See also references of EP2592809A4 *

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104125516A (zh) * 2013-04-24 2014-10-29 华为技术有限公司 媒体文件接收、媒体文件发送方法和装置及系统
EP2938091A4 (en) * 2013-04-24 2016-02-24 Huawei Tech Co Ltd METHOD AND DEVICE FOR RECEIVING AND SENDING A MEDIA FILE AND SYSTEM
JP2016519895A (ja) * 2013-04-24 2016-07-07 華為技術有限公司Ｈｕａｗｅｉ Ｔｅｃｈｎｏｌｏｇｉｅｓ Ｃｏ．，Ｌｔｄ． メディアファイル受信およびメディアファイル送信方法、装置、およびシステム
US9628547B2 (en) 2013-04-24 2017-04-18 Huawei Technologies Co., Ltd. Media file receiving and media file sending methods, apparatuses, and systems
KR101734168B1 (ko) * 2013-04-24 2017-05-11 후아웨이 테크놀러지 컴퍼니 리미티드 미디어 파일 수신 및 미디어 파일 송신 방법들, 장치들, 및 시스템들

Also Published As

Publication number Publication date
ES2581582T3 (es) 2016-09-06
EP2797287A1 (en) 2014-10-29
PL2592809T3 (pl) 2015-02-27
ES2524001T3 (es) 2014-12-03
EP2592809A1 (en) 2013-05-15
US8683071B2 (en) 2014-03-25
PL2797287T3 (pl) 2016-09-30
EP3029909A1 (en) 2016-06-08
US20130159421A1 (en) 2013-06-20
ES2646562T3 (es) 2017-12-14
EP2592809B1 (en) 2014-09-10
EP3029909B1 (en) 2017-08-09
HUE027786T2 (en) 2016-10-28
EP2592809A4 (en) 2013-09-18
US8984570B2 (en) 2015-03-17
CN102130936A (zh) 2011-07-20
CN102130936B (zh) 2013-10-09
EP2797287B1 (en) 2016-04-06
US20140137171A1 (en) 2014-05-15
NO3029909T3 (zh) 2018-01-06

Similar Documents

Publication Publication Date Title
WO2011147352A1 (zh) 一种在动态http流传输方案中支持时移回看的方法和装置
EP2391086B1 (en) Method and apparatus for playing live content
US9615119B2 (en) Method and apparatus for providing timeshift service in digital broadcasting system and system thereof
CA2702191C (en) Systems and methods for managing advertising content corresponding to streaming media content
WO2012071998A1 (zh) 一种内容分发网络中媒体文件下载方法及客户端
WO2012171507A1 (zh) 向客户端传输数据文件的方法和装置
JP2016519895A (ja) メディアファイル受信およびメディアファイル送信方法、装置、およびシステム
KR20120114016A (ko) 사용자 컨텐츠를 외부 단말기에서 네트워크 적응적으로 스트리밍하는 방법 및 장치
WO2011054319A1 (zh) 一种在httpstreaming系统中实现分层请求内容的方法，装置和系统
KR101705898B1 (ko) 디지털 방송 시스템에서 타임시프트 서비스 제공 방법 및 시스템
JPWO2016174960A1 (ja) 受信装置、送信装置、およびデータ処理方法
WO2016112641A1 (zh) 客户端、流媒体数据接收方法和流媒体数据传输系统
JPWO2017047434A1 (ja) 送信装置、受信装置、およびデータ処理方法
KR101705813B1 (ko) 무선 통신 시스템에서 멀티미디어 컨텐츠의 랜덤 액세스 방법 및 장치
EP2651123A1 (en) Personal client video recording device, personal network video recording device and methods for operation of a personal client video recording device and a personal network video recording device.
WO2011136703A1 (en) Method and arrangement for playing out a media object
JPWO2016174959A1 (ja) 受信装置、送信装置、およびデータ処理方法
WO2017114393A1 (zh) Http流媒体传输方法及装置
WO2017047433A1 (ja) 送信装置、受信装置、およびデータ処理方法
JP5787981B2 (ja) ライブコンテンツの効率よい再生装置及び方法

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: 11786124

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2011786124

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE