Application Workflow

IIS 7.0

[Note: This topic is pre-release documentation and is subject to change in future releases. Blank topics are included as placeholders.]

The following sequence describes the workflow for use of the IIS Smooth Streaming Format SDK.

  1. The application calls SSFMuxCreate (IIS Smooth Streaming Format SDK API) to create the packager

  2. Calls to SSFMuxSetOption (IIS Smooth Streaming Format SDK API)/ SSFMuxSetAllDefaults (IIS Smooth Streaming Format SDK API) initialize the packager with any required parameter settings. If using Live Mode, you should next set the packager to live mode by calling the SSFMuxSetOption (IIS Smooth Streaming Format SDK API) method with the SSFMUX_OPTION_LIVE_MODE setting.

  3. If using PlayReady encryption for VC-1 bit streams, you should set the appropriate key ID and key seed or optional content key using SSFMuxSetOption (IIS Smooth Streaming Format SDK API).

  4. Application calls SSFMuxAddStream (IIS Smooth Streaming Format SDK API) for each encoded bit stream that it needs to package. The SSF library will return the stream index number pdwStreamIndex for each stream that is added. For example if the application adds a 1000 kbps video stream and a 64 kbps audio stream, in that order, the API will update the stream index to values of 0 and 1, respectively, for these streams. The maximum allowed number of streams per muxer is 32. The sample application only accepts 16.

  5. For Live scenarios the application should now call SSFMuxGetHeader (IIS Smooth Streaming Format SDK API) for each stream individually to get the 'ftyp'+'moov' header payload which also includes the proper Stream Manifest, and Live Server Manifest boxes. This header should be sent via HTTP POST for each stream used for the IIS Live Smooth Streaming publishing point. This is done for video on demand (VOD) also.

  6. The application then feeds compressed video/audio samples via SSFMuxProcessInput (IIS Smooth Streaming Format SDK API).

    1. The application is expected to keep track of where the f-MP4 fragment boundaries lie. For video, this means the group of pictures (GOP) boundaries. For audio, usually a fixed time duration such as 5 seconds is chosen. The SDK does not check GOP boundaries, but it does check that fragments are aligned across different quality levels under the same stream index.

    2. The application uses the above stream index value returned when adding the streams in order to match the input sample with the correct SSF stream.

  7. When all of the payload required for a single f-MP4 fragment has been processed (e.g. a full 2 second closed GOP for video), the application invokes SSFMuxProcessOutput (IIS Smooth Streaming Format SDK API), again with the correct dwStreamIndex value to retrieve the fragment.

    1. If samples were passed to SSFMuxProcessInput (IIS Smooth Streaming Format SDK API) without the duration attribute, the application should call SSFMuxAdjustDuration (IIS Smooth Streaming Format SDK API) before calling SSFMuxProcessOutput (IIS Smooth Streaming Format SDK API). This allows the muxer to fix the duration of the fragment. On the other hand, if all the samples have correct durations, then the muxer can calculate the duration of the fragment from the samples, in which case calling SSFMuxAdjustDuration (IIS Smooth Streaming Format SDK API) is unnecessary.

    2. The application will receive a full fragment containing the 'moof' and 'mdat' boxes that can now be written to disk or sent over HTTP POST by the application. The application is responsible for setting up and managing the long-running HTTP POST connections to the IIS server's Live Smooth Streaming Publishing Point. Both samples call SSFMuxAdjustDuration (IIS Smooth Streaming Format SDK API) just before calling SSFMuxProcessOutput (IIS Smooth Streaming Format SDK API). The transmission must be done using HTTP chunked encoding. For more information see Protocol Parameters or Chunked Transfer Encoding.

  8. When the entire stream has been processed, the application should call SSFMuxGetIndex (IIS Smooth Streaming Format SDK API).

    1. In live mode, the call will return an empty 'mfra' box that should be sent to the IIS server to signal end-of-stream and stop the publishing point. If DVR mode was enabled on the publishing point, it will still be available for clients.

    2. For on-demand scenarios, the application should call SSFMuxGetIndex (IIS Smooth Streaming Format SDK API) to retrieve the fully populated index in the 'mfra' box and write this to disk.

  9. For on-demand scenario, application should call SSFMuxGetHeader (IIS Smooth Streaming Format SDK API) again to retrieve the header information with the correct duration values set and update the header in the file. If the application does not update the header in the file, it will contain an undefined duration.

  10. For live scenarios, the application should cleanup and shutdown its HTTP connections. For on demand, the file stream should be now flushed to disk and closed.

  11. For on-demand, need to call SSFMuxGetClientManifest (IIS Smooth Streaming Format SDK API) and SSFMuxGetServerManifest (IIS Smooth Streaming Format SDK API) to obtain the manifests’ data and write it to the manifest files. Both functions return the manifest data as UTF-8 string buffers.

  12. Call SSFMuxDestroy (IIS Smooth Streaming Format SDK API) for both VOD and Live.

NoteNote:

The sample code can be found in the Samples folder of the Smooth Streaming Format SDK installation.

Show: