JP2018519694A - Further device timing adjustments and methods for supporting DASH overbroadcast - Google Patents

Abstract

The systems, methods, and devices of various embodiments allow a receiver device to use a modified segment availability time. In various embodiments, the receiver device may use a segment in the segment availability timeline, such as a media presentation description (MPD), to consider the actual time when the segment becomes available to the DASH client. It may be possible to modify the possible start time.

Description

This application claims the benefit of the priority of US Provisional Patent Application No. 62 / 149,776 entitled `` Further Device Timing Adjustments and Methods for Supporting DASH Over Broadcast '' filed on April 20, 2015. The entire contents of the provisional patent application are incorporated herein by reference.

  Hypertext Transfer Protocol (HTTP) streaming is currently the most common method of delivering content over the Internet. In a live event, content is gradually made available through a segment of constant duration. Segment availability follows a timeline that indicates when each successive segment will be available in the HTTP server.

  The Dynamic Adaptive Streaming Over Hypertext Transfer Protocol (DASH) is a standard that implements HTTP streaming. DASH announces the availability of segments in a Media Presentation Description (MPD). The MPD is a segment availability timeline that announces the segment, the time that the segment is available, and the size of the segment.

  In current systems, the MPD is provided to the receiver device via over-the-air (OTA) delivery. Within the provided MPD, the segment availability start time may correspond to the encoder output time of the network-side encoder that generates the segment. Since the segment availability start time can correspond to the encoder output time, the availability start time runs on the receiver device, such as delivery path delay, receiver device processing delay, or receiver device clock drift. May not account for the difference in the availability of actual segments to the DASH client being used. Thus, the available start time announced in the current MPD may not correspond to the actual time that the segment will be available to the DASH client.

  The systems, methods, and devices of various embodiments allow a receiver device to use a modified segment availability time. In various embodiments, the receiver device may use a segment in the segment availability timeline, such as a media presentation description (MPD), to consider the actual time when the segment becomes available to the DASH client. It may be possible to modify the possible start time.

  In some embodiments, a method for considering receiver device timing drift includes determining a segment index by URL matching, and based on the matching period and expression combination in the availability timeline, Determining an available start time; determining a segment duration from an availability timeline; determining a decoding time for the segment; and a decoding time for the segment minus the available start time for the segment Available depending on determining if is greater than the segment duration ratio and the decoding time for the segment minus the segment available start time is greater than the segment duration ratio Recalculate start time It may include a step of Riga.

  In some embodiments, a method for considering receiver device timing drift includes determining a segment index for a received segment by URL matching and changing an available start time resulting from the received segment. Determining whether the change in available start time is greater than a threshold and starting to use in response to determining that the change in available start time is greater than the threshold Triggering time recalculation.

  Further embodiments may include a receiver device with a processor configured to perform the operations of any of the methods summarized above.

  The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate exemplary embodiments of the invention, and together with the above general description and the following detailed description, It serves to explain the features of the present invention.

