WO2016124130A1 - 一种异构网络传输下的动态时间窗口及缓存机制 - Google Patents

一种异构网络传输下的动态时间窗口及缓存机制 Download PDF

Info

Publication number
WO2016124130A1
WO2016124130A1 PCT/CN2016/073168 CN2016073168W WO2016124130A1 WO 2016124130 A1 WO2016124130 A1 WO 2016124130A1 CN 2016073168 W CN2016073168 W CN 2016073168W WO 2016124130 A1 WO2016124130 A1 WO 2016124130A1
Authority
WO
WIPO (PCT)
Prior art keywords
time
available
resource
request
signaling
Prior art date
Application number
PCT/CN2016/073168
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
Priority claimed from CN201510064427.2A external-priority patent/CN105991469B/zh
Priority claimed from CN201510341265.2A external-priority patent/CN106330751B/zh
Priority claimed from CN201510654384.3A external-priority patent/CN106572062B/zh
Priority claimed from CN201510698388.1A external-priority patent/CN106612453B/zh
Application filed by 上海交通大学 filed Critical 上海交通大学
Priority to US15/549,163 priority Critical patent/US10313738B2/en
Priority to JP2017541330A priority patent/JP6472892B2/ja
Priority to CA3004650A priority patent/CA3004650C/en
Priority to KR1020177024205A priority patent/KR101941900B1/ko
Publication of WO2016124130A1 publication Critical patent/WO2016124130A1/zh

Links

Images

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/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/433—Content storage operation, e.g. storage operation in response to a pause request, caching operations
    • H04N21/4331—Caching operations, e.g. of an advertisement for later insertion during playback
    • 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/231—Content storage operation, e.g. caching movies for short term storage, replicating data over plural servers, prioritizing data for deletion
    • H04N21/23106—Content storage operation, e.g. caching movies for short term storage, replicating data over plural servers, prioritizing data for deletion involving caching operations
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/235—Processing of additional data, e.g. scrambling of additional data or processing content descriptors
    • 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/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H04N21/23605—Creation or processing of packetized elementary streams [PES]
    • 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/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H04N21/2362—Generation or processing of Service Information [SI]
    • 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/242—Synchronization processes, e.g. processing of PCR [Program Clock References]
    • 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/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/4302—Content synchronisation processes, e.g. decoder synchronisation
    • H04N21/4307—Synchronising the rendering of multiple content streams or additional data on devices, e.g. synchronisation of audio on a mobile phone with the video output on the TV screen
    • H04N21/43079—Synchronising the rendering of multiple content streams or additional data on devices, e.g. synchronisation of audio on a mobile phone with the video output on the TV screen of additional data with content streams on multiple devices
    • 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/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/434—Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
    • H04N21/4345—Extraction or processing of SI, e.g. extracting service information from an MPEG stream
    • 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/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/435—Processing of additional data, e.g. decrypting of additional data, reconstructing software from modules extracted from the transport stream
    • 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/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/437—Interfacing the upstream path of the transmission network, e.g. for transmitting client requests to a VOD server
    • 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
    • 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/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/647—Control signaling between network components and server or clients; Network processes for video distribution between server and clients, e.g. controlling the quality of the video stream, by dropping packets, protecting content from unauthorised alteration within the network, monitoring of network load, bridging between two different networks, e.g. between IP and wireless
    • H04N21/64707—Control signaling between network components and server or clients; Network processes for video distribution between server and clients, e.g. controlling the quality of the video stream, by dropping packets, protecting content from unauthorised alteration within the network, monitoring of network load, bridging between two different networks, e.g. between IP and wireless for transferring content from a first network to a second network, e.g. between IP and wireless
    • 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/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/647—Control signaling between network components and server or clients; Network processes for video distribution between server and clients, e.g. controlling the quality of the video stream, by dropping packets, protecting content from unauthorised alteration within the network, monitoring of network load, bridging between two different networks, e.g. between IP and wireless
    • H04N21/64723—Monitoring of network processes or resources, e.g. monitoring of network load
    • H04N21/64738—Monitoring network characteristics, e.g. bandwidth, congestion level
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/06—Selective distribution of broadcast services, e.g. multimedia broadcast multicast service [MBMS]; Services to user groups; One-way selective calling services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/61—Network physical structure; Signal processing
    • H04N21/6106—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network
    • H04N21/6112—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network involving terrestrial transmission, e.g. DVB-T
    • 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/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/61—Network physical structure; Signal processing
    • H04N21/6106—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network
    • H04N21/6125—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network involving transmission via Internet
    • 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/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H04N21/64322—IP

