Packaging for HTTP Smooth Streaming (HSS)

When packaging content for delivery by IIS instead of Unified Origin, there are some additional requirements and limitations.

Limitations:

  • Only the streaming protocols supported by IIS are supported (HTTP Smooth Streaming). Your content won't be available in the formats MPEG-DASH, HLS and HDS.

  • The progressive streaming files cannot reference the sample data in other files. The audio and video sample data is duplicated.

Requirements:

  • The source content must be converted to fragmented-MP4 using a timescale of 10MHz. You can force changing the timescale using the --timescale option.

  • An additional client manifest file (.ismc) must be generated.

Note

These limitations and requirements do not apply for content delivered with Unified Origin.

Creating the media files (.isma and .ismv)

The first step is to package all the source content into the format that is used by IIS. This is the ISMV / PIFF format:

#!/bin/bash

mp4split --timescale=10000000 -o tears-of-steel-iss.ismv \
  tears-of-steel-avc1-1000k.mp4 \
  tears-of-steel-avc1-750k.mp4 \
  tears-of-steel-avc1-400k.mp4 \
  tears-of-steel-aac-128k.mp4

Now that we have packaged all the audio and video, the following step is to create the two progressive download files. In this case the audio and video data is duplicated.

#!/bin/bash

mp4split -o tos-iss-1000k-progressive.mp4 \
  tears-of-steel-avc1-1000k.mp4 \
  tears-of-steel-aac-128k.mp4

#!/bin/bash

mp4split -o tos-iss-400k-progressive.mp4 \
  tears-of-steel-avc1-400k.mp4 \
  tears-of-steel-aac-64k.mp4

Creating the media files with PlayReady

You can add PlayReady encryption to the .isma and .ismv media files.

Note

In case your input is pre-encrypted, Packager and Origin will pick up on any DRM signaling present in the input and automatically pass it through in the output they generate. This means that for any DRM system for which signaling is present in the input, you do not need to specify DRM configuration options when preparing your stream. However, do note that there are DRM systems for which such signaling can't be present by design, like FairPlay, because signaling for these systems is never stored in the media. This means that to support such DRM systems, you will always need to add the necessary DRM configuration options.

--iss.key

The 128 bits Key ID (KID) and 128 bits Content Encryption Key (CEK) are passed with the --iss.key option where KID and CEK are separated by a colon, e.g. --iss.key=KID:CEK

The KID identifier uniquely identifies the content.

The CEK is the Content Encryption Key. Note this is NOT the PlayReady Key Seed, but the actual content encryption key.

Both KID and CEK must be coded in hex (base16).

Note

The KID from the PlayReady License server may be formatted as a little-endian GUID. In that case you have to change the endianess as we always use a big-endian UUID representation of the KID.

--iss.key_iv

The 64 bit AES Initialization Vector (IV). This is a random 64 bit value.

If it is not specified then a random value is generated.

When specified, make sure not to re-use the same IV for the same CEK. I.e. it should be different between multiple mp4split calls.

--iss.license_server_url

The URL used by the player to retrieve the key.

Example

The following command creates a PlayReady protected ismv file to be used with IIS:

#!/bin/bash

KID=10000000100010001000100000000001
CEK=3a2a1b68dd2bd9b2eeb25e84c4776668
KID_UUID=10000000-1000-1000-1000-100000000001 #UUID representation of KID
CEK_B64="OiobaN0r2bLusl6ExHdmaA==" #Base64 byte array representation of CEK
LAURL="https://test.playready.microsoft.com/service/rightsmanager.asmx?cfg=(kid:${KID_UUID},contentkey:${CEK_B64},ckt:aesctr)"

mp4split --timescale=10000000 -o tos-iss-1000k-pr.ismv \
  --iss.key=${KID}:${CEK} \
  --iss.license_server_url="${LA_URL}" \
  tears-of-steel-avc1-1000k.mp4 \
  tears-of-steel-aac-128k.mp4

Please download the playready-iis.sh sample script which creates the various server manifest as discussed above. The sample content is Tears of Steel.

Creating the manifest files (.ism and .ismc)

As a last step we create the server and client manifest files. The server manifest file is an XML file that contains the media information about all the tracks and is used by IIS. The client manifest file is used by the Silverlight player.

#!/bin/bash

mp4split -o tears-of-steel-iss.ism \
  tears-of-steel-iss.ismv

#!/bin/bash

mp4split -o tears-of-steel-iss.ismc \
  tears-of-steel-iss.ism

For backwards compatibility with older Silverlight players you may have to change the FourCC for AVC video streams in the client manifest file to use H264 instead. Just pass 'H264' as parameter on the commandline.

Generating the client manifest file but use H264 instead of AVC1:

#!/bin/bash

mp4split -o tears-of-steel-iss.ismc \
  tears-of-steel-iss.ism/Manifest?H264

At this point we have 5 files stored for our presentation:

Files

Description

tears-of-steel-iss.ismv

128k audio, 400, 750 and 1000k video

tos-iss-400k-progressive.mp4

64k audio, 400k video

tos-iss-1000k-progressive.mp4

128k audio, 1000k video

tears-of-steel-iss.ism

Server manifest file

tears-of-steel-iss.ismc

Client manifest file

Please download the advanced-iis.sh sample script which creates the various server manifest as discussed above. The sample content is Tears of Steel.