1 is a communication system block diagram of a network suitable for use with various embodiments. FIG. FIG. 2 is a block diagram illustrating the architecture of a receiver device according to one embodiment. FIG. 6 is a diagram illustrating a relationship between a segment distribution route and MPD distribution adjustment according to an embodiment. It is a figure which shows the relationship between the segment delivery path | route and the delivery adjustment of MPD by another embodiment. FIG. 4 illustrates relationships between delivery path delays in various parts of the network, according to one embodiment. FIG. 6 is a process flow diagram illustrating an embodiment method for modifying a segment availability start time in response to a segment index change based on a determined first FDT reception time. FIG. 6 is a process flow diagram illustrating an embodiment method for generating a delay adjustment message in response to a segment index change based on a determined first FDT reception time. FIG. 7 is a process flow diagram illustrating an embodiment method for modifying a segment availability start time in response to a base URL change based on a determined first FDT reception time. FIG. 6 is a process flow diagram illustrating an embodiment method for generating a delay adjustment message in response to a base URL change based on a determined first FDT reception time. FIG. 6 illustrates an availability timeline, MPD availability start time, transmission time, and arrival time, according to one embodiment. FIG. 6 is a process flow diagram illustrating an embodiment method for modifying a segment availability start time in unicast mode based on any determined FDT reception time. FIG. 6 is a process flow diagram illustrating an embodiment method for generating a delay adjustment message in unicast mode based on any determined FDT reception time. FIG. 3 is a message flow diagram illustrating interaction between a multicast service device client and an application / DASH client on a receiver device, according to one embodiment. FIG. 6 is a message flow diagram illustrating interaction between a multicast service device client and an application / DASH client on a receiver device, according to another embodiment. FIG. 6 is a process flow diagram illustrating an embodiment method for adjusting an available start time based on a delay adjustment message. FIG. 6 is a process flow diagram illustrating an embodiment method for processing MPD updates. FIG. 6 is a process flow diagram illustrating another embodiment method for processing MPD updates. FIG. 6 illustrates an availability timeline, MPD availability start time, transmission time, and arrival time according to another embodiment. FIG. 5 is a process flow diagram illustrating an embodiment method for considering receiver device timing drift. FIG. 6 is a process flow diagram illustrating an embodiment method for marking a failed HTTP record. FIG. 6 is a process flow diagram illustrating another embodiment method for considering receiver device timing drift. FIG. 5 is a process flow diagram illustrating a method of a third embodiment for taking receiver device timing drift into account. FIG. 5 is a process flow diagram illustrating an embodiment method for determining a segment index by URL matching. FIG. 3 is a block diagram of exemplary MPD elements according to one embodiment. FIG. 3 is a block diagram of exemplary MPD elements according to one embodiment. FIG. 3 is a block diagram of exemplary MPD elements according to one embodiment. FIG. 2 is a block diagram of an exemplary MPD XML tree according to one embodiment. FIG. 6 illustrates a segment availability timeline according to an example. FIG. 4 illustrates an example schema portion of a single segment duration MPD according to one embodiment. FIG. 6 is a block diagram illustrating various results of crawling an MPD and matching URLs in period and representation couples, according to one embodiment. FIG. 6 illustrates a segment availability timeline according to one embodiment. FIG. 4 illustrates an example schema portion of a two segment duration MPD according to one embodiment. FIG. 6 is a block diagram illustrating various results of crawling an MPD and matching URLs in time periods and expression combinations according to another embodiment. FIG. 6 is a process flow diagram illustrating another embodiment method for determining a segment index by URL matching. FIG. 6 illustrates an availability timeline of repetitive segments according to one embodiment. FIG. 6 is a process flow diagram illustrating an embodiment method for considering receiver device timing drift based on URL matching. FIG. 6 is a process flow diagram illustrating another embodiment method for considering receiver device timing drift based on URL matching. FIG. 7 is a process flow diagram illustrating a third embodiment method for considering receiver device timing drift based on URL matching. FIG. 6 is a component diagram of an exemplary mobile device suitable for use with various embodiments. FIG. 3 is a component diagram of an exemplary server suitable for use with various embodiments.

  Various embodiments will be described in detail with reference to the accompanying drawings. Wherever possible, the same reference numbers will be used throughout the drawings to refer to the same or like parts. References to specific examples and implementations are for illustrative purposes, and are not intended to limit the scope of the invention or the claims.

  Various embodiments allow a receiver device to consider delays in availability of data segments (“segment availability”) in a data stream for use on the receiver device. In one embodiment, the receiver device can send the received segment to an application / client on the receiver device (e.g., a dynamic adaptive streaming over hypertext transfer protocol (DASH) client that retrieves the segment for the media player application). Segment availability timeline received from the network (e.g., Broadcast Multimedia Service Center (BMSC)) to generate a modified media presentation description (MPD) enumeration based on the actual time available to ) The available start time during MPD) received over the air (OTA) from the server can be adjusted. Various embodiments may allow a modified MPD to be generated when the network and receiver device clocks are synchronized or not synchronized.

  The word “exemplary” is used herein to mean “serving as an example, instance, or illustration”. Any implementation described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other implementations.

  As used herein, the terms “mobile device” and “receiver device” refer to cellular phones, smartphones, personal multimedia players or mobile multimedia players, personal digital assistants (PDAs), laptop computers, Tablet computers, smart books, palmtop computers, wireless email receivers, multimedia Internet-enabled cellular phones, wireless game controllers, smart televisions, set-top boxes, digital video recorders (DVRs), and MPD receivers and MPDs Interchangeable herein to refer to any one or all of similar personal electronic devices that include programmable processors, memory, and circuitry to make available to DASH clients It is use.

  DASH is a standard that implements HTTP streaming. DASH announces the availability of segments within the MPD. The MPD is a segment availability timeline that announces the segment, the time that the segment is available, and the size of the segment. In current systems, the MPD is provided to the receiver device via OTA distribution. The 3rd Generation Partnership Project (3GPP) is used to provide HTTP streaming using broadcast through Long Term Evolution (LTE) (i.e. evolved Multimedia Broadcast Multicast Services (eMBMS)) As a way to be done, DASH was standardized through download distribution.

  Various examples of different applications / clients, middleware, segment availability timelines, wireless technologies, and transport protocols, particularly DASH clients, multicast service device clients (MSDC), MPD, eMBMS, and HTTP are discussed herein . The discussion of DASH client, multicast service device client, MPD, eMBMS, and HTTP is given only as an example to better illustrate aspects of the various embodiments, and is intended to limit the various embodiments in any way. Not. Other applications / clients, middleware, segment availability timelines, wireless technologies, and transport protocols may be used with various embodiments, other applications / clients, middleware, segment availability timelines, wireless Techniques and transfer protocols may be substituted in various examples without departing from the spirit or scope of the invention.

  In one embodiment, the receiver device may determine the delay adjustment value to take into account the availability delay of segments for client applications on the receiver device. In one embodiment, the delay adjustment value may be provided in a delay adjustment message. The delay adjustment message may be a parameter and / or an indication of the delay adjustment value, such as a file containing the delay adjustment value. In one embodiment, the delay adjustment message is sent to the client application on the receiver device to the application / client on which the received segment retrieves the segment for the media player application (eg, a DASH client that retrieves the segment for the media player application). Segment usage, such as the segment availability timeline received from the network (for example, MPD received over OTA from the BMSC server) to generate a modified enumeration of MPDs based on the actual time available It may be possible to modify the available start time in the manifest file describing the possibilities. Although various embodiments may be discussed in terms of segment availability timelines and / or MPDs, segment availability timelines and / or MPDs are merely examples of manifest files that describe segment availability. Yes, in various examples related to the segment availability timeline and / or MPD discussed herein, any manifest file describing segment availability can be replaced. Various embodiments may allow delay adjustment messages and modified MPDs to be generated when the network and receiver device clocks are synchronized or not synchronized. In another embodiment, the delay adjustment message is sent to the application / client (e.g., media on the receiver device) without the client application on the receiver device modifying the segment availability timeline itself. It may be possible to adjust the timing of that request for the segment based on the actual time available to the DASH client that retrieves the segment for the player application.

  In various embodiments, the receiver device processor monitors the segment index number or base uniform resource identifier (URI) of the segment fragment as segment fragments are received, and continuously receives segment index numbers or Base URIs can be compared with each other. When the segment index number or base URL of a recent segment fragment is different from the segment index number or base URI of the previous segment fragment (for example, a change in segment index number or base URI is detected), the recent segment fragment It may be the first packet of the next segment in the timeline, such as the first file delivery over unidirectional transport (FLUTE) file delivery table (FDT) of the next segment in the line. A receiver device processor (e.g., a multicast service device client running on the processor) can identify the next segment as a base segment and use the arrival time of the first packet, such as the first FDT. , Modify the available start time of the base segment in the limeline and shift all subsequent available start times for subsequent segments based on the modified available start time. In this way, the receiver device processor can modify the available start time in the timeline (eg, AST in the MPD) to take into account the actual arrival time of the segment.

  In various embodiments, the receiver device processor can crawl (eg, parse) the received MPD and determine URL formats corresponding to all time periods and expression pairs. For example, the URL format may be the format “XXX $ number $ YYY”, where XXX can be a prefix, YYY can be a suffix, and $ number $ is the index number of the segment (e.g., in DASH Segment number). The receiver device processor can use this information to first determine whether the received segment URL matches the segment URL format for a particular period and expression pair, and then determine the segment number. it can. The receiver device processor can also determine whether the segment number results in a segment corresponding to that period and expression pair, and can determine the actual segment number. Once the segment number is determined, the receiver device processor can compare the segment number with a previously detected segment number. In one embodiment, the URL format may be a number based URL scheme. In a further embodiment, the base URL may always be an absolute URL. In one embodiment, baseURL @ availabilityTimeOffset may be supported by adjusting the availability time calculation. In one embodiment, the URL format or URL template may be time based rather than segment number based. For example, audio and video segments that correspond to the same time duration may have the same $ time $ tag in the template. The receiver device processor can determine an available start time for each incoming segment and can determine a base segment based on a change in the available start time for each incoming segment.

  In various embodiments, the modified available start time of the base segment is: first FDT arrival time + (number of segment fragments (SF) per segment x multicast channel (MCH) scheduling period (MSP)) + margin ( M), or modified available start time = first FDT arrival time + (SF * MSP) + M. In one embodiment, the MSP value may be a pre-provisioned default value for the receiver device. In another embodiment, the MSP may be a variable value associated with a temporary mobile group identifier (TMGI) for receiving the segment. The margin (M) may be an additional margin to account for processing delays by the receiver device and may be configured as a pre-provisioned value in the receiver device's memory. In one embodiment, SF may be equal to cell segment duration / MSP. SF is a multiplicative factor (e.g., 0.8, 0.9, 1.1, 1.2, etc., less than or greater than 1 to account for the variability in segment size generated in scheduling methods in encoders and broadcast systems. (Value greater than 0).

  In various embodiments, multiple representations, such as audio and video, broadcast simultaneously on the same bearer affect the ability of the receiver device processor to identify index changes and modify segment availability start times. May not be given. In some embodiments, two or more representations may have the same starting index and the same segment duration. In some embodiments, two or more representations may have different starting indexes and / or different segment durations. Separate audio and video representations may still contain index values, and the receiver device processor tracks the FDT arrival time of the next segment regardless of whether the two segments are audio and / or video segments As an instruction to do this, an index value change can be processed.

  In one embodiment, the receiver device processor may monitor the segment availability times of the segment fragments and compare the segment availability start times of the continuously received segments with each other as the segment fragments are received. it can. When the segment availability start time of the recent segment fragment is different from the segment availability start time of the previous segment fragment, the recent segment fragment is the first file delivery over one-way transport of the next segment in the timeline ( FLUTE) file delivery table (FDT). A receiver device processor (e.g., a multicast service device client running on the processor) can identify the next segment as a base segment and use its first FDT arrival time to The base segment availability start time can be modified and all subsequent availability start times for subsequent segments can be shifted based on the modified availability start time.

  In one embodiment, when the segment durations for different broadcast representations (e.g., audio in 2s segment duration and video in 1s segment duration) are different, the receiver device processor only uses the video representation to determine an adjustment value. Can be used. The receiver device processor can also use a higher segment duration across the representation to determine a super segment whose availability can be matched and the same calculations can be applied. The receiver device processor can only use the video representation to determine the adjustment value when the segment duration is a multiple of each other. The receiver device processor can use the lowest common multiple of the segment duration when the segment duration is not a multiple of each other.

  In various embodiments, when the receiver device processor determines that unicast fetch is active, the receiver device processor (e.g., a multicast service device client executing on the processor) is received at the receiver device. In addition, the reception time of any FDT of any of the segments can be determined, and the available start time of the segment can be corrected based on the reception time of the FDT. In this way, the available time in the MPD can be quickly shifted without waiting for the next segment to be received or the segment index change, making use of a stricter timeline and earlier Unicast fetch may be used to request segments through unicast. Setting the availability timeline based on the first broadcast FDT describing the segment ensures a more accurate timeline than the timeline determined using any FDT describing the segment can do. For example, the last FDT describing a segment can be roughly a segment duration that is slower than the first FDT describing that segment, and using it to set the segment availability start time is The availability of the segment can be delayed by the same duration. Thus, as soon as the FDT is encountered, the MPD can be made available, allowing the playout to start earlier than the next segment is received or waiting for the segment index change. In one embodiment, the first one or more segments may be fetched through unicast.

  The DASH standard unit media segment availability time is the MPD availability start time (AST) (for example, the MPD element `` MPD '' which represents the anchor time for the availability of all segments described in the MPD. (time indicated in “@availabilityStartTime”) + PeriodStart time of inclusion period + MPD availability start time (AST) of the media segment (eg, AST of the segment itself) + segment duration value. In various embodiments, based on the identified base segment URI, the receiver device processor (e.g., a multicast service device client running on the processor of the receiver device) can identify all remaining segments in the MPD. A corresponding available start time can be determined. In one embodiment, the receiver device processor modifies the MPD availability start time (AST) based on the modified availability start time of the base segment determined based on the first FDT arrival time. Can do. For example, the MPD AST is modified to be equal to the modified available start time-PeriodStart time-available start time within the base segment period ((segment duration) x (number of segments-number of starting segments)) Can be done. In various embodiments, as soon as an MPD update having the same AST as the previous MPD is received, the receiver device processor matches the AST of the MPD update to match the modified AST determined for the previous MPD. Can be adjusted. In various embodiments, upon receiving an MPD update having an AST that is different from the previous MPD, the receiver device processor may initiate a modified availability start of the base segment determined based on the first FDT arrival time. The time can be used to adjust the AST for MPD updates. In various embodiments, receipt of MPD updates with different ASTs may trigger a new available start time determination.

  In another embodiment, the receiver device processor can adjust the segmentAvailabilityOffset attribute of the baseURL element corresponding to the received segment. The segmentAvailabilityOffset parameter can modify the calculated availability start time and can adjust itself instead of the availability start time.

  In various embodiments, the receiver device processor can match the base segment to two different time periods and representation pairs. An exact match may be a period and expression pair that results in a smaller timeline adjustment, which may be likely to be a timeline adjustment in a live streaming system.

  In various embodiments, timing drift at the receiver device can be tracked, and in response to detecting the timing drift, the receiver device processor can determine a new available start time for that MPD. In various embodiments, a receiver device processor (e.g., a multicast service device client running on the receiver device processor) can track a segment number or segment URI associated with a failed HTTP request by a DASH client. . Once the segment number or segment URI is tracked, the receiver device processor can determine whether each subsequent HTTP request by the DASH client is for the same segment number or segment URI or for a different segment number or segment URI .

  As soon as an HTTP request for a different segment number or segment URI is received, the receiver device processor determines whether the failed HTTP request has been cleared or is still outstanding, and the requested segment is currently in the cache You can decide whether to do it. When a failed HTTP request is still outstanding and the requested segment is in the cache, timing drift may have occurred on the receiver device and the DASH client may have given up on that segment request (i.e. drift The segment may arrive after the condition is met. When timing drift is detected (ie, the drift condition is met), the available start time can be recalculated and the receiver device can modify the MPD to account for timing drift.

  In one embodiment, equal to 90% of the segment duration to avoid tracking segments when the DASH client issues multiple HTTP requests simultaneously (e.g., at startup to determine the line edge of the media stream) Tracking of the next segment can be delayed, such as over time. In a further embodiment, the check for the drift condition can only be applied when the next segment number is a segment index that is one greater than the current tracked segment. In some embodiments, only one segment can be tracked at a time. In other embodiments, multiple segments can be tracked at one time.

  In various embodiments, URL matching of segment URLs to corresponding time periods and expression combinations in the MPD can be utilized to determine if timing drift has occurred. In one embodiment, in response to determining that the decoding start time for the segment minus the available start time of the segment for each MPD based on matching duration and expression combination is greater than half of the segment duration, the receiver device The processor may determine that a timing drift has occurred and trigger a recalculation of the available start time (ie, trigger a reusable start time). In another embodiment, timing drift may be determined in response to determining that a segment index change has occurred based at least in part on URL matching. In one embodiment, the AST change resulting from the received segment may be determined based at least in part on URL matching. In response to the AST change being greater than a threshold, such as one segment duration, the receiver device processor can determine that a timing drift has occurred and trigger an available start time recalculation.

  FIG. 1 illustrates a cellular network system 100 suitable for use with various embodiments. The cellular network system 100 may include multiple devices, such as a receiver device 102, one or more cellular towers or base stations 104, and servers 108 and 112 connected to the Internet 110. Receiver device 102 may be connected to a cellular tower via one or more cellular connections 106, including CDMA, TDMA, GSM, PCS, 3G, 4G, LTE, or any other type of connection. Data can be exchanged with the base station 104. The cellular tower or base station 104 may be in communication with a router that can connect to the Internet 110. In this way, data can be exchanged between the receiver device 102 and the servers 108 and 112 via a connection to the cellular tower or base station 104 and / or via the Internet 110. In one embodiment, server 108 may be a content provider server or encoder that provides MPDs and segments for output via a DASH client. In one embodiment, the server 112 may be a broadcast multimedia service center (BMSC) server that can receive MPD and segment outputs from an encoder and control OTD transmission of MPDs and segments to the receiver device 102. Of course, the functions of the receiver device described herein may be described with reference to OTA transmission, but these functions are used in conjunction with wired transmission, wireless transmission, or a combination of wired and wireless transmission. It's okay. Therefore, OTA transmission is not mandatory.

  FIG. 2 illustrates a simplified receiver device 202 architecture, according to one embodiment. The receiver device 202 may include a modem layer 208 that manages all radio aspects of the receiver device 202, such as acquisition, handoff, link maintenance, and the like. The modem layer 208 can decode the received eMBMS bearer signal and deliver Internet Protocol (IP) packets to the multicast service device client (MSDC) 206.

  The multicast service device client 206 may be the service layer of the receiver device 202 that recovers the segment from the delivered IP packet and makes the segment available to applications / clients such as the application / DASH client 204. By way of example, multicast service device client 206 may be a service layer that is part of the operating system of receiver device 202. The multicast service device client 206 can also restore the MPD from the delivered IP packet. The multicast service device client 206 can store the received segment in the memory of the receiver device.

  In one embodiment, the multicast service device client 206 can adjust the MPD to generate a modified MPD and store the modified MPD in the memory of the receiver device. / DASH client 204 can be delivered. In another embodiment, the multicast service device client 206 determines a delay adjustment value for the MPD, stores the delay adjustment value for the MPD in the memory of the receiver device (eg, in a delay adjustment message), and the receiver device MPD can be stored in the memory, and the MPD and the delay adjustment value for MPD can be distributed to the application / DASH client 204.

  The application / DASH client 204 may be a DASH-enabled application and / or an application that launches the DASH client to display media (directly and / or through another application such as a media player). In one embodiment, the application / DASH client 204 obtains the modified MPD location (e.g., uniform resource locator (URL)) from the multicast service device client 206 and requests the modified MPD from the multicast service device client 206. A segment from the multicast service device client 206 can be requested for each availability timeline in the modified MPD. In another embodiment, the application / DASH client 204 obtains an MPD location (e.g., uniform resource locator (URL)) and a delay adjustment value for the MPD location (e.g., URL) from the multicast service device client 206, and Request and receive MPD and delay adjustment value for MPD from multicast service device client 206, modify MPD according to delay adjustment value for MPD and generate modified MPD, use in modified MPD A segment from the multicast service device client 206 can be requested for each possible timeline. Application / DASH client 204 can receive the requested segment from multicast service device client 206 and render the content of the segment (directly and / or through another application such as a media player) Can do.

  In one embodiment, the functionality of the multicast service device client 206 used to determine the delay adjustment value for the MPD may be integrated into the client 206, where the client 206 determines the delay adjustment value and / or The MPD itself can be modified.

  FIG. 3A illustrates distribution adjustments that may be made to a segment availability timeline, such as MPD, along a segment distribution path, according to one embodiment. The segment delivery path may include an encoder 302, a BMSC 304, a receiver device multicast service device client 306, and a receiver device DASH client 308. The encoder 302 can encode the media content into segments and deliver the segments to the BMSC 304 periodically. For example, segments can be delivered periodically from encoder 302 to BMSC 304 via an eMBMS gateway. The BMSC 304 may receive the segment through the bearer (eg, via OTA broadcast) and broadcast the segment. In one embodiment, headend latency and jitter may be known. A multicast service device client 306 residing in the receiver device can receive the segment via the modem, and the multicast service device client 306 processes the segment (e.g., decodes the segment and applies FEC). The segment may be made available to the DASH client 308 residing on the receiver device. The DASH client 308 may provide the segment to an application (eg, media player) or codec on the receiver device to allow output of media content by the receiver device.

  In addition to generating segments, encoder 302 can generate MPD 310. The MPD 310 generated by the encoder may enumerate the segments generated and / or to be generated by the encoder 302, the segment length (eg, size), and the available start time of the segment. In one embodiment, the available start time in MPD 310 generated by the encoder may correspond to the segment output time generated by encoder 302. The encoder 302 can provide the generated MPD 310 to the BMSC 304. In one embodiment, the BMSC 304 receives the generated MPD 310 and adjusts the segment availability timeline to account for any OTA delivery delay (e.g., network jitter) to generate the MPD 312. Can do. The BMSC 304 can send MPD 312 to the receiver device. The MPD 312 may enumerate the segment availability start time corresponding to the segment's OTA availability start time.

  In one embodiment, the receiver device can receive the MPD 312 and the receiver device's multicast service device client 306 receives the receiver device delay (e.g., processing delay, receiver device clock drift margin, etc.). To adjust the available start time for each clock of the local receiver device to generate a modified MPD 314 that enumerates the actual estimated available start time for the segment at the receiver device. . The multicast service device client 306 can provide the modified MPD 314 to the DASH client 308, which receives using the receiver device clock using the segment available start time in the MPD. You can request a segment from the local HTTP server of the device. In another embodiment, the multicast service device client 306 of the receiver device is available in the MPD 312 for each local receiver device clock based on the receiver device delay (eg, processing delay, clock drift, etc.). The start time can be adjusted and, independently of any MPD sent to the DASH client 308, an adjustment to the available start time can be communicated to the DASH client 308. In further embodiments, the adjustments made by multicast service device client 306 vary based on whether the indication was received via unicast transmission or via broadcast transmission and / or based on the segment size of each indication. obtain.

  FIG. 3B illustrates distribution adjustments that may be made to a segment availability timeline, such as MPD, along a segment distribution path, according to another embodiment. The distribution adjustment shown in FIG. 3B is similar to that described above with reference to FIG. 3A, except that in FIG. 3B, the multicast service device client 306 cannot modify the MPD before sending it to the DASH client 308.

  In one embodiment, the receiver device can receive the MPD 312 and the multicast service device client 306 of the receiver device can provide the MPD 312 to the DASH client 308 without modifying the segment availability start time. . In one embodiment, the multicast service device client 306 adjusts the available start time for each clock of the local receiver device based on the delay of the receiver device (e.g., processing delay, clock drift, etc.) and sets the delay adjustment value. A delay adjustment value can be determined that can be used to generate the enumerating delay adjustment message 316. The multicast service device client 306 can provide a delay adjustment message to the DASH client 308.

  In one embodiment, the DASH client 308 can use the delay adjustment indication in the delay adjustment message 316 to modify the segment availability start time in the MPD 312 to generate a modified MPD 314. The DASH client 308 can request a segment from the local HTTP server of the receiver device using the clock of the receiver device. In another embodiment, the DASH client 308 receives the delay adjustment message 316 and uses the delay adjustment message 316 to request a segment from the local HTTP server of the receiver device without generating a modified MPD 314. Can be corrected.

  FIG. 4 shows the relationship between two exemplary delivery path delays Δ1 and Δ2 in various parts of the network 400. Content from the encoder 402 flows from the encoder 402 to the segmenter 404, and various BMSCs, ie BMSC1 and BMSC2, and their respective eNodeBs, ie eNB1.1, eNB1.2, eNB1.n, eNB2.1, eNB2 .2, can be provided to two different parts of the network 406, 408 served by eNB2.n, etc. The eNB B eNB 1.2 can provide content to the receiver device 1 (410) in the first portion 406, and the eNode B eNB 2.2 in the second portion 408 can receive the receiver device 2 ( 412) can provide content. In a network 400 deployment, network portions 406 and 408 can be managed by different infrastructure vendors and / or can be different multicast broadcast single-frequency networks (MBSFN).

  The path delay Δ1 can be the processing delay for BMSC1 and this delay in providing segments from BMSC1 to receiver device 1 (410) through the respective eNodeBs, i.e. eNB1.1, eNB1.2, eNB1.n. Can experience. The path delay Δ2 can be the processing delay for BMSC2, and this delay in providing the segment from BMSC2 to the receiver device 2 (412) through the respective eNodeB, i.e. eNB2.1, eNB2.2, eNB2.n. Can experience. The path delay Δ1 in the first portion 406 may be different from the path delay Δ2 in the second portion 408. Thus, the same segment of content is received at different times of the receiver device 1 (at different times when the content may be available at receiver device 2 (412) due to the different path delays Δ1 and Δ2 in the different portions 406, 408 410) may be available. Different path delays Δ1 and Δ2 can be caused by various factors, including network deployment by multiple infrastructure vendors and / or receiver device mobility between different MBSFNs using different MSPs for the same content.

  When the path delay is less than the estimated worst case delay for network 400, the actual available start time of the segment of content at receiver device 1 (410) or receiver device 2 (412) is provided to the receiver device. It can be earlier than the available start times listed in the MPD. For example, in some synchronous network deployments, the path delay Δ1 may be shorter than the path delay Δ2, and the MPD in the network starts to be available to account for the longest path delay in the network (eg, Δ2) Times can be synchronized to match the available start time corresponding to a longer path delay Δ2. In such an example, the segment availability timeline in receiver device 2 (412) can be offset by approximately Δ2 to Δ1, and receiver device 1 (410) is at least Δ2 to The first received segment for Δ1 may be stored unnecessarily. According to various embodiments, receiver device 1 (410) and / or receiver device 2 (412) may take into account their actual experienced path delay Δ1 and / or Δ2 and the segment of content is actually available It may be possible to request them when possible.

  FIG. 5A illustrates an embodiment method 500a for modifying a segment availability start time in response to a segment index change based on a determined first FDT reception time. In one embodiment, the operations of method 500a may be performed by a multicast service device client running on a processor of a receiver device, such as a smartphone. In another embodiment, the operations of method 500a may be performed by a client application running on the processor of the receiver device, such as a DASH client.

  At block 502, the multicast service device client or client application may receive the MPD. In one embodiment, the receiver device can receive the MPD via an OTA transmission. In one embodiment, the MPD may be received from the network and the headend may set an available start time for the segment in the MPD. In one embodiment, the available start time in the MPD may be set by the network and may account for the worst case end-to-end transfer delay from the encoder generating the segment to the receiver device. In one embodiment, the client application can receive the MPD via a multicast service device client. At block 504, the multicast service device client or client application may receive one or more segment fragments for one or more segments described in the MPD. For example, the segment fragment may be an OTA received during a multicast channel (MCH) scheduling period (MSP).

  At decision block 506, the multicast service device client or client application can determine whether a segment index change has occurred. In one embodiment, a multicast service device client or client application may determine whether a segment index change has occurred by comparing the segment indexes indicated in two consecutively received segment fragments with each other. The segment index change can be indicated by a mismatch between the segment indexes of consecutively received segment fragments. In various embodiments, received segment fragments can be compared to each other regardless of the type of segment (eg, video or audio) each is associated with. In response to a determination that no segment index change has occurred (ie, decision block 506 = “No”), at block 504, the multicast service device client or client application may continue to receive segment fragments.

  In response to a determination that a segment index change has occurred (ie, decision block 506 = “Yes”), at block 508, the multicast service device client or client application may set the latest segment received as the base segment. . In one embodiment, the latest segment received may be the segment with the highest index number. At block 510, the multicast service device client or client application may receive a first FDT for the base segment. In block 512, the multicast service device client or client application may determine a first FDT reception time (1stFDTArrivalTimeBaseSegment). In one embodiment, the multicast service device client or client application has the first packet of the object corresponding to the base segment as described in the first FDT for the base segment as the first FDT reception time (1stFDTArrivalTimeBaseSegment). Can be determined.

In block 514, the multicast service device client or client application
Availability _SBASE = 1stFDTArrivalTimeBaseSegment + (SF * MSP) + M
First FDT reception time (e.g., ((1stFDTArrivalTimeBaseSegment) + (number of segment fragments (SF) per segment x MSP) + margin (M) Availability _SBASE) ) can be determined.In one embodiment, the value of the MSP can be a default value prepared in advance for the receiver _device.In another embodiment, the MSP receives the segment. It may be a variable value associated with a temporary mobile group identifier (TMGI) for the margin, and the margin (M) may be an additional margin to account for processing delays by the receiver device, In one embodiment, a multicast service device client or client application is associated with a base segment. Based at least in part on the received time of the first packet of objects, it is possible to determine the adjusted available starting time of the base segment.

At block 516, the multicast service device client or client application determines the delay adjustment value as a difference between the adjusted availability start time for the base segment (AvailabilityS _BASE ) and the base segment availability start time in the received MPD. Can be determined. At block 518, the multicast service device client or client application may shift the available start time of the segment in the MPD by the processing delay adjustment value. In this way, the multicast service device client or client application can shift the availability start time to reflect when a segment may actually be available at the receiver device.

  In optional block 520, the multicast service device client or client application may store the modified MPD in memory available to the multicast service device client or client application. In one embodiment, storing the modified MPD may include storing the modified MPD in a memory location on the receiver device associated with the URL where some or all of the MPDs are stored. . In another embodiment, the client application may not specifically store the modified MPD in a separate memory location. Rather, at optional block 522, the client application may only request a segment at the shifted available start time using the modified MPD.

  FIG. 5B illustrates an embodiment method 500b for generating a delay adjustment message in response to a segment index change based on the determined first FDT reception time. The method 500b is similar to the method 500a described above with reference to FIG.5A, except that a delay adjustment message indicating a shift of the segment availability timeline can be generated without necessarily shifting the segment availability timeline. It is the same. In one embodiment, the operations of method 500b may be performed by a multicast service device client running on the processor of the receiver device, such as a smartphone. In another embodiment, the operations of method 500b may be performed by a client application running on the processor of the receiver device, such as a DASH client. In blocks 502, 504, 506, 508, 510, 512, 514, and 516, the multicast service device client or client application is the same as the numbered block of the method 500a described above with reference to FIG. 5A. An operation can be performed to determine the delay adjustment value.

  At block 524, the multicast service device client or client application may store a delay adjustment indication in the delay adjustment message. In one embodiment, the delay adjustment message is a delay adjustment value that can be used by a client application to shift the available start time of one or more segments to take into account the segment availability at the receiver device. It can be a data file that can be used to determine In one embodiment, the delay adjustment message may be stored in a memory location on the receiver device associated with the URL where some or all of the delay adjustment messages are stored. In optional block 526, the multicast service device client may send a delay adjustment message to the client application for use by the client application in shifting the available start time of one or more segments. In another embodiment, the delay adjustment message may not be sent, but rather may be accessed or requested from the stored memory location as needed by the client application.

  FIG. 6A illustrates an embodiment method 600a for modifying a segment availability start time in response to a base URL change based on a determined first FDT reception time. Method 600a does not receive a segment index change indicating a segment fragment from a new segment, but a baseURL change between segments may indicate that a segment fragment for the new segment is being received. Similar to method 500a described above with reference to 5A. In one embodiment, the operations of method 600a may be performed by a multicast service device client running on the processor of the receiver device, such as a smartphone. In another embodiment, the operations of method 600a may be performed by a client application running on the processor of the receiver device, such as a DASH client. In blocks 502 and 504, the multicast service device client or client application may perform the similarly numbered block operations of the method 500a described above with reference to FIG. 5A.

  At block 507, the multicast service device client or client application may determine whether a baseURL change has occurred. In one embodiment, a multicast service device client or client application can determine whether a baseURL change has occurred by comparing the baseURLs indicated in two consecutively received segment fragments with each other, A baseURL change can be indicated by a mismatch between the baseURLs of consecutively received segment fragments. For example, the entire URL for each segment fragment of a segment can be unique, but the baseURL that forms the initial portion of the URL can be the same for each segment fragment of a common segment. Thus, a change in baseURL (eg, the initial portion of the URL) may indicate that a new segment fragment has been received. In response to determining that the baseURL has not changed (ie, decision block 507 = “No”), at block 504, the multicast service device client or client application may continue to receive segment fragments. In response to a determination that the baseURL has changed (ie, decision block 507 = “Yes”), the multicast service device client or client application is numbered similarly to the method 500a described above with reference to FIG. 5A. The operations of blocks 508, 510, 512, 514, 516, 518, 520, and 522 can be performed.

  FIG. 6B illustrates an embodiment method 600b for generating a delay adjustment message in response to a base URL change based on the determined first FDT reception time. The method 600b of the embodiment is described above with reference to FIG. 6A, except that a delay adjustment message indicating a shift in the segment availability timeline can be generated without necessarily shifting the segment availability timeline. This is the same as the method 600a. In one embodiment, the operations of method 600b may be performed by a multicast service device client executing on a processor of the receiver device, such as a smartphone. In another embodiment, the operations of method 600b may be performed by a client application that runs on the processor of the receiver device, such as a DASH client. In blocks 502, 504, 507, 508, 510, 512, 514, and 516, the multicast service device client or client application is responsible for the similarly numbered blocks of method 600a described above with reference to FIG. 6A. An operation can be performed to determine the delay adjustment value. In blocks 524 and 526, the multicast service device client or client application performs the similarly numbered block operations of the method 500b described above with reference to FIG. 5B to store and send the delay adjustment file. Can be executed. In one embodiment, the operations of method 600b may be performed by a multicast service device client or client application in parallel with the operations of methods 500a and 500b described above with reference to FIGS. 5A and 5B, respectively.

  FIG. 7 illustrates an availability timeline, MPD availability start time, transmission time, and arrival time according to one embodiment. As shown in Figure 7, segments 1, 2, 3, 4, and 5 may be sent from the source to the BMSC, and the BMSC will broadcast segments 1, 2, 3, 4, and 5 as a series of segment fragments Each MSP duration that can be divided into. BMSC processing and synchronization scheduling operations may delay OTA transmission of segment fragments to the receiver device, and fragments from more than one segment may be sent every MSP duration. The segment can be decoded and made available at the receiver device at some time after its OTA transmission by the BMSC.

  In the various embodiments discussed above with reference to FIGS. 5A, 5B, 6A, and 6B, after the acquisition begins, the multicast service device client or client application causes the segment fragment for the new segment to be Until identified, the segment fragment attributes (eg, segment index or baseURL) can be compared as segment fragments are received. As shown in FIG. 7, a mismatch may occur when the last FDT for segment 2 and the first FDT for segment 3 are received. Based on the arrival time of the first FDT for segment 3, according to the methods 500a, 500b, 600a, and 600b described above with reference to FIGS. The client application determines the available start time of segment 3 as (FDT arrival time + number of segment fragments (SF) per segment) x (MSP + margin (M) (for example, (SF * MSP) + M))) Can show. The modified MPD can accordingly indicate the available start time for segment 3, and the available start time for each subsequent segment, such as the available start time for segment 4, is the segment in the modified MPD It may be a continuous segment duration from the indicated available start time for 3. Thus, the base segment availability start time can be determined in the first step, so that the base segment availability start time in the MPD matches the availability start time determined in the first step, The MPD can be adjusted in the second step.

  FIG. 8A shows an embodiment method 800a for modifying a segment availability start time in unicast mode based on any determined FDT reception time. In one embodiment, the operations of method 800a may be performed by a multicast service device client executing on a processor of a receiver device, such as a smartphone. In another embodiment, the operations of method 800a may be performed by a client application running on the processor of the receiver device, such as a DASH client. As discussed above, at block 502, the multicast service device client or client application may receive the MPD. In yet another embodiment, FDT can be used to determine changes in the segment index or baseURL, where the actual arrival time is the file identifier (e.g., for FLUTE, transauto object identifier, TOI) May be the time at which the first packet carrying is received.

  At decision block 802, the multicast service device client or client application can determine whether unicast fetch is active. In one embodiment, the unicast fetch is in mode 1 (e.g., using unicast to request a segment at startup) or in mode 2 (e.g., using unicast at some point). Can be active. In mode 1 or mode 2, unicast fetch may allow a multicast service device client or client application to request a segment via unicast without waiting for the broadcast / multicast reception of the segment. A unicast fetch that is active or inactive may be indicated in any manner, such as by a flag setting associated with a unicast fetch in the memory of the receiver device. In response to a determination that unicast fetch is not active (i.e., decision block 802 = “No”), the multicast service device client or client application may proceed to block 502 of FIG. it can.

  In response to a determination that unicast fetch is active (ie, decision block 802 = “Yes”), at block 806, the multicast service device client or client application receives the FDT via broadcast transmission or multicast transmission. be able to. The FDT may be a received OTA and may be any FDT for a segment, such as a first FDT, a last FDT, or an intermediate FDT. At block 808, the multicast service device client or client application may set the segment associated with the received FDT as the base segment. In block 810, the multicast service device client or client application may determine the received FDT reception time (FDTArrivalTimeBaseSegment).

In block 812, the multicast service device client or client application
(AvailabilityS _BASE = FDTArrivalTimeBaseSegment + (SF * MSP) + M)
FDT reception time (for example, FDTArrivalTimeBaseSegment) + (number of segment fragments (SF) per segment x MSP) + margin (M) to determine the adjusted availability start time for the base segment (for example, AvailabilityS _BASE ) can do. In one embodiment, the value of MSP may be a default value prepared in advance for the receiver device. In another embodiment, the MSP may be a variable value associated with a temporary mobile group identifier (TMGI) for receiving the segment. The margin (M) may be an additional margin for taking into account processing delays by the receiver device, and may be configured as a value prepared in advance in the memory of the receiver device. In blocks 516, 518, 520, and 522, the multicast service device client or client application performs the operations of the similarly numbered blocks of method 600a described above with reference to FIG. 6A to adjust the delay. The value can be determined.

  FIG. 8B illustrates an embodiment method 800b for generating a delay adjustment message in unicast mode based on any determined FDT reception time. Method 800b is a method 800a described above with reference to FIG. 8A, except that a delay adjustment message indicating a shift in the segment availability timeline can be generated without necessarily shifting the segment availability timeline. Is the same. In one embodiment, the operations of method 800b may be performed by a multicast service device client running on a processor of a receiver device, such as a smartphone. In another embodiment, the operations of method 800b may be performed by a client application that runs on the processor of the receiver device, such as a DASH client.

  In blocks 502, 802, 804, 806, 808, 810, 812, and 516, the multicast service device client or client application is responsible for the similarly numbered blocks of method 800a described above with reference to FIG. 8A. An operation can be performed to determine the delay adjustment value. In blocks 524 and 526, the multicast service device client or client application performs the similarly numbered block operations of the method 500b described above with reference to FIG. 5B to store and send the delay adjustment file. Can be executed.

  FIG. 9A is a message flow diagram illustrating an interaction between a multicast service device client and an application / DASH client on a receiver device, according to one embodiment. The application / DASH client can request that the service be activated by sending a request for the service discovery function of the multicast service device client. The service discovery function of the multicast service device client can receive the service request, determine that the service is valid, and send service information to the streaming function of the multicast service device client to activate the service. The streaming function of the multicast service device may determine that the service is valid and send a request to activate the service's temporary mobile group identifier (TMGI) to the modem interface of the multicast service device client. The multicast service device client streaming function may also require the multicast service device client data distribution function to activate the FLUTE session, and the multicast service device client data distribution function may require the segment URL to be acquired. it can.

  When the temporary mobile group identifier becomes active in the mobile control channel (MCCH) and the device is able to decode the media transfer channel (MTCH), IP packets received by the modem are sent from the multicast service device client modem interface to the multicast service. It can be distributed to the data distribution function of the device client. Optionally, the MSD modem interface can deliver the updated bearer description to the MSP streaming function. The data delivery function of the multicast service device client can send a file capture request to the MSP streaming function. As segments N, ie N + 1, N + 2, etc. are received and decoded, they can be sent to the DASH gateway of the multicast service device client.

  In one embodiment, when the multicast function device client streaming function determines an index change between received segment fragments, the multicast service device client service discovery function determines the base segment FDT reception time and index number from the multicast service. As shown in the device service discovery function, the multicast service device service discovery function can modify the MPD to adjust the available start time, as discussed above. The service discovery function of the multicast service device client can send the modified MPD to the DASH gateway of the multicast service device client. The streaming function of the multicast service device client can indicate to the application / DASH client that the service has started.

  The application / DASH client can launch the media player and point the media player to the modified MPD URL. The application / DASH client can send an HTTP Get () request for the modified MPD at the modified MPD URL. The DASH gateway of the multicast service device client can respond with a modified MPD. The application / DASH client can send an HTTP Get () request for IS at the URL of the initial segment (IS). The DASH gateway of the multicast service device client can respond with IS. The application / DASH client can send an HTTP Get () request for segment N-1. Segment N-1 may not be available and the DASH gateway of the multicast service device client may respond that the segment was not found (eg, 404 Not Found). The application / DASH client can send an HTTP Get () request for segment N + 1. The DASH gateway of the multicast service device client can respond with segment N + 1.

  FIG. 9B is a message flow diagram illustrating an interaction between a multicast service device client and an application / DASH client on a receiver device according to another embodiment. In FIG. 9B, the flow shown in FIG. 9B is similar to the flow described above with reference to FIG. 9A, except that the video and audio segments can be captured independently. As the multicast service device client data delivery function sends capture requests for video segments indexed M and audio segments indexed M, the multicast service device client data delivery function is indexed M + 1. A capture request for the next video segment can also be sent. In one embodiment, when the multicast service device client streaming function determines an index change between the received video segment M and the video segment M + 1, the multicast service device client service discovery function may +1 indicates that it is a base segment, and the reception time and index number of the base segment FDT can be indicated to the service discovery function of the multicast service device, and the service discovery function of the multicast service device, as discussed above, You can modify the MPD to adjust the available start time. The service discovery function of the multicast service device client can send the modified MPD to the DASH gateway of the multicast service device client. The streaming function of the multicast service device client can indicate to the application / DASH client that the service has started.

  The application / DASH client can launch the media player and point the media player to the modified MPD URL. The application / DASH client can send an HTTP Get () request for the modified MPD at the modified MPD URL. The DASH gateway of the multicast service device client can respond with a modified MPD. The application / DASH client can send an HTTP Get () request for IS at the URL of the initial segment (IS). The DASH gateway of the multicast service device client can respond with IS. The application / DASH client can send an HTTP Get () request for the audio segment M and receive the audio segment M. In one embodiment, when video segment M is active, it can be received via unicast fetch, and the streaming function of the multicast service device allows the video segment M + 1 and audio segment M + 1 to be broadcast or multicast. As they become available, they can be notified of their availability.

  9A and 9B show that the service discovery function of the multicast service device modifies the MPD, but in other embodiments, the service discovery function of the multicast service device has its time segmented on the receiver device. Generate a delay adjustment message or file that includes a display of the delay adjustment value that can be used to shift the available start time in the MPD to reflect when it is actually available to the application / DASH client can do. Thus, the multicast service device client or application / DASH client uses the delay adjustment message or file to start the availability start time in the MPD when the segment is actually available to the application / DASH client on the receiver device. Can be shifted and / or segments can be requested.

  FIG. 10 is a process flow diagram illustrating an embodiment method for adjusting an available start time based on a delay adjustment message. In one embodiment, the operations of method 1000 may be performed by a client application that runs on the processor of a receiver device, such as a smartphone, such as a DASH client. In block 1002, the client application may receive the MPD. In one embodiment, a client application can receive an MPD via an HTTP server on a receiver device via a multicast service device client. In block 1004, the client application may receive a delay adjustment message. In one embodiment, a client application can receive a delay adjustment message via an HTTP server on a receiver device via a multicast service device client.

  At block 1006, the client application may shift the available start time of some or all segments in the MPD based on the delay adjustment message. In one embodiment, the step of shifting the available start time based on the delay adjustment message is the time at which each segment becomes available on the receiver device using an indication of the delay adjustment value and / or other values. May be included. In one embodiment, shifting the available start time may include modifying the MPD itself to generate a modified MPD. In another embodiment, shifting the availability start time may involve changing the indication when a segment becomes available on the receiver device without modifying the MPD itself. In embodiments where the MPD is modified, at optional block 1008, the client application may store the modified MPD in memory available to the client application. At block 1010, the client application may request a segment at the shifted availability start time.

  FIG. 11A is a process flow diagram illustrating an embodiment method for processing an MPD update. In one embodiment, the operations of method 1100a may be performed by a multicast service device client running on a processor of a receiver device, such as a smartphone. In another embodiment, the operations of method 1100a may be performed by a client application running on the processor of the receiver device, such as a DASH client.

  At block 1102, the multicast service device client or client application may receive the MPD update. In one embodiment, an MPD update may be received from the network, and the headend may set an available start time for the segment in the MPD update. In one embodiment, the available start time in the MPD update may be set by the network and may account for the worst case end-to-end transfer delay from the encoder generating the segment to the receiver device. In one embodiment, a client application can receive MPD updates via a multicast service device client.

  At block 1104, the multicast service device client or client application may determine an available start time (AST) set in the MPD update. At decision block 1106, the multicast service device client or client application may determine whether an AST change has occurred between the originally received MPD and the MPD update. For example, a multicast service device client or client application can compare the AST indicated in the original MPD with the AST in the MPD update before any modification of the MPD.

In response to determining that the AST in the MPD update is the same as the original AST (i.e., decision block 1106 = “No”), at block 1108, the multicast service device client or client application determines the AST in the MPD update. It can be adjusted to match the modified AST in the previously modified MPD. In response to a determination that the AST does not match (i.e., decision block 1106 = `` Yes ''), at block 1110, the multicast service device client or client application determines the determined adjusted availability start time for the base segment ( The AST in the MPD update can be modified by the difference between AvailabilityS _Base ) and the original AST prior to modification.

  FIG. 11B illustrates an embodiment method 1100b for processing MPD updates. Method 1100b is similar to method 1100a described above with reference to FIG. 11A, except that a change in AST within the MPD update can trigger an available start time recalculation. In one embodiment, the operations of method 1100b may be performed by a multicast service device client executing on a processor of a receiver device, such as a smartphone. In another embodiment, the operations of method 1100b may be performed by a client application, such as a DASH client, that is executed on the processor of the receiver device. In blocks 1102, 1104, 1106, and 1108, the multicast service device client or client application may perform the similarly numbered block operations of the method 1100a described above with reference to FIG. 11A.

  In response to a determination that the AST does not match (ie, decision block 1106 = “Yes”), at block 1112, the multicast service device client or client application may trigger a recalculation of the available start time. For example, a multicast service device client or client application can request the multicast service device client or client application to modify the available start time in the MPD update with FIG. 5A, FIG. 5B, FIG. 6A, FIG. 6B, FIG. An interrupt can be sent that performs one of the operations 500a, 500b, 600a, 600b, 800a, or 800b described above with reference to FIG. 8B. As a further example, an available start time recalculation trigger may include issuing a notification to an application that has activated a service associated with that segment.

  FIG. 12 shows an availability timeline, MPD availability start time, transmission time, and arrival time according to another embodiment. FIG. 12 can determine the availability start time of a segment, such as segment 3, over time, when the segment is actually used at the receiver device (e.g., based on the reception time of its first FDT). Although it is shown that the available start time is shifted to take into account what may be possible, timing drift on the receiver device may invalidate the available start time in the modified MPD.

After some time N, the availability start time, AvailabilitytimeS _{4 + N} can be indicated in the modified MPD, and the DASH client can issue an HTTP request for segment S4 + N. However, due to receiver device timing drift, HTTP retries may be exhausted by the DASH client without receiving segment S4 + N. Thus, due to timing drift of the receiver device, segment S4 + N may become available after the DASH client aborts the segment S4 + N request attempt. In various embodiments, the reception of segment S4 + N after the DASH client's HTTP retry has been exhausted (e.g., when segment S4 + N + 1 is requested) recalculates the available start time. Can trigger. In this way, the available start time recalculation can take into account the timing drift of the receiver device.

  FIG. 13 shows an embodiment method 1300 for considering receiver device timing drift. In one embodiment, the operations of method 1300 may be performed by a multicast service device client executing on a processor of a receiver device, such as a smartphone. In another embodiment, the operations of method 1300 may be performed by a client application, such as a DASH client, that is executed on the processor of the receiver device.

  At block 1302, a multicast service device client can receive an HTTP request for a segment or a client application can generate an HTTP request. The HTTP request may indicate the segment URI and segment number. At decision block 1304, the multicast service device client or client application may determine whether the segment is currently being tracked. In various embodiments, when an HTTP request associated with a segment fails, that segment can be tracked.

  In response to a determination that no segment is being tracked (i.e., decision block 1304 = “No”), at block 1306, the multicast service device client or client application may determine whether the request was successful. it can. For example, a multicast service device client or client application determines whether a 400 series HTTP response has been received indicating that the requested segment was not available to determine whether the request was successful. be able to. In response to a determination that the request was successful (i.e., decision block 1306 = “Yes”), at block 1308, the multicast service device client or client application can clear the tracking record and at block 1302, the next The next HTTP request for the segment can be received or generated.

  In response to a determination that the request failed (i.e., decision block 1306 = “No”), at block 1310, the multicast service device client or client application can track the requested segment, and at block 1302, HTTP requests for the same segment can be received or generated again.

  In response to determining that the segment is being tracked (i.e., decision block 1304 = “Yes”), at decision block 1312, the multicast service device client or client application determines whether the requested segment is being tracked. can do. In response to a determination that the requested segment is being tracked (i.e., decision block 1312 = “Yes”), as discussed above, the multicast service device client or client application may block 1306, 1308, and 1310. At, it can be determined whether the request was successful, the tracking record can be erased, or the segment can continue to be tracked.

  In response to a determination that the tracked segment is not the requested segment (i.e., decision block 1312 = “No”), at block 1314, the multicast service device client or client application determines that the tracked segment is in cache. It can be determined whether it is in (for example, in a memory location allocated for received segment storage). In this way, the multicast service device client or client application can check whether a segment that the multicast service device client or client application previously requested but failed to receive was subsequently received.

  In response to a determination that the tracked segment is not in the cache (ie, decision block 1314 = “No”), at block 1316, the multicast service device client or client application may clear the tracking record. In an optional embodiment, at block 1318, the multicast service device client or client application determines whether 90% of the segment duration (e.g., 9 * SD) has elapsed since the last new segment number was requested. Can be determined. In this way, activation scenarios in which multiple segments can be requested at one time can be distinguished from regularly timed requests that occur in almost all segment durations. In such an optional embodiment, in response to a determination that 90% of the segment duration has not elapsed (i.e., decision block 1318 = “No”), at block 1302, a multicast service device client or client application Can receive or generate HTTP requests for segments. Although shown as 90% of the segment duration (eg, 9 * SD), any percentage value of segment duration can be selected. For example, a segment duration of 10%, 50%, 95%, or any other percentage value can be substituted for the 90% segment duration in the examples described herein.

  As soon as the tracking record is erased at block 1316, or in an optional embodiment, in response to a determination that 90% of the segment duration has elapsed (i.e., decision block 1318 = “Yes”), blocks 1306, 1308 , And 1310, the multicast service device client or client application can determine if the request was successful, clear the tracking record, or continue to track the segment.

  In response to the determination that the tracked segment is in the cache (ie, decision block 1314 = “Yes”), at block 1112, the multicast service device client or client application triggers a recalculation of the available start time be able to. For example, a multicast service device client or client application can use FIG. 5A, FIG. 5B, FIG. 6A, FIG. 6B, FIG. 8A, or FIG. 5 to modify the available start time in the MPD to the multicast service device client or client application. An interrupt may be sent that performs the operation of one of the methods 500a, 500b, 600a, 600b, 800a, or 800b described above with reference to 8B. In this way, timing drift at the receiver device can be identified by late arrival of segments, and timing drift can be taken into account by the multicast service device client or client application.

  FIG. 14 illustrates an embodiment method 1400 for marking failed HTTP records. In one embodiment, the operations of method 1400 may be performed by a multicast service device client executing on a processor of a receiver device, such as a smartphone. In another embodiment, the operations of method 1400 may be performed by a client application, such as a DASH client, that is executed on the processor of the receiver device. In various embodiments, the operations of method 1400 may be performed in conjunction with the operations of methods 1500a and / or 1500b described below with reference to FIGS. 15A and 15B.

  At block 1402, a multicast service device client or client application may receive the segment. For example, the segment may be received via broadcast OTA transmission or multicast OTA transmission. At decision block 1404, the multicast service device client or client application may determine whether the received segment is being tracked. For example, a multicast service device client or client application can determine whether there is a failed HTTP record associated with the received segment URI and / or segment index. In response to a determination that the segment is not being tracked (ie, decision block 1404 = “No”), at block 1406, the multicast service device client or client application may take no action. In response to a determination that the segment is being tracked (ie, decision block 1408 = “Yes”), the multicast service device client or client application can mark the failed HTTP record as a “received segment” . In this way, a failed HTTP request associated with a later received segment can be identified and distinguished from a failed HTTP request associated with an unreceived segment.

  FIG. 15A illustrates an embodiment method 1500a for considering receiver device timing drift. In one embodiment, the operations of method 1500a may be performed by a multicast service device client executing on a processor of a receiver device, such as a smartphone. In another embodiment, the operations of method 1500a may be performed by a client application running on the processor of the receiver device, such as a DASH client. In various embodiments, the operations of method 1500a may be performed in conjunction with the operations of method 1400 described above with reference to FIG.

  At block 1502, a multicast service device client can receive an HTTP request for a segment, or a client application can generate an HTTP request. The HTTP request may indicate the segment URI and segment number. At decision block 1504, the multicast service device client or client application may determine whether a new URI is indicated in the request. For example, a multicast service device client or client application can compare a URI in an HTTP request with a URI in a previous HTTP request to determine whether the URI is new.

  In response to determining that the URI is not new (ie, decision block 1504 = “No”), at block 1506, the multicast service device client or client application may determine whether the request was successful. For example, a multicast service device client or client application determines whether a 400 series HTTP response has been received indicating that the requested segment was not available to determine whether the request was successful. be able to. In response to a determination that the request was successful (ie, decision block 1506 = “Yes”), at block 1508, the multicast service device client or client application can clear any failed HTTP records for the URI. .

  In response to the determination that the URI is new (ie, decision block 1504 = “Yes”), at block 1510, the multicast service device client or client application may determine whether the request was successful. For example, a multicast service device client or client application determines whether a 400 series HTTP response has been received indicating that the requested segment was not available to determine whether the request was successful. be able to. In response to a determination that the request has failed (i.e., decision block 1510 = “No”), at block 1512 the multicast service device client or client application adds a failed HTTP record for the URI and includes in the failed URI record. Can be set to the current time.

  In response to a determination that the request was unsuccessful (i.e., decision block 1506 = “No”) or as soon as a failed HTTP record for the URI was added in block 1512, in block 1516 the multicast service device client or client The application can set the last time stamp in the failed HTTP record for the URI to the current time. In this way, the time from the first timestamp to the last timestamp in the failed HTTP record for the URI may indicate the tracking period for that failed HTTP record.

  In block 1520, depending on clearing the failed HTTP record for the URI in block 1508, setting the last time stamp in block 1516, or determining that the request was successful (i.e., decision block 1510 = “Yes”) The multicast service device client or client application can erase any failed HTTP records that have been recorded longer than the maximum record tracking period. For example, the maximum recording tracking period may be twice FFR_period, such as 10 seconds. It is possible to erase (eg, delete) failed HTTP records from the first time stamp to the last time stamp in the failed HTTP record that are longer than the maximum record tracking period.

  At decision block 1522, the multicast service device client or client application can make any failed HTTP record marked “received segment” with the last timestamp available to the multicast service device client or client application. Determine if it is older than one segment duration before the current time present in memory. In response to a determination that any failed HTTP record marked “received segment” is not older than one segment duration (ie, decision block 1522 = “No”), at block 1502, the multicast service The device client or client application can receive or generate the next HTTP request.

  In response to the determination that the failed HTTP record marked “received segment” is older than one segment duration (ie, decision block 1522 = “Yes”), at block 1112 the multicast service device client or The client application can trigger a recalculation of the available start time. For example, a multicast service device client or client application can use FIG. 5A, FIG. 5B, FIG. 6A, FIG. 6B, FIG. 8A, or FIG. 5 to modify the available start time in the MPD to the multicast service device client or client application. An interrupt may be sent that performs the operation of one of the methods 500a, 500b, 600a, 600b, 800a, or 800b described above with reference to 8B. In this way, timing drift at the receiver device can be identified by late arrival of segments, and timing drift can be taken into account by the multicast service device client or client application.

  FIG. 15B illustrates an embodiment method 1500b for considering receiver device timing drift. The method 1500b of the embodiment is similar to the method 1500a described above with reference to FIG. 15A, except that a delay may be introduced before triggering an available start time recalculation. In one embodiment, the operations of method 1500b may be performed by a multicast service device client running on a processor of a receiver device, such as a smartphone. In another embodiment, the operations of method 1500b may be performed by a client application, such as a DASH client, that is executed on the processor of the receiver device. In blocks 1502, 1504, 1506, 1508, 1510, 1512, 1516, 1518, 1520, and 1522, the multicast service device client or client application is numbered similarly to the method 1500a described above with reference to FIG. 15A. The operation of the designated block can be executed.

  In response to a determination that a failed HTTP record marked “received segment” is older than one segment duration (ie, decision block 1522 = “Yes”), at decision block 1524, the multicast service device client Or the client application can determine that a delay has already been introduced. In response to a determination that no delay has been introduced (i.e., decision block 1524 = “No”), at block 1528, the multicast service device client or client application has a 90% segment duration (0.9 * SD) delay. Can unmark all failed HTTP records. In this way, the available start time recalculation does not have to be triggered immediately and segments related to failed HTTP records are received a second time before those segments can be marked again as “received segments”. You may have to. A forced re-request of a segment may allow a recalculation of the available start time to be avoided when the segment can be received prior to the end of its respective available start time. At block 1502, the multicast service device client or client application may receive or generate the next HTTP request.

  In response to a determination that a delay is already installed (i.e., decision block 1524 = “Yes”), at block 1526, the multicast service device client or client application introduces a delay before two segment durations. Can be determined. In response to a determination that no delay was introduced prior to two segment durations (i.e., decision block 1526 = “No”), at block 1502, the multicast service device client or client application receives the next HTTP request. Or can be generated.

  In response to the determination that the delay was introduced before the two segment durations (i.e., decision block 1526 = “Yes”), at block 1112 the multicast service device client or client application recalculates the available start time. Can be triggered. For example, a multicast service device client or client application can use FIG. 5A, FIG. 5B, FIG. 6A, FIG. 6B, FIG. 8A, or FIG. 5 to modify the available start time in the MPD to the multicast service device client or client application. An interrupt may be sent that performs the operation of one of the methods 500a, 500b, 600a, 600b, 800a, or 800b described above with reference to 8B. In this way, timing drift at the receiver device can be identified by late arrival of segments, and timing drift can be taken into account by the multicast service device client or client application.

  FIG. 16 illustrates an embodiment method 1600 for determining a segment index by URL matching. In one embodiment, the operations of method 1600 may be performed by a multicast service device client executing on a processor of a receiver device, such as a smartphone. In another embodiment, the operations of method 1600 may be performed by a client application, such as a DASH client, that is executed on the processor of the receiver device. In various embodiments, the operations of method 1600 may be performed in conjunction with the operations of method 500a or 500b described above with reference to FIGS. 5A and 5B, respectively. For example, the operation of method 1600 may be performed after receiving an MPD (block 502 in FIG.5A or FIG.5B) and receiving a segment fragment (block 504 in FIG.5A or FIG.5B) and determining whether a segment index change has occurred ( It may be performed before block 506) of FIG. 5A or FIG. 5B.

  At block 1602, the multicast service device client or client application may determine the URL of the received segment. For example, the URL for the received segment may follow the URL template “xxx $ number $ yyy”. In another example, audio and video segments that correspond to the same time duration may have the same $ time $ tag in the URL template. At block 1604, the multicast service device client or client application can crawl the MPD to find the first period and expression combination in the MPD and set the first period and expression combination as the current period and expression combination. . In various MPDs, crawling the MPD may include parsing a file, such as an XML file, that represents the MPD. As discussed herein, the duration and expression combination can be a unique expression defined by the MPD. Each period defined in the MPD may include one or more representation-related attributes, for example, one or more adaptation sets, and the combination of a period and an individual expression from one or more expressions is , Period and expression combinations may be configured. The period and expression combination in the MPD may include attributes that describe each period and expression for the service, including period boundaries, URL format, segment duration, segment time scale, start number, bandwidth, period identifier, and the like.

  At block 1606, the multicast service device client or client application may compare the determined URL of the received segment with the current period and representation combination in the MPD. For example, a multicast service device client or client application can compare the URL in the received segment with the URL indicated in the duration and expression combination.

  At decision block 1608, the multicast service device client or client application may determine whether the determined URL for the segment matches the URL in the current period and expression combination. In response to a determination that the URL does not match (i.e., decision block 1608 = “No”), at block 1614, the multicast service device client or client application crawls the MPD to the next period and representation combination in the MPD. And the next period and expression combination can be set as the current period and expression combination. At block 1606, the multicast service device client or client application may compare the determined URL with a new current period and representation combination in the MPD.

  In response to the determination that the URL matches (i.e., decision block 1608 = “Yes”), at block 1610, the multicast service device client or client application is in the current time period and the URL within the representation binding and the determined URL. A potential segment number match can be determined based at least in part. For example, a multicast service device client or client application may be based at least on a URL by identifying a segment index at the end of the segment URL, preceded by at least a non-digit, and optionally a non-digit followed by a file extension. Potential segment numbers can be determined.

  At decision block 1612, the multicast service device client or client application may determine whether the potential segment number corresponds to the current period and the segment boundary of the expression combination. The period boundary may be determined based on either the period @ start attribute or the period @ duration attribute of the MPD, or by determining the difference between the next period start attribute and the current period start attribute. In this way, the multicast service device client or client application can verify that the segment number corresponds to a segment within the boundaries of the current period.

  In response to a determination that the segment number is not within the current period boundary (i.e., decision block 1612 = “No”), at block 1614, the multicast service device client or client application crawls the MPD and The next period and expression combination can be found and the next period and expression combination can be set as the current period and expression combination. If no match can be found, the procedure fails and the multicast service device client or client application does not apply any adjustment to the MPD, or simply adds margin M to the AST as an adjustment. Either is possible.

  In response to determining that the segment number is within the boundaries of the current period (i.e., decision block 1612 = `` Yes ''), at block 1616, the multicast service device client or client application obtains a segment index for the received segment. Can be set equal to potential segment number.

  17A, 17B, and 17C are block diagrams of elements of an exemplary MPD 1700 according to one embodiment. As shown in FIG. 17A, FIG. 17B, and FIG. 17C, as the MPD is crawled to identify the duration and expression combination, important attributes of the MPD may be identified by the multicast service device client or client application. These important elements are available start time, media presentation duration, duration, duration start, duration duration, duration base URL, duration segment template, adaptation set, adaptation set base URL, adaptation set segment template, representation, representation It may include an identifier, expression bandwidth, expression base URL, and expression segment template.

  FIG. 18 is a block diagram of an exemplary MPD 1800 XML tree according to one embodiment. As shown in FIG. 18, MPD 1800 may include multiple time periods, adaptation sets, and representations. In various embodiments, a multicast service device client or client application continuously develops an MPD 1800 XML tree from each period to its respective adaptation set and to each respective representation of those adaptations along each leaf of the tree. Can be crawled. As the multicast service device client or client application crawls the MPD1800, it identifies the URL, such as the base portion of the URL that matches the template "xxx $ number $ yyy", and determines a match for the URL of the received segment Can do.

  FIG. 19 illustrates a segment availability timeline according to one embodiment. Specifically, FIG. 19 shows the available start time of a segment of the video service representation (R1) listed in its associated MPD over the actual available start time of the segment on the receiver device. As shown in FIG. 19, a single segment duration video service may have a first period S36 that ends with a short duration segment of 0.5 seconds. Assuming segment S1 is available in period 1 in 1 second, segment S36 may be available in period 1 in 36 seconds. The available end time for segment S36 and period 1 may then be 36.5 seconds, based on a 0.5 second segment duration for segment S36.

  FIG. 20 shows one illustration of a single segment duration MPD2000 according to one embodiment, each showing its own respective adaptation set 1 and 2, each having its own representation 1 and periods 1 and 2 Is a typical schema part. MPD indicates the availability start of the segment for each timeline shown in FIG.

  FIG. 21 is a block diagram illustrating various results of crawling the MPD 2000 shown in FIG. 20 and matching URLs in time periods and expression combinations, according to one embodiment. Multicast service device client or client application determines that the received segment's URL2102 is "/video150000/0/chunk_41.mp4" and tries to find a match by matching the URL2102 to the duration and expression combination 2106 can do. The period and expression combination for period 2 adaptation set 1 expression 1 can match URL 2102 because bandwidth 15000 can match and id 0 can match elements in URL 2102. The available start time of a segment is the start time of the period 35.5 seconds + the segment duration of 1000ms + the segment index N, so that the available start time can be 37.5 seconds, which can be within an infinite period boundary. = 41—can be determined as segment start number 40. In this way, the match may be valid and the segment index for the received segment may be confirmed as 41.

  FIG. 22 illustrates a segment availability timeline according to one embodiment in which multiple segment durations are described in the MPD. The content may have two representations: a first representation (R1) having a segment duration of 1 second and a second representation (R2) having a segment duration of 2 seconds. Specifically, FIG. 22 shows the available start times of the segments of representations R1 and R2 listed in their associated MPDs over the actual available start times of the segments on the receiver device. As shown in FIG. 22, the available start time of the first segment of representation R1 or R2 depends on the segment duration for the representation to which that segment may belong. One of these representations can be expected to be broadcast at any given time within a service area.

  FIG. 23 shows its own respective adaptation set with two representations 0 and 1, each having a different segment duration, i.e. 1 second and 2 seconds, respectively, according to one embodiment showing periods 1 and 2 FIG. 2 is an exemplary schema portion having 1 and two segment durations MPD2300. This exemplary MPD corresponds to the timeline shown in FIG.

  FIG. 24 is a block diagram illustrating various results of crawling MPD 2300 shown in FIG. 23 and matching URLs in time periods and expression combinations according to one embodiment. The multicast service device client or client application determines that the received segment's URL2402 is "/audio30000/1/chunk_6.mp4", matches the URL2402 to the duration and expression combination 2406, and tries to find a match can do. The period and expression combination for period 2 adaptation set 1 expression 2 can match URL 2402, because bandwidth 30000 can match and id 1 can match an element in URL 2402. The available start time of the segment is the start time of the period 8 seconds + the segment duration of 2000ms + the segment index N so that the available start time can be 10 seconds to 12 seconds, which can be within the infinite period boundary = 6- It can be determined as the start time of start segment number 5. In this way, the match may be valid and the segment index for the received segment may be confirmed as 6.

  FIG. 25 illustrates an embodiment method 2500 for determining a segment index by URL matching when two or more time periods and expression combinations match a segment's URL and have valid boundaries for the segment. For example, as shown in the availability timeline of FIG. 26, some services may include repetitive segments, such as advertisements, and when a repetitive segment such as A3 is received, the segment URL is more than one You can match the duration and expression binding URL to a valid duration. To select the best candidate matching period and expression combination, the operation of method 2500 is to select a segment number as the segment number corresponding to the period and expression combination that the multicast service device client or client application results in the minimum AST change. Can make it possible. In one embodiment, the operations of method 2500 may be performed by a multicast service device client running on a processor of a receiver device, such as a smartphone. In another embodiment, the operations of method 2500 may be performed by a client application, such as a DASH client, that is executed on the processor of the receiver device. In various embodiments, the operations of method 2500 may be performed in conjunction with the operations of method 500a or 500b described above with reference to FIGS. 5A and 5B, respectively. For example, the operation of method 2500 may be performed after receiving an MPD (block 502 in FIG.5A or FIG.5B) and receiving a segment fragment (block 504 in FIG.5A or FIG.5B) and determining if a segment index change has occurred ( It may be performed before block 506) of FIG. 5A or FIG. 5B.

  In blocks 1602-1612, the multicast service device client or client application may perform the similarly numbered block operations of the method 1600 described above with reference to FIG. In response to the determination that the potential segment number is within the current period and segment boundary of the expression combination (i.e., decision block 1612 = “Yes”), the multicast service device client or client application may Periods and expression combinations and potential segment numbers can be stored as possible matches.

  At decision block 2504, the multicast service device client or client application can determine whether the entire MPD has been crawled. In response to a determination that the entire MPD has not been crawled (i.e., decision block 2504 = “No”), at block 1614, the multicast service device client or client application crawls the MPD to the next period in the MPD. And find the expression combination, and set the next period and expression combination as the current period and expression combination.

  In response to a determination that the entire MPD has been crawled (i.e., decision block 2504 = “Yes”), at block 2506, the multicast service device client or client application causes an AST change resulting from all possible stored matches. Can be determined. For example, a multicast service device client or client application can calculate an AST that results from receipt of a segment. The AST resulting from the receipt of the segment may be calculated in any manner, such as based on the method described above with reference to any of FIGS. 5A-15B, or any other method. For example, when a segment index change occurs, method 2500 can apply the procedure of FIG. 5A or FIG. 5B to determine an MPD timeline correction as part of block 2506. The multicast service device client or client application then determines the AST change that will occur for each possible stored match by subtracting the original AST for each possible stored match from the calculated AST resulting from receipt of the segment can do.

  At block 2508, the multicast service device client or client application may set the segment index for the received segment equal to the potential segment number of a possible match with minimal change in the AST. For example, the determined minimum AST change can be identified by comparing together the determined AST changes for each individual possible stored match, and the segment index for the received segment is identified , The segment index associated with a possible match with the determined minimum AST change. Thus, at block 2508, the multicast service device client or client application causes an MPD timeline adjustment that results in a smaller time correction relative to an existing timeline in the MPD (e.g., an MPD timeline adjustment that results in a minimum AST change). ) Can be selected. In one embodiment, the multicast service device client or client application may store a delay adjustment value that results in a minimum change (ie, minimum available start time change) within the available start time.

  FIG. 27 illustrates an embodiment method 2700 for considering receiver device timing drift based on URL matching. In one embodiment, the operations of method 2700 may be performed by a multicast service device client executing on a processor of a receiver device, such as a smartphone. In another embodiment, the operations of method 2700 may be performed by a client application, such as a DASH client, that is executed on the processor of the receiver device.

  At block 2702, the multicast service device client or client application may determine the segment index of the segment received by URL matching. For example, a multicast service device client or client application may perform the operations of method 1600 or method 2500 described above with reference to FIGS. 16 and 25, respectively, to determine the segment index by URL matching.

  At block 2704, the multicast service device client or client application may determine an available start time (AvailPerMPD) for each MPD for the segment having the determined segment index based on the matching period and the expression combination. At block 2706, the multicast service device client or client application may determine a segment duration (SD) from the MPD. At block 2708, the multicast service device client or client application may determine a decoding time (DT) for the segment. Decoding time (DT) may be the time at which a segment is actually available on the receiver device.

  At decision block 2710, the multicast service device client or client application may determine whether the decoding start time (DT) -available start time per MPD (AvailPerMPD) is greater than 0.5 times the segment duration (SD). it can. Shown as half of segment duration (for example, 0.5 * SD), but determines if decoding time (DT) -available start time per MPD (AvailPerMPD) is greater than 0.5 times segment duration (SD) To do is just one exemplary comparison of thresholds that can compare the difference between the decoding time (DT) and the available start time for each MPD (AvailPerMPD). For a threshold of 0.5 times the segment duration (SD) discussed herein, a ratio of segment durations, such as 1 * SD, .6 * SD, .9 * SD, or any segment duration Other thresholds can be substituted, including fixed value thresholds or threshold sets as other ratios. In response to a determination that DT-AvailPerMPD is not greater than 0.5 * SD (i.e., decision block 2710 = “No”), the multicast service device client or client application can determine that no timing drift has occurred. No action may be taken at block 2712. A factor (such as 0.5) may be prepared on the device or received as part of a configuration file broadcast by the network.

  In response to a determination that DT-AvailPerMPD is greater than 0.5 * SD (i.e., decision block 2710 = “Yes”), the multicast service device client or client application determines that timing drift has occurred, see FIG. As described above, at block 1112, a recalculation of available start time may be triggered. The multicast service device client or client application can also notify the application that the MPD has been modified.

  FIG. 28 illustrates an embodiment method 2800 for considering receiver device timing drift based on URL matching. The method 2800 is similar to the method 2700 described above with reference to FIG. 27, except that in response to a segment index change, a recalculation of available start time can be triggered. In one embodiment, the operations of method 2800 may be performed by a multicast service device client executing on a processor of a receiver device, such as a smartphone. In another embodiment, the operations of method 2800 may be performed by a client application, such as a DASH client, that is executed on the processor of the receiver device.

  At block 2702, the multicast service device client or client application may perform the similarly numbered block operations of the method 2700 described above with reference to FIG. At decision block 506, the multicast service device client or client application may determine whether a segment index change has occurred, as described above with reference to FIG. 5A. In response to a determination that the segment index has not changed (i.e., decision block 506 = “No”), the multicast service device client or client application, in block 2712, as described above with reference to FIG. No action is required.

  In response to a determination that the segment index has changed (i.e., decision block 506 = “Yes”), the multicast service device client or client application is numbered similarly to method 2700 described above with reference to FIG. The operations of blocks 2704, 2706, 2708, 2710, 2712, and 1112 can be performed.

  FIG. 29 illustrates an embodiment method 2900 for considering receiver device timing drift based on URL matching. With reference to FIG. 27, method 2900 can be triggered except that an availability start time recalculation can be triggered in response to a determination that an AST change will exceed a threshold, such as one segment duration. Similar to method 2700 described above. In one embodiment, the operations of method 2900 may be performed by a multicast service device client executing on a processor of a receiver device, such as a smartphone. In another embodiment, the operations of method 2900 may be performed by a client application, such as a DASH client, that is executed on the processor of the receiver device.

  At block 2702, the multicast service device client or client application may perform the similarly numbered block operations of the method 2700 described above with reference to FIG.

  At block 2902, the multicast service device client or client application may determine an AST change that resulted from the received segment. For example, a multicast service device client or client application can calculate an AST that results from receipt of a segment. The AST resulting from the receipt of the segment may be calculated in any manner, such as based on the method described above with reference to any of FIGS. 5A-15B, or any other method. The multicast service device client or client application can then subtract the original AST for the segment from the calculated AST resulting from the receipt of the segment to determine the AST change resulting from the segment.

  At decision block 2904, the processor can determine whether the AST change is greater than a threshold. The threshold may be a value stored in the memory of the receiver device, equal to the segment duration, less than one segment duration, exceeding one segment duration, etc. It can be any value (user definable, defined in MPD, etc.). In response to a determination that the AST change is below the threshold (i.e., decision block 2904 = `` No ''), the multicast service device client or client application blocks as described above with reference to FIG. No action is required at 2712. In response to determining that the AST change is greater than the threshold (i.e., decision block 2904 = `` Yes ''), the multicast service device client or client application may block 1112 as described above with reference to FIG. In, an available start time recalculation can be triggered.

  In various embodiments, the operations of methods 2700, 2800, and 2900 described above with reference to FIGS. 27, 28, and 29 are performed periodically at a fixed time interval or a fixed segment count interval, respectively. Can be applied.

  Various embodiments (including but not limited to those described above with reference to FIGS. 3A-29) may be implemented in any of a variety of mobile devices (ie, receiver devices), An example is shown in FIG. For example, mobile device 3000 can include a processor 3001 coupled to a touch screen controller 3004 and an internal memory 3002. The processor 3001 may be one or more multi-core integrated circuits (ICs) designated for general purpose or specific processing tasks. The internal memory 3002 may be volatile memory or non-volatile memory, and may be secure memory and / or encrypted memory, non-secure memory and / or non-encrypted memory, or any combination thereof. . Touch screen controller 3004 and processor 3001 may also be coupled to a touch screen panel 3012 such as a resistive sensing touch screen, a capacitive sensing touch screen, an infrared sensing touch screen. The mobile computing device 3000 can communicate with one or more wireless signal transceivers 3008 (e.g., Peanut (R), Bluetooth (R), Zigbee (R), Wi-Fi, RF, cellular, etc.) And / or an antenna 3010 for transmitting and receiving coupled to the processor 3001. Transceiver 3008 and antenna 3010 may be used with the circuits described above to implement various wireless transmission protocol stacks and interfaces. Mobile computing device 3000 may include a cellular network wireless modem chip 3016 that enables communication over a cellular network and is coupled to a processor. Mobile computing device 3000 may include a peripheral device connection interface 3018 coupled to processor 3001. Peripheral device connection interface 3018 can be configured alone to accept one type of connection, or accept various types of physical and communication connections, common or proprietary, such as USB, FireWire, Thunderbolt, or PCIe It can be configured in a complex manner. Peripheral device connection interface 3018 may also be coupled to a similarly configured peripheral device connection port (not shown). The mobile computing device 3000 can also include a speaker 3014 for providing audio output. Mobile computing device 3000 may also include a housing 3020 comprised of a combination of plastic, metal, or materials to accommodate all or some of the components discussed herein. The mobile computing device 3000 can include a power source 3022 coupled to the processor 3001, such as a disposable battery or a rechargeable battery. The rechargeable battery may also be coupled to the peripheral device connection port to receive charging current from a source external to the mobile computing device 3000.

  Various embodiments (including but not limited to those described above with reference to FIGS. 3A-29) are also implemented in any of a variety of commercially available server devices, such as the server 3100 shown in FIG. May be. Such a server 3100 typically includes a processor 3101 coupled to a volatile memory 3102 and a large capacity non-volatile memory such as a disk drive 3104. Server 3100 may also include a floppy disk drive, compact disk (CD) or DVD disk drive 3106 coupled to processor 3101. Server 3100 may also be a local area network, Internet, public switched telephone network, and / or cellular network (eg, CDMA, TDMA, GSM®, PCS, 3G, 4G) coupled to other announcement system computers and servers. Including one or more network transceivers 3103, such as network access ports, coupled to the processor 3101 to establish a network interface connection with a communication network 3107 (such as a cellular network, LTE, or any other type of cellular network) obtain.

  Processors 3001 and 3101 can be any programmable microprocessor, microcomputer, or one or more that can be configured by software instructions (applications) to perform various functions, including the functions of the various embodiments described above. It may be a multiprocessor chip. In some devices, multiple processors may be provided, such as one processor dedicated to wireless communication functions and one processor dedicated to running other applications. Typically, software applications can be stored in internal memory before they are accessed and loaded into processors 3001 and 3101. Processors 3001 and 3101 may include internal memory sufficient to store application software instructions. In many devices, the internal memory may be volatile memory, or non-volatile memory such as flash memory, or a mixture of both. For the purposes of this description, a general reference to memory includes internal memory, or removable memory plugged into the device, and memory accessible by the processors 3001 and 3101, including memory within the processors 3001 and 3101 itself. Point to.

  The foregoing method descriptions and process flow diagrams are provided by way of example only and do not require or imply that the steps of the various embodiments must be performed in the order presented. As those skilled in the art will appreciate, the order of steps in the above embodiments may be performed in any order. Words such as “after”, “next”, “next” do not limit the order of the steps, and these words are simply used to guide the reader through the description of the method. Furthermore, any reference to an element in a claim in the singular, for example using the article “a”, “an” or “the” should not be construed as limiting the element to the singular.

  The various exemplary logic blocks, modules, circuits, and algorithm steps described with respect to the embodiments disclosed herein may be implemented as electronic hardware, computer software, or a combination of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Those skilled in the art may implement the described functionality in a variety of ways for a particular application, but such implementation decisions should not be construed as causing deviations from the scope of the present invention.

  The hardware used to implement the various exemplary logic, logic blocks, modules, and circuits described with respect to the aspects disclosed herein includes general purpose processors, digital signal processors (DSPs), and application specific An integrated circuit (ASIC), field programmable gate array (FPGA) or other programmable logic device, individual gate or transistor logic, individual hardware components, or those designed to perform the functions described herein It can be implemented or implemented using a combination. A general purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. The processor may also be implemented as a combination of computing devices, eg, a combination of DPC and microprocessor, multiple microprocessors, one or more microprocessors in conjunction with a DPC core, or any other such configuration. Good. Alternatively, some steps or methods may be performed by circuitry that is dedicated to a given function.

  In one or more exemplary aspects, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored as one or more processor-executable instructions or code on a non-transitory computer-readable medium or non-transitory processor-readable medium. The steps of the method or algorithm disclosed herein may be embodied in a processor executable software module that may reside on a non-transitory computer readable or processor readable storage medium. A non-transitory server readable storage medium, non-transitory computer readable storage medium, or non-transitory processor readable storage medium may be any storage medium that can be accessed by a computer or processor. By way of example, and not limitation, such non-transitory server readable media, non-transitory computer readable media, or non-transitory processor readable media may be RAM, ROM, EEPROM, flash memory, CD-ROM or other optical disk storage, It may include magnetic disk storage or other magnetic storage device, or any other medium that can be used to store desired program code in the form of instructions or data structures and that can be accessed by a computer. Discs and discs, as used herein, are compact discs (CDs), laser discs (discs), optical discs, digital versatile discs. (DVD), floppy disk, and Blu-ray disk, which normally plays data magnetically, and the disk lasers the data To reproduce optically. Combinations of the above are also included within the scope of non-transitory server-readable media, non-transitory computer-readable media, and non-transitory processor-readable media. Additionally, the operation of the method or algorithm may be one of code and / or instructions on a non-transitory server readable medium, non-transitory processor readable medium, and / or non-transitory computer readable medium that may be incorporated into a computer program product. May exist as one or any combination or set.

  The previous description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the present invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the spirit or scope of the invention. Accordingly, the present invention is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the following claims and the principles and novel features disclosed herein. It is.