Definitions

  • the present invention relates to a dynamic time request window and a caching mechanism of a client terminal under heterogeneous network transmission, and in particular to a time interval for determining a terminal requesting to send media content, and a method for allocating a cache window size.
  • media sources are not just specific content providers, more and more producers are involved, including many individual users who are also content providers and producers. These content from different providers have various associations. In order to meet the individual needs of different users, these related content often need to be presented synchronously. In this environment, heterogeneous network convergence is an inevitable trend in the development of next-generation networks, which fully demonstrates that future communications are no longer a specific access technology, but multiple access technologies coexist and work together.
  • CI Presentation Information
  • the terminal may request relevant content from the server according to the information in the signaling, but when the server receives the request, the related content may be ready, and may not yet be. If the relevant content is not ready, the terminal's request will fail and then request again until the relevant content is obtained. This is a big burden on the terminal and will also increase the network burden.
  • the server provides media content too late, the end user cannot obtain the relevant resources in time. Therefore, under the specific network media service, whether the server needs to notify the terminal media of the ready time and when to notify it becomes a issues that need resolving.
  • the present invention provides a method for adaptively adjusting a request time window and a buffer window size in a heterogeneous network terminal, thereby solving the content of a heterogeneous terminal composed of broadcast and broadband due to broadband congestion.
  • the present invention in order to solve the problem that media related resources cannot be synchronously played due to factors such as network congestion in a heterogeneous media network transmission, provides a dynamic time window and a caching mechanism under heterogeneous network transmission: For the signaling in the existing MMT, the Available_Time and Asset_Size attributes of the media content are added in the signaling part, so that the client terminal knows the time that the corresponding media content can be acquired; at the same time, the client terminal determines the current broadband network by using a corresponding method in the network.
  • the client terminal calculates the time interval in which the transmission request is cached in advance and the size of the cache window required by the terminal.
  • the present invention provides a resource dynamic request method in a heterogeneous media transmission network, which implements a mechanism for a server to send media resource signaling and a terminal dynamically request a time window of the media resource under heterogeneous media network transmission.
  • the resource dynamic request method in the heterogeneous media transmission network is specifically: adding, for the signaling in the existing MMT, the available content of the media content in the MPT table, the CI file, and the MPU signaling part, and the available_Time enables the client terminal to learn The time at which the corresponding media content can be obtained; at the same time, the client terminal determines the network bandwidth under the current network and the uplink and downlink delay of the network, and the client terminal calculates the time and delay of the source content, and sends the early request cache when the client terminal calculates the different server.
  • the time interval of the content message adds the acquireable time Available_Time information of the asset in the reserved field of the MMT_general_location_info() of the signaling MPT, and provides a calculation for the server that currently processes the resource request message with different processing modes.
  • the method of the Available_Time time window is the time interval of the content message.
  • the present invention provides a method for dynamically providing resource availability time under heterogeneous media network transmission.
  • the method increases the available time of the media resource in the signaling, the CI, or the MPU for the signaling in the existing MMT.
  • the attribute is used to enable the client to know the available time of the corresponding media resource; and the added time attribute of the media resource is obtained, so that the client can know the available time of the corresponding media resource, and the method is implemented by any one of the following two methods:
  • Method 1 Add a new descriptor AT descriptor to the signaling, which is used to describe the available time of the media resource;
  • Method 2 The attribute of the obtainable time of the media resource is added in the signaling MPT; the client terminal can obtain the time by using the media resource in the signaling, and request the media resource in advance in the corresponding interval.
  • the method for dynamically providing resources to acquire time in the heterogeneous media network transmission and taking the reserved field as the available_time_flag in the signaling, to notify the client whether the available time of the current media resource is given.
  • the present invention has the following beneficial effects:
  • the present invention is directed to signaling in an existing MMT by adding new attributes in signaling or elsewhere: the client terminal determines the network bandwidth and the content from the broadband to the client in the current broadband network through a corresponding method in the broadband network.
  • the network delay solves the problem that the media content is difficult to synchronize due to network congestion in the broadband, thereby solving the synchronization problem caused by the congestion of the IP network; further, solving the problem of large network delay in the transmission of the heterogeneous media network.
  • the present invention implements the heterogeneous media network transmission, and the server sends media resource signaling to notify the terminal media network of the available time, and solves the heterogeneous media.
  • the problem that the media resource can be acquired is unknown and cannot be requested in time.
  • Figure 1 is a schematic diagram of a model of a heterogeneous network
  • FIG. 2 is a schematic diagram of a resource request model of a heterogeneous media network in Embodiment 3;
  • Embodiment 3 is a flowchart of calculating a dynamic time window for a client to send a request in Embodiment 3;
  • Embodiment 4 is a flowchart of a time when a computing server sends signaling in Embodiment 3;
  • Embodiment 5 is a flow chart of processing new signaling by a new client in Embodiment 4.
  • Embodiment 6 is a flow chart of the old client processing new transmission signaling in Embodiment 4.
  • the CI controls the time and space layout of the broadcast and broadband content by the client to synchronize the media content.
  • the media content coming from the broadcast channel has a small and fixed delay, so there is no impact on the synchronization; and the media content from the broadband, such as audio and video, subtitles, multimedia applications, etc., is susceptible to the current IP network.
  • Producing large and jittery delays poses problems for content synchronization; at the same time, content from broadband has an effective access period, that is, it can be accessed from a certain point in time and is valid until a certain point in time. Therefore, the present invention gives effective time information of the content, and designs a mechanism for requesting the transmission of the information in advance by the terminal and allocating a cache window for the corresponding content.
  • This embodiment can solve the problem that the content in the heterogeneous terminal composed of the broadcast and the broadband cannot be synchronized due to the broadband congestion, and can reduce the overhead of the client due to the cache.
  • This embodiment adds time window information in a presence information (CI) file, or adds time window information in a media encapsulation unit (MPU), or adds available_time_info() in the MPT to describe time window information, and simultaneously gives A method of dynamically requesting and caching media resources after given time window information.
  • CI presence information
  • MPU media encapsulation unit
  • Available_Time which is used to indicate the time in the broadband that the content to be transmitted is ready at the content provider and can start transmission, and the end time. Its assignment follows the following rules:
  • the available_Time value is "unknown". In order to consider the compatibility of the system, if the available_Time attribute is not added to the signaling sent by the server, the terminal resolves to the Available_Time. unknown.
  • the Available_Time value is "anytime”.
  • the Available_Time is assigned to the specific UTC time, which is "UTC1".
  • the Available_Time is assigned to the time interval, which is "UTC1--UTC2", and the UTC is in parentheses.
  • the parsing work for Available_Time is done at the terminal.
  • the Asset_Size attribute can also be added to each part of the content in signaling or elsewhere as needed to indicate the size of the part of the content.
  • the newly added properties, Available_Time and Asset_Size, can be added to different locations in the system as needed. Such as CI, MPT, MPU, etc. Here are some examples of these locations.
  • the mediaSrc attribute is in the childList sourceList of the MediaSync element, the newly added Available_Time and Asset-_Size attributes are placed in the corresponding sourceList, as follows:
  • an available_Time is allocated for the content in each source address; if the content has only one source address, only the available content of the address is assigned an Available_Time.
  • MMT_Available_Time_info() describes the available time or available time interval information of the media content. The MPT is as follows:
  • Available_Time_Type These two bits indicate the type of time available, as explained below:
  • MMT_Available_Time_info() is added to the MPT, and MMT_Available_Time_info() describes the available time of the media content or the time interval information that can be obtained.
  • the MPT is as follows:
  • the design of the cache mechanism for dynamically allocating the cache window size is as follows:
  • the existing attributes in the CI file include the time when the object is normally started to be presented, and can be obtained by corresponding methods in the IP network, such as sending ICMP segments.
  • t 1 and bandwidth of the broadband network are available: Set a threshold Threshold. If the delay t 1 is less than the threshold, the delay is negligible, and the system does not need to transmit media for broadband.
  • the content allocation is additionally cached; if t 1 is greater than the threshold, the time interval for requesting the advance delivery of the media content in the broadband may be determined by a method in a specific scheme, and a cache window is allocated to the terminal. If the network delay is large, the available_Time provided by the content provider does not satisfy the condition that the pre-cache is kept synchronized, and the auxiliary content transmitted by the broadband channel is directly discarded.
  • the client terminal obtains the one-way delay t1 of the current broadband network and the bandwidth Bandwidth of the broadband network through a corresponding method in the IP network, such as by sending an ICMP segment;
  • the client obtains the available time (Available_Time), the normal play time (begin) and the corresponding content size (Asset_Size) of the corresponding media content by parsing signaling (such as MPT, CI);
  • Data_Transfer_Time which can be calculated by the size of a content unit and the bit rate in the current broadband environment
  • condition (1) If the condition (1) is not established, it indicates that the media content to be transmitted can be acquired too late, and cannot reach the terminal in time due to the delay of the current network, so the content is discarded; if the condition (1) is established, the current network is extended.
  • the problem of out-of-synchronization can be solved by pre-caching, and the next calculation is performed;
  • the actual request time is between two points in time:
  • the time at which the terminal can start accepting the service provider data is:
  • the time when the terminal receives data before the begin time is:
  • the size of the cache window allocated by the terminal is:
  • Buffer_Size min ⁇ t*bitrate,Asset_Size ⁇ (7)
  • the size of the cache window allocated by the terminal is:
  • Buffer_Size ⁇ t*bitrate (8)
  • the Threshold is set to 0.1s.
  • the Data_Transfer_Time is generally based on the current data size and bit rate.
  • the image information of an image and audio contained in the signaling is as follows:
  • the current network delay is 10s, which is much larger than the 0.1s Threshold, indicating that the 10s broadband delay is unacceptable, and the content needs to be sent in advance.
  • Image.1 it can get all the time after 4:59:50 Beijing time, but its acquisition time is too late, and the condition (1) is not satisfied, that is, the content can not be sent to the terminal when playing again. Content is discarded.
  • Buffer_Size takes the minimum value of ⁇ t*bitrate and Asset_Size, which is 2Mb.
  • Image.1 is discarded later because the Available_Time time point is given. Audio.1 can obtain the time that the terminal should request to send in advance and the size of the cache window that should be prepared by the Available_Time and Asset_Size given in the CI.
  • the embodiment provides a resource dynamic request time window and a terminal cache mechanism in a heterogeneous network transmission, and increases the available_Time and Asset_Size attributes of the media content in the MPT table and the MPU signaling part for signaling in the existing MMT.
  • the client terminal learns the time when the corresponding media content can be obtained.
  • the client terminal determines the network bandwidth and the uplink and downlink delay of the current broadband network through the corresponding method in the network, and the available time of the broadband source content and the delay of the broadband channel.
  • the client terminal calculates the time interval in which the transmission request is cached in advance and the size of the cache window required by the terminal.
  • the available_Time and Asset_Size attributes of the media content are added in the MPT table, the CI file, or the MPU signaling part, so that the client terminal knows the time that the corresponding media content can be acquired; the technical implementation of this part is the same as that in Embodiment 1, and is implemented.
  • Example 1 differs in the method of determining the uplink and downlink delays of the network.
  • the design of the cache mechanism for dynamically allocating the cache window size in this embodiment is as follows: the existing attributes in the CI file include the time when the object is normally started to be presented, and the HRBM message and the ARQ message can be sent through the network.
  • the method can obtain the uplink delay under the current broadband network - D f , downlink delay - D t , bandwidth of the broadband network - Bandwidth.
  • the available values are available: Set a threshold Threshold. If the downlink delay D t is less than the threshold, the delay is negligible and the system does not need to transmit for broadband.
  • the media content is allocated an additional cache; if D t is greater than the threshold, the time interval for requesting the media content in the broadband to be sent in advance may be determined by a method in a specific scheme, and a cache window is allocated to the terminal. If the network delay is large, the available_Time provided by the content provider does not satisfy the condition that the pre-cache is kept synchronized, and the auxiliary content transmitted by the broadband channel is directly discarded.
  • the client terminal obtains the uplink delay D f of the current broadband network, the downlink delay D t and the bandwidth Bandwidth of the broadband network through corresponding methods in the IP network, such as transmitting signaling or sending an ARQ message;
  • the client obtains the available time of the corresponding media content by parsing the signaling—Available_Time, normal play time—begin and the size of the corresponding content—Asset_Size;
  • Data_Transfer_Time which can be calculated by the size of a content unit and the bit rate in the current broadband environment
  • condition (1) If the condition (1) is not established, it indicates that the media content to be transmitted can be acquired too late, and cannot reach the terminal in time due to the delay of the current network, so the content is discarded; if the condition (1) is established, the current network is extended.
  • the problem of out-of-synchronization can be solved by pre-caching, and the next calculation is performed;
  • the actual request time is between two points in time:
  • the time when the terminal receives data before the begin time is:
  • the size of the cache window allocated by the terminal is:
  • Buffer_Size min ⁇ t*bitrate,Asset_Size ⁇ (7)
  • the size of the cache window allocated by the terminal is:
  • Buffer_Size ⁇ t*bitrate (8)
  • the Threshold is set to 0.1s.
  • the Data_Transfer_Time is generally based on the current data size and bit rate.
  • the image information of an image and audio contained in the signaling is as follows:
  • the current network delay is 10s, which is much larger than the 0.1s Threshold, indicating that the 10s broadband delay is unacceptable, and the content needs to be sent in advance.
  • Image.1 it can get all the time after 4:59:50 Beijing time, but its acquisition time is too late, and the condition (1) is not satisfied, that is, the content can not be sent to the terminal when playing again. Content is discarded.
  • Buffer_Size takes the minimum value of ⁇ t*bitrate and Asset_Size, which is 2Mb.
  • Image.1 is discarded later because the Available_Time time point is given. Audio.1 can obtain the time that the terminal should request to send in advance and the size of the cache window that should be prepared by the Available_Time and Asset_Size given in the CI.
  • the system can adopt the following processing method for system compatibility: the terminal sends a request at a suitable time before the begin time (send only once), after the uplink After the delay D f , the server receives the request at time t:
  • the server sends a message to the receiving end, and informs the receiving end of the Available_Time of the Asset.
  • the server sends the Asset at Available_Time.
  • the formula (9) indicates that the receiving Asseet receiver can receive it on time, so the server sends the Asset at the current time. If the formula (9) is not established, it indicates that the current time is sending the Asset is too late, and the Asset is discarded.
  • the foregoing embodiment 2 of the present invention modifies the one-way network delay in the broadband network to the uplink and downlink network delay, and modifies the request time window and the cache window size determination method, and the client terminal transmits signaling or sends an ARQ message through the network.
  • the method is to learn the bandwidth and the uplink and downlink delays in the current broadband network.
  • the client terminal calculates the time interval in which the transmission request is cached in advance and the size of the buffer window required by the terminal, and the compatibility. better.
  • this embodiment solves the problem that media related resources cannot be played synchronously due to network congestion and other factors in heterogeneous media network transmission.
  • the difference from the above embodiment is that in general_location_info(), Use a reserved field to add time window information to each of the different source properties and provide a calculation notification The method of signaling the time.
  • the MMT_general_location_info() descriptor in the MPT provides the source information of the media resource and the related signaling, where the location_type is 0x00 to 0x06 and the value of 0x0C corresponds to the location information of the asset resource, and the value of 0x07 to 0x0B corresponds to the signaling.
  • Source information, 0x0D ⁇ 0x9F are reserved for the ISO, and 0xA0 ⁇ 0xFF are reserved for the dedicated system.
  • the reserved location_type value the eight reserved values of 0xA0 to 0xA7 are used, and in the field corresponding to each location_type, the field definition of the described location information and 0x00 to 0x06, 0x0C are identical, and the available_begin and available_end attributes are added at the end of each description location information field.
  • Available_end The latest available time for the property. If the field is all set to 0, it indicates that the latest available time of this resource is unknown; if the field is set to 1, it indicates that the resource can be obtained after it is ready;
  • Available_begin is assigned the start time "UTC1", and available_end is assigned the end time "UTC2";
  • Available_begin is assigned the start time "UTC1", and the available_end field is set to 1;
  • the available_begin field is set to 1, and the available_end field is set to 1;
  • the available_begin fields are all set to 0, and the available_end fields are all set to 0.
  • the reserved field in 0xA0 ⁇ 0xFF can also use the reserved field in 0x0D ⁇ 0x9F.
  • the newly defined location_type adds the available time based on the location_type of 0x00 ⁇ 0x06 and 0x0C respectively. Information.
  • the newly added location_type is described as follows:
  • the time window for dynamically requesting the resource is given:
  • the actual request time is between two points in time:
  • D f is the uplink delay of the current media network
  • D t is the downlink delay of the current media network
  • Data_Transfer_Time is the time required by the server to send the media resource.
  • server servers In practical applications, there are generally two types of server servers.
  • the server of type A When a resource request is received, the server of type A directly returns an error message if the resource is not ready, such as an HTTP server; if the server of type B is The resource is not ready yet, the message is not returned first, and the resource is sent after the resource is ready, such as the MMT server.
  • the calculation of the request time window in Embodiment 1 is for the server of type A.
  • the B type server can accept the request message first and wait for the resource to be ready to be sent. Therefore, the client terminal can send the message requesting the resource only when the signal is known to exist when the resource is present, so for the client terminal of the B type server:
  • the time at which the server knows that the Avaliable_Time of a resource is T 0 , and the time T 0 may be late.
  • the client terminal receives the relevant signaling later. Therefore, even if the client terminal calculates the correct request time window, the current time is already later than the Latest test_Request_Time, so the request resource will still fail.
  • the following mechanism is determined by the server to determine the signaling time:
  • the time window for dynamically requesting resources of the client terminal is calculated by the same method, and then the following is first determined:
  • D t is the downlink delay of the current network.
  • This embodiment solves the problem that the media resource availability time is unknown and cannot be requested in time in the heterogeneous media network transmission.
  • the difference from the foregoing embodiment 3 is that the media resource of different sources can be described by adding the descriptor AT_descriptor().
  • new attributes are added to each part of the media resource content: available_begin and available_end, indicating the time at which the media resource is ready at the server and can be requested for acquisition.
  • a bit in the reserved field of the MPT is used as an indication bit to indicate whether the current server sends the current server. Information about the time available for resources.
  • the reserved field in the MPT defines the avialable_time_flag, specifically:
  • Available_time_flag used to indicate whether the available time of the media resource is sent; if the field is set to 0, it indicates that the available time of the media resource is not ready yet, and is not sent; if the field is set to 1, it indicates the available time of the media resource. The information has been sent with the signaling.
  • the newly added attributes available_begin and available_end can be placed in the signaling, CI, MPU, etc.
  • the following two specific solutions are used to select one:
  • Method 1 Add a new descriptor AT descriptor to the signaling, which is used to describe the available time of the media resource;
  • Method 2 The attribute of the obtainable time of the media resource is added in the signaling MPT; the client terminal can obtain the time by using the media resource in the signaling, and request the media resource in advance in the corresponding interval.
  • the available_Time information of the resource added in the MMT_general_location_info() descriptor in Embodiment 3 refer to the available_Time information of the resource added in the MMT_general_location_info() descriptor in Embodiment 3, and details are not described herein again.
  • AT descriptor By adding a new descriptor AT descriptor, it is used to transmit the available time information of the current media resource.
  • the AT descriptor is sent together with the MPT's asset_descriptors ⁇ when it is sent.
  • the AT descriptor is defined as follows:
  • An AT descriptor contains time information that the resource is ready and available to the sender. If the available time of the media resource is known, the AT descriptor can be included in the MPT.
  • the syntax of the AT descriptor is defined in the following three ways:
  • the first method defines six attributes in the table, namely descriptor_tag, descriptor_length, available_time_count, location_index, available_begin, available_end.
  • the server only sends an AT descriptor containing the available time information of all address sources.
  • the available_time_count indicates the number of available time information corresponding to different location_types in the MPT.
  • the location_index attribute provides an index of the source address of the different location address in the MPT corresponding to the obtainable time information in the current loop, and the available time of the resource can be obtained through the index.
  • Mode 2 defines six attributes in the table, namely descriptor_tag, descriptor_length, location_count, location_index, available_begin, available_end.
  • the server only sends an AT descriptor containing the available time information of all address sources.
  • location_count represents the number of different location sources in the MPT.
  • the location_index attribute provides an index of the different location sources in the MPT corresponding to the time information that can be obtained in the current loop, and the index can be used to obtain the available time of the resource. If the resource availability time of a location source is unknown, the available_begin and available_end attributes are all set to '0'.
  • Mode 3 defines five attributes in the table, namely descriptor_tag, descriptor_length, location_index, available_begin, available_end.
  • the server will send multiple AT descriptors, which respectively represent the available time information of different address sources.
  • the location_index attribute provides an index of the source address of the different location address in the MPT corresponding to the obtainable time information in the current loop, and the index can be used to obtain the available time of the resource.
  • Descriptor_tag the tag value of the current descriptor, corresponding to this descriptor, where the tag reserved by the descriptor is 0x8000;
  • Descriptor_length specifies the length from the next field to the end field of this descriptor
  • Location_index – indicates the index of the address information in the MMT_general_location_info corresponding to the time described by the current descriptor.
  • Available_end The latest available time for the property. If the field is all set to 0, it indicates that the latest available time of this resource is unknown; if the field is set to 1, it indicates that the resource can be obtained after it is ready;
  • Available_time_count the number of available time information corresponding to different location_types in the MPT
  • Location_count the number of different location sources in the MPT
  • Available_begin is assigned the start time "UTC1", and available_end is assigned the end time "UTC2";
  • Available_begin is assigned the start time "UTC1", and the available_end field is set to 1;
  • the available_begin field is set to 1, and the available_end field is set to 1;
  • the available_begin fields are all set to 0, and the available_end fields are all set to 0.
  • the AT descriptor can be identified from the descriptor tag, so the available_time_flag is optional.
  • the AT descriptor is not provided in the transmitted signaling, and the server sets the 'available_time_flag' identifier in the MPT to '0'.
  • the server sets the 'available_time_flag' in the MPT to '1'.
  • the new client For the new client, it will read the contents of the AT descriptor and get the 'location_type', 'location_index', 'available_begin' and 'available_end' attributes of the asset. Through the location_index, the client knows that it is in MMT_general_location_info(). The location resource corresponding to the location resource described in the description can obtain time information. The client will request resources in advance of this available time.

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Databases & Information Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Computer And Data Communications (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本发明提供了一种异构网络传输下的动态时间窗口及缓存机制，所述方法针对已有的MMT中的信令，在信令中或其他地方增加媒体内容的Available_Time及Asset_Size属性，使客户终端获知相应媒体内容能获取的时间及媒体内容的大小；同时，客户终端确定当前宽带网络下的网络带宽及内容从宽带到客户端的网络延时，通过宽带源内容的可获取时间和宽带信道的延迟，客户终端计算出发送请求提前缓存的时间区间及终端所需要的缓存窗口大小。本发明解决了广播与宽带中组成的异构终端中内容因宽带拥塞而无法同步的问题，同时也减小了客户端由于缓存而带来的额外开销。

Description

一种异构网络传输下的动态时间窗口及缓存机制 技术领域
本发明涉及一种在异构网络传输下客户终端的动态时间请求窗口及缓存机制，具体的说，涉及一种确定终端请求发送媒体内容的时间区间，以及缓存窗口大小的分配方法。
背景技术
随着时代的变革，人们已不满足于仅仅依靠传统电视来获取信息和进行娱乐，更多的终端设备出现在我们面前，如连接互联网的PC、几乎人手一台的手机以及越来越普及的移动平板电脑等，这些新的产品已经在慢慢侵蚀传统电视业务的市场。随着移动通信和宽带无线技术的发展，以及多媒体业务的日益成熟，融合已成为信息通信业的发展潮流，它可以使用户能够便捷地接入网络，轻松地享用更丰富的媒体内容和多样化的服务。
与此同时，媒体内容的呈现将不只是简单的视频，音频，字幕，媒体类型将会越来越丰富多样。媒体来源也不只是特定的内容提供商，越来越多的制作者参与其中，包括很多个人用户同时也是内容的提供和制作者。这些来自不同提供者的内容存在着各种关联关系，为了满足不同用户的个性化需求，这些关联内容往往需要同步呈现。在此环境下，异构网络融合作为下一代网络发展的必然趋势，充分说明了未来的通信不再是某种特定的接入技术，而是多种接入技术并存、协同工作。
在由广播和宽带组成的异构网络环境下，终端呈现的媒体内容可同时从广播和宽带通道传输过来。对于此异构网络终端的呈现，有一种基于呈现信息(CI，Composition Information)的多源内容分发机制。CI采用HTML5和XML等技术提供媒体数据的时间和空间信息，使得多媒体数据可以在终端进行多样化的呈现。
终端可以根据信令中的信息从服务器端请求相关内容，但是服务器端收到请求的时候，相关内容可能已经准备好，可能还没有。如果相关内容还没有准备好，终端的请求就会失败，然后再次请求，直到获得相关内容。这对终端是很大的负担，同时也会增加网络负担。
由于现在的宽带网络需要在多个节点对内容进行转发，因此存在网络延时大甚至网络阻塞等问题。因此需要在接收端提前对内容进行缓存，以应对终端内容无法播放或者媒体内容无法同步播放的问题。
缓存的引入又带来了新的问题，终端需要提前缓存多少的内容、从何时开始缓存，都会影响客户端设备的配置与系统的性能。因此客户端缓存窗口的大小和拉取缓存的时间成为一个亟待解决的问题。
同时，服务端如果太晚提供媒体内容，终端用户就无法及时取到相关资源，因此在特定的网络媒体服务下，服务端是否必要通知终端媒体准备好的时间，以及何时通知，也成为一个需要解决的问题。
发明内容
针对现有技术的不足，本发明提供了一种在异构网络终端自适应地调整请求时间窗口和缓存窗口大小的方法，从而解决了广播与宽带中组成的异构终端中内容因宽带拥塞而无法同步的问题，同时也减小了客户端由于缓存而带来的额外开销。
根据本发明的第一目的，为了解决异构媒体网络传输中因网络拥塞等因素造成的媒体相关资源无法同步播放的问题，本发明提供一种异构网络传输下的动态时间窗口及缓存机制：针对已有的MMT中的信令，在信令部分增加媒体内容的Available_Time及Asset_Size属性，使客户终端获知相应媒体内容能获取的时间；同时，客户终端通过网络中相应的方法确定当前宽带网络下的网络带宽及内容从宽带到客户端的网络延时，通过宽带源内容的可获取时间和宽带信道的延迟，客户终端计算出发送请求提前缓存的时间区间及终端所需要的缓存窗口大小。
根据本发明的第二目的，本发明提供一种异构媒体传输网络下的资源动态请求方法，实现异构媒体网络传输下服务端发送媒体资源信令以及终端动态请求该媒体资源时间窗口的机制。
所述的异构媒体传输网络下的资源动态请求方法，具体为：针对已有的MMT中的信令，在MPT表、CI文件和MPU信令部分增加媒体内容的Available_Time，Available_Time使客户终端获知相应媒体内容可获取的时间；同时，客户终端确定当前网络下的网络带宽及网络的上、下行延迟，通过源内容的可获取时间和延迟，客户终端计算出不同服务端的情况下发送提前请求缓存内容消息的时间区间；所述方法在信令MPT的MMT_general_location_info()的预留字段里添加了asset的可获取时间Available_Time信息，对于目前处理资源请求消息有不同处理方式的服务端，给出了计算Available_Time时间窗口的方法。
根据本发明的第三目的，为了解决在新一代的异构媒体网络传输系统中动态加入资源可获取的时间的问题，本发明提供一种异构媒体网络传输下动态提供资源可获取时间的方法，所述方法针对已有的MMT中的信令，在信令、CI或者MPU中增加媒体资源的可获取时间 属性，使客户端获知相应媒体资源的可获取时间；所述增加媒体资源的可获取时间属性，使客户端获知相应媒体资源的可获取时间，通过以下两种方法中任一种实现：
方法一：在信令中增加一个新的描述符AT descriptor，该描述符用来描述媒体资源的可获取时间；
方法二：在信令MPT里增加媒体资源的可获取时间的属性；客户终端通过信令中的媒体资源可获取时间，在相应的区间内提前请求媒体的资源。
进一步的，所述异构媒体网络传输下动态提供资源可获取时间的方法，同时在信令里取预留字段作为available_time_flag，用以告知客户端当前媒体资源的可获取时间是否给出。
与现有技术相比，本发明具有如下的有益效果：
本发明针对已有的MMT中的信令，通过在信令或其他地方加入新的属性：客户终端通过宽带网络中相应的方法确定当前宽带网络下的网络带宽及内容从宽带到客户端的单向网络延时，解决了因宽带中网络阻塞而导致的媒体内容难以同步的问题，从而解决因IP网络拥塞带来的同步问题；进一步，解决了在异构媒体网络传输中因网络延时较大而导致的媒体内容无法按时呈现或无法同步呈现的问题；进一步的，本发明实现了异构媒体网络传输下服务端发送媒体资源信令以通知终端媒体网络的可获取时间，解决了异构媒体网络传输中因媒体资源可获取时间未知而无法及时请求的问题。
附图说明
通过阅读参照以下附图对非限制性实施例所作的详细描述，本发明的其它特征、目的和优点将会变得更明显：
图1是异构网络的模型示意图；
图2是实施例3中异构媒体网络的资源请求模型示意图；
图3是实施例3中计算客户端发送请求的动态时间窗口的流程图；
图4是实施例3中计算服务端发送信令的时间的流程图；
图5是实施例4中新的客户端处理新发送信令的流程图；
图6是实施例4中旧的客户端处理新发送信令的流程图。
具体实施方式
下面结合具体实施例对本发明进行详细说明。以下实施例将有助于本领域的技术人员进一步理解本发明，但不以任何形式限制本发明。应当指出的是，对本领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干变形和改进。这些都属于本发明的保护 范围。
如今，基于异构网络的多样化终端呈现方式已成为发展的趋势。在观看高质量广播视频节目的同时，人们对于多样化的网络媒体服务的诉求也越来越高。在由广播和宽带网络组成的异构系统中，由CI来控制客户端播放广播与宽带内容的时间与空间布局，实现媒体内容的同步。一般来说，由广播通道过来的媒体内容有很小并且固定的延时，因此对于同步没有影响；而从宽带过来的媒体内容如音视频、字幕、多媒体应用等内容易受当前IP网络影响，产生较大且抖动的延时，给内容同步带来了问题；同时，从宽带过来的内容存在有效访问期的问题，即从某个时间点开始可以访问，到某个时间点前有效。因此本发明给出了内容的有效时间信息，并设计了一种在终端提前请求该信息的发送，并为相应内容分配缓存窗口的机制。
实施例1
本实施例能解决广播与宽带中组成的异构终端中内容因宽带拥塞而无法同步的问题，同时能减小客户端由于缓存而带来的额外开销。本实施例通过在呈现信息(CI)文件中增加时间窗口信息，或在媒体封装单元(MPU)中增加时间窗口信息，或在MPT内增加available_time_info()用以描述时间窗口信息，并同时给出了在给定时间窗口信息后动态请求及缓存媒体资源的方法。
首先在原有的信令或其他地方给每部分内容都加入一个新属性:Available_Time，用以说明宽带中待传送的该内容在内容提供商处准备好并可以开始传输的时间，以及结束访问时间。其赋值遵循如下规则：
1)时间未知
若服务器端还不能确定待传送的内容准备好的时间，则Available_Time赋值为"unknown"；同时为了考虑系统的兼容性，若服务器端发送的信令中未添加Available_Time属性，则终端解析为Available_Time为未知。
2)随时可以访问
若服务器端的媒体内容随时可以访问与发送，则Available_Time赋值为"anytime"。
3)某个特定时间开始后，一直有效
若服务器端的内容在某个特定时间开始后一直有效，则Available_Time赋值为该特定的UTC时间，即"UTC1"。
4)某个特定时间区域内有效
若服务器端的内容在某个特定的时间区间内可获取，则Available_Time赋值为该时间区间，即"UTC1--UTC2"，括号内为UTC。
对于Available_Time的解析工作在终端完成
同样可根据需要在信令或其他地方给每部分内容加入Asset_Size属性，用以表示该部分内容的大小。
新添加的属性，Available_Time和Asset_Size，在系统中的具体位置可以根据需要添加在不同地方。比如CI，MPT,MPU等。下面就以这几个位置为例给予介绍。
下面分别给出了在CI、MPT和MPU中添加Available_Time和Asset_Size属性的实例：1)在CI中添加新的属性
若mediaSrc属性在MediaSync元素里，则将新添加的Available_Time和Asset_Size属性同样放在此元素中，如下：
Figure PCTCN2016073168-appb-000001
若mediaSrc属性在MediaSync元素的子元素sourceList里，则新添加的Available_Time和Asset-_Size属性放在相应的sourceList中，如下：
Figure PCTCN2016073168-appb-000002
2)在MPT中添加新的属性
可以在MPT表中每个asset增加Asset_Size，描述其大小。
若内容有多个源地址，则为每个源地址中的该部分内容都分配一个Available_Time；若该内容只有一个源地址，则只为该地址的源内容分配一个Available_Time。具体实现方式可以有多种，下面给出两个示例。
A.在MPT中加入Available_Time_Type和MMT_Available_Time_info()，以四种情况为例子，我们可以分配Available_Time_Type两个比特，用以表征Avaliable_Time的四种情况，如果可获取时间的分类情况更多，可考虑分配更多比特。MMT_Available_Time_info()说明了媒体内容的可获取时间或可获取时间区间信息。MPT如下：
MP table Syntax
Figure PCTCN2016073168-appb-000003
Figure PCTCN2016073168-appb-000004
MMT_Available_Time_info Syntax
Figure PCTCN2016073168-appb-000005
Available_Time_Type:这两个比特表明在可获取时间的类型，说明如下：
Value of Available_Time_Type
Figure PCTCN2016073168-appb-000006
B.只在MPT中加入MMT_Available_Time_info()，MMT_Available_Time_info()说明了媒体内容的可获取时间或可获取时间区间信息。MPT如下：
MP table Syntax
Figure PCTCN2016073168-appb-000007
Figure PCTCN2016073168-appb-000008
MMT_Available_Time_info Syntax
Figure PCTCN2016073168-appb-000009
Figure PCTCN2016073168-appb-000010
available_begin和available_end的用法如下
Figure PCTCN2016073168-appb-000011
3)在MPU中添加新的属性
在MPU中因为描述的是单个MPU的大小，故此处取mpu_size
Figure PCTCN2016073168-appb-000012
动态分配缓存窗口大小的缓存机制设计思路如下：CI文件中已有的属性已包括对象的正常开始呈现的时间—begin，同时可通过IP网络内的相应方法，如发送ICMP报文段的方式得到当前的单向宽带网络延时—t1与宽带网络的带宽—Bandwidth。在信令中或其他地方加入宽带内容可获取时间的属性Available_Time和Asset_Size后：设定一个阈值Threshold，若延时t1小于此阈值，则该延时可忽略不计，系统无需为宽带传输的媒体内容分配额外缓存；若t1大于此阈值，则可通过具体方案中的方法确定请求提前发送宽带中媒体内容的时间区间，并为终端分配缓存窗口。若网络延时很大，内容提供商提供的Available_Time已不满足提前缓存保持同步的条件，则直接将该宽带通道传送的辅助内容丢弃。
具体方案如下(下面的步骤可以根据实际情况选用，组合)：
1)在信令中或其他地方加入对应内容的Available_Time和Asset_Size属性；
2)客户终端通过IP网络内的相应方法，如通过发送ICMP报文段，得到当前宽带网络的单向延时t1与宽带网络的带宽Bandwidth；
3)客户端通过解析信令(如MPT、CI)得到对应媒体内容的可获取时间(Available_Time)，正常播放时间(begin)以及对应内容的大小(Asset_Size)；
4)若t1<Threshold，则延时忽略不计；若t1>Threshold，则通过如下方法计算出终端发送请求的时间窗口和终端分配的缓存大小：
①计算服务商传输一个内容单元所需要的时间：Data_Transfer_Time,此时间可由一个内容单元的大小和当前宽带环境下比特率来计算获取；
②若Available_Time为"unknown"或CI中并无此属性，则不进行处理；若Available_Time为"anytime"，则跳过此步骤进入③；若Available_Time为一个特定的UTC时间一个UTC时间的区间，则取最早的时间进行如下判断：
Available_Time+t1+Data_Transfer_Time<begin    (1)
若条件(1)不成立，则表明待传送的媒体内容可获取时间太晚，在当前网络的延时下不能及时到达终端，故丢弃此部分内容；若条件(1)成立，则表明当前网络延时带来的不同步问题可由提前缓存来解决，进行下一步计算；
③计算终端请求提前发送媒体内容的时间区间：
请求最早时间：
Earliest_Request_Time＝Available_Time-t1    (2)
请求最晚时间：
Latest_Request_Time＝begin-2t1-Data_Transfer_Time    (3)
实际请求的时间介于两个时间点之间：
Earliest_Request_Time<Actual_Request_Time<Latest_Request_Time    (4)
④终端选定一个请求时间后，则终端能够开始接受服务商数据的时间为：
Receive_Time＝Actual_Request_Time+2t1    (5)
终端到begin时间点之前接收数据的时间为：
Δt＝begin-Receive_Time    (6)
⑤如果CI中给出了Asset_Size属性，则终端分配的缓存窗口大小为：
Buffer_Size＝min{Δt*bitrate，Asset_Size}    (7)
若果CI中未给出Asset_Size属性，则终端分配的缓存窗口大小为：
Buffer_Size＝Δt*bitrate    (8)
方案中用到的变量及其含义总结如下表：
Figure PCTCN2016073168-appb-000013
下面给出一个实例：
已知客户端在接收到对应信令时系统的当前状态如下，此处设定Threshold为0.1s，Data_Transfer_Time一般依据当时data大小和比特率，这里取3s
参数 取值
t1 10s
Bandwidth 10Mbps
Threshold 0.1s
该信令包含的一个图像和音频的文件信息如下：
Figure PCTCN2016073168-appb-000014
当前的网络延时为10s，远大于0.1s的Threshold，说明10s的宽带延时是不可接受的，需要提前请求内容的发送。
对于Image.1，其可获取时间为北京时间4:59:50后的所有时间，但其可获取时间太靠后，不满足条件(1)，即不能再播放时将内容发送至终端，故此内容丢弃。
对于Audio.1，其可获取时间在北京时间4:59:20至4:59:50之间，其4:59:20满足条件(1)，故可由式(2)和(3)得到请求发送的时间区间：
Earliest_Request_Time＝2015-01-31T4:59:10+08:00
Latest_Request_Time＝2015-01-31T4:59:37+08:00
若取实际的请求时间为:
Actual_Request_Time＝2015-01-31T4:59:30+08:00
若当前比特率为200Kb/s,则可得各变量参数如下
Earliest_Request_Time 2015-01-31T4:59:10+08:00
Latest_Request_Time 2015-01-31T4:59:37+08:00
Actual_Request_Time 2015-01-31T4:59:30+08:00
Receive_Time 2015-01-31T4:59:50+08:00
Δt 20s
Δt*bitrate 4M
Buffer_Size 2Mb
其中Buffer_Size取Δt*bitrate与Asset_Size的最小值，即2Mb。
故在此实例中，Image.1因为Available_Time时间点给定较晚丢弃，Audio.1可由CI中给定的Available_Time和Asset_Size得到终端应该提前请求发送的时间和应该准备的缓存窗口大小。
实施例2
为解决广播与宽带中组成的异构终端中内容因宽带拥塞而无法同步的问题，同时为了减小客户端由于缓存而带来的额外开销，
本实施例提供一种异构网络传输下的资源动态请求时间窗口及终端缓存机制，针对已有的MMT中的信令，在MPT表、MPU信令部分增加媒体内容的Available_Time及Asset_Size属性，使客户终端获知相应媒体内容能获取的时间；同时，客户终端通过网络中相应的方法确定当前宽带网络下的网络带宽及网络的上、下行延迟，通过宽带源内容的可获取时间和宽带信道的延迟，客户终端计算出发送请求提前缓存的时间区间及终端所需要的缓存窗口大小。
本实施例中，在MPT表、CI文件或MPU信令部分增加媒体内容的Available_Time及Asset_Size属性，使客户终端获知相应媒体内容能获取的时间；此部分的技术实现与实施例1相同，与实施例1不同之处在于：网络上下行延时的确定方法。
具体的，本实施例中的动态分配缓存窗口大小的缓存机制设计思路如下：CI文件中已有的属性已包括对象的正常开始呈现的时间—begin，同时可通过网络内发送HRBM message和ARQ消息的方法，可得到当前宽带网络下的上行延时—Df,下行延时—Dt,宽带网络的带宽—Bandwidth。在信令中或其他地方加入宽带内容可获取时间的属性Available_Time和Asset_Size后：设定一个阈值Threshold，若下行延时Dt小于此阈值，则该延时可忽略不计，系统无需为宽带传输的媒体内容分配额外缓存；若Dt大于此阈值，则可通过具体方案中的方法确定请求提前发送宽带中媒体内容的时间区间，并为终端分配缓存窗口。若网络延时很大，内容提供商提供的Available_Time已不满足提前缓存保持同步的条件，则直接将该宽带通道传送的辅助内容丢弃。
具体方案如下(下面的步骤可以根据实际情况选用，组合)：
1)在信令中或其他地方加入对应内容的Available_Time和Asset_Size属性；
2)客户终端通过IP网络内的相应方法，如传输信令或发送ARQ消息，得到当前宽带网络的上行延时Df，下行延时Dt与宽带网络的带宽Bandwidth；
3)客户端通过解析信令得到对应媒体内容的可获取时间—Available_Time，正常播放时间—begin以及对应内容的大小—Asset_Size；
4)若Df<Threshold，则延时忽略不计；若Dt>Threshold，则通过如下方法计算出终端发送请求的时间窗口和终端分配的缓存大小：
①计算服务商传输一个内容单元所需要的时间：Data_Transfer_Time,此时间可由一个内容单元的大小和当前宽带环境下比特率来计算获取；
②若Available_Time为"unknown"或CI中并无此属性，则不进行处理；若Available_Time为"anytime"，则跳过此步骤进入③；若Available_Time为一个特定的UTC时间一个UTC时间的区间，则取最早的时间进行如下判断：
Available_Time+Dt+Data_Transfer_Time<begin    (1)
若条件(1)不成立，则表明待传送的媒体内容可获取时间太晚，在当前网络的延时下不能及时到达终端，故丢弃此部分内容；若条件(1)成立，则表明当前网络延时带来的不同步问题可由提前缓存来解决，进行下一步计算；
③计算终端请求提前发送媒体内容的时间区间：
请求最早时间：
Earliest_Request_Time＝Available_Time-Df    (2)
请求最晚时间：
Latest_Request_Time＝begin-Df-Dt-Data_Transfer_Time    (3)
实际请求的时间介于两个时间点之间：
Earliest_Request_Time<Actual_Request_Time<Latest_Request_Time    (4)④终端选定一个请求时间后，则终端能够开始接受服务商数据的时间为：
Receive_Time＝Actual_Request_Time+Df+Dt    (5)
终端到begin时间点之前接收数据的时间为：
Δt＝begin-Receive_Time    (6)
⑤如果CI中给出了Asset_Size属性，则终端分配的缓存窗口大小为：
Buffer_Size＝min{Δt*bitrate，Asset_Size}    (7)
若果CI中未给出Asset_Size属性，则终端分配的缓存窗口大小为：
Buffer_Size＝Δt*bitrate    (8)
方案中用到的变量及其含义总结如下表：
Figure PCTCN2016073168-appb-000015
下面给出一个实例：
已知客户端在接收到对应信令时系统的当前状态如下，此处设定Threshold为0.1s，Data_Transfer_Time一般依据当时data大小和比特率，这里取3s
Figure PCTCN2016073168-appb-000016
该信令包含的一个图像和音频的文件信息如下：
Figure PCTCN2016073168-appb-000017
当前的网络延时为10s，远大于0.1s的Threshold，说明10s的宽带延时是不可接受的，需要提前请求内容的发送。
对于Image.1，其可获取时间为北京时间4:59:50后的所有时间，但其可获取时间太靠后，不满足条件(1)，即不能再播放时将内容发送至终端，故此内容丢弃。
对于Audio.1，其可获取时间在北京时间4:59:20至4:59:50之间，其4:59:20满足条件(1)，故可由式(2)和(3)得到请求发送的时间区间：
Earliest_Request_Time＝2015-01-31T4:59:10+08:00
Latest_Request_Time＝2015-01-31T4:59:37+08:00
若取实际的请求时间为:
Actual_Request_Time＝2015-01-31T4:59:30+08:00
若当前比特率为200Kb/s,则可得各变量参数如下
Earliest_Request_Time 2015-01-31T4:59:10+08:00
Latest_Request_Time 2015-01-31T4:59:37+08:00
Actual_Request_Time 2015-01-31T4:59:30+08:00
Receive_Time 2015-01-31T4:59:50+08:00
Δt 20s
Δt*bitrate 4M
Buffer_Size 2Mb
其中Buffer_Size取Δt*bitrate与Asset_Size的最小值，即2Mb。
故在此实例中，Image.1因为Available_Time时间点给定较晚丢弃，Audio.1可由CI中给定的Available_Time和Asset_Size得到终端应该提前请求发送的时间和应该准备的缓存窗口大小。
如果在旧的的系统中，接收方无法获知Asset的Available_Time，为了系统的兼容性，系统可采取如下处理方法：终端在begin时间之前某个合适的时刻发送一次请求(仅发送一次)，经过上行延时Df之后，服务器端在时刻t收到请求：
a)如果时刻t在Asset的Available_Time之前且根据接收方的等待时间窗口大小判断出时间间隔较大，则服务器端发送消息给接收端，告诉接收端Asset的Available_Time。服务器于Available_Time发送Asset。
b)如果时刻t在Asset的Available_Time之前但根据接收方的等待时间窗口大小判断出时间间隔不大(，则服务器端直接等待至Available_Time然后直接发送Asset。
c)如果时刻t在Asset的Available_Time之后，则做如下判断：
t+Dt<Begin    (9)
若(9)式成立，则表明现在发送Asseet接收方能按时接收下来，因此服务器端在当前时刻发送Asset，若(9)式不成立，则表明当前时刻发送Asset已晚，丢弃该Asset。
本发明上述的实施例2将宽带网络中的单向网络延迟修改为上下行的网络延迟，修改了请求时间窗口和缓存窗口大小的确定方法，客户终端通过网络中传输信令或发送ARQ消息的方法，获知当前宽带网络下的带宽和上下行延迟，通过宽带源内容的可获取时间和宽带信道的延迟，客户终端计算出发送请求提前缓存的时间区间及终端所需要的缓存窗口大小，兼容性更好。
实施例3
如图2-4所示，本实施例解决了异构媒体网络传输中因网络拥塞等因素造成的媒体相关资源无法同步播放的问题，与上述实施例不同之处在于，在general_location_info()里，使用预留字段为每一个不同来源的媒体资源添加时间窗口信息的方法，并提供计算通知 信令发送时间的方法。
本实施例具体实施中包括以下三部分内容：
一.在MMT_general_location_info()描述符中添加资源的Available_Time信息
为了解决问题资源按时呈现及同步问题，首先在原有的信令或其他地方给每部分内容都加入新属性:available begin和available end，用以说明在当前网络中待传送的该内容在内容服务商处准备好并可以开始传输的时间，以及结束访问时间。
在上述实施例1中，已分别给出了在MPT、CI和MPU中添加Available_Time的方法，下面增加在MPT的MMT_general_location_info()描述符中添加可获取时间的方法及实例：
MPT中的MMT_general_location_info()描述符提供了媒体资源和相关信令的来源信息，其中location_type为0x00～0x06和0x0C的取值对应的为asset资源的位置信息，0x07～0x0B的取值对应为信令来源的信息，0x0D～0x9F为给ISO预留的字段，0xA0～0xFF为给专用系统预留的字段。为了考虑与以前系统的兼容性，选择在预留的location_type取值中，使用0xA0～0xA7这八个预留的取值，在每种location_type对应的字段中，所描述的位置信息的字段定义和0x00～0x06、0x0C一致，并且在每个描述位置信息字段的最后添加available_begin和available_end属性。
增加的定义字段available_begin和available_end如下：
MMT_general_location_info Syntax
Figure PCTCN2016073168-appb-000018
Figure PCTCN2016073168-appb-000019
Figure PCTCN2016073168-appb-000020
available_begin–媒体资源的最早可获取时间。如果字段全部置0，表明此资源最早可获取时间未知；如果字段全部置1，表明此资源最早可获取时间早于当前时间；
available_end–媒体资源的最晚可获取时间。如果字段全部置0，表明此资源最晚的可获取时间未知；如果字段全部置1，表明此资源在准备好之后就一直可被获取；
其中available_begin和available_end的用法如下：
Figure PCTCN2016073168-appb-000021
Figure PCTCN2016073168-appb-000022
即：
(1)如果某资源可在一个时间段内可被获取，新添加属性分别赋值为：
available_begin赋值为起始时间“UTC1”，available_end赋值为结束时间“UTC2”；
(2)如果某资源在某时刻开始就一直可被获取，新添加的属性分别赋值为：
available_begin赋值为起始时间“UTC1”，available_end字段全部置1；
(3)如果某资源在任何时间内都可被获取，新添加的属性分别赋值为：
available_begin字段全部置1,available_end字段全部置1；
(4)如果某资源可获取的情况尚未知，新添加的属性分别赋值为：
available_begin字段全部置0，available_end字段全部置0。
对应于location_type此处使用0xA0～0xFF里的预留字段，也可使用0x0D～0x9F里的预留字段，新定义的location_type分别在0x00～0x06，0x0C这几种location_type的基础上增加了可获取时间的信息。
新添加的location_type说明如下：
Value of location_type
Figure PCTCN2016073168-appb-000023
Figure PCTCN2016073168-appb-000024
二.不同类型的服务端系统下客户终端时间请求窗口的计算方法
在实施例1中给出了客户终端解析信令得到媒体资源的Available_Time后，动态请求该资源的时间窗口：
(Earliset_Request_Time,Latest_Request_Time)    (1)
请求最早时间Earliest_Request_Time：
Earliest_Request_Time＝Available_Time-Df    (2)
请求最晚时间Latest_Request_Time：
Latest_Request_Time＝begin-Df-Dt-Data_Transfer_Time    (3)
实际请求的时间介于两个时间点之间：
Earliest_Request_Time<Actual_Request_Time<Latest_Request_Time    (4)
其中Df为当前媒体网络的上行延时，Dt为当前媒体网络的下行延时，Data_Transfer_Time为该服务端发送该媒体资源所需要的时间。
在实际应用中，一般有两种类型的服务端server，在收到资源请求时，A类型的服务端如果资源还未准备好，就直接返回错误信息，如HTTP server；B类型的服务端如果资源还未准备好，先不返回消息，等待资源准备就绪后就发送该资源，如MMT server。
实施例1中请求时间窗口的计算是针对A类型的服务端的。
现给出B类型服务端情况下的客户终端Available_Time的计算方法如下：
B类型服务端可以先接受请求消息，等待资源准备就绪后发送，因此客户终端只要解析信令得知某资源存在时即可发送请求资源的消息，因此对于B类型服务端的客户终端：
Earliest_Request_Time＝客户终端解析信令得知资源存在的时刻    (5)
Latest_Request_Time＝Begin–Data_Transfer_Time–Dt–Df    (6)
三.服务端发送通知Available_Time信令的时间窗口计算方法
在某些媒体传输网络下，假定服务端获知某资源的Avaliable_Time的时刻为T0，此T0时刻可能较晚，导致发送端发出信令后，客户终端接收到相关信令的时间较晚，因此即使客 户终端虽然计算出了正确的请求时间窗口，但当前时刻已经晚于Latestest_Request_Time，因此请求资源仍然会失败。
在这种情况下，给定如下服务端确定发送信令时间的机制：
在服务端，通过同样的方法计算出客户终端动态请求资源的时间窗口，然后首先作如下判断：
T0+Dt<Latestest_Request_Time    (7)
若(7)式不成立，表明Receiver最早只能在Latest_Request_Time之后获取信令中的Available_Time属性，因此不能及时请求资源，故在这种情况下不发送相关信令；若(7)式成立，表明Receiver可以在Latest_Request_Time之前获取信令中的Available_Time属性，因此继续按如下方法获取发送信令时间的区间。
计算通知的最晚时间Latest_Notify_Time:
Latest_Notify_Time＝Latest_Request_Time-Dt    (8)
则实际的发送信令的时间Actual_Notify_Time在如下区间：
T0<Actual_Notify_Time<Latest_Notify_Time    (9)
其中Dt为当前网络的下行延时。
实施例4
本实施例解决了异构媒体网络传输中因媒体资源可获取时间未知而无法及时请求的问题，不同与上述实施例3之处在于：通过增加描述符AT_descriptor()来描述不同来源的媒体资源可获取时间信息的方法，并给出了新老客户端解析新增加的描述符的流程。在原有的信令中或其它地方给每部分媒体资源内容都加入新的属性：available_begin和available_end，用以说明该媒体资源在服务端处准备好并可请求获取的时间。
具体实施如下：
一.在MPT的预留字段里取出一个比特作为available_time_flag，用来指示当前的服务端是否发送了资源可获取时间的信息。
为了考虑到已有系统的兼容性，并且在信令中告知客户端某资源的可获取时间是否可知，取MPT的预留字段中的一个比特作为指示位，用于指示当前的服务端是否发送了资源可获取时间的信息。
MPT里的预留字段定义了avialable_time_flag，具体为：
available_time_flag:用于指示媒体资源的可获取时间是否发送；如果字段置为0，表示媒体资源的可获取时间还未准备好，没有发送；如果字段置为1，表示媒体资源的可获取时间 信息已随信令一起发送。
新定义available_time_flag在MPT中位置如下：
MP table syntax
Figure PCTCN2016073168-appb-000025
Figure PCTCN2016073168-appb-000026
二.增加媒体资源可获取时间的属性
新添加的属性available_begin和available_end可以放在信令、CI、MPU等位置，下面给出两具体的解决方案使用时选择一种：
方法一：在信令中增加一个新的描述符AT descriptor，该描述符用来描述媒体资源的可获取时间；
方法二：在信令MPT里增加媒体资源的可获取时间的属性；客户终端通过信令中的媒体资源可获取时间，在相应的区间内提前请求媒体的资源。该方法二的实现细节，可以参见实施例3中在MMT_general_location_info()描述符中添加资源的Available_Time信息，此部分不再赘述。
以下对上述的方法一的优选实施方式的细节进行描述：
在信令中增加描述符AT descriptor用来描述媒体资源可获取时间
通过增加一个新的描述符AT descriptor,用来传输当前媒体资源的可获取时间信息。AT descriptor在发送的时候附在MPT的asset_descriptors{}里一起发送
AT descriptor的定义如下：
1.介绍
一个AT descriptor包含了资源在发送方准备好并可获取的时间信息。如果媒体资源的可获取时间已知，AT descriptor可以被包含在MPT内。
2.语法
AT descriptor的语法定义有如下三种方式：
方式一AT descriptor syntax
Figure PCTCN2016073168-appb-000027
方式一在表中定义了六个属性，分别为descriptor_tag，descriptor_length,available_time_count，location_index,available_begin，available_end。这种情况下服务端只发送一个AT descriptor，包含所有地址来源的可获取时间信息。其中available_time_count表示的是MPT中不同的location_type对应的有可获取时间信息的数量。location_index属性提供了当前循环里的可获取时间信息所对应的其在MPT里不同location地址来源的索引，并通过该索引将对应能得到资源的可获取时间。
方式二AT descriptor syntax
Figure PCTCN2016073168-appb-000028
方式二在表中定义了六个属性，分别为descriptor_tag，descriptor_length,location_count,location_index,available_begin，available_end。这种情况下服务端只发送一个AT descriptor，包含所有地址来源的可获取时间信息。其中location_count表示的是MPT中不同的location来源的数量。location_index属性提供了当前循环里可获取时间信息所对应的其在MPT里不同location来源的索引，并通过该索引将对应能得到资源的可获取时间。如果某个location来源的资源可获取时间未知，则将available_begin和available_end属性全部置‘0’。
方式三AT descriptor syntax
Figure PCTCN2016073168-appb-000029
方式三在表中定义了五个属性，分别为descriptor_tag，descriptor_length,location_index,available_begin，available_end。这种情况下，服务端会发送多个AT descriptor，分别表示不同地址来源的可获取时间信息。location_index属性提供了当前循环里的可获取时间信息所对应的其在MPT里不同location地址来源的索引，并通过索引将对应能得到资源的可获取时间。
3.语义
descriptor_tag–当前descriptor的标签值，对应于此descriptor，此处取descriptor预留的标签取值0x8000；
descriptor_length–说明了从下一个字段到此descriptor结束字段的长度
location_index–表示当前descriptor描述的时间所对应MMT_general_location_info中的地址信息索引。
available_begin–媒体资源的最早可获取时间。如果字段全部置0，表明此资源最早可获取时间未知；如果字段全部置1，表明此资源最早可获取时间早于当前时间；
available_end–媒体资源的最晚可获取时间。如果字段全部置0，表明此资源最晚的可获取时间未知；如果字段全部置1，表明此资源在准备好之后就一直可被获取；
available_time_count–MPT中不同的location_type对应的有可获取时间信息的数量；
location_count–MPT中不同的location来源的数量；
其中available_begin和available_end的用法如下：
Figure PCTCN2016073168-appb-000030
即：
(1)如果某资源可在一个时间段内可被获取，新添加属性分别赋值为：
available_begin赋值为起始时间“UTC1”，available_end赋值为结束时间“UTC2”；
(2)如果某资源在某时刻开始就一直可被获取，新添加的属性分别赋值为：
available_begin赋值为起始时间“UTC1”，available_end字段全部置1；
(3)如果某资源在任何时间内都可被获取，新添加的属性分别赋值为：
available_begin字段全部置1,available_end字段全部置1；
(4)如果某资源可获取的情况尚未知，新添加的属性分别赋值为：
available_begin字段全部置0，available_end字段全部置0。
对于这种方案，因为即使没有available_time_flag，AT descriptor也能从descriptor tag里识别出来，因此available_time_flag是可选的。
下面给出一种通过传输AT descriptor来通知客户端可获取时间的一种可以实现的方式(具 体流程如图5-6所示)：
对于使用AT descriptor来传输可获取时间的方案：
●如果在服务端媒体资源的可获取时间未知，则发送的信令内不提供AT descriptor，服务端将MPT中‘available_time_flag’标识符置为‘0’。
●如果该媒体资源的可获取时间已知且提供在了信令内的AT descriptor中，则服务端将MPT中‘available_time_flag’置为‘1’。
√对于新的客户端来说，它将读取到AT descriptor的内容并且得到该asset的‘location_type’、‘location_index’、‘available_begin’和‘available_end’属性,通过location_index，客户端获知在MMT_general_location_info()中描述的location资源所对应可获取时间信息。客户端会在此可获取时间之内提前请求资源。
√对于旧的客户端来说，它将忽略掉available_time_flag，当其接受到descriptor_tag为0x8000的AT descriptor之后，因为对于旧系统这个tag是属于预留的字段，因此它将忽略掉这个AT descriptor，并无法获知资源的可获取时间。客户端可能会在内容准备好之前提前请求资源并因此请求不到。
以上对本发明的具体实施例进行了描述。需要理解的是，本发明并不局限于上述特定实施方式，本领域技术人员可以在权利要求的范围内做出各种变形或修改，这并不影响本发明的实质内容。

