Export (0) Print
Expand All

3.2.5 Processing Events and Sequencing Rules

The following event processing and sequencing rules apply:

  • When a valid Manifest Request message arrives, the server MUST respond with a Manifest Response message.

  • When a valid Fragment Request message arrives, the server MUST respond with a Fragment Response message. Depending on the value of the FragmentsNoun field in the Fragment Request (see section 2.2.3), the form of the FragmentResponse field, specified in section 2.2.4, varies according to the following rules:

    • If the FragmentsNoun field is a FragmentsNounFullResponse, the FragmentResponse field MUST be a FragmentFullResponse.

    • If the FragmentsNoun field is a FragmentsNounMetadataOnly, the FragmentResponse field MUST be a FragmentMetadataResponse.

    • If the FragmentsNoun field is a FragmentsNounDataOnly, the FragmentResponse field MUST be a FragmentDataResponse.

    • If the FragmentsNoun field is a FragmentsNounIndependentOnly, the FragmentResponse field MUST be a FragmentFullResponse, and all Samples in the FragmentResponse MUST be independently decodable, as defined in [ISO/IEC-14496-12].

The following special processing rules apply when generating a Fragment Response in a livepresentation:

  • Requested Streams Collection: The server computes the set of all Stream Descriptions which pertain to the fragments referenced in the incoming Fragment Request message.

  • For each entry in the Requested Streams Collection, perform the following processing:

    • If the selected item is not a child stream of another stream, do the following:

      • Child Streams Collection: The server computes the set of all Stream Descriptions for which the Parent Streams field references the selected item in the Requested Streams Collection.

      • From each item in the Child Streams Collection, generate a SparseStreamFragment field, specified in section 2.2.5 by setting the SparseStreamName field to the Name field of the Stream Description data element, and setting the SparseStreamTimestamp field to the greatest timestamp of any fragment for the corresponding stream that is available from the server, but that is not later than the timestamp of the corresponding requested fragment.

      • Generate a SparseStreamSet field from the SparseStreamFragment fields generated in the previous step.

    • If the selected item is a child stream of another stream, and the requested fragment is not the first fragment in the track, do the following:

      • Generate a SparseStreamFragment field, specified in section 2.2.5, by setting SparseStreamName field to the Name field of the selected item. Set the SparseStreamTimestamp field to the timestamp of the preceding fragment in the track.

      • Generate a SparseStreamSet field containing a single SparseStreamFragment field, as specified in the preceding step.

    • If any SparseStreamSet fields are generated as a result of the preceding steps, generate a SparseStreamPointer field according to the following rules:

      • If the processing rules specified by HTTP [RFC2616] result in an HTTP Header whose name matches the value of the Sparse Stream Pointer Header field, the data becomes the HeaderData field. Otherwise, the HeaderData and DELIMITER fields are omitted.

      • The remainder of the SparseStreamPointer field is generate from the SparseStreamSet fields.

 
Show:
© 2015 Microsoft