# MSS in AWS Elemental MediaPackage
Microsoft Smooth StreamingAdded Microsoft Smooth Streaming information
Added the topic that describes how MSS endpoints work in MediaPackage.
AWS Elemental MediaPackage supports Microsoft Smooth Streaming (MSS) for delivering content to legacy devices such as smart TVs and other platforms where MSS is the preferred or required streaming format. This topic provides an overview of MSS and how it works with MediaPackage.
MSS remains important for reaching legacy devices and platforms that don't support newer protocols, even though HLS and DASH are more common in modern streaming environments.
Similar to other adaptive bitrate streaming protocols like HLS and DASH, MSS dynamically adjusts the quality of a video stream based on network conditions and device capabilities. The key difference is that MSS uses a different format and structure for its manifests and segments, and it was developed by Microsoft specifically for their platforms (like Silverlight, Xbox, etc.).
## When to use MSS
MSS is particularly valuable in the following scenarios:
+ **Legacy device support**: If your audience uses older smart TVs, set-top boxes, or gaming consoles (particularly Xbox 360) that only support MSS, this format is essential for reaching those viewers.
+ **Corporate environments**: Many enterprise environments standardized on Microsoft technologies, including Silverlight-based players, and may not have updated their infrastructure to support newer protocols.
+ **Multi-protocol strategy**: For maximum audience reach, content providers often implement a multi-protocol strategy where the same content is available in HLS, DASH, and MSS formats, allowing the client to use whichever format it supports best.
+ **Regions with older device penetration**: In some geographic regions, older devices with MSS support remain common, making this format important for reaching those markets.
## Choosing the right streaming protocol for your audience
To reach the widest possible audience, select the appropriate streaming protocols based on your viewers' devices. This section helps you decide when to use MSS versus other protocols.
### Protocol selection guide
Use this guide to determine which protocols you need to implement:
1. **Identify your audience's devices**: Survey your target audience to understand what devices they use to consume your content.
1. **Check device compatibility**: If your audience includes any of these devices, consider implementing MSS:
+ Xbox 360 consoles
+ Legacy smart TVs (especially older Samsung and LG models)
+ Devices with Microsoft Silverlight players
+ Corporate environments with standardized Microsoft infrastructure
1. **Evaluate audience reach vs. implementation cost**: Determine what percentage of your audience requires MSS support and whether the additional implementation effort is justified.
1. **Consider a multi-protocol approach**: For maximum audience reach, implement multiple protocols and use device detection to serve the appropriate format.
### Protocol comparison for implementation planning
This comparison helps you understand the key differences between streaming protocols to plan your implementation:
**Streaming Protocol Comparison**
| Feature | MSS | HLS | DASH |
| --- | --- | --- | --- |
| Developer | Microsoft | Apple | MPEG |
| Year introduced | 2008 | 2009 | 2012 |
| Manifest format | XML | M3U8 (text) | XML (MPD) |
| Segment format | MP4 (ISM) | TS or fMP4 | MP4 |
| DRM support | PlayReady only | FairPlay, AES-128 | Multiple (Widevine, PlayReady, etc.) |
| Device support | Xbox, Silverlight, older smart TVs | iOS, macOS, newer smart TVs | Android, browsers, newer smart TVs |
| Industry adoption | Limited (legacy) | Widespread | Growing |
### Common implementation scenarios
Based on your audience needs, consider these common implementation scenarios:
Modern devices only
If your audience exclusively uses modern devices (smartphones, tablets, newer smart TVs, modern browsers):
+ **Recommended**: HLS and DASH
+ **Not needed**: MSS
Mixed device ecosystem
If your audience uses a mix of modern and legacy devices:
+ **Recommended**: HLS, DASH, and MSS
+ **Implementation approach**: Use device detection at the CDN level to route viewers to the appropriate format
Corporate/Enterprise environments
If delivering to corporate environments with standardized Microsoft infrastructure:
+ **Recommended**: MSS (primary) with HLS/DASH as alternatives
+ **Implementation approach**: Optimize for MSS playback while providing alternatives for BYOD scenarios
While HLS and DASH are now the dominant streaming protocols for modern devices, MSS continues to play an important role in comprehensive streaming strategies that aim to reach the widest possible audience.
## Planning your MSS implementation
When you plan your MSS implementation in MediaPackage, you need to understand the technical requirements and considerations to ensure successful delivery to legacy devices.
### Technical requirements
Make sure your implementation meets these technical requirements:
+ **Container type**: MSS requires the ISM container type. You cannot use CMAF or TS containers with MSS manifests.
+ **Encryption**: Only CENC encryption with PlayReady DRM is supported for MSS content. Key rotation is not supported.
+ **Audio codecs**: MSS typically uses AAC audio with the AACL FourCC code.
+ **Video codecs**: MSS typically uses H.264 video with the H264 FourCC code.
### Implementation options
When you configure your MSS endpoints, consider these options:
+ **Manifest layouts**: Choose between:
+ **Full layout**: Better compatibility with older players but larger manifest size
+ **Compact layout**: Uses the FragmentRepeat field to significantly reduce manifest size for streams with consistent segment durations
+ **Subtitles**: If you need subtitles, use TTML format as MSS does not support WebVTT.
### Implementation limitations
Be aware of these limitations when you plan your MSS implementation:
+ **SCTE-35**: MSS endpoints do not support SCTE-35 message passthrough or ad marker insertion. If you need ad insertion, consider server-side ad insertion before packaging.
+ **DRM options**: Only PlayReady DRM is supported. Key rotation is not supported for MSS content. If you need multi-DRM support, you'll need to implement additional protocols alongside MSS.
+ **Subtitle formats**: Limited to TTML subtitles only.
### Implementation checklist
Use this checklist when you plan your MSS implementation:
1. Verify your source content is compatible with MSS requirements (codecs, container)
1. Decide on manifest layout based on your audience's devices (Full for maximum compatibility, Compact for efficiency)
1. Understand that LookaheadCount is fixed at 2 and plan your segment duration accordingly for desired latency
1. If encryption is needed, set up a SPEKE key provider for PlayReady DRM
1. Configure your CDN with appropriate cache settings and MIME types for MSS content
1. Test playback on representative devices from your target audience
For step-by-step instructions on creating MSS endpoints, see [Create an MSS manifest](endpoints-create.md#endpoints-ism).
## MSS use cases
Consider using MSS endpoints in the following scenarios:
+ Delivering content to legacy smart TVs and devices that only support MSS
+ Supporting Microsoft platforms where MSS is the preferred streaming format
+ Creating multi-protocol streaming workflows that need to include MSS alongside other formats
+ Broadcasting to regions where older devices with MSS support are still common
+ Supporting Xbox 360 and other legacy Microsoft gaming consoles
+ Providing content to corporate environments that standardized on Microsoft Silverlight-based players
Here's a real-world example of MSS implementation:
**Example Broadcasting sports events to multiple device types**
A major sports broadcaster needed to stream live events to viewers using a wide range of devices, from modern smartphones to older smart TVs and gaming consoles. They implemented a multi-protocol strategy using MediaPackage to create:
+ HLS endpoints for iOS devices and newer smart TVs
+ DASH endpoints for Android devices and modern browsers
+ MSS endpoints for Xbox 360 consoles and older Samsung smart TVs
By including MSS in their delivery strategy, they were able to reach an additional 15% of their audience who were using legacy devices that didn't support newer protocols. The broadcaster configured their CDN to route viewers to the appropriate format based on device detection, ensuring optimal playback for all viewers regardless of their device.
For information about testing MSS playback on compatible devices, see [Testing MSS playback in AWS Elemental MediaPackage](mss-testing-playback.md).
The following sections provide more information about using MSS with MediaPackage.
**Topics**
+ [
## When to use MSS
](#mss-when-to-use)
+ [
## Choosing the right streaming protocol for your audience
](#mss-protocol-comparison)
+ [
## Planning your MSS implementation
](#mss-features)
+ [
## MSS use cases
](#mss-use-cases)
+ [
# MSS manifest structure in AWS Elemental MediaPackage
](mss-manifest-structure.md)
+ [
# MSS encryption and DRM in AWS Elemental MediaPackage
](mss-encryption.md)
+ [
# Testing MSS playback in AWS Elemental MediaPackage
](mss-testing-playback.md)
+ [
# Troubleshooting MSS endpoints in AWS Elemental MediaPackage
](mss-troubleshooting.md)
+ [
# CDN configuration for MSS in AWS Elemental MediaPackage
](mss-cdn-configuration.md)
# MSS manifest structure in AWS Elemental MediaPackage
MSS manifest structure
This topic explains the structure and components of Microsoft Smooth Streaming (MSS) manifests in AWS Elemental MediaPackage. Understanding the manifest structure helps you troubleshoot playback issues and optimize your MSS streaming workflow. For step-by-step instructions on creating MSS endpoints, see [Create an MSS manifest](endpoints-create.md#endpoints-ism). For information about encrypting MSS content, see [MSS encryption and DRM in AWS Elemental MediaPackage](mss-encryption.md).
An MSS manifest is an XML document that describes the available media streams, their qualities, and how to access the media fragments. The main components of an MSS manifest include:
+ **SmoothStreamingMedia**: The root element containing metadata about the presentation, including version, timescale, and whether the content is live.
+ **Protection**: Contains DRM information when content is encrypted.
+ **StreamIndex**: Defines a media stream (video, audio, or text) and its properties.
+ **QualityLevel**: Defines the available bitrates and encoding parameters for a stream.
+ **c**: Represents a fragment (segment) with attributes for duration (d), timestamp (t), and repeat count (r).
MSS manifests use the MIME type `text/xml` and are accessed using URLs that end with `.ism/Manifest` rather than `.html`.
## MSS manifest examples
Here's an example of an MSS manifest with the Full layout:
```
TG9yZW0gaXBzdW0=
```
When using the Compact manifest layout, MediaPackage uses the FragmentRepeat (r) attribute to indicate repeated segments with the same duration, significantly reducing manifest size. Here's an example of a compact manifest:
```
```
Notice that in the compact format, the `r="3"` attribute indicates that the segment with duration 2000 repeats 3 times, which is more efficient than listing each segment separately.
For more information about configuring manifest layouts when creating MSS endpoints, see [Create an MSS manifest](endpoints-create.md#endpoints-ism). To understand how these manifest formats affect playback on legacy devices, see [Testing MSS playback in AWS Elemental MediaPackage](mss-testing-playback.md).
## Key manifest attributes
Key attributes in the MSS manifest that you should understand:
TimeScale
Defines the timescale used for timestamps in the manifest. In the example above, 10000000 means that time values are in units of 1/10,000,000 seconds (0.1 microseconds).
IsLive
Indicates whether the content is live (TRUE) or video-on-demand (FALSE).
LookaheadCount
The number of fragments that must be available before the current fragment is made available in the manifest.
DVRWindowLength
The duration of the DVR window in TimeScale units. In the example above, 600000000 units at a timescale of 10000000 equals 60 seconds.
FourCC
Four-character code that identifies the codec used for the stream. Common values are "H264" for video and "AACL" for audio.
For information about how these attributes affect playback behavior, see [Troubleshooting MSS endpoints in AWS Elemental MediaPackage](mss-troubleshooting.md). To learn how to configure these attributes when creating MSS endpoints, see [Create an MSS manifest](endpoints-create.md#endpoints-ism).
## MSS segment structure
MSS segments are based on the ISO Base Media File Format (ISOBMFF). Unlike CMAF segments used for DASH and HLS, MSS requires ISM segments which include specific boxes for MSS playback:
+ **Tfxd UUID Box**: Encapsulates the absolute timestamp and duration of a fragment in a live presentation.
+ **Tfrf UUID Box**: Encapsulates the absolute timestamp and duration for one or more subsequent fragments of the same track in a live presentation (used for lookahead).
+ **Senc UUID Box**: Contains the sample-specific encryption data, including the initialization vectors needed for decryption when content is protected.
MSS segments don't have a sequence number like HLS segments. Instead, the player determines the next segment by taking the sum of the previous segment's presentation timestamp and duration.
If you encounter issues with MSS segment playback or availability, see [Troubleshooting MSS endpoints in AWS Elemental MediaPackage](mss-troubleshooting.md) for common problems and solutions.
For information about creating MSS endpoints, see [Create an MSS manifest](endpoints-create.md#endpoints-ism).
# MSS encryption and DRM in AWS Elemental MediaPackage
MSS encryption
This topic explains how to protect your Microsoft Smooth Streaming (MSS) content using encryption and digital rights management (DRM) in AWS Elemental MediaPackage. For information about MSS manifest structure and how encryption affects it, see [MSS manifest structure in AWS Elemental MediaPackage](mss-manifest-structure.md). For general information about MSS in MediaPackage, see [MSS in AWS Elemental MediaPackage](mss-overview.md).
MSS encryption in MediaPackage supports PlayReady DRM only. Other DRM systems are not supported for MSS content.
## Understanding MSS encryption requirements
When encrypting MSS content in MediaPackage, note the following requirements and limitations:
+ **DRM system**: Only PlayReady DRM is supported for MSS content
+ **Encryption method**: The encryption method must be CENC (Common Encryption)
+ **PlayReady header**: The PlayReady header is inserted at the top level of the manifest
+ **Key rotation and constant IV**: Key rotation and constant IV (Initialization Vector) are not supported for MSS content
+ **CPIX requirements**: Your key server must provide a `smoothProtectionHeaderData` element in the CPIX response so that MediaPackage can insert it in the manifest. For more information about CPIX, see the [CPIX documentation](https://docs.unified-streaming.com/documentation/drm/cpix_intro.html).
+ **Shared DRM presets**: Video and audio presets must be set to SHARED because MSS uses the same DRM information across the manifest for video, audio, and subtitle segments
For information about how these encryption options affect your CDN configuration, see [CDN configuration for MSS in AWS Elemental MediaPackage](mss-cdn-configuration.md). For details on planning your MSS implementation with encryption, see [Planning your MSS implementation](mss-overview.md#mss-features).
## Encrypting your MSS content with PlayReady
To encrypt your MSS content:
1. When creating or editing your endpoint, select **Encrypt content** in the Encryption section.
1. For **Encryption method**, select **CENC**.
1. For **DRM systems**, select **PlayReady**.
1. Ensure that video and audio presets are set to **SHARED** because MSS uses the same DRM information across all segments.
1. Complete the remaining encryption fields as described in [Encryption fields](endpoints-create.md#endpoints-encryption).
## PlayReady DRM for MSS
PlayReady is Microsoft's DRM technology and is the only supported DRM system for MSS content. When using PlayReady with MSS:
+ The PlayReady header is included in the MSS manifest in the `Protection` element
+ The PlayReady SystemID is `9a04f079-9840-4286-ab92-e65be0885f95`
+ The encryption keys are provided by your SPEKE key provider
For more information about configuring SPEKE with MediaPackage, see [Content encryption and DRM in AWS Elemental MediaPackage](using-encryption.md).
## Key server requirements
When setting up a key server for MSS content, ensure that:
+ The key server has the correct headers that match what is present in the PSSH box
+ The UUIDs are properly configured
+ Request information is in SOAP/HTTP format. MSS uses the same information consistently across all components - the manifest, key service, audio streams, and video streams all share the same request format and authentication details
For more information about requirements for using PlayReady with MSS, see [Microsoft PlayReady documentation](https://docs.microsoft.com/en-us/playready/packaging/mp4-based-formats-supported-by-playready-clients ).
Unlike some other streaming protocols that may use different authentication or request formats for different components, MSS maintains consistency across all elements. This means that once you configure the SOAP/HTTP request format for your key server, the same format and authentication approach will be used whether the player is requesting the manifest, contacting the key service, or accessing audio and video streams.
## MSS encryption limitations
MSS encryption has the following limitations:
+ Key rotation is not supported
+ Constant IV (Initialization Vector) is not supported
## Verifying your encrypted MSS streams
To test your encrypted MSS content:
1. Use the Castlabs Demo Player at [https://demo.castlabs.com/](https://demo.castlabs.com/) for testing PlayReady encrypted MSS content
1. Enter your MSS endpoint URL
1. If your content is encrypted with PlayReady DRM, verify that the player can decrypt and play the content. Use the Castlabs player specifically for encrypted content. Other players might not work reliably with PlayReady encrypted MSS streams.
For production environments, ensure your players and devices are properly configured to handle PlayReady-protected content.
For comprehensive testing procedures and compatible players for MSS content, see [Testing MSS playback in AWS Elemental MediaPackage](mss-testing-playback.md).
# Testing MSS playback in AWS Elemental MediaPackage
Testing MSS playback
After creating your MSS endpoint in AWS Elemental MediaPackage, you need to test playback to ensure your content is properly delivered to viewers. This topic shows you how to test MSS playback using compatible players and tools. For information about creating MSS endpoints, see [Create an MSS manifest](endpoints-create.md#endpoints-ism). For information about planning your MSS implementation, see [Planning your MSS implementation](mss-overview.md#mss-features).
## MSS compatible players
For testing MSS playback, we recommend using the following players:
+ **Dash.js Reference Player** (recommended for unencrypted content): [https://reference.dashif.org/dash.js/nightly/samples/dash-if-reference-player/index.html](https://reference.dashif.org/dash.js/nightly/samples/dash-if-reference-player/index.html)
Example URL format: `https://reference.dashif.org/dash.js/nightly/samples/dash-if-reference-player/index.html?mpd=https://playready.directtaps.net/smoothstreaming/SSWSS720H264/SuperSpeedway_720.ism/Manifest`
+ **Castlabs Demo Player** (recommended for encrypted content): [https://demo.castlabs.com/](https://demo.castlabs.com/)
Use this player for PlayReady encrypted MSS content. The dash.js player might not work reliably with encrypted MSS streams.
For detailed information about testing encrypted MSS content, see the [MSS DRM Castlabs documentation](https://w.amazon.com/bin/view/AWS/EMPv2/MSS-DRM-Castlabs-Docs-Feedback-Deck).
MSS is also supported by the following players and platforms:
+ Microsoft Silverlight-based players
+ Xbox 360 and Xbox One
+ Windows Media Player with appropriate extensions
+ Certain smart TV models (especially older Samsung and LG models)
+ Some set-top boxes that specifically support MSS
When you select a player for testing MSS content, consider the following:
+ **Dash.js Reference Player**: Good for general MSS testing and provides diagnostic information about manifest parsing and segment loading.
+ **Castlabs Demo Player**: Best for encrypted content testing as it handles PlayReady DRM more reliably than other web-based players.
+ **Xbox consoles**: Important for testing if your target audience includes gaming console users. Xbox 360 in particular relies heavily on MSS.
+ **Legacy smart TVs**: If targeting older smart TV models, test on actual devices when possible, as their MSS implementations may have specific quirks or limitations.
## Testing procedure
Follow these steps to test your MSS endpoint:
1. Get your MSS endpoint URL from the MediaPackage console. The URL will end with .isml.
1. Open the Dash.js Reference Player or Castlabs Demo Player (for encrypted content).
1. Enter your MSS endpoint URL in the player.
1. Verify that playback starts and the content plays smoothly.
1. If your content is encrypted with PlayReady DRM, verify that the player can decrypt and play the content.
For a comprehensive test of your MSS implementation, consider these additional testing steps:
+ **Network condition testing**: Test playback under various network conditions (bandwidth throttling, packet loss, latency) to verify adaptive bitrate switching works correctly.
+ **Device compatibility matrix**: Create a compatibility matrix of target devices and test on representative samples from each category.
+ **Long-duration testing**: For live streams, conduct extended playback tests (4\$1 hours) to verify there are no issues with manifest updates or segment availability over time.
+ **CDN edge case testing**: Test from different geographic locations to ensure your CDN configuration works properly across all regions.
**Example Real-world testing scenario: Live sports broadcast**
A media company preparing for a major sports tournament implemented the following testing strategy for their MSS streams:
1. Pre-event testing with simulated content to verify endpoint configuration
1. Dress rehearsal with actual live content one week before the event
1. Testing on 5 different device types representing their audience demographics
1. Network simulation tests with bandwidth fluctuations to verify adaptive bitrate behavior
1. Monitoring setup to track manifest requests, segment delivery, and error rates during the event
This comprehensive approach helped them identify and resolve several issues before the live event, including a CDN configuration problem that was causing intermittent 404 errors for MSS segments.
For information about monitoring your MSS streams during testing and production, see [Monitoring MSS streams](mss-troubleshooting.md#mss-monitoring-tips). For information about testing encrypted MSS content, see [Verifying your encrypted MSS streams](mss-encryption.md#mss-encryption-testing).
## CDN configuration for testing
For production environments, ensure your CDN is properly configured to handle MSS content:
+ Set appropriate cache control headers for both manifests (.isml) and segments
+ Configure proper MIME types: application/vnd.ms-sstr\$1xml for manifests and video/mp4 for segments
+ If using encryption, ensure your CDN is configured to handle PlayReady DRM
For detailed CDN configuration instructions specific to MSS, see [CDN configuration for MSS in AWS Elemental MediaPackage](mss-cdn-configuration.md).
If you encounter issues during testing, see [Troubleshooting MSS endpoints in AWS Elemental MediaPackage](mss-troubleshooting.md) for common problems and solutions.
# Troubleshooting MSS endpoints in AWS Elemental MediaPackage
Troubleshooting MSS
This topic helps you identify and resolve common issues with Microsoft Smooth Streaming (MSS) endpoints in AWS Elemental MediaPackage.
## Resolving common MSS playback issues
If you encounter issues with your MSS endpoints, consider the following common problems and solutions:
404 errors when requesting segments
This could be due to the LookaheadCount setting. MSS holds back segments at the live edge until 2 future segments are available (this value is fixed and not configurable).
**Solution:** Ensure your player is requesting segments within the available window, accounting for the fixed 2-segment lookahead buffer.
Playback issues on legacy devices
Some older devices may have limitations with certain MSS features.
**Solution:** Try using the **Full** manifest layout instead of **Compact**, as it's more widely supported by legacy players.
DRM issues
MSS only supports PlayReady DRM.
**Solution:** Ensure your SPEKE key provider is correctly configured to provide PlayReady keys. For more information, see [Content encryption and DRM in AWS Elemental MediaPackage](using-encryption.md).
Manifest not loading
The MSS manifest may not load if the endpoint is not properly configured.
**Solution:** Verify that you've selected the ISM container type when creating your endpoint. MSS manifests require the ISM container type.
Playback stuttering or buffering
This could be due to network issues or segment availability.
**Solution:** Check your network connection and ensure your CDN is properly configured for MSS content. Also, verify that your segment duration is appropriate for your content and network conditions.
For a better understanding of MSS manifest structure to help diagnose issues, see [MSS manifest structure in AWS Elemental MediaPackage](mss-manifest-structure.md).
## Monitoring MSS streams
Effective monitoring of your MSS streams helps you ensure reliable delivery and quickly identify issues before they impact your viewers. This section provides detailed guidance on setting up comprehensive monitoring for MSS endpoints.
### Key metrics to monitor
When monitoring MSS streams, pay attention to these key metrics:
Request count
Track the number of requests for manifests and segments to understand your audience size and viewing patterns.
**Normal pattern**: MSS clients typically request manifests less frequently than HLS clients, with a ratio of approximately 1 manifest request to 10-20 segment requests.
**Warning signs**: Sudden drops in request count may indicate playback issues or CDN problems.
HTTP response codes
Monitor the distribution of HTTP status codes to identify potential issues.
**Normal pattern**: Primarily 200 OK responses, with some 412 errors near the live edge due to the lookahead buffer (these are expected).
**Warning signs**: High rates of 5xx errors, unexpected 403 errors, or 404 errors for established content.
Latency
Track the time it takes to serve manifest and segment requests.
**Normal pattern**: Manifest requests typically have higher latency than segment requests due to dynamic generation.
**Warning signs**: Increasing latency trends or spikes above 500ms for segment delivery.
Egress bytes
Monitor the volume of data being delivered to understand bandwidth usage and costs.
**Normal pattern**: Consistent patterns that align with your audience's viewing habits.
**Warning signs**: Unexpected spikes or drops that don't correlate with audience size changes.
### Setting up a CloudWatch dashboard for MSS
Create a dedicated Amazon CloudWatch dashboard to monitor your MSS endpoints with these recommended widgets:
1. **Request metrics**:
```
{
"metrics": [
[ "AWS/MediaPackage", "EgressRequestCount", "Channel", "YourChannelName", "Origin", "YourOriginEndpointName", { "stat": "Sum", "period": 60 } ]
],
"view": "timeSeries",
"stacked": false,
"region": "us-west-2",
"title": "MSS Endpoint Requests",
"period": 300
}
```
1. **HTTP status code distribution**:
```
{
"metrics": [
[ "AWS/MediaPackage", "EgressRequestCount", "Channel", "YourChannelName", "Origin", "YourOriginEndpointName", "StatusCodeRange", "4xx", { "stat": "Sum", "period": 60 } ],
[ "AWS/MediaPackage", "EgressRequestCount", "Channel", "YourChannelName", "Origin", "YourOriginEndpointName", "StatusCodeRange", "5xx", { "stat": "Sum", "period": 60 } ],
[ "AWS/MediaPackage", "EgressRequestCount", "Channel", "YourChannelName", "Origin", "YourOriginEndpointName", { "stat": "Sum", "period": 60 } ]
],
"view": "timeSeries",
"stacked": true,
"region": "us-west-2",
"title": "MSS HTTP Status Codes",
"period": 300
}
```
1. **Latency tracking**:
```
{
"metrics": [
[ "AWS/MediaPackage", "EgressResponseTime", "Channel", "YourChannelName", "Origin", "YourOriginEndpointName", { "stat": "Average", "period": 60 } ],
[ "AWS/MediaPackage", "EgressResponseTime", "Channel", "YourChannelName", "Origin", "YourOriginEndpointName", { "stat": "p90", "period": 60 } ],
[ "AWS/MediaPackage", "EgressResponseTime", "Channel", "YourChannelName", "Origin", "YourOriginEndpointName", { "stat": "p99", "period": 60 } ]
],
"view": "timeSeries",
"stacked": false,
"region": "us-west-2",
"title": "MSS Endpoint Latency",
"period": 300
}
```
1. **Egress tracking**:
```
{
"metrics": [
[ "AWS/MediaPackage", "EgressBytes", "Channel", "YourChannelName", "Origin", "YourOriginEndpointName", { "stat": "Sum", "period": 60 } ]
],
"view": "timeSeries",
"stacked": false,
"region": "us-west-2",
"title": "MSS Egress Bytes",
"period": 300
}
```
Replace `YourChannelName` and `YourOriginEndpointName` with your actual channel and endpoint names, and adjust the region as needed.
### Recommended CloudWatch alarms
Set up these Amazon CloudWatch alarms to proactively detect issues with your MSS streams:
High error rate alarm
Triggers when the percentage of 4xx or 5xx errors exceeds a threshold.
```
aws cloudwatch put-metric-alarm \
--alarm-name MSS_HighErrorRate \
--alarm-description "Alarm when MSS endpoint error rate exceeds 5%" \
--metrics '[
{
"Id": "e1",
"Expression": "(m2+m3)/m1*100",
"Label": "Error Rate"
},
{
"Id": "m1",
"MetricStat": {
"Metric": {
"Namespace": "AWS/MediaPackage",
"MetricName": "EgressRequestCount",
"Dimensions": [
{ "Name": "Channel", "Value": "YourChannelName" },
{ "Name": "Origin", "Value": "YourOriginEndpointName" }
]
},
"Period": 300,
"Stat": "Sum"
},
"ReturnData": false
},
{
"Id": "m2",
"MetricStat": {
"Metric": {
"Namespace": "AWS/MediaPackage",
"MetricName": "EgressRequestCount",
"Dimensions": [
{ "Name": "Channel", "Value": "YourChannelName" },
{ "Name": "Origin", "Value": "YourOriginEndpointName" },
{ "Name": "StatusCodeRange", "Value": "4xx" }
]
},
"Period": 300,
"Stat": "Sum"
},
"ReturnData": false
},
{
"Id": "m3",
"MetricStat": {
"Metric": {
"Namespace": "AWS/MediaPackage",
"MetricName": "EgressRequestCount",
"Dimensions": [
{ "Name": "Channel", "Value": "YourChannelName" },
{ "Name": "Origin", "Value": "YourOriginEndpointName" },
{ "Name": "StatusCodeRange", "Value": "5xx" }
]
},
"Period": 300,
"Stat": "Sum"
},
"ReturnData": false
}
]' \
--threshold 5 \
--comparison-operator GreaterThanThreshold \
--evaluation-periods 2 \
--alarm-actions [your-sns-topic-arn]
```
Latency spike alarm
Triggers when the average latency exceeds a threshold.
```
aws cloudwatch put-metric-alarm \
--alarm-name MSS_HighLatency \
--alarm-description "Alarm when MSS endpoint latency exceeds 500ms" \
--metric-name EgressResponseTime \
--namespace AWS/MediaPackage \
--statistic Average \
--period 300 \
--threshold 500 \
--comparison-operator GreaterThanThreshold \
--dimensions Name=Channel,Value=YourChannelName Name=Origin,Value=YourOriginEndpointName \
--evaluation-periods 3 \
--alarm-actions [your-sns-topic-arn]
```
Request drop alarm
Triggers when request count drops significantly, which could indicate delivery issues.
```
aws cloudwatch put-metric-alarm \
--alarm-name MSS_RequestDrop \
--alarm-description "Alarm when MSS requests drop by more than 50%" \
--metric-name EgressRequestCount \
--namespace AWS/MediaPackage \
--statistic Sum \
--period 300 \
--threshold 0 \
--comparison-operator LessThanThreshold \
--dimensions Name=Channel,Value=YourChannelName Name=Origin,Value=YourOriginEndpointName \
--evaluation-periods 2 \
--alarm-actions [your-sns-topic-arn] \
--treat-missing-data breaching
```
### Interpreting monitoring data
Understanding common patterns in your monitoring data can help you quickly identify and resolve issues:
Pattern: Spike in 404 errors
**Possible causes**:
+ Segment duration too short relative to the fixed 2-fragment lookahead buffer
+ Input stream interruption causing gaps in available segments
+ CDN cache configuration issues
**Recommended action**: Check input stream health, ensure segment duration works well with the fixed 2-fragment lookahead buffer, and review CDN cache settings.
Pattern: Increasing latency trend
**Possible causes**:
+ Growing audience size exceeding capacity
+ CDN origin shield not properly configured
+ Network congestion between CDN and origin
**Recommended action**: Review your CDN configuration, consider implementing or optimizing origin shield settings, and check for network bottlenecks.
Pattern: Cyclical spikes in request count
**Possible causes**:
+ Normal audience behavior patterns (e.g., primetime viewing)
+ CDN cache expiration causing request floods
**Recommended action**: If these align with expected audience patterns, this is normal. If not, review your CDN TTL settings to ensure they're appropriate for your content type.
For comprehensive information about MediaPackage monitoring capabilities, see [Logging and monitoring in MediaPackage](monitoring.md).
## Common MSS error codes
Understanding the specific HTTP error codes returned by MSS endpoints helps you diagnose and resolve issues more effectively:
404 Not Found
Occurs when the player requests a segment that cannot be found. This typically happens when the requested segment is not available or the URL is incorrect.
**Common causes**:
+ Player requesting segments beyond the available window
+ LookaheadCount settings causing segments to be held back
+ Input stream interruptions creating gaps in available content
412 Precondition Failed
Occurs when lookahead fragments are not available for the requested segment. This indicates that MediaPackage does not have the lookahead fragments internally available.
**Common causes**:
+ Player requesting segments too close to the live edge
+ Input stream issues preventing lookahead fragments from being generated
+ Network delays affecting fragment availability
403 Forbidden
Occurs when access to the requested resource is denied.
**Common causes**:
+ CDN authentication or authorization issues
+ Incorrect endpoint permissions or access policies
+ Geographic restrictions or IP blocking
5xx Server Errors
Indicates server-side issues with the MSS endpoint or underlying infrastructure.
**Common causes**:
+ Service capacity issues or overload
+ Backend service failures or timeouts
+ Configuration errors in the endpoint setup
## Using diagnostic tools to identify MSS issues
The following tools can help you troubleshoot MSS streaming issues:
+ Browser developer tools to inspect network requests and responses
+ Dash.js or Bitmovin player to verify playback and DRM functionality
+ Amazon CloudWatch to monitor endpoint metrics and logs
If you continue to experience issues with your MSS endpoints after trying these solutions, contact AWS Support for assistance.
# CDN configuration for MSS in AWS Elemental MediaPackage
CDN configuration for MSS
This topic explains how to configure your Content Delivery Network (CDN) to properly handle Microsoft Smooth Streaming (MSS) content from AWS Elemental MediaPackage.
## Optimizing cache settings for MSS delivery
Configure appropriate cache control headers for MSS content:
Live manifests
Set a short TTL (Time To Live) for live manifests, typically 5-10 seconds, to ensure viewers receive updated content.
Example: `Cache-Control: max-age=5`
VOD manifests
For video-on-demand content, you can set longer TTLs for manifests, typically 60 seconds or more.
Example: `Cache-Control: max-age=60`
Segments
Set longer TTLs for segments since they don't change once created.
Example: `Cache-Control: max-age=86400` (24 hours)
## MIME types for MSS content
Configure your CDN to serve MSS content with the correct MIME types:
MSS manifests
MIME type: `text/xml`
File pattern: `*.ism/Manifest`
MSS segments
MIME type: `video/mp4`
File pattern: `*Fragments*`
## Configuring your CDN for PlayReady DRM
If your MSS content is encrypted with PlayReady DRM:
+ Ensure your CDN passes through the PlayReady header in the manifest without modification
+ Configure your CDN to handle the proper CORS (Cross-Origin Resource Sharing) headers if your players require them
+ Verify that your CDN doesn't modify the encrypted segments in any way
For detailed information about MSS encryption and PlayReady DRM, see [MSS encryption and DRM in AWS Elemental MediaPackage](mss-encryption.md).
## Setting up Amazon CloudFront for MSS delivery
Amazon CloudFront (CloudFront) works well with MSS content from MediaPackage. To configure CloudFront for MSS:
1. Create a new CloudFront distribution or use an existing one
1. Set the origin to your MediaPackage endpoint domain
1. Configure cache behaviors with the appropriate TTLs for manifests and segments
1. If using DRM, ensure that CloudFront is configured to forward the necessary headers
Here's a real-world example of CloudFront configuration for MSS content:
**Example CloudFront configuration for a global MSS deployment**
A global media company delivering MSS content to legacy devices across multiple regions implemented the following CloudFront configuration:
+ **Origin settings**:
+ Origin domain: their MediaPackage endpoint domain
+ Origin protocol policy: Match viewer
+ Origin keep-alive timeout: 5 seconds
+ **Cache behavior for manifests (.ism/Manifest)**:
+ Path pattern: \$1.ism/Manifest
+ TTL settings: Minimum 0, Default 5, Maximum 10 (seconds)
+ Compress objects automatically: Yes
+ **Cache behavior for segments**:
+ Path pattern: \$1Fragments\$1
+ TTL settings: Minimum 3600, Default 86400, Maximum 604800 (seconds)
+ Compress objects automatically: No (to avoid modifying encrypted segments)
This configuration ensured that manifests were refreshed frequently while segments were cached for longer periods, optimizing both content freshness and CDN cost efficiency. The company also implemented regional price classes in CloudFront to balance performance and cost based on their audience distribution.
For Microsoft Smooth Streaming endpoints, you should create a cache behavior with the path pattern `out/v1/your-endpoint-id/index.ism/*` to properly route manifest requests.
For more information about using CloudFront with MediaPackage, see [Working with AWS Elemental MediaPackage and CDNs](cdns.md).