Claims (19)

  1. 一种异构网络传输下的动态时间窗口及缓存机制，其特征在于：针对已有的MMT中的信令，在信令部分增加媒体内容的Available_Time及Asset_Size属性，使客户终端获知相应媒体内容能获取的时间；同时，客户终端通过网络中相应的方法确定当前宽带网络下的网络带宽及内容从宽带到客户端的网络延时，通过宽带源内容的可获取时间和宽带信道的延迟，客户终端计算出发送请求提前缓存的时间区间及终端所需要的缓存窗口大小。
  2. 根据权利要求1所述的一种异构网络传输下的动态时间窗口及缓存机制，其特征在于：在原有的MMT信令中给有需要的内容加入新的属性:Available_Time和Asset_Size，用以说明宽带中待传送的该内容在内容提供商处准备好并可以开始传输的时间以及该部分内容的大小；Available_Time赋值遵循如下规则：
    1)时间未知
    若服务器端还不能确定待传送的内容准备好的时间，则Available_Time赋值为"unknown"；若服务器端发送的信令中未添加Available_Time属性，则终端解析为Available_Time为未知；
    2)随时可以访问
    若服务器端的媒体内容随时可以访问与发送，则Available_Time赋值为"anytime"；
    3)某个特定时间开始后，一直有效
    若服务器端的内容在某个特定时间开始后一直有效，则Available_Time赋值为该特定的UTC时间，即"(UTC1)"；
    4)某个特定时间区域内有效
    若服务器端的内容在某个特定的时间区间内可获取，则Available_Time赋值为该时间区间，即"(UTC1)-(UTC2)"；
    对于Available_Time的解析工作在终端完成。
  3. 根据权利要求1或2所述的一种异构网络传输下的动态时间窗口及缓存机制，其特征在于：终端能够获取的CI文件中已有的属性包括对象的正常开始呈现的时间—begin，同时通过网络内发送HRBM message或ARQ消息的方法，得到当前宽带网络下的上行延时—Df、下行延时—Dt、宽带网络的带宽—Bandwidth；在信令中加入宽带内容可获取时间的属性Available_Time和Asset_Size后：设定一个阈值Threshold，若下行延时Dt小于此阈值，则该延时忽略不计，系统无需为宽带传输的媒体内容分配额外缓存；若Dt大于此阈值，则确定请 求提前发送宽带中媒体内容的时间区间，并为终端分配缓存窗口；若网络延时很大，内容提供商提供的Available_Time已不满足提前缓存保持同步的条件，则直接将该宽带网络通道传送的内容丢弃。
  4. 根据权利要求3所述的异构网络传输下的资源动态请求时间窗口及终端缓存机制，其特征在于：所述确定请求提前发送宽带中媒体内容的时间区间，并为终端分配缓存窗口，具体方案如下：
    1)在信令中加入对应内容的Available_Time和Asset_Size属性；
    2)客户终端通过网络内的相应方法，得到当前宽带网络的上行延时Df、下行延时Dt与宽带网络的带宽Bandwidth；
    3)客户端通过解析信令得到对应媒体内容的可获取时间Available_Time，正常播放时间begin以及对应内容的大小Asset_Size；
    4)若Dt<Threshold，则延迟忽略不计；若Dt>Threshold，则通过如下方法计算出终端发送请求的时间窗口和终端分配的缓存大小：
    ①计算服务商传输一个内容单元所需要的时间：Data_Transfer_Time，此时间由一个内容单元的大小和当前宽带环境下比特率来计算获取；
    ②若Available_Time为"unknown"或CI中并无此属性，则不进行处理；若Available_Time为"anytime"，则跳过此步骤进入③；若Available_Time为一个特定的UTC时间区间，则取最早的时间进行如下判断：
    Available_Time+Dt+Data_Transfer_Time<begin        (1)
    若条件(1)不成立，则表明待传送的媒体内容可获取时间太晚，在当前网络的延时下不能及时到达终端，故丢弃此部分内容；若条件(1)成立，则表明当前网络延时带来的不同步问题可由提前缓存来解决，进行下一步计算；
    ③计算终端请求提前发送媒体内容的时间区间：
    请求最早时间：
    Earliest_Request_Time＝Available_Time-Df       (2)
    请求最晚时间：
    Latest_Request_Time＝begin-Dt-Df-Data_Transfer_Time      (3)
    实际请求的时间介于两个时间点之间：
    Earliest_Request_Time<Actual_Request_Time<Latest_Request_Time    (4)
    ④终端选定一个请求时间后，则终端能够开始接受服务商数据的时间为：
    Receive_Time＝Actual_Request_Time+Dt+Df       (5)
    终端到begin时间点之前接收数据的时间为：
    Δt＝begin-Receive_Time        (6)
    ⑤如果CI中给出了Asset_Size属性，则终端分配的缓存窗口大小为：
    Buffer_Size＝min{Δt*bitrate，Asset_Size}      (7)
    若果CI中未给出Asset_Size属性，则终端分配的缓存窗口大小为：
    Buffer_Size＝Δt*bitrate        (8)。
  5. 一种异构媒体传输网络下的资源动态请求方法，其特征在于：针对已有的MMT中的信令，在MPT表、CI文件和MPU信令部分增加媒体内容的Available_Time，Available_Time使客户终端获知相应媒体内容可获取的时间；同时，客户终端确定当前网络下的网络带宽及网络的上、下行延迟，通过源内容的可获取时间和延迟，客户终端计算出不同服务端的情况下发送提前请求缓存内容消息的时间区间；
    所述方法在信令MPT的MMT_general_location_info()的预留字段里添加了asset的可获取时间Available_Time信息，对于目前处理资源请求消息有不同处理方式的服务端，给出了计算Available_Time时间窗口的方法。
  6. 根据权利要求5所述的异构媒体传输网络下的资源动态请求方法，其特征在于：所述方法在信令MPT的MMT_general_location_info()的预留字段里添加了asset的可获取时间Available_Time信息，具体为：首先在原有的信令给每部分内容都加入新属性:available_begin和available_end，用以说明在当前网络中待传送的该内容在内容服务商处准备好并能开始传输的时间，以及结束访问时间；
    MPT中的MMT_general_location_info()描述符提供了媒体资源和相关信令的来源信息，其中location_type为0x00～0x06和0x0C的取值对应的为asset资源的位置信息，0x07～0x0B的取值对应为信令来源的信息，0x0D～0x9F为给ISO预留的字段，0xA0～0xFF为给专用系统预留的字段，在预留的location_type字段中，加入不同位置来源的资源的可获取时间信息。
  7. 根据权利要求6所述的异构媒体传输网络下的资源动态请求方法，其特征在于：增加的定义字段available_begin和available_end，具体为：
    available_begin：媒体资源的最早可获取时间；如果字段全部置0，表明此资源最早可获取时间未知；如果字段全部置1，表明此资源最早可获取时间早于当前时间；
    available_end：媒体资源的最晚可获取时间；如果字段全部置0，表明此资源最晚的可获取时间未知；如果字段全部置1，表明此资源在准备好之后就一直可被获取。
  8. 根据权利要求7所述的异构媒体传输网络下的资源动态请求方法，其特征在于：
    其中available_begin和available_end的用法如下：
    (1)如果某资源可在一个时间段内可被获取，新添加属性分别赋值为：
    available_begin赋值为起始时间“UTC1”，available_end赋值为结束时间“UTC2”；
    (2)如果某资源在某时刻开始就一直可被获取，新添加的属性分别赋值为：
    available_begin赋值为起始时间“UTC1”，available_end字段全部置1；
    (3)如果某资源在任何时间内都可被获取，新添加的属性分别赋值为：
    available_begin字段全部置1，available_end字段全部置1；
    (4)如果某资源可获取的情况尚未知，新添加的属性分别赋值为：
    available_begin字段全部置0，available_end字段全部置0。
  9. 根据权利要求5-8任一项所述的异构媒体传输网络下的资源动态请求方法，其特征在于：所述计算Available_Time时间窗口的方法，其中：
    在实际应用中，有两种类型的服务端server，在收到资源请求时，A类型的服务端如果资源还未准备好，就直接返回错误信息；B类型的服务端如果资源还未准备好，先不返回消息，等待资源准备就绪后就发送该资源；
    针对A类型的服务端，客户终端解析信令得到媒体资源的Available_Time后，动态请求该资源的时间窗口：
    (Earliset_Request_Time,Latest_Request_Time)      (1)
    请求最早时间Earliest_Request_Time：
    Earliest_Request_Time＝Available_Time-Df       (2)
    请求最晚时间Latest_Request_Time：
    Latest_Request_Time＝begin-Df-Dt-Data_Transfer_Time       (3)
    实际请求的时间介于两个时间点之间：
    Earliest_Request_Time<Actual_Request_Time<Latest_Request_Time    (4)
    其中Df为当前媒体网络的上行延时，Dt为当前媒体网络的下行延时，Data_Transfer_Time为该服务端发送该媒体资源所需要的时间；
    针对B类型服务端，客户终端Available_Time的计算方法如下：
    B类型服务端先接受请求消息，等待资源准备就绪后发送，客户终端只要解析信令得知某资源存在时即发送请求资源的消息，因此对于B类型服务端的客户终端：
    Earliest_Request_Time＝客户终端解析信令得知资源存在的时刻    (5)
    Latest_Request_Time＝Begin–Data_Transfer_Time–Dt–Df     (6)。
  10. 根据权利要求9所述的异构媒体传输网络下的资源动态请求方法，其特征在于:服务端发送通知Available_Time信令的时间窗口计算方法，具体如下：
    在某些媒体传输网络下，假定服务端获知某资源的Avaliable_Time的时刻为T0，此T0时刻可能晚，导致发送端发出信令后，客户终端接收到相关信令的时间晚，即使客户终端虽然计算出了正确的请求时间窗口，但当前时刻已经晚于Latestest_Request_Time，因此请求资源仍然会失败；
    在这种情况下，给定如下服务端确定发送信令时间的机制：
    在服务端，通过同样的方法计算出客户终端动态请求资源的时间窗口，然后首先作如下判断：
    T0+Dt<Latestest_Request_Time        (7)
    若(7)式不成立，表明Receiver最早只能在Latest_Request_Time之后获取信令中的Available_Time属性，因此不能及时请求资源，在这种情况下不发送相关信令；
    若(7)式成立，表明Receiver能在Latest_Request_Time之前获取信令中的Available_Time属性，因此继续按如下方法获取发送信令时间的区间：
    计算通知的最晚时间Latest_Notify_Time:
    Latest_Notify_Time＝Latest_Request_Time-Dt     (8)
    则实际的发送信令的时间Actua_Notify_Time在如下区间：
    T0<Actual_Notify_Time<Latest_Notify_Time        (9)。
  11. 一种异构媒体网络传输下动态提供资源可获取时间的方法，其特征在于：所述方法针对已有的MMT中的信令，在信令、CI或者MPU中增加媒体资源的可获取时间属性，使客户端获知相应媒体资源的可获取时间；
    所述增加媒体资源的可获取时间属性，使客户端获知相应媒体资源的可获取时间，通过以下两种方法中任一种实现：
    方法一：在信令中增加一个新的描述符AT descriptor，该描述符用来描述媒体资源的可获取时间；
    方法二：在信令MPT里增加媒体资源的可获取时间的属性；客户终端通过信令中的媒体资源可获取时间，在相应的区间内提前请求媒体的资源。
  12. 根据权利要求11所述的异构媒体网络传输下动态提供资源可获取时间的方法，其特征在于：所述方法一，具体为：在描述符AT descriptor里添加asset的可获取时间信息，在AT descriptor里定义新的属性，用以说明在当前网络中待传送的该内容在内容服务商处准备好并能开始传输的时间，以及结束访问时间，AT descriptor里定义的新的属性包括三个必有属性location_index、available_begin和available_end，以及可选属性available_time_count、location_count中一种。
  13. 根据权利要求12所述的异构媒体网络传输下动态提供资源可获取时间的方法，其特征在于：所述方法一中：
    available_time_count：MPT中不同的location_type对应的有可获取时间信息的数量；
    location_count：MPT中不同的location来源数量；
    location_index：索引号，用以表示当前描述符所描述的信息所对应的不同地址来源的MMT_general_location_info()；
    available_begin：媒体资源的最早可获取时间；如果字段全部置0，表明此资源最早可获取时间未知；如果字段全部置1，表明此资源最早可获取时间早于当前时间；
    available_end：媒体资源的最晚可获取时间；如果字段全部置0，表明此资源最晚的可获取时间未知；如果字段全部置1，表明此资源在准备好之后就一直可被获取。
  14. 根据权利要求11所述的异构媒体网络传输下动态提供资源可获取时间的方法，其特征在于：所述方法二，具体为：在信令MPT的MMT_general_location_info()的预留字段里添加asset的可获取时间信息：
    在原有的MMT_general_location_info()里给每部分内容都加入新属性：available_begin和available_end，用以说明在当前网络中待传送的该内容在内容服务商处准备好并能开始传输的时间，以及结束访问时间。
  15. 根据权利要求14所述的异构媒体网络传输下动态提供资源可获取时间的方法，其特征在于：所述方法二中：
    available_begin：媒体资源的最早可获取时间；如果字段全部置0，表明此资源最早可获取时间未知；如果字段全部置1，表明此资源最早可获取时间早于当前时间；
    available_end：媒体资源的最晚可获取时间；如果字段全部置0，表明此资源最晚的可获取时间未知；如果字段全部置1，表明此资源在准备好之后就一直可被获取。
  16. 根据权利要求15所述的异构媒体网络传输下动态提供资源可获取时间的方法，其特征在于：MPT中的MMT_general_location_info()描述符提供了媒体资源和相关信令的来源信息，其中location_type为0x00～0x06和0x0C的取值对应的为asset资源的位置信息，0x07～0x0B的取值对应为信令来源的信息，0x0D～0x9F为给ISO预留的字段，0xA0～0xFF为给专用系统预留的字段，在预留的location_type字段中，加入不同位置来源的资源的可获取时间信息。
  17. 根据权利要求12-16任一项所述的异构媒体网络传输下动态提供资源可获取时间的方法，其特征在于：所述available_begin和available_end的用法如下：
    (1)如果某资源可在一个时间段内可被获取，新添加属性分别赋值为：
    available_begin赋值为起始时间“UTC1”，available_end赋值为结束时间“UTC2”；
    (2)如果某资源在某时刻开始就一直可被获取，新添加的属性分别赋值为：
    available_begin赋值为起始时间“UTC1”，available_end字段全部置1；
    (3)如果某资源在任何时间内都可被获取，新添加的属性分别赋值为：
    available_begin字段全部置1，available_end字段全部置1；
    (4)如果某资源可获取的情况尚未知，新添加的属性分别赋值为：
    available_begin字段全部置0，available_end字段全部置0。
  18. 根据权利要求11-16任一项所述的异构媒体网络传输下动态提供资源可获取时间的方法，其特征在于：所述方法进一步在信令里取预留字段作为available_time_flag，用以告知客户端当前媒体资源的可获取时间是否给出。
  19. 根据权利要求18所述的异构媒体网络传输下动态提供资源可获取时间的方法，其特征在于：在MPT的预留字段里取出一个比特作为available_time_flag，用来指示当前的服务端是否发送了资源可获取时间的信息；如果available_time_flag字段置为0，表示媒体资源的可获取时间还未准备好，没有发送相关信令；如果字段置为1，表示媒体资源的可获取时间信息已随信令一起发送。