100 cellular network system
102 Receiver device
104 Cellular tower or base station
106 Cellular connection
108 servers
110 Internet
112 servers
202 Receiver device
204 Application / DASH Client
206 Multicast service device client (MSDC)
208 Modem layer
302 encoder
304 BMSC
306 Multicast service device client
308 DASH client
310 MPD
312 MPD
314 MPD
400 network
402 Encoder
404 Segmenta
406 network, first part, network part, part
408 network, second part, network part, part
410 Receiver device 1
412 Receiver device 2
500a method
500b method
600a method
600b method
800a method
800b method
1000 methods
1100a method
1100b method
1300 method
1400 method
1500a method
1500b method
1600 method
1170 MPD
1180 MPD
2000 MPD
2102 URL
2106 Duration and expression combinations
2402 URL
2406 Duration and expression combination
2300 MPD
2500 methods
2700 method
2800 method
2900 method
3000 mobile devices
3001 processor
3002 Internal memory
3004 touch screen controller
3008 radio signal transceiver
3010 antenna
3012 touch screen panel
3014 Speaker
3016 cellular network wireless modem chip
3018 Peripheral device connection interface
3020 housing
3022 power supply
3100 server
3101 processor
3102 volatile memory
3103 Network transceiver
3104 disk drive
3106 Floppy disk drive, compact disk (CD) or DVD disk drive

