Revision Summary Date Revision History Revision Class Comments 6/4/2010 0.1 Major First Release. 7/16/2010 0.1 None No changes to the meaning, language, or formatting of the technical content. 8/27/2010 0.1 None No changes to the meaning, language, or formatting of the technical content. 10/8/2010 0.2 Clarified the meaning of the technical content. 11/19/2010 0.2 None No changes to the meaning, language, or formatting of the technical content. 1/7/2011 0.2 None No changes to the meaning, language, or formatting of the technical content. 2/11/2011 0.2 None No changes to the meaning, language, or formatting of the technical content.
3/25/2011 0.2 None No changes to the meaning, language, or formatting of the technical content. 5/6/2011 0.2.1 Editorial Changed language and formatting in the technical content. 6/17/2011 0.3 Clarified the meaning of the technical content. 9/23/2011 0.3 None No changes to the meaning, language, or formatting of the technical content. 12/16/2011 1.0 Major Updated and revised the technical content. 3/30/2012 2.0 Updated and revised the technical content. 7/12/2012 2.1 Minor Clarified the meaning of the technical content. 10/25/2012 3.0 Major Updated and revised the technical content. 1/31/2013 3.0 None No changes to the meaning, language,
For each SparseStreamFragment in the Sparse Stream Pointer message, the client MUST perform the following operations: Search the Stream Collection data element in the Active Presentation data element to locate the Stream Description whose Name field matches the SparseStreamName field. If no can be found or if the Sparse Stream Flag of the matching Stream Description data element is false, the client MUST enter the Final state without yielding a Fragment Description data element. Compare the value of the SparseStreamTimeStamp field to the Last Downloaded Timestamp field of the Stream Description data element. If the Last Downloaded Timestamp field is not set, or if the value of the SparseStreamTimeStamp field is greater than the Last Downloaded Timestamp field, add an entry to the Sparse Stream Notifications collection for which the Stream Description Reference field is set to the matching Stream Description, and the Timestamp field is set to the value of the SparseStreamTimeStamp field. If the Sparse Stream Notifications collection is not empty, the client yields this collection to the higher layer in addition to the Fragment Description. Timer Events None. Other Local Events None. Server Details The server does not maintain state and treats all arriving messages independently. Abstract Data Model This section describes a conceptual model of possible data organization that an implementation maintains to participate in this protocol. The described organization is provided to facilitate the explanation of how the protocol behaves. This document does not mandate that implementations adhere to this model as long as their external behavior is consistent with that described in this document. The server uses the same conceptual model as the client, specified in section . Timers None. Initialization There is no initialization required for the Smooth Streaming Transport Protocol layer. Successful initialization of the underlying transport (HTTP) is a prerequisite for successful operation of the server. The Sparse Stream Pointer Header is initialized from configuration above the Smooth Streaming Transport Protocol layer. The configured value on the client MUST match the configured value on the server for interoperability. <2>
Protocol syntax refers to data elements (such as packets, structures, enumerations, and methods) as well as interfaces. Protocol revision refers to changes made to a protocol that affect the bits that are sent over the wire. The changes made to this document are listed in the following table. For more information, please contact . Section Tracking number (if applicable) and description Major change (Y or N) Change type StreamFragmentElement : Added description stating that in the StreamFragmentElement element a contiguous sequence of fragments MUST be represented using the start-time coding or the one of the duration coding schemes. Y Content update.
26 35 35 13 14 13 14 32 27 26 16 40 40 14 34 34 16 23 11 30 29 28 19 27 11 31 19 27 26 N 6 O local events 50 52 7 P 58 9 9 41 54 59 16 R 6 7 6 9 S Security 58 58 Sequencing client 49 49 47 47 46 51 Server 50 51 51 51 52 52 50 51 52 51 40 40 14 34 34 10 16 23 36 11 T 30 29 28 Timer events 50 52 Timers 44 51 19 60 27 11 Triggered events client 46 45 45 45 51 Triggered events - higher-layer 45 51 31 U 19 V 10 10