Live Smooth Streaming Publishing Point Advanced Settings

This is probably a post that’s long due. IIS Media Services allows you to create and configure live publishing points from the UI but that’s not all that you can do with those publishing points. There are some “hidden” and “advanced” properties that you can set on the publishing point to achieve some interesting new behavior. A few new advanced properties were also added in the IIS Media Services 4.0 that was just released. Below is a table listing all the supported publishing point attributes in IIS Media Services 3.0 and 4.0:

Name

Type

Default Value

Notes

Minimum Version Supported

title

String

N/A

Title of the publishing point

3.0

estimatedTime

Uint32

0

Estimated duration of the live event in seconds.

3.0

lookaheadChunks

Uint32

2

Number of look-ahead chunks that server will buffer

3.0

sourceType

String

N/A

Must be "Push" or "Pull" which indicates how the publishing point ingests encoder stream

3.0

publishing

String

N/A

Comma separated string with optional values "Streams", "Archives" and "Fragments" indicating how this publishing point would publish the live data. e.g. " Fragments;Streams;Archives "

3.0

archivePath

String

N/A

If set, this path overwrites the default archive path set in the config. Note that server will not create the URL path hierarchy in the new path from this value. Users must not use the same archivePath for multiple publishing points.

3.0

startOnFirstRequest

Boolean

FALSE

Indicates whether the publishing point should automatically start upon the first request.

3.0

archiveSegmentLength

Uint32

0

This specifies the archive segment length in seconds. Default value 0 means that a single smooth streaming presentation will be generated for the entire live broadcast.

3.0

manifestWindowLength

Uint32

0

This specifies the DVR window in seconds. Default value 0 means the entire live broadcast will be available for DVR.

3.0

restartOnEncoderReconnect

Boolean

FALSE

This attribute is only applicable to publishing points with “Push” source type. If set, it allows the publishing point to be automatically shut down from “Stopped” state and restarted when new encoder streams come in. Note that this flag must be used together with startOnFirstRequest flag. Expression Encoder 4 does not work with option yet and the support will come in future releases.

3.0

formats

String


N/A

Indicate additional output formats that the publishing point supports. In IIS Media Services 4.0, the only one supported is “m3u8-aapl” which is for Apple Live HTTP Streaming.

4.0

useEventIdInArchivePath

Boolean

FALSE

If set and the encoder is specifying Event ID on the POST URL, server will use the value of the Event ID as the name of the archive sub-folder for this publishing point session instead of using the auto-generated timestamp value.

WARNING: Event ID must be unique for each live session. Otherwise the publishing point may fail to start due to name conflict of archive session directories.

4.0

sendEOSOnStop

Boolean

TRUE

This flag indicates whether the publishing point should send End-of-Stream (EOS) signal to downstream publishing points when stopping. Sending EOS signals will cause downstream publishing points going into “Stopped” state. Setting this flag to FALSE is useful when doing regular server maintenance on upstream servers when stopping downstream publishing points is not desirable. Downstream publishing points can be configured to automatically roll over to the backup server to continue streaming.

4.0

liveCacheSizeSec

Uint32

0

This specifies how many latest fragments in live streaming, in duration of seconds, should be cached in the publishing point’s internal memory. Note that in normal case, the operating system’s file cache is doing the caching for reading and writing. This setting is useful when you want to guarantee memory caching for a specific publishing point so that clients following the live stream of that publishing point can get the best performance.

4.0

clientManifestVersion

Uint32

20

For IISMS 4.0 release, the allowed values are “20” and “22”. “20” means 2.0 version of client manifest which is compatible with Smooth Streaming Client 1.0 and 1.1. “22” means 2.2 version of client manifest which supports a new manifest compression schema (require a new client update that will be released soon).

4.0

Note:

  • This table does not include publishing point attributes specific to Apple Live HTTP Streaming which are mostly configurable from the UI.
  • Some of these attributes are configurable and will be overwritten by the UI.
  • To configure any of these attributes, simply open the publishing point file (.isml file) in a text editor and add a line in the <head> section. For example
    <meta name="liveCacheSizeSec" content="20" />

9 Comments

  • Some of these properties are exposed through publishing point setting's UI. Others would need to be manually added into the .isml file.

  • In the current release, there is no option to completely disable live DVR on the server as well as the client. Setting "manifestWindowLength" to zero means unlimited live DVR.

  • If "liveCacheSizeSec" is zero or does not exist, the publishing point will not try to allocate its own memory for buffering fragments. Instead, it would directly write the fragment to the file system and the Windows file cache will handle the caching based on its own rules. There should not be much difference between these two if the server is just running a few publishing points. But if the server is handling not just live smooth streaming, but also on-demand smoooth streaming and other types of contents, having dedicated fragment buffer in the publishing point (by setting liveCacheSizeSec value) can garantee a certain level of performance for that publishing point. This is because in that case the system's file cache would have to juggle between all the caching needs and inevitably page out some live smooth streaming's fragments.

  • That's controlled by the encoder. They should not vary much and need to be consistent across all bitrates for a given time position.

  • @Mark

    If you're using Expression Encoder, it's probably because Expression Encoder always starts from timestamp zero which results in identical URLs between sessions. The solution is to use "Event ID" feature that was supported in EE4 SP1. Giving each session a new EventID garentees unique URLs between sessions. See here http://blogs.iis.net/samzhang/archive/2011/02/05/eventid-support-in-expression-encoder-sp1.aspx

  • @Jeremy

    All the properties here including useEventIdInArchivePath needs to be set in the header part of the .isml file.

  • How can get the Archive path of the publish point programmatically?

  • hi , I have a few question to ask. we want to build a lot of channel, but the DVR is can't disable. so, the diskio is too high, the request from client get 412 response. what should I do?

  • we want use ram disk for the DVR. so , we want the archiveSegmentLength and lookaheadChunks to be a small value, maybe 0 for lookaheadChunks . Would it cause any problem to the service? manifestWindowLength less than 60 will be OK?


Comments have been disabled for this content.