BR112016022245B1 - METHOD AND DEVICE TO RECOVER MEDIA DATA - Google Patents

Abstract

CONTINUOUS MULTI-PERIOD CONTENT PROCESSING. In one example, a device includes one or more processors configured to determine that a manifest file for media content indicates that the media content includes a first period and a second period, that the manifest file indicates that the first and second periods are continuous, and that ad media data is available for insertion between the first and second periods, select a first adaptation set in the first period based at least in part on signaled characteristics for the first adaptation set, retrieve data from media from the first adaptation set based on the selection of the first adaptation set, retrieve the advertisement media data, and retrieve media data from a second adaptation set in the second period that the manifest file indicates is associated with the first adaptation set adaptation based on selecting the first adaptation set and storing the retrieved media data in a memory.

Description

[0001] This application claims the benefit of US provisional application serial number 61/969,777, filed March 24, 2015, the entire contents of which are hereby incorporated by reference.

TECHNICAL FIELD

[0002] The present disclosure relates to transporting media data, for example, streaming media data over a network.

BACKGROUND

[0003] Digital video capabilities can be incorporated into a wide range of devices, including digital televisions, digital direct broadcast systems, wireless broadcast systems, personal digital assistants (PDAs), desktop or laptop computers, digital cameras, devices recording machines, digital media players, video game devices, video game consoles, satellite radio or cell phones, video teleconferencing devices, and the like. Digital video devices implement video compression techniques such as those described in the standards defined by MPEG-2, MPEG-4, ITU-T H.263, ITU-T H.264/MPEG-4, Part 10, Advanced Video Encoding video (AVC), ITU-H.265/MPEG-H Efficiency Video Coding standard part 2 and extensions of such standards, to transmit and receive digital video information more efficiently.

[0004] Video compression techniques perform spatial and/or temporal prediction to reduce or remove inherent redundancy in video sequences. For block-based video encoding, a video slice or frame can be divided into macroblocks. Each macroblock can be further divided. Macroblocks in an intra-coded (I) frame or slice are coded using spatial prediction with respect to neighboring macroblocks. Macroblocks in a slice or intercoded frame (P or B) can use spatial prediction with respect to neighboring macroblocks in the same frame or slice or temporal prediction with respect to other reference frames.

[0005] After encoding video data (and/or other media data such as timed audio and/or text data), the media data can be packaged for transmission or storage. Packed media data can be sent using a unicast protocol, such as hypertext transfer protocol (HTTP_), or a broadcast or multicast protocol, such as Service for Enhanced Multimedia Broadcast Multicast (eMBMS).

SUMMARY

[0006] In general, this disclosure describes techniques for preparing media content that is used for adaptive streaming so that in the case of streaming and playout, additional media data (e.g., ad media data) into an existing set of Media data can be joined and added together by signaling a time limit, for example by a decision at the sender who uses the content or by the receiver who receives the content, but at the same time the decoding and playout of the content at the receiver is continuous through period limit, that is, maintaining period continuity. Media content can be separated into distinct periods, where each period includes one or more adaptation sets, each containing one or more representations. In general, representations in the same adaptation set can be considered alternative to each other, so that a client device can switch between representations, for example, adapt to changing network bandwidth. One-period adaptation sets can include such switchable representations, that is, representations that share common delivery and encoding characteristics but differ in bitrates.

[0007] This disclosure describes techniques for splitting content offered in one period into two continuous periods so that additional media data can be inserted between the continuous periods. In this way, features for representations of continuous periods do not need to be signaled again after media data is added. Instead, the same features flagged for data representations in one period can be used for data representations in the next continuous period (where additional media data may be inserted between continuous periods). In this way, the media data of the media content and the added media data can be presented in a continuous mode. For example, a client device can use a second period adaptation set that matches a first period adaptation set, based on the second period adaptation set selection and without restarting the media parsing and decoding entity in the client).

[0008] In one example, a method of retrieving media data includes determining that a manifest file for media content indicates that the media content includes a first period and a second period, that the manifest file indicates that the first and second periods second periods are continuous, and that ad media data is available for insertion between the first and second periods, select a first adaptation set in the first period based at least in part on features flagged for the first adaptation set, retrieve data from media from the first adaptation set based on the selection of the first adaptation set, retrieve the advertisement media data, and retrieve media data from a second adaptation set in the second period that is associated with the first adaptation set based on the selection of the first set of adaptation.

[0009] In another example, a device for retrieving media data includes memory configured to store media data, and one or more hardware-based processors configured to determine that a manifest file for media content indicates that media content includes a first period and a second period, that the manifest file indicates that the first and second periods are continuous, and that ad media data is available for insertion between the first and second periods, select a first adaptation set in the first period based at least in part on characteristics flagged for the first adaptation set, retrieve media data from the first adaptation set based on the selection of the first adaptation set, retrieve advertisement media data, and retrieve media data from a second adaptation set in the second period that the manifest file indicates to be associated with the first adaptation set based on the selection of the first adaptation set and store the retrieved media data to memory.

[0010] In another example, a method of sending media data includes dividing, by a media server, main content of media data into a plurality of periods including a first period and a second period, wherein the first period and the second period are temporally sequential, by the media server inserting secondary media content between the first period and the second period, signaling by the media server a time pointer for each of the plurality of periods, where the time pointer defines one or more time characteristics for each of the plurality of periods, and receiving, by the media server, a request from a dynamic adaptive streaming client over HTTP (DASH) to retrieve a stream of media comprising the plurality of periods, secondary media content, and time indicators.

[0011] In another example, a device for sending media data includes a memory configured to store media data, and one or more hardware-based processors configured to divide the main content of the media data into a plurality of periods including a first period and a second period that are temporally sequential, inserting secondary media content between the first period and the second period, signaling a time indicator for each of the plurality of periods, wherein the time indicator defines one or more time characteristics for each of the plurality of periods, and receiving a request from a dynamic adaptive streaming client over HTTP (DASH) to retrieve a media stream comprising the plurality of periods, secondary media content and time indicators.

[0012] Details of one or more examples are set out in the attached drawings and description below. Other features, objects and advantages will be apparent from the description and drawings, and from the claims.

BRIEF DESCRIPTION OF THE DRAWINGS

[0013] Figure 1 is a block diagram illustrating an example system that implements techniques for streaming media data over a network.

[0014] Figure 2 is a conceptual diagram illustrating sample multimedia content elements.

[0015] Figure 3 is a block diagram illustrating another example system that can implement the techniques of this disclosure.

[0016] Figures 4-6 are flowcharts illustrating one or more techniques in accordance with various aspects of the present disclosure.

[0017] Figure 7 is a flowchart illustrating an example method of performing certain techniques of this disclosure by a media server.

[0018] Figure 8 is a flowchart illustrating an example method of performing certain techniques of this disclosure by a client device.

DETAILED DESCRIPTION

[0019] In general, this disclosure describes techniques for inserting ad (ad) into a continuous multiperiod stream. These techniques can be used when streaming media data, for example, under a unicast service (such as HTTP), broadcast, or multicast service, such as Enhanced Multimedia Broadcast Service for Multicast (eMBMS). For example, the techniques of this disclosure can be used in combination with, or to augment the techniques of, Improved MBMS Operation - Improvements in MBMS (MI-EMO). Mi-EMO is described, for example, in Overview of 3GPP Release 12 VO.1.1, December 2013, available at HTTP://www.3gpp.org/ftp/Information/WORK PLAN/Descritpion R eleasea/Rel-12 description 20131224.zip.

[0020] It should be understood that ad data is media data, that is, data presented to a user during one or more brief intermissions of the presentation of the primary media data. Additional media data (eg ad media data) is generally presented in substantially the same way as the primary media data. For example, if the primary media data includes both audio and video data, the ad media data will likely also include video and audio data. As such, the advertisement data should not be confused with a server advertisement for a client device that is generally not presented to a user.

[0021] The techniques in this disclosure can be applied in the context of a streaming network protocol, such as Dynamic Adaptive Streaming over HTTP (DASH). In DASH, media content is split into a set of representations, where each representation corresponds to a specific combination of characteristics, e.g. encoding characteristics (such as CODEC, profile, level and the like), delivery characteristics (e.g. angle of view, image dimensions, frame rate, and the like) and bit rate. The media content may further include adaptation sets, where each adaptation set includes a plurality of representations that act as switchable alternatives to one another, such that the representations share the same delivery characteristics but differ by bitrate, e.g. for bandwidth adaptation purposes. These characteristics of representations, as well as indications of adaptation sets, are typically flagged in a manifest file. Additionally, each adaptation set can correspond to a specific period of media content, where each period can include one or more adaptation sets. A period generally corresponds to a section of media content defined by a start playing time for the period to the start playing time for a subsequent period. Media content can include one or more time periods.

[0022] This disclosure concerns the conversion of a manifest file, such as a Media Presentation Description (MPD), and generated content such as On-demand or live content to an MPD (or other manifest file) with multiple periods providing period continuity. Multi-period content can be created for different reasons. For example, multiple time periods can be created to allow content merging, for example for ad insertion. In another example, multiple periods can be created to provide a synchronization point to avoid drift in segment numbering. In another example, multiple periods can be created to remove or add certain representations in an adaptation set. In another example, multiple periods can be created to remove or add certain adaptation sets. In another example, multiple periods can be created to add or remove content offered on certain content delivery networks (CDNs). In another example, multiple periods can be created to allow for shorter segment signaling if produced by the encoder. These sample techniques can be used individually or in any combination.

[0023] Periods provide opportunities for ad insertion, also known as suggestions. However, advertisements may or may not be added, based on decisions made by the sender or customer. Therefore, content for which no ads are inserted is typically continuous in terms of analytics and media delivery. If the periods are continuous, continuous playout to the client is signaled so that the client does not have to reboot and possibly avoid any result of a period limit failure. To address continuous playout, this disclosure describes several techniques. In one example, a content provider divides regular On-Demand Content into multiple periods and provides period continuation signaling. In another example, a content provider divides regular Live Content into multiple periods and provides period continuation signaling. In another example, a content provider signals multiple periods based on MPD information only without modifying the media content, ie representations.