PCT/CN2016/073168 2015-02-06 2016-02-02 一种异构网络传输下的动态时间窗口及缓存机制 WO2016124130A1 (zh)

Priority Applications (4)

Application Number Priority Date Filing Date Title
US15/549,163 US10313738B2 (en) 2015-02-06 2016-02-02 Dynamic time window and cache mechanism under the heterogeneous network transmission
JP2017541330A JP6472892B2 (ja) 2015-02-06 2016-02-02 異種ネットワーク伝送における動的時間窓およびキャッシュメカニズム
CA3004650A CA3004650C (en) 2015-02-06 2016-02-02 Dynamic time window and buffer mechanism in heterogeneous network transmission
KR1020177024205A KR101941900B1 (ko) 2015-02-06 2016-02-02 동적 시간에서 캐시 윈도우 사이즈와 캐시 타임을 고려한 이종 네트워크 전송 방법

Applications Claiming Priority (8)

Application Number Priority Date Filing Date Title
CN201510064427.2A CN105991469B (zh) 2015-02-06 2015-02-06 一种异构网络传输下的动态时间窗口及缓存机制
CN201510064427.2 2015-02-06
CN201510341265.2 2015-06-18
CN201510341265.2A CN106330751B (zh) 2015-06-18 2015-06-18 异构网络传输下的资源动态请求时间窗口及终端缓存方法
CN201510654384.3A CN106572062B (zh) 2015-10-10 2015-10-10 一种异构媒体传输网络下的资源动态请求方法
CN201510654384.3 2015-10-10
CN201510698388.1 2015-10-23
CN201510698388.1A CN106612453B (zh) 2015-10-23 2015-10-23 一种异构媒体网络传输下动态提供资源可获取时间的方法

