Export (0) Print
Expand All
This topic has not yet been rated - Rate this topic

4.5 Server-Side Playlist Streaming

The client can seek and skip to a new entry within a server-side playlist. For more information, see section 4.5.1. The following sequence occurs between a client and server during a server-side playlist switch using either the pipelined mode or the non-pipelined mode of the protocol:

  1. The client sends a Describe request to retrieve the ASF header.

  2. The server responds with a $H (Header) packet.

  3. The client sends a Play request for the file, selecting one or more streams.

  4. The server responds with a $H (Header) packet and $D (Data) packets of the first playlist element.

  5. After all data packets of the current playlist element have been sent to the client, the server sends an $E (End-of-Stream Notification) packet, with the Reason field set to S_FALSE (0x00000001).

  6. The server sends a $C (Stream Change Notification) packet to the client. This signal, like the data stream, is sent as part of the response body for the last GET request sent by the client.

  7. The server sends the $H (Header) and $M (Metadata) packets for the next playlist entry.

  8. The client sends a Log request for the previous entry in the playlist.

    Note  When the non-pipelined mode of the protocol is used, the client sends this POST request over a separate TCP connection rather than the one created with the client's initial GET request. The POST request contains the client identifier so that the server can associate the log with the client.

    Note  When the pipelined mode of the protocol is used, the client sends this POST request over the same TCP connection that was created with a client's initial GET request. The response to the POST request is not returned until the previous GET request is terminated by the server.

  9. The client starts rendering the stream by sending a GET request.

    Note  When the non-pipelined mode of the protocol is used, the client sends a SelectStream request. This request contains the stream information in the stream-switch-entry token on the Pragma header. The client might select other streams than those predictably selected by the server. Predictive stream selection provides a way for the server to predict the streams that the client is going to request so the server can begin streaming those streams immediately. For more information, see section 4.5.2.

    Note  When the pipelined mode of the protocol is used, the client sends a PlayNextEntry request with the xPlayNextEntry token on the Pragma header over the same connection to the server. This request also contains the stream selection for the next entry in the stream-switch-entry token on the Pragma header. The xPlayNextEntry token indicates that the client can begin streaming the data for the next entry.

  10. The server terminates the Play request for the previous entry in the playlist.

  11. The server sends the response for the Log request.

  12. The server sends $H (Header) and $D (Data) packets for the next entry in the playlist.

  13. The server continues looping playlist element data packets (step 5) until the end of the playlist is reached. The end is indicated by the server sending a $E (End-of-Stream Notification) packet with the Reason field set to S_OK (0x00000000).

The following figure shows the previously described sequence.

6f3efef9-0c5f-4b61-8d33-d7cecb2c950d

Figure 5: Sequencing during normal playlist streaming

 
Did you find this helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft. All rights reserved.