[0024] In some examples, when receiving media content using broadcast or multicast, an MBMS client or eMBMS client can receive the media content, then make the media content available to a streaming client, such as a DASH client. The DASH client can retrieve media content from the MBMS client using, for example, HTTP retrieval operations. In HTTP streaming such as DASH, frequently used operations include HEAD, GET, and partial GET. The HEAD operation retrieves a header from a file associated with a given uniform resource locator (URL) or uniform resource name (URN), without retrieving a payload associated with the URL or URN. The GET operation retrieves an entire file associated with a given URL or URN. The partial GET operation takes a range of bytes as an input parameter and retrieves a continuous number of bytes from a file, where the number of bytes corresponds to the received range of bytes. In this way, movie fragments can be provided for HTTP streaming, because a partial GET operation can get one or more individual movie fragments. In one film fragment, there can be several track fragments from different tracks. In HTTP streaming, a media presentation can be a structured collection of data that can be accessed by the client. The client can request and download media data information to present a streaming service to a user.

[0025] In the example of streaming 3GPP data using HTTP streaming, there may be multiple representations for video data and/or audio of multimedia content. As explained below, different representations can correspond to different coding characteristics (e.g. different profiles or levels of a video coding standard), different coding standards or extensions of coding standards (such as multiview and/or scalable extensions) or different bit rates. The manifest of such representations can be defined in a Media Presentation Description (MPD) data structure. A media presentation can be a structured collection of data that can be accessed by an HTTP streaming client device. The HTTP streaming client device can request and download media data information to present a streaming service to a user of the client device. A media presentation can be described in the MPD data structure, which can include updates to the MPD.

[0026] A media presentation may contain a sequence of one or more periods. Periods can be defined by a period element in the MPD. The MPD can include a start attribute and an availableStartTime attribute for each period. For live services, the sum of the start of period attribute and the availableStartTime MPD attribute can specify the availability time of the period in UTC format, in particular the first Media Segment of each representation in the corresponding period. For on-demand services, the start attribute of the first period can be 0. For any other period, the start attribute can specify a time offset between the start time of the corresponding period versus the start time of the first period. Each period can extend until the beginning of the next period, or until the end of the media presentation in the case of the last period. Period start times can be accurate. They may reflect the actual timing resulting from playing media from all previous periods.

[0027] Each period can contain one or more representations for the same media content. A representation can be one of a number of alternative encoded versions of audio or video data. Representations may differ by encoding types, for example by bitrate, resolution and/or codec for video data and bitrate, language and/or codec for audio data. The term representation can be used to refer to a section of encoded audio or video data corresponding to a specific period of multimedia content and encoded in a specific way.

[0028] Representations of a specific period can be assigned to a group indicated by an attribute in the MPD indicative of a set of adaptations to which the representations belong. Representations in the same adaptation set are generally considered to be alternatives to each other, where a client device can dynamically and continuously switch between these representations, for example, to perform bandwidth adaptation. For example, each representation of video data for a specific period can be assigned the same set of adaptations, so that any of the representations can be selected for decoding to present media data, such as video data or audio data, from the content. of multimedia for the corresponding period. The media content in a period can be represented by a representation of group 0, if present, or a combination of at most one representation of each non-zero group, in some examples. Timing data for each representation of a period can be expressed in terms of the start time of the period.

[0029] A representation may include one or more segments. Each representation can include an initialization segment, or each segment of a representation can be bootstrap. When present, the initialization segment can contain initialization information for accessing the representation. In general, the boot segment does not contain media data. A segment can be uniquely referenced by an identifier, such as a uniform resource locator (URL), uniform resource name (URN), or uniform resource identifier (URI). MPD can provide identifiers for each segment. In some examples, MPD may also provide ranges of bytes in the form of a range attribute, which may correspond to data for a segment in a file accessible by URL, URN, or URI.

[0030] Different representations can be selected for substantially simultaneous recovery for different types of media data. For example, a client device can select an audio representation, a video representation, and a timed text representation from which to retrieve segments. In some examples, the client device may select specific adaptation sets to perform bandwidth adaptation. That is, the client device may select a adaptation set including video representations, a adaptation set including audio representations, and/or a adaptation set including exto-timed. Alternatively, the client device may select adaptation sets for certain media types (eg, video), and directly select representations for other media types (eg, audio and/or timed text).

[0031] Typically, no continuity is needed over a period limit in terms of offering content. Content can be served with different codecs, language attributes, content protection, and so on. The client is expected to play the content continuously over time, but there may be implementation implications to make the playout fully continuous and seamless.

[0032] In general, audio/video switching across period boundaries may not be seamless. According to ISO/IEC 23009-1, section 7.2.1, at the beginning of a new period, the playout procedure of media content components may need to be adjusted at the end of the preceding period to match the periodStart time of the new period seen that there may be minor overlaps or gaps with representation at the end of the preceding period. Overlaps (respectively gaps) can result from Media Segments with media stream effective presentation duration longer (respectively shorter) than indicated by period length. Also at the beginning of a period, if the earliest presentation time of any access unit of a representation cannot equal the presentation time offset flagged in @presentationTimeOffset, then the playout procedures need to be adjusted accordingly.

[0033] However, under certain conditions, seamless continuation of presentation across periods may be achieved, especially if the content is suitably conditioned. This section provides an overview of content delivery requirements and recommendations across periods and customer behavior when downloading and serving content across periods.

[0034] Note that the discussion below applies to both static and dynamic Media Presentations, and the techniques described below may be independent of the use of xlink. The rules described below may apply for the case after remote elements are dereferenced.

[0035] The presentation duration of a representation may be the difference between the final presentation time of the representation and the earliest presentation time of the representation. The display time duration can have, for example, the same unit as the display time offset, ie @timescale, and expresses the exact display duration of the representation.

[0036] The presentation duration can be signaled by one of the following two example techniques, or similar techniques. One example technique involves a new optional @presentationTimeDuration attribute specifying the presentation duration of the representation included in the timescale of the @timescale attribute. A second example technique involves a supplemental descriptor with @scheme_id_URI defined in “urn:mpeg:dash:period_continuity:2014”, which can be supplied to an adaptation set with the @value of the descriptor, PID, matching the value of an @ id of a period that may be contained in the MPD, the value of the AdaptationSet@id being AID, and the value of the @presentationTimeOffset for these adaptation sets may be provided and may be PTO.

[0037] If this signal is present, then for the period with the period@id value being PID and for the adaptation set with AdaptationSet@id being AID, the presentation duration of each representation in that adaptation set can be obtained as the PTO offset minus the @presentationTimeOffset value.

[0038] If content could be offered with multiple periods, then the content provider could offer the content in such a way that effective media display time can be as close as possible to the effective period duration. It may be recommended that the length of the period be the maximum of the duration of submission of all representations contained in the period.

[0039] In certain circumstances, the content provider offers content in the next period that may be a continuation of content in the previous period, possibly in the immediately following period or in a later period. The last mentioned case applies, for example, after an advertisement period has been entered. The content provider can express that media components contained in two adaptation sets in two different periods are associated by assigning equivalent Asset Identifiers to both periods and by identifying both adaptation sets with identical value for the @id attribute.

[0040] If adaptation sets in two different periods are associated, then all or any of the following parameters may be identical for the two adaptation sets: the language as described by the @lang attribute, the type of media component described by the attribute @contentType, the image aspect ratio as described by the @par attribute, any role properties as described by the role elements, any accessibility properties as described by the Accessibility elements, and any viewpoint properties as described by the Accessibility elements. Point of view. In one example, the DASH pattern can be modified in accordance with the techniques of this disclosure to require that, where adaptation sets in two different periods are associated, each of the above parameters be identical for the two adaptation sets.

[0041] Furthermore, two adaptation sets in an MPD can be said to be continuous-period if each of the following conditions is true for the two adaptation sets: . adaptation sets are indicated to be, and/or determined to be, associated, . @presentationTimeOffset may be present or may be inferred as 0 for all representations in both adaptation sets, . in an adaptation set, the value of @presentationTimeOffset can be identical for all representations, . the sum of the @presentationTimeOffset value and the presentation duration of all representations in one adaptation set is identical to the @presentationTimeOffset value of the other adaptation set, and . if representations in the two adaptation sets have the same value for @id, then they have functionally equivalent Initialization Segments, ie the Initialization Segment of one representation can be used to continue the layout of the other representation.

[0042] Content authors could flag continuous period adaptation sets by flagging presentation duration using one of the two example techniques introduced above (e.g., using presentation duration flags such as the @presentationTimeDuration attribute and/or the descriptor supplement with @scheme_id_URI defined in “urn:mpeg:dash:period_continuity: 2014”). Content authors could provide an MPD with continuous period adaptation sets if the MPD contains periods with identical Asset Identifiers. Furthermore, if two adaptation sets in an MPD are continuous period and the second adaptation set has an associated Supplementary Descriptor with @schemeIDURI=”urn.mpeg:dash:period-switchable,” then the concatenation of any representation of the first Adaptation with any representation from the second adaptation set without the Initialization Segment results in a bitstream format that conforms to the media formats in use as signaled in the first adaptation set. This property can be referred to as concatenatable period fitting sets. For simplified processing on clients, content authors can provide an MPD with concatenatable span adaptation sets if the MPD contains spans with identical Asset Identifiers.

[0043] Typically, no continuity is assured over a period limit, in terms of offering content. Content may be offered with different codecs, language attributes, and different protection, among other things. The client can play the content continuously over time, but there may be implementation implications to provide fully continuous and seamless playout. It may be the case that on time limits (eg where there is no continuity) the rendering engine may be reset, for example due to changes in formats, codecs or other properties. This can result in a restart delay. Such restart delay can be reduced or minimized.

[0044] If the MPD is of static type, then effective media presentation may be extended by startup delays. However, in the case of dynamic services, adding restart delay to the playout can result in drift between the encoder and the presentation engine. Therefore, the playout can be adjusted at the end of each period to provide a continuous presentation without adding drift between the time documented in the MPD and the actual playout, i.e., the difference between the effective playout time and the period start time can remain constant.

[0045] If the client presents media components from a certain adaptation set in one period, and if the following period has been assigned an identical Asset Identifier, then the client may identify an associated period and, in the absence of other information, continue o touch the content in the associated adaptation set.

[0046] If additionally the adaptation sets are of continuous period, that is, the presentation times are continuous and this can be signaled in the MPD, then the client can continuously play the content through the period limit. More appropriately, the client can continue to play the representation in the adaptation set with the same @id, however there may be no guarantee that this representation can be available. In that case, the client will seamlessly switch to any other representation in the adaptation set.

[0047] The input format can be an MPD that conforms to the On Demand profile. The relevant MPD elements and attributes are provided in the table below. In the example below, the MPD contains two fitting sets. Table 1 - Relevant information for the on-demand profile

[0048] For each representation, the Segment Index can be downloaded with the representation URL given in BaseURL given as baseURL and the value of SegmentBase@indexRange given as init as follows:GET baseURL HTTP/1.1 Range: bytes=0- (init-1)

[0049] Then the received byte range can be analyzed for Segment Index. From the first Segment Index box, information can be extracted. Track timescale can be extracted from segment index timescale and can be specified as timescale. The total number of Nsub subsegments can be extracted from the Segment Index as the reference_count. The earliest ept presentation time can be extracted from the Segment Index as the earliest_presentation_time. The first offset fo can be extracted from the Segment Index as the first_offset. For each leaf subsegment i, the subsequent duration in the Segment Index of each leaf subsegment denoted as sdur[i], the subsegment size size[i], and other subsegment-related information ssi[i].

[0050] In an example of an on-demand stream, the presentation can be split into two periods earlier in tsplit media presentation time expressed in relation to the period start time. There can be two adaptation sets and each adaptation set can have a representation. In some examples, an alignment of a subsequent boundary of adaptation sets may be applied.

[0051] The following information can be assumed to be available for single-period content. . period@start ps . MPD@mediaPresentationDuration mpDUR . BaseURL bu1, bu2 . SegmentBase@indexRange ir1, ir2 . SegmentBase@timescale ts1, ts2 . SegmentBase@presentationDuration pd1, pd2 . o Segment index of representation O Nsub1, Nsub2 O ept1, ept2 O fo1, fo2 O sdur1[i], sdur2[i] O fo1[i], fo2[i] O ss1[i], ss2[i]

[0052] To generate a new media presentation, the following information can be generated: Update of attributes and elements in the first period of for each representation of each adaptation set: a. period@start ps1 b. add period@duration pdur1 = tsplit c. baseURL bu11, bu12 d. SegmentBase@indexRange ir11, ir12 e. SegmentBase@presentationTimeOffset pto11, pto12 f. SegmentBase@presentationDuration pd11, pd12 g. The segment index of representation i. Nsub11, Nsbu12 ii. Ept11, ept12 iii. Pho11, fo12 iv. Sdur11[i], sdur12[i] v. Ssi11[i], ssi12[i] h. The representation itself can be shortened Update and add attributes and elements in the second new period for each representation: 1. add period@duration pdur2 2. BaseURL bu21, bu22 3. SegmentBase@indexRange ir21, ir22 4. SegmentBase@presentationTimeOffset pto21, pto22 5. SegmentBase@presentationDuration pd21, pd22 f. The segment index of representation i. Nsub21, Nsbu22 ii. Ept21, ep22iii. Fo21, fo22 iv. Sdur21[i], sdur22[i] v. Ssi21[i], ssi22[i] The representation itself can be generated.

[0053] New information can be generated as follows for the first representation that aligns with the segment boundary. First, the Nsub11 can be found that corresponds to tsplit, for example, according to the following algorithm: . time = eptl — ptol . Nsub11 = 0 . while (time < tsplit*tsl &&Nsubll < Nsubl)) . do The time + = sdur[Nsubll] The Nsubll++ . done

[0054] By this algorithm, Nsubll can be determined. Nsbull can be smaller than Nsubll. If Nsubll is not less than Nsubll, no period division is necessarily done.

[0055] The split time for l representation may be tsplitl = time/tsl >= tsplit since a split on an exact segment boundary may be desired. Note that the advertised split can be tsplit, but at a representation level, only segment boundaries are split. The new segment index size can be smaller than the previous one, that is, the new segment index size can be (Nsubl - Nsbu11)*12 byte smaller. This can be deducted from the first displacement.

[0056] Time can be the pd11 presentation duration. The period@start of period 1 can be kept. The period@duration can be set in tsplit. The following algorithm is an example of how new information can be generated for representation 1 in period 1. . bull = bul_period1 . ir11 = ir1 - (Nsubl - Nsub11)*12 . pto11 = pto1 . pd11 = time . ept11 = ept1 . fo11 = fo1 - (Nsub1 - Nsub11)*12 . i = 0 . while (while (i < Nsub11)) . do O ssi11[i] = ssi[i] O i++ . done

[0057] The following Nsub12 can be found that corresponds to tsplit, for example according to the following algorithm: . time = ept2 - pto2 . Nsub12 = 0 . while (time <tsplit*ts2 && Nsub12 < Nsub2)) . do O time += sdur[Nsub12] O Nsub12++ . done

[0058] The actual split time for representation 2 may be tsplit2 = time/t2 >=tsplit, a split at an exact subsequent boundary may be desired. The new segment index size can be smaller than the previous one, for example it can be (Nsub2 - Nsub12)*12 bytes smaller. This can be deduced from the first displacement.

[0059] Time can be the pd21 presentation duration. The algorithm below is an example of how new information can be generated for representation 2 in period 1. . bul2 = bu2_period1 . ir12 = ir2 - (Nsub2 - Nsub12)*12 . pto12 = pto2 . pd12 = time . ept12 = ept2 . fo12 = fo2 - (Nsub2 - Nsub12)*12 . i = 0 . while (while (i < Nsub12)) . make O ss12[i] = ss2[i] O i++ . done

[0060] A new period 2 can be generated. In particular, in an example, a server device can generate the new period2. Firstly, the server device 60 can copy the information from period 1 (also the asset identifier, and adaptation sets with ids, and etc.) The period@start of the new period need not be provided. The period@duration pdur2 of the new period can be mpDUR - tsplit. The following algorithm is an example of how new information can be generated for representation 1 in period 2. . Nsub12 = Nsub1 - Nsub11 . but21 = bu1_period2 . ir21 = ir1 - (Nsub1 - Nsub12)*12 . pto21 = (tsplit1 - tsplit)*ts1 . pd21 = pd1 - pd11 . ept21 = pd11 . fo21 = fo1 - (Nsub1 - Nsub12)*12 . i = 0 . while (while (i < Nsub12)) . do O ssi21[1] = ss1[i + Nsub11] O i++ . done

[0061] The following algorithm is an example of how new information can be generated for representation 2 in period 2. . Nsub22 = Nsub2 - Nsub12 . bu22 = bu2_period2 . ir22 = ir2 - (Nsub2 - Nsub22)*12 . pto22 = (tsplit2 - tsplit)*ts2 . pd22 = pd2 - pd12 . ept22 = pd12 . fo22 = fo2 - (Nsub2 - Nsub22)*12 . i = 0 . while (while (i < Nsub22)) . do O ssi22[i] = ssi2[i+Nsub12] O i++ . done

[0062] In other examples, tsplit can be used as a time division to have pto21 be 0. This may be the case as division can be done on the IDR frame.

[0063] The above information can be mapped back into a complete MPD with the same information, however by the algorithm discussed above, a tsplit-time join point can be generated. Any period can be entered at the join point. The above effort can remove MPD@mediaPresentationDuration and add and replace as documented above.

[0064] In another example technique of this disclosure, a live stream can be used. For a live profile information, information can be available from MPD and Segments. Track timescale can be extracted from Segment index timescale and can be specified as timescale. The total number of Nseg segments can be extracted from Segment Information. The earliest ept presentation time can be extracted from the Segment Index as the earliest_presentation_time. The first @startNumber offset can be extracted from the MPD. For each segment I, the segment duration in the Segment Index of each leaf subsegment indicated as sdur[i] and other segment-related information si[i].

[0065] In an example presentation, the presentation can be divided into two periods earlier in tsplit media presentation time expressed in relation to the period Start time. This division might not line up with the segment boundary of the second adaptation set. There can be two adaptation sets and each adaptation set can have a representation.

[0066] The following information can be assumed to be available for single-period content. . period@start ps . MPD@mediaPresentationDuration mpDUR . SegmentTemplate@media mt1, mt2 . SegmentTemplate@timescale ts1, ts2 . SegmentTemplate@presentationDuration pd1, pd2 . The segment information The Nseg1, Nseg2 The ept1, ept2 The sn1, sn2 The sdur1[i], sdur2[i] The si1[i], si2[i]

[0067] To generate a new media presentation, the following information can be generated: . a server device can update attributes and elements in the first period for each representation of each adaptation set, as follows: The period@start ps1 The add period@duration pdur1 = tsplit The Segmenttemplate@media mt11, mt12 The segmentTemplate@presentationTimeOffset pto11 , pto12 O segmentTemplate@presentationDuration pd11, pd12 O The segment information of the representation G Nseg11, Nseg12 G ept11, etp12 G sn11, sn12 Gsdur11[i], sdur12[i] G si11[i], si12[i] O the representation itself can be shortened. a server device can update and add new elements and attributes in the second period for each representation, as follows: The add period@duration pdur2 The Segmenttemplate@media mt21, mt22 The segmentTemplate@presentationTimeOffset pto21, pto22 The segmentTemplate@presentationDuration pd21, pd22 O The segment information of the representation G Nseg21, Nseg22 G ept21, etp22 G sn21, sn22 Gsdur21[i], sdur22[i] G si21[i], si22[i] O the representation itself can be generated.

[0068] A server device can generate new information as follows for the first representation that aligns with the segment boundary. First, Nseg11 can be found that corresponds to tsplit, according to the following algorithm: . time = eptl — ptol . Nseg11 = 0 . while (time < tsplit*tsl && Nsegll < Nsegl)) . do The time + =sdur[Nsegll] The Nsegll++ . done

[0069] By this algorithm, a server device can determine Nsegll. Nsegll can be smaller than Nsegl. If Nsegll is not less than Nsegl, no period division can be done. Time can be duration of pdll presentation. The split time for l representation may be tsplitl = time/tsl >= tsplit as a split on an exact segment boundary may be desired. Note that the advertised split can be tsplit, but at a representation level only segment boundaries can be split. The period@start of period l can be maintained. The period@duration can be set in tsplit. The following algorithm is an example of how new information can be generated for representation l in period l. . mtll = mtl. ptoll = ptol. pdll = time . eptll = eptl . sn11 = sn1 . i = 0 . while (while (i < Nseg11)) . do O si11[i] = si1[i] O i++ . done

[0070] Then Nseg12 can be found that corresponds to tsplit, for example, according to the following example algorithm: . time = ept2 - pto2 . Nseg12 = 0 . while (time < tsplit*ts2 && Nseg12 < Nseg2)) . do O time += sdurf[Nseg12] O Nseg12++ . done

[0071] The actual split time for representation 2 may be tsplit2 = time/ts2 >= tsplit as a split on an exact subsegment boundary may be desired. Time can be the duration of pd12 presentation. The following algorithm is an example of how new information can be generated for representation 2 in period 1. . mt12 = mt2 . pto12 = pto2 . pd12 = time . ept11 = ept1 . sn12 = sn2 . i = 0 . while (while (i < Nseg12)) . do O si12[i] = si2[i] O i++ . done

[0072] A new period 2 can be generated. Firstly, information from period 1 can be copied (also the asset identifier, and adaptation sets with ids and etc.). The period@start of the new period may not be provided. The period@duration pdur2 of the new period can be mpDUR -tsplit. The following algorithm is an example of how new information can be generated for representation 1 in period 2. . Nseg12 = Nseg1 - Nseg11 . mt21 = mt1 . pto21 = (tsplit1 - tsplit)*ts1 . pd21 = pd1 - pd11 . ept21 = pd11 . sn21 = sn1 + Nseg11 . i = 0 . while (while (i < Nseg12)) . do O si21[i] = si1[i+Nseg11] O i++ . done

[0073] The following algorithm is an example of how new information can be generated for representation 2 in period 2. . Nseg22 = Nseg2 - Nseg12 . mt22 = mt2 . pto22 = (tsplit1 - tsplit)*ts2 . pd22 = pd2 - pd12 . ept22 = pd12 . sn22 = sn2 + Nseg12 . i = 0 . while (while (i < Nseg22)) . do O si22[i] = si2[i+Nseg12] O i++ . done

[0074] In some examples, tsplit1 can be used as time division to have pto21 be 0. This may be the case, when division can be done on the IDR frame.

[0075] The above information can be mapped into a complete MPD with the same information, however by doing so a tsplit-time junction point can be generated. Any period can be entered here. The above effort may remove MPD@mediaPresentationDuration and add and replace the information documented above.

[0076] Using techniques from the current development, On Demand profile can be optimized. The problem with the On Demand profile offering could be that to do a period build for ad insertion, you must physically modify the file. This has two consequences. First, modifications require file-level modifications and are relatively complex. This means that for ad insertion, the content can be changed. Second, if different ad junction points are considered, different content and different URLs may be used. This means that for the same content, storage and especially caching efficiency can be reduced. Therefore, it may be proposed below to allow ad insertion and period based on MPD level information only. This requires some modifications to the MPD and these tools will be added to the newly developed ad insertion profile that includes xlink.

[0077] In an example of an on-demand stream, the presentation may be split into two periods earlier in the tsplit media presentation time expressed in relation to the Period Start time. There can be two adaptation sets and each adaptation set can have a representation. In some examples, an alignment of a subsequent boundary of adaptation sets may be applied. The following information can be assumed to be available for single-period content. . period@start ps . MPD@mediaPresentationDuration mpDUR . BaseURL bu1, bu2 . SegmentBase@indexRange ir1, ir2 . SegmentBase@timescale ts1, ts2 . SegmentBase@presentationDuration pd1, pd2 . o Segment index of representation O Nsub1, Nsub2 O ept1, ept2 O fo1, fo2 O sdur1[i], sdur2[i] O fo1[i], fo2[i] O ss1[i], ss2[i]

[0078] To generate a new media presentation, the following information can be generated: . Update of attributes and elements in the first period for each representation of each adaptation set: o. period@start ps1 o add period@duration pdur1 = tsplit o SegmentBase@indexRange o SegmentBase@presentationTimeOffset pto11, pto12 o SegmentBase@presentationDuration pd11, pd12 Update and add attributes and elements in the second new period for each representation: o add period@duration pdur2 O SegmentBase@indexRange O SegmentBase@presentationTimeOffset pto21, pto22 O SegmentBase@presentationDuration pd21, pd22

[0079] The above information for pto and pd can be generated in the same way as for the On Demand Profile. The only difference may be that it can be explicitly said in the representation, that only the time between pto and pd can be touched for that representation, using the information in the Segment Index.

[0080] The following example is in reference to Figure 3. An MPD may be available that points to on-demand content on the CDN containing a single-period presentation. The MPD, based on suggestions (ad insertion opportunities), can be modified for multiple ad periods without changing the content on the server. For each lead, an xlink to the Ad Decision server can be provided. The MPD can be provided to the DASH client. For each xlink in the MPD, it can be checked whether advertisements are added, possibly targeting the user. If not, the period can be set to 0. If so, other content can be added. The DASH client plays content continuously, and if set to zero, the media engine may not be freshly started.

[0081] Figure 1 is a block diagram illustrating an example system 10 that implements techniques for streaming media data over a network. In this example, system 10 includes content preparation device 20, server device 60, and client device 40. Client device 40 and server device 60 are communicatively coupled over network 74, which may comprise the Internet. In some examples, content preparation device 20 and server device 60 may also be coupled over network 74 or another network, or may be directly communicatively coupled. In some examples, content preparation device 20 and server device 60 may comprise the same device.

[0082] The content preparation device 20, in the example of Figure 1, comprises audio source 22 and video source 24. Audio source 22 may comprise, for example, a microphone that produces electrical signals representative of audio data captured to be encoded by the audio encoder 26. Alternatively, the audio source 22 may comprise a storage medium that stores pre-recorded audio data, an audio data generator such as a computer synthesizer, or any other source of audio data . The video source 24 may comprise a video camera producing video data to be encoded by the video encoder 28, a storage medium encoded with previously recorded video data, a video data generation unit as a graphic source of computer, or any other source of video data. Content preparation device 20 is not necessarily communicatively coupled to server device 60 in all examples, but may store multimedia content on separate media that is read by server device 60.

[0083] Raw video and audio data can comprise analog or digital data. Analog data may be digitized before being encoded by audio encoder 26 and/or video encoder 28. Audio source 22 may obtain audio data from a speaking participant while the speaking participant is speaking, and Video 24 can simultaneously obtain video data from the speaking participant. In other examples, audio source 22 may comprise computer readable storage media comprising stored audio data, and video source 24 may comprise computer readable storage media comprising stored video data. Thus, the techniques described in this disclosure can be applied to live, streaming, real-time video and audio data or to pre-recorded, archived video and audio data.

[0084] Audio frames that correspond to video frames are generically audio frames containing audio data that was captured (or generated) by the audio source 22 contemporaneously with video data captured (or generated) by the video source 24 that is contained in the video frames. For example, while a speaking participant generally produces audio data by speaking, audio source 22 captures the audio data, and video source 24 captures video data from the speaking participant at the same time, i.e., while audio source 22 is capturing the audio data. Consequently, an audio frame can temporally correspond to one or more specific video frames. Therefore, an audio frame corresponding to a video frame corresponds in general to a situation in which audio data and video data were captured at the same time and for which an audio frame and a video frame respectively comprise audio data and video data that were captured at the same time.

[0085] In some examples, the audio encoder 26 may encode a timestamp into each encoded audio frame that represents a time at which the audio data for the encoded audio frame was recorded, and similarly, the video encoder 28 can encode a time stamp into each encoded video frame that represents a time at which the video data for the encoded video frame was recorded. In such examples, an audio frame corresponding to a video frame may comprise an audio frame comprising a timestamp and a video frame comprising the same timestamp. Content preparation device 20 may include an internal clock from which audio encoder 26 and/or video encoder 28 may generate time stamps, or which audio source 22 and video source 24 may use to associate video and audio data respectively with a timestamp.

[0086] In some examples, audio source 22 may send data to audio encoder 26 corresponding to a time at which audio data was recorded, and video source 24 may send data to video encoder 28 corresponding to a time in which video data was recorded. In some examples, the audio encoder 26 may encode a sequence identifier into the encoded audio data to indicate a relative temporal ordering of the encoded audio data, but if it necessarily indicates an absolute time at which the audio data was recorded, and similarly , video encoder 28 may also use sequence identifiers to indicate a relative temporal ordering of encoded video data. Similarly, in some examples, a sequence identifier may be mapped or otherwise correlated to a timestamp.

[0087] The audio encoder 26 generally produces an encoded audio data stream, while the video encoder 28 produces an encoded video data stream. Each individual stream of data (either audio or video) can be referred to as an elementary stream. An elementary stream is a digitally encoded, single (possibly compressed) component of a representation. For example, the encoded audio or video portion of the representation can be an elementary stream. An elementary stream can be converted to a packaged elementary stream (PES) before being encapsulated into a video file. In the same representation, a flow ID can be used to distinguish the PES packets belonging to one elementary flow from the other. The basic data unit of an elementary stream is a packetized elementary stream (PES) packet. Thus, encoded video data generally corresponds to elementary video streams. Similarly, audio data corresponds to one or more respective elementary streams.

[0088] Many video encoding standards, such as ITU-T H.264/AVC and the nearby High Efficiency Video Coding (HEVC) standard, define the syntax, semantics, and decoding process for error-free bit streams , any of which conform to a certain profile or level. Video coding standards typically do not specify the encoder, but the encoder is tasked with ensuring that the generated bitstreams conform to the standard for a decoder. In the context of video coding standards, a “profile” is a subset of algorithms, features or tools, and limitations that apply to them. As defined by the H.264 standard, for example, a “profile” is a subset of the entire bitstream syntax that is specified by the H.264 standard. A “level” corresponds to limitations on decoder resource consumption, such as decoder and compute memory, which are related to image resolution, bit rate, and block processing rate. A profile can be flagged with a profile_idc (profile indicator) value, while a level can be flagged with a level_idc (level indicator) value.

[0089] The H.264 standard, for example, recognizes that, within the limits imposed by the syntax of a given profile, it is still possible to demand a large variation in the performance of encoders and decoders depending on the values taken by syntax elements in the bit stream as the specified size of the decoded images. The H.264 standard further recognizes that, in many applications, it is neither practical nor economical to implement a decoder capable of handling all hypothetical uses of the syntax in a specific profile. Accordingly, the H.264 standard defines a “level” as a specified set of constraints imposed on values of syntax elements in the bis stream. These limitations can be simple limits on values. Alternatively, these limitations may take the form of limitations on arithmetic combinations of values (eg, image width multiplied by image height multiplied by number of decoded images per second). The H.264 standard further provides that individual implementations can support a different level for each supported profile.

[0090] A decoder conforming to a profile commonly supports all features defined in the profile. For example, as an encoding feature, B-picture encoding is not supported in the baseline H.264/AVC profile, but is supported in other H.264/AVC profiles. A decoder conforming to a level may be able to decode any bit stream that does not require resources beyond the limitations defined in the level. Profile definitions and levels can be useful for interpretability. For example, during video streaming, a pair of profile and level settings can be negotiated and agreed upon for an entire streaming session. More specifically, in H.264/AVC, a level can set limitations on the number of macroblocks that need to be processed, decoded picture buffer (DPB) size, encoded picture buffer (CPB) size, motion vector range vertical, maximum number of motion vectors for two consecutive MBs, and whether a B-block can have sub-macroblock divisions smaller than 8x8 pixels. In this way, a decoder can determine whether the decoder is capable of properly decoding the bit stream.

[0091] In the example of Figure 1, the encapsulation unit 30 of the content preparation device 20 receives elementary streams comprising encoded video data from the video encoder 28 and elementary streams comprising encoded audio data from the audio encoder 26. In some examples, the video encoder 28 and audio encoder 26 may individually include packers to form PES packets from encoded data. In other examples, video encoder 28 and audio encoder 26 can individually interface with respective packers to form PES packets from encoded data. In yet other examples, encapsulation unit 30 may include packers for forming PES packets from encoded video and audio data.

[0092] Video encoder 28 can encode multimedia content video data in a variety of ways to produce different representations of multimedia content at various bitrates and with various characteristics such as pixel resolutions, frame rates, compliance with various encoding standards, compliance with various profiles and/or levels of profiles for various encoding standards, representations having single or multiple views (e.g., for two-dimensional or three-dimensional reproduction) or other such features. A representation, as used in this disclosure, may comprise one of audio data, video data, text data (eg, for closedcaptions), or other such data. The representation can include an elementary stream, such as an audio elementary stream or a video elementary stream. Each PES packet can include a stream_id that identifies the elementary stream to which the PES packet belongs. The encapsulation unit 30 is responsible for assembling elementary streams into video files (eg segments) of various representations.

[0093] The encapsulation unit 30 receives PES packets for elementary streams of a representation from audio encoder 26 and video encoder 28 and forms corresponding Network Abstraction Layer (NAL) units from the PES packets. In the H.264/AVC (Advanced Video Coding) example, encoded video segments are organized into NAL units, which provide a “network-friendly” video representation addressing applications such as video telephony, storage, broadcast or streaming. NAL units can be categorized into Video Coding Layer (VCL) NAL units and non-VCL NAL units. VCL units may contain the core compression engine and may include block, macroblock, and/or slice level data. Other NAL units may be non-VCL NAL units. In some examples, a time-encoded image, normally presented as a primary encoded image, may be contained in an access unit, which may include one or more NAL units.

[0094] Non-VCL NAL units may include parameter set NAL units and NAL SEI units, among others. Parameter sets can contain sequence-level header information (in sequence parameter sets (SPS)) and infrequently changing image-level header information (in image parameter sets (PPS)). With parameter sets (eg PPS and SPS), infrequently changing information does not need to be repeated for each sequence or image, consequently the coding efficiency can be improved. Furthermore, the use of parameter sets can allow out-of-band transmission of important header information, avoiding the need for redundant transmissions for error resiliency. In examples of out-of-band transmission, parameter set NAL units may be transmitted on a different channel than other NAL units, such as NAL SEI units.

[0095] Supplemental Enhancement Information (SEI) may contain information that is not required to decode the encoded image samples from NAL VCL units, but may assist in processes related to decoding, display, error resiliency, and other purposes. SEI messages can be contained in non-VCL NAL units. SEI messages are the normative part of some standard specifications, and thus are not always mandatory for standard-compliant decoder implementation. SEI messages can be sequence-level SEI messages or picture-level SEI messages. Some sequence-level information may be contained in SEI messages, such as scalability information SEI messages in the SVC example and view scalability information SEI messages in MVC. These sample SEI messages can convey information, for example, on operating point extraction and operating point characteristics. Furthermore, the encapsulation unit 30 can form a manifest file such as a media presentation descriptor (MPD) that describes characteristics of the representations. The encapsulation unit 30 can format the MPD according to Extensible Markup Language (XML).

[0096] The encapsulation unit 30 may provide data for one or more multimedia content representations, along with the manifest file (eg, the MPD) to the transmission interface 32. The transmission interface 32 may comprise an interface network interface or an interface for writing to storage media, such as a universal serial bus (USB) interface, a CD or DVD burner, an interface for flash or magnetic storage media, or other interfaces for storing or transmitting data from media. Encapsulation unit 30 can provide data from each of the multimedia content representations to transmission interface 32, which can send the data to server device 60 via network transmission or storage media. In the example of Figure 1, the server device 60 includes storage media 62 that store various multimedia contents 64, each including a respective manifest file 66 and one or more representations 68A - 68N (representations 68). In some examples, output interface 32 may also send data directly to network 74.

[0097] In some examples, the 68 representations can be separated into adaptation sets. That is, various subsets of representations 68 may include respective common sets of characteristics, such as codec, profile and level, resolution, number of views, file format for segments, text type information that can identify a language, or other text characteristics. to be displayed with the representation and/or audio data to be decoded and presented, for example by speakers, camera angle information that can describe a camera angle or real world camera perspective of a scene for representations in the adaptation set, rating information describing content suitability for specific audiences, or similar.

[0098] The manifest file 66 may include data indicative of subsets of representations 68 corresponding to specific adaptation sets, as well as common characteristics for the adaptation sets. Manifest file 66 may also include data representative of individual characteristics, such as bitrates, for individual representations of adaptation sets. In this way, an adaption set can provide simplified network bandwidth adaptation. Representations in an adaptation set may be indicated using child elements of an adaptation set element of manifest file 66. In accordance with the techniques of this disclosure, the server device 60 may modify manifest file 66 to indicate that content of multimedia 64 includes two or more continuous periods, between which advertising content may be inserted.

[0099] In particular, server device 60 may construct manifest file 66 using any of the various techniques described above, or similar techniques, to indicate that there are continuous periods in multimedia content 64, so that additional content (such as content from ad) can be inserted between continuous periods. For example, server device 60 can add a Period@duration attribute to manifest file 66 for each period that is divided into two continuous periods. Similarly, the server device 60 can add new rolling period indicative data to the manifest file 66 such as a Period@duration element, baseURL elements, SegmentBase@indexRange elements, SegmentBase@presentationTimeOffset elements, and SegmentBase@presentationDuration. Furthermore, the server device 60 can signal the various segment index elements discussed above, and generate new representations for the new period from the existing representations.

[0100] Therefore, in some examples, the server device 60 may divide media data main content into a plurality of periods including a first period and a second period, where the first period and the second period are temporally sequential. That is, the first and second periods include data for core content that is intended to be played out continuously. Server device 60 may insert secondary media content (eg, advertisement media content) between the first and second periods. Furthermore, server device 60 may signal a time indicator for each of the plurality of periods that defines one or more time characteristics for each of the plurality of periods. The time indicator may comprise, for example, Period@duration attributes in manifest file 66 for periods. Server device 60 may then receive a request, for example, from client device 40 to retrieve a media stream comprising periods, secondary media content, and time indicators. The request may be one of a plurality of requests to retrieve media stream data from client device 40. For example, the plurality of requests may be partial GET or HTTP GET requests.

[0101] Although the above techniques are described with respect to the server device 60, it should be understood that the content preparation device 20 can also (i.e., in addition to or alternatively) be configured to split a period into two continuous periods and insert ad media data between rolling periods.

[0102] Server device 60 includes request processing unit 70 and network interface 72. In some examples, server device 60 may include a plurality of network interfaces. Furthermore, any or all of the features of server device 60 may be implemented in other devices in a content delivery network, such as routers, links, proxy devices, switches, or other devices. In some examples, intermediate devices of a content delivery network may cache multimedia content data 64, and include components that substantially conform to those of server device 60. In general, network interface 72 is configured to send and receive data over the network 74.

[0103] Request processing unit 70 is configured to receive network requests from client devices, such as client device 40, for data on storage media 62. For example, request processing unit 70 can implement Hypertext Transfer Protocol (HTTP) version 1.1, as described in RFC 2616, “Hypertext Transfer protocol - HTTP/1.1,” by R. Fielding et al., Network Working Group, IETF, June 1999. That is, the unit request processing 70 can be configured to receive partial GET or HTTP GET requests and provide multimedia content data 64 in responses to the requests. Requests can specify a segment from one of the 68 representations, for example using a segment URL. In some examples, requests may also specify one or more byte ranges of the segment, thus comprising partial GET requests. The request processing unit 70 can be further configured to listen for HEAD HTTP requests to provide header data for a segment of one of the representations 68. In any case, the request processing unit 70 can be configured to process the requests to provide requested data to a requesting device such as client device 40.

[0104] Additionally or alternatively, the request processing unit 70 can be configured to distribute media data via a broadcast or multicast protocol, such as eMBMS. Content preparation device 20 may create DASH segments and/or subsegments in substantially the same manner as described, however server device 60 may distribute these segments or subsegments using eMBMS or another broadcast or multicast network transport protocol. For example, request processing unit 70 may be configured to receive a multicast group join request from client device 40. That is, server device 60 may advertise an internet protocol (IP) address. associated with a multicast group for client devices, including client device 40, associated with specific media content (eg, a broadcast of a live event). Client device 40 in turn may submit a request to join the multicast group. This request may be propagated throughout network 74, for example, routers comprising network 74, such that the routers are induced to direct traffic destined for the IP address associated with the multicast group to subscribing client devices, such as the customer 40.

[0105] As illustrated in the example of figure 1, multimedia content 64 includes manifest file 66, which may correspond to a media presentation description (MPD). The manifest file 66 may contain descriptions of different alternative representations 68 (e.g. video services with different qualities) and the description may include, for example, codec information, a profile value, a level value, a bits, and other descriptive characteristics of representations 68. Client device 40 may retrieve the MPD of a media presentation to determine how to access segments of representations 68.

