2.2.1 Definitions

In addition to the definitions provided in Volume 1, the following definitions are used in this Volume. These terms apply to the OIPF HAS format specified in section 5. Where MPEG DASH defines the same terms in its specification, the DASH definitions apply to the specification of DASH usage in section 4.

2.2.2 Abbreviations

In addition to the Abbreviations provided in Volume 1, the following abbreviations are used in this Volume.

4.2.1 General

For MPEG-2 TS based content (system format TS, as specified in [OIPF_MEDIA2]) the MPEG-2 TS simple profile, as defined in section 8.7 of [DASH], is adopted, with the additional restrictions and constraints as specified in the present section. This constitutes the definition of an interoperability point of the MPEG DASH MPEG-2 TS simple profile. This interoperability point is identified with the URI "urn:oipf:dash:profile:ts:2012" and is called the "OIPF MPEG-2 TS simple" interoperability point.

Additional constraints are placed on the use of the MPEG-2 TS simple profile regarding PID value allocations to the component streams contained in the DASH Segments. These are specified in section 4.2.1.1.

The present document does not provide any adaptive bit-rate streaming method for use with the TTS format.

4.2.2 Protected TS Content

The BBTS and PF protected formats are compatible with provision by adaptive bit-rate streaming as specified in this section.

The following general requirements apply if Segments are protected:

• The DRM related metadata (i.e. PMT containing CA descriptors, CAT, EMM streams or ECM streams) in relation to a certain elementary stream shall be delivered as part of the Media Segments that carry the samples of the elementary stream or the Initialisation Segment.
• The DRM related metadata (i.e. ECM stream) of the CA system that applies to a certain elementary stream shall have the same PID in all Segments, in all Representations, in which it is included.

The following sub-sections specify further specific details of DASH usage that apply to the BBTS and PF formats.

The MPEG2-TS Simple profile defined in DASH guarantees that the OITF can play any bitstream generated by the concatenation of consecutive segments from any Representation within the same Adaptation Set. The same guarantee shall apply to protected MPEG2-TS segments. Note that BBTS and PF formats are conformant with ISO/IEC 13818-1 [MPEG2TS]. This guarantee may be achieved by using the same Crypto-period boundaries and Control Words across different Representations, in which case there is no further impact from adaptive streaming on the CSP solutions specified in volume 7 [OIPF_CSP2].

4.3.1 General

For MP4 file format based content (system format MP4, as specified in [OIPF_MEDIA2]) the ISO base media file format live profile, as defined in section 8.4 of [DASH], is adopted, with the additional restrictions and constraints as specified in the present section. This constitutes the definition of an interoperability point of the MPEG DASH ISOBMFF live profile. This interoperability point is identified with the URI "urn:oipf:dash:profile:isoff-live:2012" and is called the "OIPF ISOBMFF live" interoperability point.

4.3.2 Protected Content

The present document does not provide any adaptive bit-rate streaming method for use with the DCF or PDCF protected format.

The MP4 common encryption format specified in [CENC] and the MIPMP protected format are compatible with provision by adaptive bit-rate streaming as specified in this section.

4.6.1 Audio Description and Clean Audio

If the content item includes Clean Audio or Audio Description (AD) components then the MPD shall identify these using the Role and Accessibility descriptors as defined in Table 1. Furthermore for receiver mix AD, the associated audio stream shall use depdendencyId to indicate the dependency to the main Representation, and imply that the associated audio stream shall not be provided as a Representation on its own.

5.2.1 Media Presentation Description

The OIPF HAS Media Presentation Description (MPD) shall be as specified in [TS26234] section 12.2, with the following extensions and additional requirements:

• The MPD shall be an XML file that shall validate against the schema in Appendix A. Note that the XML schema in Appendix A imports the schema specified in [TS26234]. This means that an MPD that does not use any of the OIPF specific extensions will validate against both the schema defined in [TS26234] as well as Appendix A.
• A <Representation> element may carry the @group-attribute set to a non-zero value. In this case the attribute indicates that the <Representation> element is not necessarily a complete Representation, but consists of one or more individual Components (video, audio, subtitle, etc.) which may be downloaded and provided to the terminal in addition to content being downloaded from other <Representation> elements. In this case the <Representation> element shall contain one or more <Component> elements, as specified in section 5.2.2, one for each Component contained in the <Representation>. Note that it is the responsibility of the application on the terminal to select the desired Components and to initialize the terminal accordingly. Appendix C contains an informative description of how this can be done. The value of the @group-attribute shall be the same for Representations that contain at least one same Component. Two Representations with completely different Components (e.g. audio at two different languages) shall have different values for the @group attribute.

