What’s so important about the “Stopped” state?

One frequently asked question especially from new users of IIS Live Smooth Streaming is that “why does the publishing point have to get stuck at “Stopped” state before it can be shut down?”. This can  be especially annoying if you want to control your publishing point from the encoder side: After you stopped the encoder, the publishing point goes to “Stopped” state. But if you try to restart the encoder right away, it will fail to connect until you shut down the publishing point.

The answer to that question goes back to one important difference between Live Smooth Streaming and traditional live streaming: live DVR. With traditional live streaming, it’s guaranteed that every one is viewing the same thing at the same time. When the live stream is over, there is nothing that the clients can do except for stopping the playback. For IIS Live Smooth Streaming, clients can pause, seek, fast forward and rewind within the DVR window. So it’s no longer true that all clients are playing the same position at the same time. When the live event is over, you wouldn’t want to immediately shut down the live session because there will still be many clients playing different parts of the live DVR. So with that, the reason why we created this “Stopped” state in IIS Live Smooth Streaming is really two folds:

1. It allows the publishing point to keep serving DVR requests without actively receiving live data from the encoder. Essentially we’re creating a two-phase close down for a live streaming session. The first phase is to go from both live and DVR to DVR only – this is the “Stopped” state. The second phase is to completely shut down the live streaming session for all clients.

2. “Stopped” state also provides a grace period for live to on-demand transition. When the publishing point enters into “Stopped” state, it immediately finishes all the file archive operation so that the archive files are ready to be copied over to your on-demand location for later on-demand serving. You can do this live to on-demand transition while the publishing point is in “Stopped” state so that clients can still view this event. When the on-demand service is ready, you can shut down the publishing point and redirect your clients to the new on-demand location for that event.

What’s outlined above was exactly how “Stopped” state was used in real world IIS Live Smooth Streaming deployments including events like Olympics. We saw gradual declining of client traffic after the live event is over. The publishing point needs to stay in “Stopped” state to satisfy those DVR requests and sometimes it can take a long time before the majority of the clients go away. Our customers also leverage this grace period to do their live to on-demand workflow.

While “Stopped” state is important for real world production, we do realize that automating the stop to shutdown process is still a valuable and convenient option for things like testing. As a matter of fact, IIS Media Services supports this option called “restartOnEncoderReconnect” since 3.0 release. This option allows the publishing point to automatically shut down and restart from “Stopped” state when it receives new streams from the encoder. Please see my previous blog here for the details of this option. Unfortunately Expression Encoder 4 today has an issue working with this option but it should be fixed soon in future releases. If you’re using other encoders that output Live Smooth Streaming, you can contact your encoder provider to see if/how it works with this option.

==============================

Update: Expression Encoder 4 SP1 now supports the “restartOnEncoderReconnect” option for live smooth streaming publishing points. You need to generate an unique event ID from the Expression Encoder’s output setting page every time you start a new session.