[0106] In particular, retrieval unit 52 (which may implement the techniques of this disclosure) may retrieve configuration data (not shown) from client device 40 to determine video decoder 48 decoding capabilities and stream delivery capabilities video 44. The configuration data may also include any or all of a language preference selected by a user of client device 40, one or more camera perspectives corresponding to depth preferences defined by the user of client device 40, and /or a user-selected rating preference of the client device 40. The retrieval unit 52 may comprise, for example, a web browser or media client configured to submit partial GET and HTTP GET requests. The retrieval unit 52 may correspond to software instructions executed by one or more processors or processing units (not shown) of the client device 40. In some examples, all or portions of the functionality described in connection with the retrieval unit 52 may be implemented in hardware, or a combination of hardware, software and/or firmware, where necessary hardware may be provided to execute instructions for software or firmware.

[0107] The retrieval unit 52 can compare the decoding and provisioning capabilities of client device 40 with the characteristics of representations 68 indicated by manifest file information 66. The retrieval unit 52 can initially retrieve at least a portion of the file of manifest file 66 to determine characteristics of representations 68. For example, the retrieval unit 52 may request a portion of the manifest file 66 that describes characteristics of one or more adaptation assemblies. Retrieval unit 52 can select a subset of representations 68 (e.g., an adaptation set) having characteristics that can be met by the encoding and provisioning capabilities of client device 40. Retrieval unit 52 can determine bit rates for representations in the adaptation set, determine a currently available amount of network bandwidth, and retrieve segments from one of the representations having a bitrate that can be serviced by the network bandwidth.

[0108] In general, higher bitrate renderings can provide higher quality video playback, while lower bitrate renderings can provide sufficient quality video playback when available network bandwidth decreases. Therefore, when available network bandwidth is relatively high, the recovery unit 52 can recover data from relatively high bit rate representations, whereas when available network bandwidth is low, the recovery unit 52 can recover data from relatively low bit rate representations. In this way, client device 40 can stream multimedia data over network 74 while also adapting to changing network bandwidth availability on network 74.

[0109] Additionally or alternatively, the recovery unit 52 can be configured to receive data according to a broadcast or multicast network protocol, such as eMBMS or IP multicast. In such examples, retrieval unit 52 may submit a request to join a multicast network group associated with specific media content. After joining the multicast group, the retrieval unit 52 can receive data from the multicast group without further requests issued to a server device 60 or content preparation device 20. The retrieval unit 52 can submit a request to leave the multicast group. multicast group when multicast group data is no longer needed, for example, stopping playback or changing channels to a different multicast group.

[0110] Furthermore, in accordance with the techniques of this disclosure, the retrieval unit 52 can be configured to determine whether the manifest file 66 indicates that two or more periods of multimedia content 64 are continuous. For example, the unit of recovery 52 may determine that two adaptation sets of two periods are continuous periods when the adaptation sets are joined, the manifest file 66 includes an element of @presentationTimeOffset, or it may be inferred as 0, for all the representations in the adaptation sets, in an adaptation set the value of @presentationTimeOffset is identical for all representations, the sum of the value of @presentationTimeOffset, and the presentation duration of all representations in an adaptation set is identical to the value @presentationTimeOffset from the other adaptation set.

[0111] Furthermore, the recovery unit 52 may use the initialization segment of a representation in an adaptation set of one period as an initialization segment for a representation of another adaptation set of another period, where the adaptation sets are continuous periods, if the representations have the same value for @id. Similarly, where two adaptation sets are continuous periods and the later adaptation set has a supplemental descriptor associated with @schemeIDURI=”urn.mpeg:dash:period-switchable,” the retrieval unit 52 may determine which representations in a from the adaptation sets can be concatenated with any representation from the other adaptation set without the initialization segment of the other adaptation set. Thus, the retrieval unit 52 can select a second period adaptation set based on a selection of a first period adaptation set (e.g., without further analyzing characteristics of the second period adaptation set), assuming that the first and second periods are continuous.

[0112] Thus, the unit of recovery 52 can be configured to determine that a manifest file for media content indicates that the media content includes a first period and a second period, that the manifest file indicates that the first and second periods are continuous, and what ad media data is available for insertion between the first and second periods. The retrieval unit 52 may also be reconfigured to select a first adaptation set in the first period based at least in part on signaled characteristics for the first adaptation set. Such characteristics may include, for example, encoding and delivery characteristics such as codec, profile, level, image dimensions, frame rate or the like. To select the adaptation set, the retrieval unit 52 can compare coding and provisioning capabilities of the client device 40 with the characteristics of the various available adaptation sets, and select a adaptation set that can be encoded and provided by the client device. 40.

[0113] The recovery unit 52 can then recover media data from the first adaptation set based on the selection of the first adaptation set. More particularly, the retrieval unit 52 can select an adaptation set representation (if more than one representation is available), for example, based on available network bandwidth and bit rates for the adaptation set representations, so that the bit rate for the representation does not exceed the available network bandwidth. Retrieval unit 52 can also retrieve advertisement media data. Furthermore, the recovery unit 52 can recover media data from a second adaptation set in the second period that is associated with the first adaptation set based on the selection of the first adaptation set. In this way, the retrieval unit 52 can simply determine that the second adaptation set is period continuous with the first adaptation set, and simply select the second adaptation set because it is period continuous with the first adaptation set that has already been selected, instead of analyzing features of adaptation sets from the second period as was done for the first adaptation set.

[0114] The network interface 54 can receive and provide data from segments of a selected representation to the recovery unit 52, which can, in turn, provide the segments to the decapsulation unit 50. The decapsulation unit 50 can decapsulate elements of a video file into constituent PES streams, unpacking the PES streams to retrieve encoded data, and sending the encoded data to audio decoder 46 or video decoder 40, depending on whether the encoded data is part of an audio stream or video, for example, as indicated by the stream's PES packet headers. Audio decoder 46 decodes audio data and outputs the decoded audio data to audio output 42, while video decoder 48 decodes encoded video data and outputs the decoded video data, which may include a plurality of video views. a stream, to video output 44.

[0115] The video encoder 28, video decoder 48, audio encoder 26, audio decoder 46, encapsulation unit 30, recovery unit 52, and decapsulation unit 50 each can be implemented as any of a variety of sets of suitable processing circuitry, as applicable, such as one or more microprocessors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), discrete logic circuitry, software , hardware, firmware or any combination thereof. Each of the video encoder 28 and video decoder 48 may be included in one or more encoders or decoders, any of which may be integrated as part of a combined video encoder/decoder (CODEC). Similarly, each of the audio encoder 26 and audio decoder 46 may be included in one or more encoders or decoders, any of which may be integrated as part of a combined CODEC. An apparatus including video encoder 28, video decoder 48, audio encoder 26, audio decoder 46, encapsulation unit 30, recovery unit 52, and/or decapsulation unit 50 may comprise an integrated circuit, a microprocessor, and /or a wireless communication device such as a cell phone.

[0116] Client device 40, server device 60, and/or content preparation device 20 can be configured to operate in accordance with the techniques of this disclosure. For purposes of example, this disclosure describes these techniques with respect to client device 40 and server device 60. However, it can be understood that content preparation device 20 may be configured to perform these techniques, rather than (or in addition to) de) server device 60.

[0117] The encapsulation unit 30 can form NAL units comprising a header identifying a program to which the NAL unit belongs, as well as a payload, audio data, video data, or data describing the program stream or transport to which the NAL unit corresponds. For example, in H.264/AVC, a NAL unit includes a 1-byte header and a variable-length payload. A NAL unit including video data in its payload can comprise several levels of video data granularity. For example, a NAL unit may comprise a block of video data, a plurality of blocks, a slice of video data, or an entire frame of video data. The encapsulation unit 30 can receive encoded video data from the video encoder 28 in the form of elementary stream PES packets. The encapsulation unit 30 can associate each elementary stream with a corresponding program.

[0118] The encapsulation unit 30 can also assemble access units from a plurality of NAL units. In general, an access unit may comprise one or more NAL units for representing a frame of video data, as well as audio data corresponding to the frame when such audio data is available. An access unit generally includes all NAL units for an output time instance, for example all video and audio data for a time instance. For example, if each video has a frame rate of 20 frames per second (fps), each time instance might correspond to a time interval of 0.05 seconds. During that time interval, specific frames for all views of the same access unit (the same time instance) can be provided simultaneously. In one example, an access unit may comprise an encoded image at a time instance, which may be presented as a primary encoded image.

[0119] Therefore, an access unit can comprise all video and audio frames of a common temporal instance, for example, all views corresponding to time X. This revelation also refers to an encoded image of a specific view as a “view component.” That is, a view component may comprise an encoded image (or frame) for a specific view at a specific time. Therefore, an access unit can be defined as comprising all view components of a common temporal instance. The decoding order of access units need not necessarily be the same as the display or output order.

[0120] A media presentation may include a media presentation description (MPD), which may contain descriptions of different alternative representations (for example, video services with different qualities), and the description may include, for example, codec information , a profile value, and a level value. An MPD is an example of a manifest file, such as manifest file 66. Client device 40 may retrieve the MPD from a media presentation to determine how to access movie fragments from various presentations. Movie snippets can be located in movie snippet boxes (moof boxes) of video files.

[0121] The manifest file 66 (which may comprise, for example, an MPD) may announce availability of segments of representations 68. That is, the MPD may include information indicating the wall clock time at which a first segment of a of the representations 68 becomes available, as well as information indicating the durations of segments in the representations 68. In this way, the retrieval unit 52 of the client device 40 can determine when each segment is available, based on the start time as well as the durations. of segments preceding a specific segment.

[0122] After the encapsulation unit 30 has mounted NAL units and/or access units on a video file based on received data, the encapsulation unit 30 passes the video file to the transmission interface 32 for transmission. in some examples, encapsulation unit 30 may store the video file locally or send the video file to a remote server via output interface 32, rather than sending the video file directly to client device 40. output interface 32 may comprise, for example, a transmitter, a transceiver, a device for recording data to computer readable media such as, for example, an optical drive, a magnetic media drive (e.g., floppy drive), a universal serial bus (USB) port, a network interface, or other output interface. Output interface 32 transmits the video file to computer readable media 34, such as a broadcast signal, magnetic media, optical media, memory, flash drive, or other computer readable media.