An example instance of the OIPF compliant MPD with the constraints from section 5.3 is depicted in Figure 2.

5.2.2 Component Element

<?xml version="1.0" encoding="UTF-8"?>
<MPD
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns="urn:3GPP:ns:PSS:AdaptiveHTTPStreamingMPD:2009"
  xmlns:oipf="urn:oipf:iptv:has:2010"
  minBufferTime="PT10S"
  xsi:schemaLocation="urn:3GPP:ns:PSS:AdaptiveHTTPStreamingMPD:2009 3GPP-MPD-009.xsd
    urn:oipf:iptv:has:2010 OIPF-MPD-009.xsd"
  >
  <Period start="PT0S" segmentAlignmentFlag="true" bitStreamSwitchingFlag="true">
  <SegmentInfoDefault
    sourceUrlTemplatePeriod="http://www.aService.com/aMovie/$RepresentationID$/Seg$Index$.3gs"
    duration="PT2S">
  </SegmentInfoDefault>
  <Representation bandwidth="5000000" mimeType="video/mp4" startWithRAP="true" group="1">
    <SegmentInfo baseURL="http://www.aService.com/aMovie/HQ/" >
      <InitialisationSegmentURL sourceURL="http://www.aService.com/aMovie/Init.mp4"/>
      <Url sourceURL="Seg10.3gs"/>
      <Url sourceURL="Seg11.3gs"/>
      <Url sourceURL="Seg12.3gs"/>
      <!-- Media Segments in high quality available from 
        http://www.aService.com/aMovie/HQ/SegXX.3gs -->
    </SegmentInfo>
    <oipf:Components>
      <oipf:Component type="video" id="1" description="Video"/>
      <oipf:Component type="audio" id="2" lang="en" description="Audio-En"/>
    </oipf:Components>
  </Representation>
  <Representation bandwidth="2500000" mimeType="video/mp4" startWithRAP="true" group="1">
    <SegmentInfo>
      <InitialisationSegmentURL sourceURL="http://www.aService.com/aMovie/Init.mp4"/>
      <Url sourceURL="http://www.aService.com/aMovie/LQ/Seg10.3gs"/>
      <Url sourceURL="http://www.aService.com/aMovie/LQ/Seg11.3gs"/>
      <Url sourceURL="http://www.aService.com/aMovie/LQ/Seg12.3gs"/>
      <!-- Media Segments in low quality available from 
        http://www.aService.com/aMovie/LQ/SegXX.3gs -->
    </SegmentInfo>
    <oipf:Components>
      <oipf:Component type="video" id="1" description="Video"/>
      <oipf:Component type="audio" id="2" lang="en" description="Audio-En"/>
    </oipf:Components>
  </Representation>
  <Representation bandwidth="125000" mimeType="video/mp4" startWithRAP="true" group="2">
    <SegmentInfo>
      <InitialisationSegmentURL sourceURL="http://www.aService.com/aMovie/Init.mp4"/>
      <UrlTemplate startIndex="10" endIndex="12" id="FR"/>
      <!-- Media Segments with French audio available from 
        http://www.aService.com/aMovie/FR/SegXX.3gs -->
    </SegmentInfo>
    <oipf:Components>
      <oipf:Component type="audio" id="3" lang="fr" description="Audio-Fr"/>
    </oipf:Components>
  </Representation>
  </Period>
</MPD>

5.6.1 MPEG-2 Transport Stream Systems Layer

5.6.2 MP4 File Format Systems Layer

If the Representation@mimeType attribute equals “video/mp4”, then the carriage of A/V Content and related information (e.g. subtitles) shall be in compliance with the [OIPF_MEDIA2] requirements on usage of the MP4 systems layer format, with the following restrictions:

• For every Representation, a [TS26234] Initialisation Segment shall be available.
  • For all Representations, a reference to the Initialisation Segment shall be present in a <InitialisationSegmentURL> element in the <Representation> element.
  • An Initialisation Segment shall be delivered with MIME type “video/mp4”.
  • Initialisation Segments shall be formatted as specified in [TS26234], section 12.4.2.2. For every media stream of the (set of partial) Representation(s), the moov-box in the Initialisation Segments shall contain a trak-box describing the samples of the media streams in compliance with [ISOFF].
• Every Representation shall consist of Media Segments that are formatted as specified in [TS26234], section 12.4.2.3.
  • A Media Segment shall be delivered with MIME type “video/vnd.3gpp.Segment” as specified in [TS26244]
  • To allow a terminal to seek to any Segment with a certain index and start playback with perfect audio/video synchronization, every traf-box of a track that contains audio should contain a [TS26244] tfad-box. The contents of the box shall be such that if the terminal starts the playback of the audio samples of a Segment as specified in the box, then the audio and video of the Segment are played in perfect sync.