Publications (1)

Publication Number Publication Date
WO2016124130A1 true WO2016124130A1 (zh) 2016-08-11

Family

ID=56563467

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2016/073168 WO2016124130A1 (zh) 2015-02-06 2016-02-02 一种异构网络传输下的动态时间窗口及缓存机制

Country Status (5)

Country Link
US (1) US10313738B2 (zh)
JP (1) JP6472892B2 (zh)
KR (1) KR101941900B1 (zh)
CA (1) CA3004650C (zh)
WO (1) WO2016124130A1 (zh)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20190013967A (ko) * 2016-08-29 2019-02-11 상하이 지아오통 유니버시티 이종 네트워크 기반의 멀티미디어 자원 동기화 푸시 방법
CN113783751A (zh) * 2021-08-30 2021-12-10 北京东方网信科技股份有限公司 一种检测用户宽带质量的方法、电子设备及介质
WO2023029846A1 (zh) * 2021-09-06 2023-03-09 北京字跳网络技术有限公司 多媒体资源上传方法、装置、电子设备以及可读存储介质
CN116709432A (zh) * 2022-11-22 2023-09-05 荣耀终端有限公司 一种缓存队列调整方法及电子设备

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170344523A1 (en) * 2016-05-25 2017-11-30 Samsung Electronics Co., Ltd Method and apparatus for presentation customization and interactivity
KR102709173B1 (ko) * 2019-03-08 2024-09-25 삼성전자주식회사 방송 수신 장치 및 그 동작방법
CN109921941B (zh) * 2019-03-18 2021-09-17 腾讯科技（深圳）有限公司 网络业务质量评估和优化方法、装置、介质及电子设备
CN112087399A (zh) * 2019-06-12 2020-12-15 阿里巴巴集团控股有限公司 LoRa数据传输方法、装置、设备及存储介质
CN112631369B (zh) * 2020-12-23 2023-05-12 中国人民解放军63921部队 一种用于多个异构系统间的时间同步联合控制方法
CN114071840B (zh) * 2022-01-18 2022-03-29 南京秦之邦科技有限公司 城市灯具远程控制系统及其控制方法
CN114827681B (zh) * 2022-04-24 2024-03-22 咪咕视讯科技有限公司 视频同步方法、装置、电子设备、终端设备及存储介质

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101415148A (zh) * 2008-11-26 2009-04-22 深圳华为通信技术有限公司 实现增值业务的方法、系统及用户终端
CA2844605A1 (en) * 2011-08-10 2013-02-14 Lg Electronics Inc. Method for transmitting broadcast service, method for receiving broadcast service, and apparatus for receiving broadcast service
WO2014120377A1 (en) * 2013-02-04 2014-08-07 Qualcomm Incorporated Determining available media data for network streaming

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101995314B1 (ko) * 2013-04-22 2019-07-02 삼성전자주식회사 Ｄｖｂ 지상파 방송 시스템에서 ｍｐｅｇ ｍｍｔ를 위한 시그널링 정보를 송수신하는 장치 및 방법
JP6505996B2 (ja) * 2013-08-30 2019-04-24 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ 受信方法、及び、受信装置

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101415148A (zh) * 2008-11-26 2009-04-22 深圳华为通信技术有限公司 实现增值业务的方法、系统及用户终端
CA2844605A1 (en) * 2011-08-10 2013-02-14 Lg Electronics Inc. Method for transmitting broadcast service, method for receiving broadcast service, and apparatus for receiving broadcast service
WO2014120377A1 (en) * 2013-02-04 2014-08-07 Qualcomm Incorporated Determining available media data for network streaming

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20190013967A (ko) * 2016-08-29 2019-02-11 상하이 지아오통 유니버시티 이종 네트워크 기반의 멀티미디어 자원 동기화 푸시 방법
KR102271686B1 (ko) * 2016-08-29 2021-07-01 상하이 지아오통 유니버시티 이종 네트워크 기반의 멀티미디어 자원 동기화 푸시 방법
CN113783751A (zh) * 2021-08-30 2021-12-10 北京东方网信科技股份有限公司 一种检测用户宽带质量的方法、电子设备及介质
CN113783751B (zh) * 2021-08-30 2023-01-17 北京东方网信科技股份有限公司 一种检测用户宽带质量的方法、电子设备及介质
WO2023029846A1 (zh) * 2021-09-06 2023-03-09 北京字跳网络技术有限公司 多媒体资源上传方法、装置、电子设备以及可读存储介质
CN116709432A (zh) * 2022-11-22 2023-09-05 荣耀终端有限公司 一种缓存队列调整方法及电子设备
CN116709432B (zh) * 2022-11-22 2024-04-16 荣耀终端有限公司 一种缓存队列调整方法及电子设备

