Common mistakes / issues when creating and using Composite Stream Manifests (.CSM)10 Comments
One of the greatest features added on the Beta 2 version of the IIS Smooth Streaming Player Development Kit (SSPDK) is the support for Composite Stream Manifests for Rough Cut Editing. This a powerful feature which I really recommend looking at, and if you want to learn the basics of the CSMs you must take a look at the following posts:
- Composite Manifest Support for Rough Cut Editing scenarios in SSME by Vishal Sood
- New Composite Manifest support for building Rough Cut Editing (RCE) scenarios with Smooth Streaming by John Deutscher
I’ve been working with CSMs for three months now, so in this post I would like to share with you the lessons I’ve learnt during the process of creation and usage of the CSMs.
There are a few common mistakes and issues you might face during that process, so I hope this post will be helpful for the community.
Configure IIS to serve .CSM files
In order to do that, you have to add a mime type entry on IIS for the .CSM extension on every IIS server that is serving up the .csm files. The mime type for the .csm must be “text/xml”. You can do this on the IIS Manager. Also you can achieve the same by editing the applicationHost.config and adding the following line:
<mimeMap fileExtension=”.csm” mimeType=”text/xml” />
“Error encountered on HEAD request to manifest uri <your manifest> for <position> clip in RCE manifest”
This will likely be the first issue you will encounter after trying to use a CSM. When using a CSM the Smooth Streaming Media Element (SSME) attempts to do a HEAD request on the manifest for each clip to make sure that the content hasn’t been moved (and if it has, it will used the new URL on the response).
There are two changes you have to make in order to fix this issue.
The first one is related to an existing known-issue on the applicationHost.config file of IIS. This server bug prevents the On-Demand smooth streaming handler from responding to HEAD request. To fix this go to the Smooth Streaming Readme page and check the Known Issues section, specifically the “Configuring the SmoothHandler handler mapping to process HTTP Head requests” item.
The second change must be done on the clientaccesspolicy.xml file, essentially to indicate that HEAD requests are allowed. To fix this make sure that your clientaccesspolicy.xml file includes http-methods=”*”or http-methods=”GET,HEAD,POST”:
<?xml version=”1.0″ encoding=”utf-8″?>
<allow-from http-methods=”*” http-request-headers=”*”>
<resource path=”/” include-subpaths=”true”/>
“Caught exception trying to parse main manifest: V2 Manifest: Audio stream requires CodecPrivateData attribute”
This is because the CSM contains a clip that is referring a V1 Manifest, which is not a valid source for a CSM.
“Caught exception trying to parse main manifest: First video (audio) chunk in clip <position> [start time = <start time>, duration = <duration>] does not contain clip start position <clipStartPosition>”
This message indicates that the first chunk time + the first chunk duration of the reported stream is smaller or larger that the clip’s begin position. Therefore the first chunk time + the first chunk duration of the stream must contain the clip’s begin position.
“Caught exception trying to parse main manifest: Last video (audio) chunk in clip <position> [start time = <start time>, duration = <duration>] does not contain clip end position <clipEndPosition>”
This message indicates that the last chunk time + the last chunk duration of the reported stream is smaller or larger that the clip’s end position. Therefore the last chunk time + the last chunk duration of the stream must contain the clip’s end position.
Different Audio encoding settings in the CSM clips
If you have clips with different audio encoding settings, then the playback will suddenly stop. Due to a limitation on Silverlight, the audio settings have to be the same. The Silverlight pipeline is not able to handle audio property changes on the fly. So make sure that the audio of the clips are being encoded at same bit rate.
Sparse stream data within the clip
This will likely not cause any issue, but as today having sparse stream data within a clip is not supported I decided to include it on this list.
As you see, there are a couple of things to have in mind when creating and using composite stream manifests. I hope this post encourages you to use this amazing feature.
Leave a comment
Your email address will not be published.