• The Initialisation Segment and the Media Segments are formatted such that a file that consists of the Initialisation Segment and an arbitrary selection of Media Segments of either any complete Representation (@group attribute equal to zero) or the set of partial Representations (@group attribute unequal to zero), stored in order of the sequence_number in their mfhd-box (i.e. increasing order and no duplicates), is an [ISOFF] compliant file. (Note that this statement assumes that [ISOFF] allows for ‘gaps’ in the sequence_numbers of consecutive moof-boxes; i.e. the difference in the sequence_number of consecutive moof-boxes may be larger than one).
• Regardless of the allocation of Components Streams to Representations,
  • Component Streams of the same Component shall be carried in track fragments that have the same trackID (in the tfhd-box).
  • Component Streams of different Components shall be carried in track fragments that have different trackIDs (in the tfhd-box).
• If the Segments are protected, the Initialisation Segment and Media Segments shall also meet the requirements as specified in section 5.6.1.5.

An informative appendix on the use of the MP4 file format systems layer is provided in Appendix D.

5.7.1 Live Streaming

If the @timeShiftBufferDepth attribute is present in the MPD, it may be used by the terminal to know at any moment which Segments are effectively available for downloading with the current MPD. If this timeshift information is not present in the MPD, the terminal may assume that all Segments described in the MPD which are already in the past are available for downloading.

When contents provider updates the MPD for live streaming, the new MPD should include all available Segments including the Segments included in the previous MPD. If the sum of timeShiftBuffer in the previous MPD and Segment duration in the previous MPD is larger than NOW-availabilityStartTime in the current MPD, the playlist should include the combination of the media Segments for which the sum of the start time of the Media Segment and the Period start time falls in the interval [NOW-timeShiftBufferDepth-duration; CheckTime] of the current MPD and the previous MPD.

Periods may be used in the live streaming scenario to appropriately describe successive live events with different encoding or adaptive streaming properties. Timeshift is still possible across the boundaries of such events, provided that the timeshift window is large enough.

5.7.2 Trick Play

Following the principles included in the 3GPP specification, the basic implementation of trick modes (fast forward, fast rewind, slow motion, slow rewind, pause and resume) is based on the processing of Segments by the terminal software: downloaded Segments may be provided to the decoder at a speed lower or higher than their nominal timeline (the internal timestamps) would mandate, thus producing the desired trick effect on the screen. Under these conditions the timestamps and the internal clock, if any, in the downloaded Segments do not correspond to the real time clock in the decoder, which need to be set appropriately.

Pausing a Media Presentation can be implemented by simply stopping the request of Media Segments or parts thereof. Resuming a Media Presentation can be implemented through sending requests to Media Segments, starting with the next fragment after the last requested fragment. Slow motion and slow rewind can be implemented through controlling the normal stream playout speed at client side. The rest of this section addresses fast forward and fast rewind implementation.

The playback of Segments in fast forward and fast rewind has an immediate effect on the bitrate that is effectively required in the network, because the Segments also need to be downloaded at a faster or at a slower rate than in normal play mode. The terminal should take this into account when doing the bitrate calculations for implementing the adaptive protocol. Dedicated stream(s) may be used to implement efficient trick modes: it is recommended to produce the stream(s) with a lower frame rate, longer Segments or a lower resolution to ensure that the bitrate is kept at a reasonable level even when the Segment is downloaded at a faster rate. The dedicated stream is described as Representation with a <TrickMode> element in the MPD. It is also recommended that if there are dedicated fast forward Representations, the normal Representations do not contain the <TrickMode> element in the MPD.

A very low bitrate version of video might be used to implement some trick speeds, even if that Representation was not created with trick modes in mind; note however that in this case it is possible that the terminal would inject a very high frame rate to the decoder (yet at an acceptable bitrate).

For fast rewind trick modes the terminal downloads successive Segments in reverse order, and it also requires that the frames corresponding to the Segment are presented in reverse order with respect to the capturing/encoding order. The feasibility of this process depends on the capability of the decoder and also on the encoding properties of the stream (e.g. it may be easier to implement if the Segment has been encoded using only intra frames).

In order to start trick mode and easily switch between trick and normal play mode at any time and support for reverse playing, the trick mode streams may be composed of intra frame only with a fixed interval.

5.7.3 MPEG-2 TS Seeking

To determine the random access point in a media Segment, the client should download and search RAP one by one till the required RAP is found. The ‘random_acess_indicator’ and ‘elementary_stream_priority_indicator’ in adaptation field of the transport stream may be used for locating every RAP.