Also Published As

Publication number Publication date
KR20170110113A (ko) 2017-10-10
US10313738B2 (en) 2019-06-04
JP2018509818A (ja) 2018-04-05
CA3004650A1 (en) 2016-08-11
CA3004650C (en) 2022-04-12
US20180262799A1 (en) 2018-09-13
JP6472892B2 (ja) 2019-02-20
KR101941900B1 (ko) 2019-01-24

Similar Documents

Publication Publication Date Title
WO2016124130A1 (zh) 一种异构网络传输下的动态时间窗口及缓存机制
US20230216906A1 (en) Dynamically Switched Multicast Delivery
JP6250821B2 (ja) 目標メディアコンテンツの配信
JP5788473B2 (ja) 端末の出力を同期させる方法およびシステム
US20100083305A1 (en) Interface Device Having Multiple Software Clients to Facilitate Display of Targeted Information
US10498492B2 (en) Method and device for receiving and transmitting information in multimedia system
JP2015529044A (ja) マルチメディアデータの転送特徴情報を配信する方法及び装置
US9813475B1 (en) Delivering a video stream
KR20160106701A (ko) 세그먼트들로 분할된 멀티미디어 콘텐츠를 수신하도록 구성된 클라이언트 단말에 의해 네트워크 정보를 획득하기 위한 방법
KR102277748B1 (ko) 멀티미디어 전송 시스템에서 미디어 데이터 관련 정보를 송신하는 방법 및 장치
CN110072128B (zh) 媒体流的实时推送方法及服务器
KR20110070550A (ko) 비디오 스트림 전송 장치 및 방법
CN105991469B (zh) 一种异构网络传输下的动态时间窗口及缓存机制
CN110278456B (zh) 动态时间窗口及缓存窗口的控制方法
CN106572062B (zh) 一种异构媒体传输网络下的资源动态请求方法
WO2023083136A1 (zh) 直播方法、系统、bier控制器、路由器、设备及可读介质
KR101176285B1 (ko) 채널변경을 위한 아이피 티비 서비스 방법 및 장치
US10523409B2 (en) Method of synchronization during the processing, by a multimedia player, of an item of multimedia content transmitted by an MBMS service
CN110545492B (zh) 媒体流的实时递送方法及服务器
WO2017114393A1 (zh) Http流媒体传输方法及装置
KR20140050515A (ko) 멀티캐스트 및 유니캐스트 혼용 기반의 주문형 비디오 서비스 제공 장치 및 그 방법
CN110809174B (zh) 一种异构媒体网络传输下动态提供资源可获取时间的方法
WO2020216035A1 (zh) 媒体流的实时推送方法、实时接收方法、服务器及客户端
TW201103333A (en) Quick Internet online requesting method
KR102303777B1 (ko) 다중 경로 스트리밍 서비스 제공 방법, 이를 위한 컴퓨터 판독 가능한 기록 매체 및 컴퓨터 프로그램

Legal Events

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

Ref document number: 16746125

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2017541330

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 20177024205

Country of ref document: KR

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 15549163

Country of ref document: US

ENP Entry into the national phase

Ref document number: 3004650

Country of ref document: CA

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 11/01/2018)

122 Ep: pct application non-entry in european phase

Ref document number: 16746125

Country of ref document: EP

Kind code of ref document: A1