[0123] The network interface 54 may comprise a NAL unit or network access unit 74 and provide the NAL unit or access unit to the encapsulation unit 50 via the recovery unit 52. The decapsulation unit 50 can decapsulate an element of a video file into constituent PES streams, unpacking the PES streams to retrieve encoded data, and sending the encoded data to audio decoder 46 or video decoder 48, depending on whether the encoded data is part of a video stream. audio or video, for example, as indicated by the stream's PES packet headers. Audio decoder 46 decodes encoded audio data and outputs the decoded audio data to audio output 42, while video decoder 48 decodes encoded video data and outputs the decoded video data, which may include a plurality of views. of a stream, to video output 44.

[0124] In an example, a method of retrieving media data is described, the method comprising dividing, by a media server, main content of media data into a plurality of periods, inserting, by the media server, media content secondary between a first period and a second period, wherein the first period and the second period are temporally sequential, signaling, by the media server, a time pointer for each of the plurality of periods, wherein the time pointer defines one or more time characteristics for each of the plurality of periods, and receiving, by the media server, a request to retrieve, from a dynamic adaptive streaming over HTTP (DASH) client, a media stream comprising the plurality of periods, the secondary media content, and time indicators.

[0125] In another example, a method of retrieving media data is described, the method comprising determining that a manifest file for media content indicates that the media content includes a first sentence and a second sentence, that the manifest file indicates that the first and second periods are continuous, and that ad media data is available for insertion between the first and second periods, select a first fitting set in the first period based at least in part on features flagged for the first set of adaptation, retrieve media data from the first adaptation set based on the selection of the first adaptation set, retrieve the announcement media data, and retrieve media data from a second adaptation set in the second period that the manifest file indicates be associated with the first adaptation set in the selection of the first adaptation set.

[0126] In another example, a method of retrieving media data is described, the method comprising determining whether media content includes a first period and a second period, determining whether the first period and the second period are continuous, determining whether data from advertisement media are available for insertion between the first and second periods, and form a manifest file, where the manifest file includes indications of whether the media content includes the first period and the second period, whether the first and second periods period are continuous, and whether ad media data is available for insertion between the first and second periods.

[0127] Figure 2 is a conceptual diagram illustrating sample multimedia content elements 102. Multimedia content 102 may correspond to multimedia content 64 (Figure 1), or other multimedia content stored in memory 62. In the example of Figure 2, multimedia content 102 includes Media Presentation Description (MPD) 104 and a plurality of representations 110A-110N. Representation 110A includes optional header data 112 and segments 114A-114N (segments 114), while representation 110N includes optional header data 122 and segments 124A-124N (segments 124). The letter N is used to designate the last film fragment in each of representations 110A, 110N as a matter of convenience. In some examples, there may be different numbers of film fragments between representations 110A, 110N.

[0128] MPD 104 may comprise a separate data structure of representations 110A-110N. MPD 104 may correspond to manifest file 66 of Figure 1. Similarly, representations 110A-110N may correspond to representations 68 of Figure 1. In general, MPD 104 may include data that generically describes features of representations 110A-110N, such as encoding and supply characteristics, adaptation sets, a profile to which MPD 104 corresponds, text type information, camera angle information, classification information, device mode information (e.g., information indicative of representations that include substrings temporal), and/or information to retrieve remote periods (e.g., for targeted ad insertion into media content during playback).

[0129] Header data 112, when present, can describe characteristics of segments 114, for example, temporal locations of random access points (RAPs, also referred to as flow access points (SAPs)), which of the segments 114 includes points access points, byte offsets to random access points in segments 114, uniform resource locators (URLs) of segments 114, or other aspects of segments 114. Header data 122, when present, may describe similar characteristics for segments 124. Additionally or alternatively, such features can be fully included in MPD 104.

[0130] Segments 114, 124 include one or more encoded video samples, each of which may include frames or slices of video data. Each of the segments encoded video samples 114 may have similar characteristics, for example, height, width and bandwidth requirements. Such features may be described by MPD data 104, although such data is not illustrated in the example of Figure 2. MPD 104 may include features as described by the 3GPP Specification, with the addition of any or all of the flagged information described in that disclosure.

[0131] Each of the segments 114, 124 can be associated with a unique uniform resource locator (URL). In this way, each of the segments 114, 124 may be independently retrievable using a streaming network protocol such as DASH. Thus, a target device such as client device 40 can use an HTTP GET request to retrieve segments 114 or 124. In some examples, client device 40 can use HTTP partial GET requests to retrieve specific byte ranges from segments 114 or 124.

[0132] Media presentation description 104 may, in accordance with the techniques of this disclosure, indicate that a period to which representations 110A-110N correspond is continuous with another period two subsequent representations (not shown) may correspond. Therefore, an adaptation set including representations 110A-110N may be the same as another adaptation set, where such features may include all or any of the language as described by a media presentation description @lang attribute 104, component type of media described by a media presentation description @contentType attribute 104, image aspect ratio as described by a media presentation description @pair attribute 104, any role property as described by a media presentation description Role Elements media 104, any accessibility property as described by Media Presentation Description Accessibility elements 104, and/or any viewpoint property as described by Media Presentation Description Viewpoint elements 104.

[0133] In this way, the client device 40 can select the adaptation set including representations 110A-110N based on characteristics signaled in media presentation description 104, and then retrieve media data from the other adaptation set (from the continuous period , subsequent) based on the selection of the adaptation set including representations 110A-110N. That is, the client device 40 need not evaluate features of the associated fitting set, because such features are identical (based on the indication in media presentation description 104 that the fitting set of the subsequent period is associated with the fitting set including representations 110A-110N).

[0134] Figure 3 is a block diagram illustrating another example system 200 that can implement the techniques of this disclosure. Elements of system 200 in Figure 4 may generally correspond to elements of Figure 1. For example, system 200 includes advertisement (advertisement) decision server 208, content delivery system 212, and client device 206. elements of the content delivery system 212 may generally correspond to the content preparation device 20 and/or server device 60 of Figure 1, while elements of the client device 206 may correspond to the client device 40 of Figure 1. For example, elements of client device 206 may correspond to recovery unit 52 of Figure 1.

[0135] In this example, the client device 206 includes media engine 202 and DASH access client 204. The content delivery system 212 includes MPD generator 214, packer 216, and content delivery network (CDN)/server Origin 218. Origin server 218 stores MPD 220, main content 222A-222C, and advertisement data 224A-224C.

[0136] The media engine 202, DASH access client 204, MPD generator 214, and packer 216 can be implemented in hardware or software. When implemented in software, it is assumed that necessary hardware, such as one or more processing units and one or more computer-readable storage media, are also provided. Computer-readable storage media can store instructions for the software, and processing units can execute the instructions to perform the functionality described above.

[0137] An MPD is available that points to On Demand content on the CDN containing a single period presentation. The MPD, based on suggestions (ad insertion opportunities), is modified to add multiple periods without changing the content on the server. For each lead, an xlink to the Ad Decision server is provided. The MPD is provided for the DASH client. For each xlink in the MPD, it is checked whether advertisements are added, possibly targeting the user. If not, the period is resolved to 0. If so, another content is added. The DASH client plays content continuously, and if set to zero, the media engine is not freshly started.

[0138] The MPD generator 214 of figure 3 can be configured to indicate that two or more Periods are continuous. Accordingly, the MPD generator 214 may indicate adaptation sets of periods that are associated, as discussed above, in an MPD (or other manifest file), in accordance with the techniques of such disclosure. Thus, client device 206 can select a one period adaptation set and an associated other continuous period adaptation set, based on characteristics of the first period adaptation set signaled in the MPD generated by the MPD generator 214.

[0139] Thus, the content distribution system 212 and Origin/CND server 218 represent examples of a device for sending media data, the device including a memory configured to store media data, and one or more processors based on devices configured to divide the main content of the media data into a plurality of periods including a first period and a second period that are temporally sequential, inserting secondary media content between the first period and the second period, signaling a time indicator for each of the plurality of periods, wherein the time indicator defines one or more time characteristics for each of the plurality of periods, and receiving a request from a dynamic adaptive streaming client over HTTP (DASH) to retrieve a stream of media comprising the plurality of periods, secondary media content and time indicators.

[0140] Similarly, client device 206 represents an example of a device for retrieving media data, the device including a memory configured to store media data; and one or more hardware-based processors configured to determine that a manifest file for media content indicates that the media content includes a first period and a second period, that the manifest file indicates that the first and second periods are continuous, and what ad media data is available for insertion between the first and second periods, selecting a first adaptation set in the first period based at least in part on characteristics flagged for the first adaptation set, retrieving media data from the first adaptation set adaptation based on the selection of the first adaptation set, retrieve media data from the advertisement, and retrieve media data from a second adaptation set in the second period that the manifest file indicates is associated with the first adaptation set based on the selection of the first adaptation set and store the retrieved media data to memory.

[0141] Figure 4 is a flowchart illustrating a method of sending media data in accordance with one or more techniques of the current disclosure. In this example, a media server may divide the main content of media data into a plurality of periods (300). The media server may insert secondary media content between a first period and a second period (302), wherein the first period and second period are temporally sequential. Secondary media content can be, for example, advertising media content, which must be presented in substantially the same way as primary media content. The media server may signal a time pointer for each of the plurality of periods (304), wherein the time pointer defines one or more time characteristics for each of the plurality of periods. The media server may receive a request to retrieve a media stream (306), for example from a dynamic adaptive streaming client over HTTP (DASH). The request for the media stream may correspond to a request to retrieve a media stream comprising the plurality of periods, secondary media content, and time indicators.

[0142] Fig. 5 is a flowchart illustrating a method of recovering media data according to one or more techniques of the present disclosure. In this example, a device determines characteristics of a manifest file (310). For example, the device may determine that the manifest file for media content states that the media content includes a first period and a second period, that the manifest file indicates that the first and second periods are continuous, and that data of ad media are available for insertion between the first and second periods. The device may select a first adaptation set (312). In one example, the first adaptation set may be in the first period, and the selection may be based at least in part on the traits flagged for the first adaptation set. The device may then retrieve media data from the first adaptation set (314) based on the selection of the first adaptation set. The device can then retrieve the ad media data (316). Furthermore, the device may retrieve media data from a second adaptation set based on the selection of the first adaptation set (318). The second adaptation set can be in the second period, and the manifest file can indicate that the second adaptation set is associated with the first adaptation set.