Claims (16)

A method for taking into account the timing drift of a receiver device,
Determining an index for the segment by uniform resource identifier (URL) matching;
Determining an availability start time of the segment based on a matching period and expression combination in an availability timeline;
Determining a segment duration from the availability timeline;
Determining a decoding time for the segment;
Determining whether the decoding time for the segment minus the available start time of the segment is greater than a threshold;
Triggering recalculation of the available start time in response to determining that the decoding time for the segment minus the available start time for the segment is greater than the threshold; Method. The step of determining whether the decoding time for the segment minus the availability start time for the segment is greater than a threshold value, the determining the availability start time for the segment from the decoding time for the segment; Determining whether the subtraction is greater than the segment duration ratio,
Triggering the recalculation of the available start start time in response to determining that the decoding start time for the segment minus the available start time for the segment is greater than the threshold value; Triggering recalculation of the available start time in response to determining that the decoding start time for the segment minus the available start time for the segment is greater than the ratio of the segment duration. The method of claim 1 comprising:   The method of claim 2, wherein the ratio of the segment duration is one half. Determining whether a segment index change occurs between two received segment fragments at the receiver device;
The step of determining the availability start time of the segment based on a matching period and a representation combination in the availability timeline includes the segment index between the two received segment fragments at the receiver device. The method of claim 1, comprising determining the availability start time of the segment based on a matching period and a representation combination in the availability timeline in response to determining that a change has occurred.   5. The method of claim 4, wherein the availability timeline is a dynamic adaptive streaming over hypertext transfer protocol (DASH) media presentation description (MPD). A method for taking into account the timing drift of a receiver device,
Determining a segment index for the received segment by uniform resource identifier (URL) matching;
Determining a change in available start time resulting from the received segment;
Determining whether the change in the available start time is greater than a threshold;
Triggering recalculation of the available start time in response to determining that the change in the available start time is greater than the threshold.   The method of claim 6, wherein the threshold is a segment duration.   8. The method of claim 7, wherein the availability timeline is a dynamic adaptive streaming over hypertext transfer protocol (DASH) media presentation description (MPD). A receiver device,
Comprising a processor configured with processor-executable instructions for performing an operation, the operation comprising:
Determining the index of the segment by uniform resource identifier (URL) matching;
Determining an availability start time for the segment based on a matching period and expression combination in an availability timeline;
Determining a segment duration from the availability timeline;
Determining a decoding time for the segment;
Determining whether the decoding time for the segment minus the available start time of the segment is greater than a threshold;
Triggering a recalculation of the available start time in response to determining that the decoding time for the segment minus the available start time for the segment is greater than the threshold; Receiver device. The processor is
Determining whether the decoding time for the segment minus the availability start time for the segment is greater than a threshold value, the determining the availability start time for the segment from the decoding time for the segment; Determining whether subtracted is greater than the ratio of the segment durations,
Triggering recalculation of the available start time in response to determining that the decoding start time for the segment minus the available start time for the segment is greater than the threshold; Triggering a recalculation of the available start time in response to determining that the decoding time for the segment minus the available start time of the segment is greater than the ratio of the segment duration The receiver device of claim 9, wherein the receiver device is configured with processor-executable instructions for performing such operations.   The receiver device of claim 10, wherein the ratio of the segment duration is one half. The processor comprises processor executable instructions for performing operations further comprising determining whether a segment index change occurs between two received segment fragments;
Wherein the processor determines the availability start time of the segment based on a matching period and a representation combination in the availability timeline, wherein the segment index change between the two received segment fragments A processor execution for performing an operation including determining the availability start time of the segment based on a matching period and a representation combination in the availability timeline in response to determining that the occurrence has occurred 10. A receiver device according to claim 9, consisting of possible instructions.   13. The receiver device of claim 12, wherein the availability timeline is a dynamic adaptive streaming over hypertext transfer protocol (DASH) media presentation description (MPD). A receiver device,
Comprising a processor configured with processor-executable instructions for performing an operation, the operation comprising:
Determining a segment index for the received segment by uniform resource identifier (URL) matching;
Determining an available start time change resulting from the received segment;
Determining whether the change in the available start time is greater than a threshold;
Triggering a recalculation of the available start time in response to determining that the change in the available start time is greater than the threshold.   15. A receiver device according to claim 14, wherein the threshold is a segment duration.   16. The receiver device of claim 15, wherein the availability timeline is a dynamic adaptive streaming over hypertext transfer protocol (DASH) media presentation description (MPD).