# Amazon IVS Streaming Configuration Streaming ConfigurationStreaming Configuration In "Encoder Settings > Stream Ingest: Codecs and Ingest Protocols > SRT," we added a link to information on configuring settings. In "Stream Takeover," we updated the URI for SRT streams.Streaming Configuration In "Audio Settings," specified a minimum bitrate, 96 Kbps.Streaming Configuration In "Channel Types," updated definitions of channel types. For `STANDARD` channels, resolution can be up to 1080p; for `BASIC` channels, 480p. (The prior definitions were only in terms of vertical resolution.)Streaming Configuration Renamed the Encoder Configuration page to Streaming Configuration.Streaming Configuration Several changes, including adding [Reducing Latency](https://docs.aws.amazon.com//ivs/latest/LowLatencyUserGuide/streaming-config.html#streaming-config-reducing-latency) subsection on “Avoid Third-Party Streaming/Forwarding Services” and clarifying why we strongly recommend [CBR](https://docs.aws.amazon.com//ivs/latest/LowLatencyUserGuide/streaming-config.html#streaming-config-settings-cbr) over VBR. Amazon Interactive Video Service (IVS) allows developers to easily deliver low-latency video to viewers worldwide. With Amazon IVS, streamers need to handle only stream production, then send the stream to Amazon IVS. Amazon IVS handles video processing (ingesting and transcoding), delivery, and playback to viewers using the Amazon IVS player. There is a wealth of solutions for live streaming. Whether you have a studio equipped with multiple cameras, visual switchers, graphics compositing, and a variety of audio mixing equipment, or you plan to start your first stream off a smartphone, you need to deal with some of the same concepts and encoding parameters. This document describes how to configure video encoders to stream to Amazon IVS. The audience for this document is developers who want to build streaming functionality into their applications. Note that audio-only input is not supported for IVS low-latency streaming. ## Prerequisites Follow the steps in [Getting Started with IVS Low-Latency Streaming](getting-started.md), to create a channel and set up streaming. In the process, a channel ARN (Amazon Resource Name) and stream key are assigned, along with URLs for ingesting and playing back a stream. You will need to point your streaming application to the ingest URL. Before reading this document, you should be familiar with: + Amazon IVS basics: Read [What is IVS Low-Latency Streaming](what-is.md) and [Getting Started with IVS Low-Latency Streaming](getting-started.md) + Amazon IVS API: Understand the [IVS Low-Latency Streaming API Reference](https://docs.aws.amazon.com/ivs/latest/LowLatencyAPIReference/Welcome.html). ## Reducing Latency Amazon IVS low-latency streaming is compatible with most streaming applications and requires only minor changes to your streaming-application configuration. For the lowest possible latency, you must use the Amazon IVS player; third-party HLS video players are not supported. See the Amazon IVS Player SDK documentation. To prepare your streaming application for low-latency streaming, do the following. (Note: not all these options are available on every streaming application.) + On the video encoder, set `IDR/Keyframe` to a 2-second interval (or 1 second, for even lower end-to-end latency). `IDR/Keyframe` directly affects the timing of stream startup and the latency of related EventBridge events (Stream Start and Recording Start). If `IDR/Keyframe` is 2 seconds, stream-start latency will be approximately 6-7 seconds. If `IDR/Keyframe` is 1 second, stream-start latency will be approximately 3-4 seconds. Your video will be available for viewers and auto-recording to Amazon S3 only after the initial stream-start latency period. The shorter, 1-second keyframe interval has some QoS tradeoffs. It can cause the Amazon IVS Player’s adaptive bitrate streaming (ABR) to switch resolution more often; the segment size is smaller, so the ABR check happens more often. Buffering may increase due to increased resolution-switching and/or if the viewer’s network cannot download the segments fast enough. Evaluate these tradeoffs when deciding between a 1- or 2-second keyframe interval. Avoid setting `IDR/Keyframe` to values higher than 5 seconds. Not only will the stream-start latency be higher than when using 1 or 2 seconds, but IVS will be unable to guarantee that every segment generated for playback will begin with an IDR/keyframe. Segments not beginning with an IDR/keyframe may result in decode errors or visual distortions when viewers start playback or change renditions. + If available, set your encoder to zero-latency tuning within an x264 configuration. + Ensure that buffer size (VBV) does not exceed the average bitrate (kilobits-per-second) of the stream. ### Avoid Third-Party Streaming/Forwarding Services We strongly recommend you do not use third-party service to restream or forward content to Amazon IVS. *This will incur extra latency.* For low latency, stream directly to Amazon IVS. ## Encoder Settings ### Stream Ingest: Codecs and Ingest Protocols **Codecs**: Amazon IVS supports H.264 for video and AAC (LC) for audio. **Ingest protocols**: Amazon IVS supports the most common ingest protocols used in streaming software and hardware: RTMPS (Real-Time Messaging Protocol over a TLS/SSL connection), RTMP, and SRT (Secure Reliable Transport). Amazon IVS streaming through RTMPS requires TLS version 1.2 or later. #### RTMPS/RTMP Your video encoder must connect to Amazon IVS ingest over the RTMPS protocol associated with outbound port 443/TCP. To ensure this, specify an IVS ingest server, which includes the port in the path: `rtmps:///` For example: `rtmps://a1b2c3d4e5f6.global-contribute.live-video.net:443/app/` IVS channels also can be configured to allow insecure RTMP ingest, though we recommend that you use RTMPS unless you have specific and verified use cases that require RTMP. When streaming RTMP, ensure that the protocol is set to `rtmp://` and remove the `:443` port. For example: `rtmp://a1b2c3d4e5f6.global-contribute.live-video.net/app/` #### SRT Your video encoder must connect to the ingest endpoint using the SRT protocol at port 9000. To ensure this, specify an ingest endpoint, which includes the port and passphrase in the path: `srt://:?streamid=&passphrase=` Use a passphrase only if insecure ingest is not enabled for the channel. For example: `srt://a1b2c3d4e5f6.srt.live-video.net:9000?streamid=sk_us-west-2_abcd1234efgh5678ijkl&passphrase=ZU5A3yrjGAkghUNDr0c5NXBhsPrjlmtcKMNBluh7oImwJQ3ijeyClvMKxlpPcGAMziICJ` To optimize SRT stream performance, see this Haivision blog: [How to Configure SRT Settings on Your Video Encoder for Optimal Performance.](https://www.haivision.com/blog/all/how-to-configure-srt-settings-video-encoder-optimal-performance/) ### Resolution/Bitrate/FPS The stream’s resolution largely determines its bitrate and frame rate (frames-per-second, or FPS). Use the following guidelines; these are our recommendations. Note the resolutions shown below are landscape orientation (horizontal x vertical), so reverse these for portrait orientation. | | Acceptable Quality (SD) 480p (852x480) | Good Quality (HD) 720p (1280x720) | High Quality (Full HD) 1080p (1920x1080) | | --- | --- | --- | --- | | Bitrate | Up to 1500 Kbps | Up to 4500 Kbps | Up to 8500 Kbps | | FPS | 30 | 30 or 60 | 30 or 60 | | Keyframe interval | 2 seconds | 2 seconds | 2 seconds | Bitrate, FPS, and resolution are interrelated. The optimal values depend on circumstances and can be complicated to determine. Our best guidance is to start with the values above and experiment if desired. The goal is clear and smooth motion of video components during streaming and good resolution within the available bandwidth. Increasing frame rate and/or resolution increases overall video quality, but this is necessarily limited by bandwidth. Amazon IVS supports framerates up to 60 FPS (including European PAL 25 and 50 standard frame rates). The higher the framerate, the better the quality -- as long as there is adequate bitrate bandwidth. Depending on the application, a low framerate can be fine; e.g., for a security camera. ### Channel Types Streaming Configuration For the `STANDARD` channel type, added a note that audio is transcoded only for renditions 360p and below; above that, audio is passed through. Channel type determines the allowable resolution and bitrate. *If you exceed the allowable input resolution or bitrate, the stream probably will disconnect immediately*. There are four channel types: `STANDARD`, `ADVANCED_SD`, `ADVANCED_HD`, and `BASIC`. When you create a channel, the default type is `STANDARD`. There are two types of video processing, *transcoding* and *transmuxing*. This is determined by the channel type, whether the channel is configured for multitrack video input, and whether the broadcaster uses a multitrack-enabled client. (Multitrack video is configured with the `multitrackInputConfiguration` API property of the [Channel](https://docs.aws.amazon.com//ivs/latest/LowLatencyAPIReference/API_Channel.html) data type.) + Video on `STANDARD` (without multitrack input) and `ADVANCED` channels is transcoded: multiple qualities are generated from the original input, to automatically give viewers the best experience for their devices and network conditions. Transcoding allows higher playback quality across a range of download speeds. Transcoding is the best option for broadcasters with limited first-mile internet connectivity and/or limited device capabilities (e.g., mobile phones instead of desktop PCs). + Video on `STANDARD` (with multitrack input enabled and the broadcaster using a multitrack-enabled client) and `BASIC` channels is transmuxed: Amazon IVS delivers the original input to viewers. Similar to transcoding, transmuxed multitrack input delivers viewers the best experience for their devices and network conditions. All transcoded channels have *transcode* presets, which determine which renditions are produced. Think of these as ABR ladders. They allow you to trade off available download bandwidth and video quality, to optimize the viewing experience. + `STANDARD` channels have one, default transcode preset. + `ADVANCED` channels have two, selectable transcode presets: + *Constrained bandwidth delivery* uses a lower bitrate than `STANDARD` for each quality level. Use it if you have low download bandwidth and/or simple video content (e.g., talking heads). + *Higher bandwidth delivery* uses a higher bitrate for each uality level. Use it if you have high download bandwidth and/or complex ideo content (e.g., flashes and quick scene changes). This is the default. #### STANDARD Channels ##### Single-Track Video Input `STANDARD` channels are transcoded. The highest video resolution produced is full HD, 1080p. This is the default channel type. + **Transcode presets**: There is one, default transcode-preset ladder. + **Audio**: For renditions 360p and below, audio is transcoded. For other renditions, original audio is passed through. | Input Resolution and Maximum Bitrate | Ladder Details | | --- | --- | | 1080p60 at 8.5 Mbps | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ivs/latest/LowLatencyUserGuide/streaming-config.html) | | 1080p30 at 8.5 Mbps | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ivs/latest/LowLatencyUserGuide/streaming-config.html) | | Less than 1080p60 and greater than 720p60, at 8.5 Mbps | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ivs/latest/LowLatencyUserGuide/streaming-config.html) | | Less than 1080p30 and greater than 720p30, at 8.5 Mbps | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ivs/latest/LowLatencyUserGuide/streaming-config.html) | | 720p60 at 8.5 Mbps | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ivs/latest/LowLatencyUserGuide/streaming-config.html) | | 720p30 at 8.5 Mbps | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ivs/latest/LowLatencyUserGuide/streaming-config.html) | | Less than 720p30/60 and greater than or equal to 480p30/60, at 8.5 Mbps | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ivs/latest/LowLatencyUserGuide/streaming-config.html) | ##### Multitrack Video Input `STANDARD` channels are transmuxed when the input is multitrack video. The highest video resolution produced is limited by the `multitrackInputConfiguration.maximumResolution` property. The specific renditions are dynamic depending on the [broadcaster’s system and environmental requirements](https://docs.aws.amazon.com//ivs/latest/LowLatencyUserGuide/multitrack-video-setup.html#multitrack-video-setup-broadcaster-system). For all video renditions, audio is source passthrough. #### ADVANCED-HD Channels `ADVANCED-HD` channels are transcoded. The highest video resolution produced is HD, 720p. + **Transcode presets**: There are two, selectable transcode-preset ladders. + **Audio**: Audio is transcoded. | Input Resolution and Maximum Bitrate | Ladder Details | | --- | --- | | 720p60 up to 1080p60, at 8.5 Mbps | Transcode preset: higher bandwidth delivery (default): [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ivs/latest/LowLatencyUserGuide/streaming-config.html) Transcode preset: constrained bandwidth delivery: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ivs/latest/LowLatencyUserGuide/streaming-config.html) | | 720p30 up to 1080p30, at 8.5 Mbps | Transcode preset: higher bandwidth delivery (default): [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ivs/latest/LowLatencyUserGuide/streaming-config.html) Transcode preset: constrained bandwidth delivery: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ivs/latest/LowLatencyUserGuide/streaming-config.html) | | Less than 720p30/60 and greater than 480p30/60, at 8.5 Mbps | Transcode preset: higher bandwidth delivery (default): [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ivs/latest/LowLatencyUserGuide/streaming-config.html) Transcode preset: constrained bandwidth delivery: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ivs/latest/LowLatencyUserGuide/streaming-config.html) | | 480p30/60 at 8.5 Mbps | Transcode preset: higher bandwidth delivery (default): [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ivs/latest/LowLatencyUserGuide/streaming-config.html) Transcode preset: constrained bandwidth delivery: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ivs/latest/LowLatencyUserGuide/streaming-config.html) | #### ADVANCED-SD Channels `ADVANCED-SD` channels are transcoded. Available renditions are capped at input quality, with no up-conversion. + **Transcode presets**: There are two, selectable transcode-preset ladders. + **Audio**: Audio is transcoded. | Input Resolution and Maximum Bitrate | Ladder Details | | --- | --- | | 480p30/60 up to 1080p30/60, at 8.5 Mbps | Transcode preset: higher bandwidth delivery (default): [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ivs/latest/LowLatencyUserGuide/streaming-config.html) Transcode preset: constrained bandwidth delivery: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ivs/latest/LowLatencyUserGuide/streaming-config.html) | #### BASIC Channels `BASIC` channels are transmuxed. A single rendition is produced. + **Transcode presets**: NA + **Audio**: Source audio is passed through. | Input Resolution and Maximum Bitrate | Ladder Details | | --- | --- | | Greater than 480p30/60 and less than or equal to 1080p30/60, at 3.5 Mbps | Source encoding parameters (no ladder) | | 480p30/60 at 1.5 Mbps | Source encoding parameters (no ladder) | ### Video Settings We recommend the following settings. They are available to most H.264 video-encoding software or hardware APIs. + On the video encoder, set `IDR/Keyframe` to a 2-second interval (or 1 second, for even lower end-to-end latency). + H.264 level: Main + Scene change: Off (preferred) + Chroma subsample: YUV420P + CABAC: Preferred + ColorSpace: BT.709 (recommended for maximum compatibility across HDTVs and computer displays). Amazon IVS video transcoding supports ColorSpace pass-through; advanced users can use other ColorSpace video and full-range video. ### Audio Settings Streaming Configuration In "Audio Settings," changed the supported bitrate to 320 Kpbs (from 192).Streaming Configuration Changed the codec audio setting from AAC to AAC (LC). We support the following settings: + Codec: AAC (LC) + Bitrate: 96 Kbps to 320 Kbps + Sample rate: 44.1 Khz or 48 Khz (it is best to match your production audio flow) + Channels: Maximum 2 - Stereo (1: mono or 2: stereo audio channel support) ### Use CBR, Not VBR Always use CBR (Constant BitRate), not VBR (Variable BitRate), as the rate-control method for encoders. CBR is better suited for the fixed-bandwidth nature of networks, and it produces more predictable, stable video playback for client devices. With a consistent bitrate, it is easy for viewers to select a quality level that their connection can handle over time. Depending on the complexity of the scene, VBR can result in spikes in bitrate, which can cause frame drops before the video reaches Amazon IVS and/or buffering in client players. *We strongly recommend you only use CBR.* If you use VBR, your streams will be more subject to buffering and playback that is not smooth. ### Use Progressive Signals **Use progressive signal flows; avoid any interlaced video in production flow and/or encoding.** Progressive stream signals yield much better playback quality displaying a whole frame at a time, avoiding any motion artifacting that is produced when displaying an interlaced signal. ## Network Requirements You must have a stable internet connection that can maintain an adequate, constant upload stream. An unstable internet connection could result in stream stuttering and lagging for your viewers. **Use wired connections.** WiFi and LTE connections can be spotty or suffer from interference or latency due to bad QoS/packet-queue prioritization. Whenever possible, rely on a hardwired connection for streams. Plan to allocate 50% more bandwidth than the minimum required. The overhead is added to compensate for the bitrate fluctuations in encoding of a video bitstream. Use a dedicated Internet VLAN to encoding machines. Keeping the encoder on a separate network prevents potentially disruptive effects, including: pollution by traffic, bandwidth bottlenecks and adverse security factors. ## Closed Captioning Amazon IVS Streaming Configuration In "Closed Captioning," clarified that the Player SDKs support only 1 language, not multi-track captions playback. IVS supports closed captioning. As a streamer, if you want to offer captions to your audience, you must transmit caption data in an accepted format, either embedded in your stream or alongside your stream, through your video encoder. Amazon IVS accepts captions in line 21 CEA-708/EIA-608 format (also referred to as 608 over 708). You can transmit captions using one of the following methods: + CEA-708/EIA-608 embedded in the video elementary stream, as described in ATSC A/72 (SEI user\$1data). This format is common among television broadcast encoders. + CEA-708/EIA-608 transmitted via RTMPS onCaptionInfo script/AMF0 tag. This format is common among Internet broadcast encoders and media servers like Elemental Technologies and Wowza. The Amazon IVS Player SDKs support one language; they do not support multi-track captions playback. Note: The Amazon IVS Player SDKs support caption data only in the CC1 NTSC field 1. They do not support multi-track captions playback. When transmitting via RTMPS, the payload must contain an ECMA array with two element pairs: + A string named `type` that contains the characters `708`. + A string named `data` that contains a base64-encoded CEA-708/EIA-608 payload. For example: ``` 00000000 12 00 00 69 00 00 00 00 00 00 00 02 00 0d 6f 6e |...i..........on| 00000010 43 61 70 74 69 6f 6e 49 6e 66 6f 08 00 00 00 02 |CaptionInfo.....| 00000020 00 04 74 79 70 65 02 00 03 37 30 38 00 04 64 61 |..type...708..da| 00000030 74 61 02 00 3c 74 51 41 78 52 30 45 35 4e 41 4e |ta../ ``` + Video file — FFmpeg works with many video-file formats and capture cards. Here is an example of streaming based on a MP4 input: ``` ffmpeg -re -i input.mp4 -c:v libx264 -b:v 6000K -maxrate 6000K -pix_fmt yuv420p -s 1920x1080 -profile:v main -preset veryfast -force_key_frames expr:gte(t,n_forced*2) -x264opts "nal-hrd=cbr:no-scenecut” -acodec aac -ab 160k -ar 44100 -f flv rtmps:///app/ ``` For more information about what to enter for `` and ``, see the information about setting up live-streaming software in [Getting Started with IVS Low-Latency Streaming](getting-started.md). For example: + Ingest server: `rtmps://jds34ksdg3las.global-contribute.live-video.net/app/` + Stream key: `sk_us-west-2_abcd1234efgh5678ijkl` ## Stream Takeover Stream takeover allows a user to replace an ongoing stream on a channel they own with a new stream. During this process, the previous stream never disconnects, it is simply replaced by the new stream. This allows users to seamlessly connect to a new stream without having to wait until the ongoing stream disconnects entirely. The stream-takeover process extends an ongoing stream session but does not initiate a new one. This maintains stream continuity without requiring viewers to refresh the player, though they may experience a brief buffering state. There are no discontinuities in recordings of stream sessions during which a stream takeover occurs. To initiate a stream takeover, append the `priority` URL parameter to the user's stream key. The stream key becomes `?priority=`, where `` is a positive integer between 1 and 2,147,483,647. The URI syntax for using stream takeover with the RTMPS protocol is: ``` rtmps:///?priority=N ``` For SRT ingest, the URI syntax for stream takeover is: ``` srt://?streamid=#!::u=,priority=N&passphrase=foobar ``` A takeover succeeds if the priority integer provided for the new stream is greater than the priority integer for the ongoing stream, or if no previous priority integer was set. Also, the old and new stream must share the same resolution, video codec, audio codec, and number of tracks. By default, up to 100 takeovers can be done in a single stream, as long as a greater priority integer is used for each successive takeover. The maximum number of stream takeovers is adjustable per AWS account (see [ Service Quotas](https://docs.aws.amazon.com//ivs/latest/LowLatencyUserGuide/service-quotas.html#quotas-other)). Once the stream is over, the channel retains no memory of previous priority integers or how many takeovers were done, so any priority integer can be reused in future streams. Also, if encoder settings were changed for stream takeover, the stream session retains no memory of previous encoder settings, displaying only the latest settings. If the auto-reconnect feature is enabled, the IVS mobile broadcast SDKs use stream takeover to automatically reconnect when a broadcaster switches networks (for example, from WiFi to cellular). To enable auto-reconnect: + On iOS, set `config.autoReconnect.enabled = true` on your `IVSBroadcastConfiguration` object. + On Android, set `config.autoReconnect.setEnabled(true)` on your `BroadcastConfiguration` object. ### Considerations for Using Auto-Reconnect and Stream Takeover Together When mobile broadcast SDK customers enable auto-reconnect as described above, the ongoing streamer (Broadcaster A) will try to reconnect up to 5 times following a network disruption, starting with `priority=1` and incrementing the priority with each reconnect attempt. This process allows the broadcast to automatically recover on unstable networks by gradually increasing the priority with each successful reconnect. However, due to the incremental nature of the auto-reconnect behavior, it becomes challenging for another broadcaster (Broadcaster B) to successfully use stream takeover when the original broadcaster is using auto-reconnect. The priority value required to ensure a successful takeover will be unpredictable, as reconnect attempts by Broadcaster A increment the priority value with each retry over the stream duration. **Note: *** We do not recommend using stream takeover to override a stream from the mobile broadcast SDK when auto-reconnect is enabled*, as you will need to manage or keep a record of the priority required for takeover. While setting a large priority value may work initially, it could create challenges if another takeover is needed later. We recommend maintaining auto-reconnect for Broadcaster A during network instability and stream takeover by Broadcaster B as distinct use cases. ## Stream with the Amazon IVS Broadcast SDK Streaming Configuration For streaming from Android and iOS, replaced the information on Larix Broadcaster with a pointer to documentation on the Amazon IVS broadcast SDK. The Amazon IVS broadcast SDK is for developers who are building Android, iOS, or Web applications with Amazon IVS. See the broadcast SDK documentation in the *Amazon IVS User Guide*, starting [here](broadcast.md). There are subpages with guides for Android, iOS, and Web streaming. The broadcast SDKs enable you to customize bitrate, frame rate, and resolution. ## Testing the Stream **Always verify that your stream works.** Navigate to the video stream in the [Amazon IVS console](https://console.aws.amazon.com/ivs), to watch what is being streamed and manage the live stream.