[0143] Fig. 6 is a flowchart illustrating a method of sending media data according to one or more techniques of the present disclosure. In this example, a device can determine whether media content includes a first period and a second period (320). The device can determine whether the first period and the second period are continuous (322). The device can determine if ad media data is available for insertion (324), for example, between the first and second periods. The device may form a manifest file (326), wherein the manifest file includes indications of whether the media content includes the first period and second period, whether the first period and second period are continuous, and whether the data of ad media are available for insertion between the first and second periods.

[0144] Figure 7 is a flowchart illustrating an example method of performing certain techniques of this disclosure by a media server. This exemplary method includes dividing, by a media server, the main content of media data into a plurality of periods including a first period and a second period, wherein the first period and second period are temporally sequential (350). This example method also includes signaling, by the media server, information indicating that secondary media content is available for insertion between the first period and the second period (352). This exemplary method further includes signaling, by the media server, a time pointer for each of the plurality of periods, wherein the time pointer defines one or more characteristics for each of the plurality of periods (354).

[0145] Figure 8 is a flowchart illustrating an example method of performing certain techniques of this disclosure by a client device. This example method includes determining that a manifest file for media content indicates that the media content includes a first period and a second period, that the manifest file indicates that the first and second periods are continuous, and that ad media are available for insertion between the first and second periods (370). This example method also includes selecting a first adaptation set in the first period based at least in part on characteristics flagged for the first adaptation set (372). This example method further includes retrieving media data from the first adaptation set based on the selection of the first adaptation set (374). Finally, this example method includes retrieving media data from a second adaptation set in the second period that is associated with the first adaptation set based on the selection of the first adaptation set (376).

[0146] It should be understood that in some examples, a client device may be configured to perform all or any of the techniques of the first example, the second example, and the third example described above. For example, different content delivery networks may support different mechanisms for targeted advertisement insertion, and a client device may implement the techniques of all or any of the first example, second example, and/or third example. As another example, a content delivery network may support all or any of the techniques of the first example, second example and/or third example described above. Furthermore, the techniques of the first example, second example and/or third example described above can be performed together in any combination.

[0147] In one or more examples, the described functions can be implemented in hardware, software, firmware or any combination thereof. If implemented in software, functions may be stored in or transmitted through as one or more instructions or code on computer-readable media and executed by a hardware-based processing unit. Computer-readable media may include computer-readable storage media, which corresponds to tangible media such as data storage media, or communication media including any media that facilitates the transfer of a computer program from one place to another, for example , according to a communication protocol. Thus, computer-readable media can generally correspond to (1) computer-readable storage media that is non-transient or (2) a communication medium such as a signal or carrier wave. Data storage media can be any available media that can be accessed by one or more computers or one or more processors to retrieve instructions, code and/or data structures for implementing the techniques described in this disclosure. A computer program product may include computer readable media.

[0148] By way of example, and not limitation, such computer-readable storage media may comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage, or other magnetic storage devices, flash memory, or any other media 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. Also, any connection is properly termed a computer-readable medium. For example, if instructions are transmitted from a website, server, or other remote source using coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and micro- waves, so coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of media. It should be understood, however, that computer readable storage media and data storage media do not include connections, carrier waves, signals or other transient media, but are instead intended for tangible, non-transient storage media. Disk and disc, as used here, include compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk, and Blu-ray disc, where disks typically play data magnetically, while discs play data optically with lasers. Combinations of the above shall also be included within the scope of computer readable media.

[0149] Instructions can be executed by one or more processors, such as one or more digital signal processors (DSPs), general purpose microprocessors, application specific integrated circuits (ASICs), field programmable logic arrangements (FPGAs), or another set of equivalent discrete or integrated logic circuits. Accordingly, the term "processor" as used herein may refer to any of the above frameworks or any other framework suitable for implementing the techniques described herein. Furthermore, in some respects, the functionality described here may be provided in dedicated hardware and/or software modules configured to encode and decode, or incorporated into a combined codec. Also, the techniques can be fully implemented in one or more circuits or logic elements.

[0150] The techniques of this disclosure can be implemented in a wide variety of devices or apparatus, including a cordless telephone handset, an integrated circuit (IC) or a set of ICs (eg, a chip set). Various components, modules, or units are described in this disclosure to emphasize functional aspects of devices configured to perform the disclosed techniques, but do not necessarily require performance by different hardware units. Rather, as described above, multiple units can be combined into a codec hardware unit or provided by a collection of interoperable hardware units, including one or more processors as described above, in combination with suitable software and/or firmware. .

[0151] Several examples have been described. These and other examples are within the scope of the following claims.

Claims (10)

1. Method of retrieving media data, the method being characterized in that it comprises: determining (370) from a manifest file for media content that the media content includes a first sentence and a second sentence, that the first and second periods are continuous, and what ad media data is available for insertion between the first and second periods; selecting (372) a first period fitting set from a plurality of first period fitting sets based, at least in part, on flagged supply characteristics in the manifest file for the first fitting set, each fitting set comprising a respective plurality of representations of the first period of media content, each of the plurality of representations sharing the same delivery characteristics but having a different bit rate; retrieving (374) media data from the first adaptation set based on the selection of the first adaptation set; based on determining that ad media data is available for insertion between the first and second periods and selecting the first adaptation set, determining that a second adaptation set in the second period is associated with the first adaptation set, where each second adaptation set is one of a plurality of adaptation sets in the second period, each adaptation set comprising a respective plurality of representations of the second period of media content, each of the respective plurality of representations sharing the same delivery characteristics but having a different bitrate, wherein determining that the second adaptation set is associated with the first adaptation set comprises determining that the manifest file flags the same value for asset identifiers of the first adaptation set and the second adaptation set, and the manifest file indicates that the first adaptation set and the second adaptation set have the same value for the respective “@id” attributes; and retrieving (376) media data from the second adaptation set; and based on the attribute of "@id" of representations in the first adaptation set being the same as "@id" of representations in a second adaptation set, using an initialization segment of a representation of the first adaptation set as a segment initialization of a corresponding representation in the second adaptation set. 2. Method according to claim 1, characterized in that the manifest file comprises a media presentation description (MPD). 3. Method, according to claim 1, characterized in that it further comprises determining, from the manifest file, a representation duration for a representation of the first adaptation set using at least one of the data that signal a value for a @presentationTimeDuration syntax element that specifies the presentation duration, or data signaling a complementary descriptor with a @scheme_id_URI element set to “urn:mpeg:dash:period_continuity:2014” for the first adaptation set. 4. Method, according to claim 3, characterized in that the first adaptation set additionally includes an element "@value" of a packet identifier (PID) that corresponds to a value of an element "@id" of a period that is described in the manifest file, a value for an “AdaptationSet@id” element that represents an adaptation set identifier, and a value of an “@presentationTimeOffset” for the first adaptation set. 5. Method according to claim 1, characterized in that it further comprises determining that the second adaptation set has one or more characteristics in common with the first adaptation set, where the characteristics in common include one or more of a language, a media component type, a figuration aspect ratio, a role property, an accessibility property, or a point of view property. 6. Method according to claim 1, characterized in that it further comprises determining that the second adaptation set is continuous with the first adaptation set when: the first and second adaptation sets are associated; an “@presentationTimeOffset” is present in the manifest file or can be inferred as 0 for all representations in both adaptation sets; the manifest file indicates, for at least one of the first adaptation set and the second adaptation set, that the value of “@presentationTimeOffset” is identical for all representations; and a sum of the “@presentationTimeOffset” value and a presentation duration of all representations in the first adaptation set is identical to the “@presentationTimeOffset” value of the second adaptation set. 7. Device for retrieving media data, the device being characterized in that it comprises: a memory configured to store media data; and one or more hardware-based processors configured to: determine (370) from a manifest file for media content that the media content includes a first period and a second period, that the first period and second period are continuous, and what ad media data is available for insertion between the first and second periods; select (372) a first period adaptation set, from a plurality of first period adaptation sets, based, at least in part, on flagged supply characteristics in the manifest file for the first period adaptation, each set adaptation comprising a respective plurality of representations of the first period of media content, each of a plurality of representations sharing the same delivery characteristics but having a different bitrate; retrieving (374) media data from the first adaptation set based on the selection of the first adaptation set; based on determining that ad media data is available for insertion between the first and second periods and selecting the first adaptation set, determining that a second adaptation set in the second period is associated with the first adaptation set, where each second adaptation set is one of a plurality of adaptation sets in the second period, each adaptation set comprising a respective plurality of representations of the second period of media content, each of the respective plurality of representations sharing the same delivery characteristics but having a different bitrate, wherein determining that the second adaptation set is associated with the first adaptation set comprises determining that the manifest file flags the same value for asset identifiers of the first adaptation set and the second adaptation set, and the manifest file indicates that the first adaptation set and the second adaptation set have the same value for the respective “@id” attributes; retrieving (376) media data from the second adaptation set and storing the retrieved media data into memory; and based on the attribute of "@id" of representations in the first adaptation set being the same as "@id" of representations in a second adaptation set, using an initialization segment of a representation of the first adaptation set as a segment initialization of a corresponding representation in the second adaptation set. 8. Device according to claim 7, characterized in that the manifest file comprises a media presentation description (MPD). 9. Device according to claim 7, characterized in that the one or more hardware-based processors are configured to determine, from the manifest file, that the second adaptation set has one or more characteristics in common with the first adaptation set, where the common features include one or more of a language, a type of media component, a figuration aspect ratio, a role property, an accessibility property, or a point of view property View. 10. Device according to claim 7, characterized in that the one or more hardware-based processors are configured to determine that the second adaptation set is continuous period with the first adaptation set when: the first and the second adaptation sets are associated; an “@presentationTimeOffset” is present in the manifest file or can be inferred as 0 for all representations and both adaptation sets; the manifest file indicates, for at least one of the first adaptation set and the second adaptation set, that the value of “@presentationTimeOffset” is identical for all representations; and a sum of the “@presentationTimeOffset” value and a presentation duration of all representations in the first adaptation set is identical to the “@presentationTimeOffset” value of the second adaptation set.