* The name of the stream for which to retrieve the HLS master playlist URL. *
*
* You must specify either the StreamName or the StreamARN.
*
* The Amazon Resource Name (ARN) of the stream for which to retrieve the HLS master playlist URL. *
*
* You must specify either the StreamName or the StreamARN.
*
* Whether to retrieve live, live replay, or archived, on-demand data. *
** Features of the three types of sessions include the following: *
*
* LIVE : For sessions of this type, the HLS media playlist is continually updated with the
* latest fragments as they become available. We recommend that the media player retrieve a new playlist on a
* one-second interval. When this type of session is played in a media player, the user interface typically displays
* a "live" notification, with no scrubber control for choosing the position in the playback window to display.
*
* In LIVE mode, the newest available fragments are included in an HLS media playlist, even if there is
* a gap between fragments (that is, if a fragment is missing). A gap like this might cause a media player to halt
* or cause a jump in playback. In this mode, fragments are not added to the HLS media playlist if they are older
* than the newest fragment in the playlist. If the missing fragment becomes available after a subsequent fragment
* is added to the playlist, the older fragment is not added, and the gap is not filled.
*
* LIVE_REPLAY : For sessions of this type, the HLS media playlist is updated similarly to how
* it is updated for LIVE mode except that it starts by including fragments from a given start time.
* Instead of fragments being added as they are ingested, fragments are added as the duration of the next fragment
* elapses. For example, if the fragments in the session are two seconds long, then a new fragment is added to the
* media playlist every two seconds. This mode is useful to be able to start playback from when an event is detected
* and continue live streaming media that has not yet been ingested as of the time of the session creation. This
* mode is also useful to stream previously archived media without being limited by the 1,000 fragment limit in the
* ON_DEMAND mode.
*
* ON_DEMAND : For sessions of this type, the HLS media playlist contains all the fragments for
* the session, up to the number that is specified in MaxMediaPlaylistFragmentResults. The playlist
* must be retrieved only once for each session. When this type of session is played in a media player, the user
* interface typically displays a scrubber control for choosing the position in the playback window to display.
*
* In all playback modes, if FragmentSelectorType is PRODUCER_TIMESTAMP, and if there are
* multiple fragments with the same start timestamp, the fragment that has the largest fragment number (that is, the
* newest fragment) is included in the HLS media playlist. The other fragments are not included. Fragments that have
* different timestamps but have overlapping durations are still included in the HLS media playlist. This can lead
* to unexpected behavior in the media player.
*
* The default is LIVE.
*
* The time range of the requested fragment and the source of the timestamps. *
*
* This parameter is required if PlaybackMode is ON_DEMAND or LIVE_REPLAY.
* This parameter is optional if PlaybackMode is LIVE. If PlaybackMode is
* LIVE, the FragmentSelectorType can be set, but the TimestampRange should
* not be set. If PlaybackMode is ON_DEMAND or LIVE_REPLAY, both
* FragmentSelectorType and TimestampRange must be set.
*
* Specifies which format should be used for packaging the media. Specifying the FRAGMENTED_MP4
* container format packages the media into MP4 fragments (fMP4 or CMAF). This is the recommended packaging because
* there is minimal packaging overhead. The other container format option is MPEG_TS. HLS has supported
* MPEG TS chunks since it was released and is sometimes the only supported packaging on older HLS players. MPEG TS
* typically has a 5-25 percent packaging overhead. This means MPEG TS typically requires 5-25 percent more
* bandwidth and cost than fMP4.
*
* The default is FRAGMENTED_MP4.
*
* Specifies when flags marking discontinuities between fragments are added to the media playlists. *
*
* Media players typically build a timeline of media content to play, based on the timestamps of each fragment. This
* means that if there is any overlap or gap between fragments (as is typical if HLSFragmentSelector is set
* to SERVER_TIMESTAMP), the media player timeline will also have small gaps between fragments in some
* places, and will overwrite frames in other places. Gaps in the media player timeline can cause playback to stall
* and overlaps can cause playback to be jittery. When there are discontinuity flags between fragments, the media
* player is expected to reset the timeline, resulting in the next fragment being played immediately after the
* previous fragment.
*
* The following modes are supported: *
*
* ALWAYS: a discontinuity marker is placed between every fragment in the HLS media playlist. It is
* recommended to use a value of ALWAYS if the fragment timestamps are not accurate.
*
* NEVER: no discontinuity markers are placed anywhere. It is recommended to use a value of
* NEVER to ensure the media player timeline most accurately maps to the producer timestamps.
*
* ON_DISCONTINUITY: a discontinuity marker is placed between fragments that have a gap or overlap of
* more than 50 milliseconds. For most playback scenarios, it is recommended to use a value of
* ON_DISCONTINUITY so that the media player timeline is only reset when there is a significant issue
* with the media timeline (e.g. a missing fragment).
*
* The default is ALWAYS when HLSFragmentSelector is set to SERVER_TIMESTAMP, and
* NEVER when it is set to PRODUCER_TIMESTAMP.
*
* Specifies when the fragment start timestamps should be included in the HLS media playlist. Typically, media * players report the playhead position as a time relative to the start of the first fragment in the playback * session. However, when the start timestamps are included in the HLS media playlist, some media players might * report the current playhead as an absolute time based on the fragment timestamps. This can be useful for creating * a playback experience that shows viewers the wall-clock time of the media. *
*
* The default is NEVER. When HLSFragmentSelector is SERVER_TIMESTAMP, the
* timestamps will be the server start timestamps. Similarly, when HLSFragmentSelector is
* PRODUCER_TIMESTAMP, the timestamps will be the producer start timestamps.
*
* The time in seconds until the requested session expires. This value can be between 300 (5 minutes) and 43200 (12 * hours). *
*
* When a session expires, no new calls to GetHLSMasterPlaylist, GetHLSMediaPlaylist,
* GetMP4InitFragment, GetMP4MediaFragment, or GetTSFragment can be made for
* that session.
*
* The default is 300 (5 minutes). *
*/ private Integer expires; /** ** The maximum number of fragments that are returned in the HLS media playlists. *
*
* When the PlaybackMode is LIVE, the most recent fragments are returned up to this value.
* When the PlaybackMode is ON_DEMAND, the oldest fragments are returned, up to this
* maximum number.
*
* When there are a higher number of fragments available in a live HLS media playlist, video players often buffer * content before starting playback. Increasing the buffer size increases the playback latency, but it decreases the * likelihood that rebuffering will occur during playback. We recommend that a live HLS media playlist have a * minimum of 3 fragments and a maximum of 10 fragments. *
*
* The default is 5 fragments if PlaybackMode is LIVE or LIVE_REPLAY, and
* 1,000 if PlaybackMode is ON_DEMAND.
*
* The maximum value of 5,000 fragments corresponds to more than 80 minutes of video on streams with 1-second * fragments, and more than 13 hours of video on streams with 10-second fragments. *
*/ private Long maxMediaPlaylistFragmentResults; /** ** The name of the stream for which to retrieve the HLS master playlist URL. *
*
* You must specify either the StreamName or the StreamARN.
*
* You must specify either the StreamName or the StreamARN.
*/
public void setStreamName(String streamName) {
this.streamName = streamName;
}
/**
*
* The name of the stream for which to retrieve the HLS master playlist URL. *
*
* You must specify either the StreamName or the StreamARN.
*
* You must specify either the StreamName or the StreamARN.
*/
public String getStreamName() {
return this.streamName;
}
/**
*
* The name of the stream for which to retrieve the HLS master playlist URL. *
*
* You must specify either the StreamName or the StreamARN.
*
* You must specify either the StreamName or the StreamARN.
* @return Returns a reference to this object so that method calls can be chained together.
*/
public GetHLSStreamingSessionURLRequest withStreamName(String streamName) {
setStreamName(streamName);
return this;
}
/**
*
* The Amazon Resource Name (ARN) of the stream for which to retrieve the HLS master playlist URL. *
*
* You must specify either the StreamName or the StreamARN.
*
* You must specify either the StreamName or the StreamARN.
*/
public void setStreamARN(String streamARN) {
this.streamARN = streamARN;
}
/**
*
* The Amazon Resource Name (ARN) of the stream for which to retrieve the HLS master playlist URL. *
*
* You must specify either the StreamName or the StreamARN.
*
* You must specify either the StreamName or the StreamARN.
*/
public String getStreamARN() {
return this.streamARN;
}
/**
*
* The Amazon Resource Name (ARN) of the stream for which to retrieve the HLS master playlist URL. *
*
* You must specify either the StreamName or the StreamARN.
*
* You must specify either the StreamName or the StreamARN.
* @return Returns a reference to this object so that method calls can be chained together.
*/
public GetHLSStreamingSessionURLRequest withStreamARN(String streamARN) {
setStreamARN(streamARN);
return this;
}
/**
*
* Whether to retrieve live, live replay, or archived, on-demand data. *
** Features of the three types of sessions include the following: *
*
* LIVE : For sessions of this type, the HLS media playlist is continually updated with the
* latest fragments as they become available. We recommend that the media player retrieve a new playlist on a
* one-second interval. When this type of session is played in a media player, the user interface typically displays
* a "live" notification, with no scrubber control for choosing the position in the playback window to display.
*
* In LIVE mode, the newest available fragments are included in an HLS media playlist, even if there is
* a gap between fragments (that is, if a fragment is missing). A gap like this might cause a media player to halt
* or cause a jump in playback. In this mode, fragments are not added to the HLS media playlist if they are older
* than the newest fragment in the playlist. If the missing fragment becomes available after a subsequent fragment
* is added to the playlist, the older fragment is not added, and the gap is not filled.
*
* LIVE_REPLAY : For sessions of this type, the HLS media playlist is updated similarly to how
* it is updated for LIVE mode except that it starts by including fragments from a given start time.
* Instead of fragments being added as they are ingested, fragments are added as the duration of the next fragment
* elapses. For example, if the fragments in the session are two seconds long, then a new fragment is added to the
* media playlist every two seconds. This mode is useful to be able to start playback from when an event is detected
* and continue live streaming media that has not yet been ingested as of the time of the session creation. This
* mode is also useful to stream previously archived media without being limited by the 1,000 fragment limit in the
* ON_DEMAND mode.
*
* ON_DEMAND : For sessions of this type, the HLS media playlist contains all the fragments for
* the session, up to the number that is specified in MaxMediaPlaylistFragmentResults. The playlist
* must be retrieved only once for each session. When this type of session is played in a media player, the user
* interface typically displays a scrubber control for choosing the position in the playback window to display.
*
* In all playback modes, if FragmentSelectorType is PRODUCER_TIMESTAMP, and if there are
* multiple fragments with the same start timestamp, the fragment that has the largest fragment number (that is, the
* newest fragment) is included in the HLS media playlist. The other fragments are not included. Fragments that have
* different timestamps but have overlapping durations are still included in the HLS media playlist. This can lead
* to unexpected behavior in the media player.
*
* The default is LIVE.
*
* Features of the three types of sessions include the following: *
*
* LIVE : For sessions of this type, the HLS media playlist is continually updated with
* the latest fragments as they become available. We recommend that the media player retrieve a new playlist
* on a one-second interval. When this type of session is played in a media player, the user interface
* typically displays a "live" notification, with no scrubber control for choosing the position in the
* playback window to display.
*
* In LIVE mode, the newest available fragments are included in an HLS media playlist, even if
* there is a gap between fragments (that is, if a fragment is missing). A gap like this might cause a media
* player to halt or cause a jump in playback. In this mode, fragments are not added to the HLS media
* playlist if they are older than the newest fragment in the playlist. If the missing fragment becomes
* available after a subsequent fragment is added to the playlist, the older fragment is not added, and the
* gap is not filled.
*
* LIVE_REPLAY : For sessions of this type, the HLS media playlist is updated similarly
* to how it is updated for LIVE mode except that it starts by including fragments from a given
* start time. Instead of fragments being added as they are ingested, fragments are added as the duration of
* the next fragment elapses. For example, if the fragments in the session are two seconds long, then a new
* fragment is added to the media playlist every two seconds. This mode is useful to be able to start
* playback from when an event is detected and continue live streaming media that has not yet been ingested
* as of the time of the session creation. This mode is also useful to stream previously archived media
* without being limited by the 1,000 fragment limit in the ON_DEMAND mode.
*
* ON_DEMAND : For sessions of this type, the HLS media playlist contains all the
* fragments for the session, up to the number that is specified in
* MaxMediaPlaylistFragmentResults. The playlist must be retrieved only once for each session.
* When this type of session is played in a media player, the user interface typically displays a scrubber
* control for choosing the position in the playback window to display.
*
* In all playback modes, if FragmentSelectorType is PRODUCER_TIMESTAMP, and if
* there are multiple fragments with the same start timestamp, the fragment that has the largest fragment
* number (that is, the newest fragment) is included in the HLS media playlist. The other fragments are not
* included. Fragments that have different timestamps but have overlapping durations are still included in
* the HLS media playlist. This can lead to unexpected behavior in the media player.
*
* The default is LIVE.
* @see HLSPlaybackMode
*/
public void setPlaybackMode(String playbackMode) {
this.playbackMode = playbackMode;
}
/**
*
* Whether to retrieve live, live replay, or archived, on-demand data. *
** Features of the three types of sessions include the following: *
*
* LIVE : For sessions of this type, the HLS media playlist is continually updated with the
* latest fragments as they become available. We recommend that the media player retrieve a new playlist on a
* one-second interval. When this type of session is played in a media player, the user interface typically displays
* a "live" notification, with no scrubber control for choosing the position in the playback window to display.
*
* In LIVE mode, the newest available fragments are included in an HLS media playlist, even if there is
* a gap between fragments (that is, if a fragment is missing). A gap like this might cause a media player to halt
* or cause a jump in playback. In this mode, fragments are not added to the HLS media playlist if they are older
* than the newest fragment in the playlist. If the missing fragment becomes available after a subsequent fragment
* is added to the playlist, the older fragment is not added, and the gap is not filled.
*
* LIVE_REPLAY : For sessions of this type, the HLS media playlist is updated similarly to how
* it is updated for LIVE mode except that it starts by including fragments from a given start time.
* Instead of fragments being added as they are ingested, fragments are added as the duration of the next fragment
* elapses. For example, if the fragments in the session are two seconds long, then a new fragment is added to the
* media playlist every two seconds. This mode is useful to be able to start playback from when an event is detected
* and continue live streaming media that has not yet been ingested as of the time of the session creation. This
* mode is also useful to stream previously archived media without being limited by the 1,000 fragment limit in the
* ON_DEMAND mode.
*
* ON_DEMAND : For sessions of this type, the HLS media playlist contains all the fragments for
* the session, up to the number that is specified in MaxMediaPlaylistFragmentResults. The playlist
* must be retrieved only once for each session. When this type of session is played in a media player, the user
* interface typically displays a scrubber control for choosing the position in the playback window to display.
*
* In all playback modes, if FragmentSelectorType is PRODUCER_TIMESTAMP, and if there are
* multiple fragments with the same start timestamp, the fragment that has the largest fragment number (that is, the
* newest fragment) is included in the HLS media playlist. The other fragments are not included. Fragments that have
* different timestamps but have overlapping durations are still included in the HLS media playlist. This can lead
* to unexpected behavior in the media player.
*
* The default is LIVE.
*
* Features of the three types of sessions include the following: *
*
* LIVE : For sessions of this type, the HLS media playlist is continually updated with
* the latest fragments as they become available. We recommend that the media player retrieve a new playlist
* on a one-second interval. When this type of session is played in a media player, the user interface
* typically displays a "live" notification, with no scrubber control for choosing the position in the
* playback window to display.
*
* In LIVE mode, the newest available fragments are included in an HLS media playlist, even if
* there is a gap between fragments (that is, if a fragment is missing). A gap like this might cause a media
* player to halt or cause a jump in playback. In this mode, fragments are not added to the HLS media
* playlist if they are older than the newest fragment in the playlist. If the missing fragment becomes
* available after a subsequent fragment is added to the playlist, the older fragment is not added, and the
* gap is not filled.
*
* LIVE_REPLAY : For sessions of this type, the HLS media playlist is updated similarly
* to how it is updated for LIVE mode except that it starts by including fragments from a given
* start time. Instead of fragments being added as they are ingested, fragments are added as the duration of
* the next fragment elapses. For example, if the fragments in the session are two seconds long, then a new
* fragment is added to the media playlist every two seconds. This mode is useful to be able to start
* playback from when an event is detected and continue live streaming media that has not yet been ingested
* as of the time of the session creation. This mode is also useful to stream previously archived media
* without being limited by the 1,000 fragment limit in the ON_DEMAND mode.
*
* ON_DEMAND : For sessions of this type, the HLS media playlist contains all the
* fragments for the session, up to the number that is specified in
* MaxMediaPlaylistFragmentResults. The playlist must be retrieved only once for each session.
* When this type of session is played in a media player, the user interface typically displays a scrubber
* control for choosing the position in the playback window to display.
*
* In all playback modes, if FragmentSelectorType is PRODUCER_TIMESTAMP, and if
* there are multiple fragments with the same start timestamp, the fragment that has the largest fragment
* number (that is, the newest fragment) is included in the HLS media playlist. The other fragments are not
* included. Fragments that have different timestamps but have overlapping durations are still included in
* the HLS media playlist. This can lead to unexpected behavior in the media player.
*
* The default is LIVE.
* @see HLSPlaybackMode
*/
public String getPlaybackMode() {
return this.playbackMode;
}
/**
*
* Whether to retrieve live, live replay, or archived, on-demand data. *
** Features of the three types of sessions include the following: *
*
* LIVE : For sessions of this type, the HLS media playlist is continually updated with the
* latest fragments as they become available. We recommend that the media player retrieve a new playlist on a
* one-second interval. When this type of session is played in a media player, the user interface typically displays
* a "live" notification, with no scrubber control for choosing the position in the playback window to display.
*
* In LIVE mode, the newest available fragments are included in an HLS media playlist, even if there is
* a gap between fragments (that is, if a fragment is missing). A gap like this might cause a media player to halt
* or cause a jump in playback. In this mode, fragments are not added to the HLS media playlist if they are older
* than the newest fragment in the playlist. If the missing fragment becomes available after a subsequent fragment
* is added to the playlist, the older fragment is not added, and the gap is not filled.
*
* LIVE_REPLAY : For sessions of this type, the HLS media playlist is updated similarly to how
* it is updated for LIVE mode except that it starts by including fragments from a given start time.
* Instead of fragments being added as they are ingested, fragments are added as the duration of the next fragment
* elapses. For example, if the fragments in the session are two seconds long, then a new fragment is added to the
* media playlist every two seconds. This mode is useful to be able to start playback from when an event is detected
* and continue live streaming media that has not yet been ingested as of the time of the session creation. This
* mode is also useful to stream previously archived media without being limited by the 1,000 fragment limit in the
* ON_DEMAND mode.
*
* ON_DEMAND : For sessions of this type, the HLS media playlist contains all the fragments for
* the session, up to the number that is specified in MaxMediaPlaylistFragmentResults. The playlist
* must be retrieved only once for each session. When this type of session is played in a media player, the user
* interface typically displays a scrubber control for choosing the position in the playback window to display.
*
* In all playback modes, if FragmentSelectorType is PRODUCER_TIMESTAMP, and if there are
* multiple fragments with the same start timestamp, the fragment that has the largest fragment number (that is, the
* newest fragment) is included in the HLS media playlist. The other fragments are not included. Fragments that have
* different timestamps but have overlapping durations are still included in the HLS media playlist. This can lead
* to unexpected behavior in the media player.
*
* The default is LIVE.
*
* Features of the three types of sessions include the following: *
*
* LIVE : For sessions of this type, the HLS media playlist is continually updated with
* the latest fragments as they become available. We recommend that the media player retrieve a new playlist
* on a one-second interval. When this type of session is played in a media player, the user interface
* typically displays a "live" notification, with no scrubber control for choosing the position in the
* playback window to display.
*
* In LIVE mode, the newest available fragments are included in an HLS media playlist, even if
* there is a gap between fragments (that is, if a fragment is missing). A gap like this might cause a media
* player to halt or cause a jump in playback. In this mode, fragments are not added to the HLS media
* playlist if they are older than the newest fragment in the playlist. If the missing fragment becomes
* available after a subsequent fragment is added to the playlist, the older fragment is not added, and the
* gap is not filled.
*
* LIVE_REPLAY : For sessions of this type, the HLS media playlist is updated similarly
* to how it is updated for LIVE mode except that it starts by including fragments from a given
* start time. Instead of fragments being added as they are ingested, fragments are added as the duration of
* the next fragment elapses. For example, if the fragments in the session are two seconds long, then a new
* fragment is added to the media playlist every two seconds. This mode is useful to be able to start
* playback from when an event is detected and continue live streaming media that has not yet been ingested
* as of the time of the session creation. This mode is also useful to stream previously archived media
* without being limited by the 1,000 fragment limit in the ON_DEMAND mode.
*
* ON_DEMAND : For sessions of this type, the HLS media playlist contains all the
* fragments for the session, up to the number that is specified in
* MaxMediaPlaylistFragmentResults. The playlist must be retrieved only once for each session.
* When this type of session is played in a media player, the user interface typically displays a scrubber
* control for choosing the position in the playback window to display.
*
* In all playback modes, if FragmentSelectorType is PRODUCER_TIMESTAMP, and if
* there are multiple fragments with the same start timestamp, the fragment that has the largest fragment
* number (that is, the newest fragment) is included in the HLS media playlist. The other fragments are not
* included. Fragments that have different timestamps but have overlapping durations are still included in
* the HLS media playlist. This can lead to unexpected behavior in the media player.
*
* The default is LIVE.
* @return Returns a reference to this object so that method calls can be chained together.
* @see HLSPlaybackMode
*/
public GetHLSStreamingSessionURLRequest withPlaybackMode(String playbackMode) {
setPlaybackMode(playbackMode);
return this;
}
/**
*
* Whether to retrieve live, live replay, or archived, on-demand data. *
** Features of the three types of sessions include the following: *
*
* LIVE : For sessions of this type, the HLS media playlist is continually updated with the
* latest fragments as they become available. We recommend that the media player retrieve a new playlist on a
* one-second interval. When this type of session is played in a media player, the user interface typically displays
* a "live" notification, with no scrubber control for choosing the position in the playback window to display.
*
* In LIVE mode, the newest available fragments are included in an HLS media playlist, even if there is
* a gap between fragments (that is, if a fragment is missing). A gap like this might cause a media player to halt
* or cause a jump in playback. In this mode, fragments are not added to the HLS media playlist if they are older
* than the newest fragment in the playlist. If the missing fragment becomes available after a subsequent fragment
* is added to the playlist, the older fragment is not added, and the gap is not filled.
*
* LIVE_REPLAY : For sessions of this type, the HLS media playlist is updated similarly to how
* it is updated for LIVE mode except that it starts by including fragments from a given start time.
* Instead of fragments being added as they are ingested, fragments are added as the duration of the next fragment
* elapses. For example, if the fragments in the session are two seconds long, then a new fragment is added to the
* media playlist every two seconds. This mode is useful to be able to start playback from when an event is detected
* and continue live streaming media that has not yet been ingested as of the time of the session creation. This
* mode is also useful to stream previously archived media without being limited by the 1,000 fragment limit in the
* ON_DEMAND mode.
*
* ON_DEMAND : For sessions of this type, the HLS media playlist contains all the fragments for
* the session, up to the number that is specified in MaxMediaPlaylistFragmentResults. The playlist
* must be retrieved only once for each session. When this type of session is played in a media player, the user
* interface typically displays a scrubber control for choosing the position in the playback window to display.
*
* In all playback modes, if FragmentSelectorType is PRODUCER_TIMESTAMP, and if there are
* multiple fragments with the same start timestamp, the fragment that has the largest fragment number (that is, the
* newest fragment) is included in the HLS media playlist. The other fragments are not included. Fragments that have
* different timestamps but have overlapping durations are still included in the HLS media playlist. This can lead
* to unexpected behavior in the media player.
*
* The default is LIVE.
*
* Features of the three types of sessions include the following: *
*
* LIVE : For sessions of this type, the HLS media playlist is continually updated with
* the latest fragments as they become available. We recommend that the media player retrieve a new playlist
* on a one-second interval. When this type of session is played in a media player, the user interface
* typically displays a "live" notification, with no scrubber control for choosing the position in the
* playback window to display.
*
* In LIVE mode, the newest available fragments are included in an HLS media playlist, even if
* there is a gap between fragments (that is, if a fragment is missing). A gap like this might cause a media
* player to halt or cause a jump in playback. In this mode, fragments are not added to the HLS media
* playlist if they are older than the newest fragment in the playlist. If the missing fragment becomes
* available after a subsequent fragment is added to the playlist, the older fragment is not added, and the
* gap is not filled.
*
* LIVE_REPLAY : For sessions of this type, the HLS media playlist is updated similarly
* to how it is updated for LIVE mode except that it starts by including fragments from a given
* start time. Instead of fragments being added as they are ingested, fragments are added as the duration of
* the next fragment elapses. For example, if the fragments in the session are two seconds long, then a new
* fragment is added to the media playlist every two seconds. This mode is useful to be able to start
* playback from when an event is detected and continue live streaming media that has not yet been ingested
* as of the time of the session creation. This mode is also useful to stream previously archived media
* without being limited by the 1,000 fragment limit in the ON_DEMAND mode.
*
* ON_DEMAND : For sessions of this type, the HLS media playlist contains all the
* fragments for the session, up to the number that is specified in
* MaxMediaPlaylistFragmentResults. The playlist must be retrieved only once for each session.
* When this type of session is played in a media player, the user interface typically displays a scrubber
* control for choosing the position in the playback window to display.
*
* In all playback modes, if FragmentSelectorType is PRODUCER_TIMESTAMP, and if
* there are multiple fragments with the same start timestamp, the fragment that has the largest fragment
* number (that is, the newest fragment) is included in the HLS media playlist. The other fragments are not
* included. Fragments that have different timestamps but have overlapping durations are still included in
* the HLS media playlist. This can lead to unexpected behavior in the media player.
*
* The default is LIVE.
* @return Returns a reference to this object so that method calls can be chained together.
* @see HLSPlaybackMode
*/
public GetHLSStreamingSessionURLRequest withPlaybackMode(HLSPlaybackMode playbackMode) {
this.playbackMode = playbackMode.toString();
return this;
}
/**
*
* The time range of the requested fragment and the source of the timestamps. *
*
* This parameter is required if PlaybackMode is ON_DEMAND or LIVE_REPLAY.
* This parameter is optional if PlaybackMode is LIVE. If PlaybackMode is
* LIVE, the FragmentSelectorType can be set, but the TimestampRange should
* not be set. If PlaybackMode is ON_DEMAND or LIVE_REPLAY, both
* FragmentSelectorType and TimestampRange must be set.
*
* This parameter is required if PlaybackMode is ON_DEMAND or
* LIVE_REPLAY. This parameter is optional if PlaybackMode is LIVE. If
* PlaybackMode is LIVE, the FragmentSelectorType can be set, but the
* TimestampRange should not be set. If PlaybackMode is ON_DEMAND or
* LIVE_REPLAY, both FragmentSelectorType and TimestampRange must be
* set.
*/
public void setHLSFragmentSelector(HLSFragmentSelector hLSFragmentSelector) {
this.hLSFragmentSelector = hLSFragmentSelector;
}
/**
*
* The time range of the requested fragment and the source of the timestamps. *
*
* This parameter is required if PlaybackMode is ON_DEMAND or LIVE_REPLAY.
* This parameter is optional if PlaybackMode is LIVE. If PlaybackMode is
* LIVE, the FragmentSelectorType can be set, but the TimestampRange should
* not be set. If PlaybackMode is ON_DEMAND or LIVE_REPLAY, both
* FragmentSelectorType and TimestampRange must be set.
*
* This parameter is required if PlaybackMode is ON_DEMAND or
* LIVE_REPLAY. This parameter is optional if PlaybackMode is LIVE. If
* PlaybackMode is LIVE, the FragmentSelectorType can be set, but the
* TimestampRange should not be set. If PlaybackMode is ON_DEMAND or
* LIVE_REPLAY, both FragmentSelectorType and TimestampRange must be
* set.
*/
public HLSFragmentSelector getHLSFragmentSelector() {
return this.hLSFragmentSelector;
}
/**
*
* The time range of the requested fragment and the source of the timestamps. *
*
* This parameter is required if PlaybackMode is ON_DEMAND or LIVE_REPLAY.
* This parameter is optional if PlaybackMode is LIVE. If PlaybackMode is
* LIVE, the FragmentSelectorType can be set, but the TimestampRange should
* not be set. If PlaybackMode is ON_DEMAND or LIVE_REPLAY, both
* FragmentSelectorType and TimestampRange must be set.
*
* This parameter is required if PlaybackMode is ON_DEMAND or
* LIVE_REPLAY. This parameter is optional if PlaybackMode is LIVE. If
* PlaybackMode is LIVE, the FragmentSelectorType can be set, but the
* TimestampRange should not be set. If PlaybackMode is ON_DEMAND or
* LIVE_REPLAY, both FragmentSelectorType and TimestampRange must be
* set.
* @return Returns a reference to this object so that method calls can be chained together.
*/
public GetHLSStreamingSessionURLRequest withHLSFragmentSelector(HLSFragmentSelector hLSFragmentSelector) {
setHLSFragmentSelector(hLSFragmentSelector);
return this;
}
/**
*
* Specifies which format should be used for packaging the media. Specifying the FRAGMENTED_MP4
* container format packages the media into MP4 fragments (fMP4 or CMAF). This is the recommended packaging because
* there is minimal packaging overhead. The other container format option is MPEG_TS. HLS has supported
* MPEG TS chunks since it was released and is sometimes the only supported packaging on older HLS players. MPEG TS
* typically has a 5-25 percent packaging overhead. This means MPEG TS typically requires 5-25 percent more
* bandwidth and cost than fMP4.
*
* The default is FRAGMENTED_MP4.
*
FRAGMENTED_MP4
* container format packages the media into MP4 fragments (fMP4 or CMAF). This is the recommended packaging
* because there is minimal packaging overhead. The other container format option is MPEG_TS.
* HLS has supported MPEG TS chunks since it was released and is sometimes the only supported packaging on
* older HLS players. MPEG TS typically has a 5-25 percent packaging overhead. This means MPEG TS typically
* requires 5-25 percent more bandwidth and cost than fMP4.
*
* The default is FRAGMENTED_MP4.
* @see ContainerFormat
*/
public void setContainerFormat(String containerFormat) {
this.containerFormat = containerFormat;
}
/**
*
* Specifies which format should be used for packaging the media. Specifying the FRAGMENTED_MP4
* container format packages the media into MP4 fragments (fMP4 or CMAF). This is the recommended packaging because
* there is minimal packaging overhead. The other container format option is MPEG_TS. HLS has supported
* MPEG TS chunks since it was released and is sometimes the only supported packaging on older HLS players. MPEG TS
* typically has a 5-25 percent packaging overhead. This means MPEG TS typically requires 5-25 percent more
* bandwidth and cost than fMP4.
*
* The default is FRAGMENTED_MP4.
*
FRAGMENTED_MP4
* container format packages the media into MP4 fragments (fMP4 or CMAF). This is the recommended packaging
* because there is minimal packaging overhead. The other container format option is MPEG_TS.
* HLS has supported MPEG TS chunks since it was released and is sometimes the only supported packaging on
* older HLS players. MPEG TS typically has a 5-25 percent packaging overhead. This means MPEG TS typically
* requires 5-25 percent more bandwidth and cost than fMP4.
*
* The default is FRAGMENTED_MP4.
* @see ContainerFormat
*/
public String getContainerFormat() {
return this.containerFormat;
}
/**
*
* Specifies which format should be used for packaging the media. Specifying the FRAGMENTED_MP4
* container format packages the media into MP4 fragments (fMP4 or CMAF). This is the recommended packaging because
* there is minimal packaging overhead. The other container format option is MPEG_TS. HLS has supported
* MPEG TS chunks since it was released and is sometimes the only supported packaging on older HLS players. MPEG TS
* typically has a 5-25 percent packaging overhead. This means MPEG TS typically requires 5-25 percent more
* bandwidth and cost than fMP4.
*
* The default is FRAGMENTED_MP4.
*
FRAGMENTED_MP4
* container format packages the media into MP4 fragments (fMP4 or CMAF). This is the recommended packaging
* because there is minimal packaging overhead. The other container format option is MPEG_TS.
* HLS has supported MPEG TS chunks since it was released and is sometimes the only supported packaging on
* older HLS players. MPEG TS typically has a 5-25 percent packaging overhead. This means MPEG TS typically
* requires 5-25 percent more bandwidth and cost than fMP4.
*
* The default is FRAGMENTED_MP4.
* @return Returns a reference to this object so that method calls can be chained together.
* @see ContainerFormat
*/
public GetHLSStreamingSessionURLRequest withContainerFormat(String containerFormat) {
setContainerFormat(containerFormat);
return this;
}
/**
*
* Specifies which format should be used for packaging the media. Specifying the FRAGMENTED_MP4
* container format packages the media into MP4 fragments (fMP4 or CMAF). This is the recommended packaging because
* there is minimal packaging overhead. The other container format option is MPEG_TS. HLS has supported
* MPEG TS chunks since it was released and is sometimes the only supported packaging on older HLS players. MPEG TS
* typically has a 5-25 percent packaging overhead. This means MPEG TS typically requires 5-25 percent more
* bandwidth and cost than fMP4.
*
* The default is FRAGMENTED_MP4.
*
FRAGMENTED_MP4
* container format packages the media into MP4 fragments (fMP4 or CMAF). This is the recommended packaging
* because there is minimal packaging overhead. The other container format option is MPEG_TS.
* HLS has supported MPEG TS chunks since it was released and is sometimes the only supported packaging on
* older HLS players. MPEG TS typically has a 5-25 percent packaging overhead. This means MPEG TS typically
* requires 5-25 percent more bandwidth and cost than fMP4.
*
* The default is FRAGMENTED_MP4.
* @return Returns a reference to this object so that method calls can be chained together.
* @see ContainerFormat
*/
public GetHLSStreamingSessionURLRequest withContainerFormat(ContainerFormat containerFormat) {
this.containerFormat = containerFormat.toString();
return this;
}
/**
*
* Specifies when flags marking discontinuities between fragments are added to the media playlists. *
*
* Media players typically build a timeline of media content to play, based on the timestamps of each fragment. This
* means that if there is any overlap or gap between fragments (as is typical if HLSFragmentSelector is set
* to SERVER_TIMESTAMP), the media player timeline will also have small gaps between fragments in some
* places, and will overwrite frames in other places. Gaps in the media player timeline can cause playback to stall
* and overlaps can cause playback to be jittery. When there are discontinuity flags between fragments, the media
* player is expected to reset the timeline, resulting in the next fragment being played immediately after the
* previous fragment.
*
* The following modes are supported: *
*
* ALWAYS: a discontinuity marker is placed between every fragment in the HLS media playlist. It is
* recommended to use a value of ALWAYS if the fragment timestamps are not accurate.
*
* NEVER: no discontinuity markers are placed anywhere. It is recommended to use a value of
* NEVER to ensure the media player timeline most accurately maps to the producer timestamps.
*
* ON_DISCONTINUITY: a discontinuity marker is placed between fragments that have a gap or overlap of
* more than 50 milliseconds. For most playback scenarios, it is recommended to use a value of
* ON_DISCONTINUITY so that the media player timeline is only reset when there is a significant issue
* with the media timeline (e.g. a missing fragment).
*
* The default is ALWAYS when HLSFragmentSelector is set to SERVER_TIMESTAMP, and
* NEVER when it is set to PRODUCER_TIMESTAMP.
*
* Media players typically build a timeline of media content to play, based on the timestamps of each
* fragment. This means that if there is any overlap or gap between fragments (as is typical if
* HLSFragmentSelector is set to SERVER_TIMESTAMP), the media player timeline will also
* have small gaps between fragments in some places, and will overwrite frames in other places. Gaps in the
* media player timeline can cause playback to stall and overlaps can cause playback to be jittery. When
* there are discontinuity flags between fragments, the media player is expected to reset the timeline,
* resulting in the next fragment being played immediately after the previous fragment.
*
* The following modes are supported: *
*
* ALWAYS: a discontinuity marker is placed between every fragment in the HLS media playlist. It
* is recommended to use a value of ALWAYS if the fragment timestamps are not accurate.
*
* NEVER: no discontinuity markers are placed anywhere. It is recommended to use a value of
* NEVER to ensure the media player timeline most accurately maps to the producer timestamps.
*
* ON_DISCONTINUITY: a discontinuity marker is placed between fragments that have a gap or
* overlap of more than 50 milliseconds. For most playback scenarios, it is recommended to use a value of
* ON_DISCONTINUITY so that the media player timeline is only reset when there is a significant
* issue with the media timeline (e.g. a missing fragment).
*
* The default is ALWAYS when HLSFragmentSelector is set to SERVER_TIMESTAMP
* , and NEVER when it is set to PRODUCER_TIMESTAMP.
* @see HLSDiscontinuityMode
*/
public void setDiscontinuityMode(String discontinuityMode) {
this.discontinuityMode = discontinuityMode;
}
/**
*
* Specifies when flags marking discontinuities between fragments are added to the media playlists. *
*
* Media players typically build a timeline of media content to play, based on the timestamps of each fragment. This
* means that if there is any overlap or gap between fragments (as is typical if HLSFragmentSelector is set
* to SERVER_TIMESTAMP), the media player timeline will also have small gaps between fragments in some
* places, and will overwrite frames in other places. Gaps in the media player timeline can cause playback to stall
* and overlaps can cause playback to be jittery. When there are discontinuity flags between fragments, the media
* player is expected to reset the timeline, resulting in the next fragment being played immediately after the
* previous fragment.
*
* The following modes are supported: *
*
* ALWAYS: a discontinuity marker is placed between every fragment in the HLS media playlist. It is
* recommended to use a value of ALWAYS if the fragment timestamps are not accurate.
*
* NEVER: no discontinuity markers are placed anywhere. It is recommended to use a value of
* NEVER to ensure the media player timeline most accurately maps to the producer timestamps.
*
* ON_DISCONTINUITY: a discontinuity marker is placed between fragments that have a gap or overlap of
* more than 50 milliseconds. For most playback scenarios, it is recommended to use a value of
* ON_DISCONTINUITY so that the media player timeline is only reset when there is a significant issue
* with the media timeline (e.g. a missing fragment).
*
* The default is ALWAYS when HLSFragmentSelector is set to SERVER_TIMESTAMP, and
* NEVER when it is set to PRODUCER_TIMESTAMP.
*
* Media players typically build a timeline of media content to play, based on the timestamps of each
* fragment. This means that if there is any overlap or gap between fragments (as is typical if
* HLSFragmentSelector is set to SERVER_TIMESTAMP), the media player timeline will also
* have small gaps between fragments in some places, and will overwrite frames in other places. Gaps in the
* media player timeline can cause playback to stall and overlaps can cause playback to be jittery. When
* there are discontinuity flags between fragments, the media player is expected to reset the timeline,
* resulting in the next fragment being played immediately after the previous fragment.
*
* The following modes are supported: *
*
* ALWAYS: a discontinuity marker is placed between every fragment in the HLS media playlist.
* It is recommended to use a value of ALWAYS if the fragment timestamps are not accurate.
*
* NEVER: no discontinuity markers are placed anywhere. It is recommended to use a value of
* NEVER to ensure the media player timeline most accurately maps to the producer timestamps.
*
* ON_DISCONTINUITY: a discontinuity marker is placed between fragments that have a gap or
* overlap of more than 50 milliseconds. For most playback scenarios, it is recommended to use a value of
* ON_DISCONTINUITY so that the media player timeline is only reset when there is a significant
* issue with the media timeline (e.g. a missing fragment).
*
* The default is ALWAYS when HLSFragmentSelector is set to
* SERVER_TIMESTAMP, and NEVER when it is set to PRODUCER_TIMESTAMP.
* @see HLSDiscontinuityMode
*/
public String getDiscontinuityMode() {
return this.discontinuityMode;
}
/**
*
* Specifies when flags marking discontinuities between fragments are added to the media playlists. *
*
* Media players typically build a timeline of media content to play, based on the timestamps of each fragment. This
* means that if there is any overlap or gap between fragments (as is typical if HLSFragmentSelector is set
* to SERVER_TIMESTAMP), the media player timeline will also have small gaps between fragments in some
* places, and will overwrite frames in other places. Gaps in the media player timeline can cause playback to stall
* and overlaps can cause playback to be jittery. When there are discontinuity flags between fragments, the media
* player is expected to reset the timeline, resulting in the next fragment being played immediately after the
* previous fragment.
*
* The following modes are supported: *
*
* ALWAYS: a discontinuity marker is placed between every fragment in the HLS media playlist. It is
* recommended to use a value of ALWAYS if the fragment timestamps are not accurate.
*
* NEVER: no discontinuity markers are placed anywhere. It is recommended to use a value of
* NEVER to ensure the media player timeline most accurately maps to the producer timestamps.
*
* ON_DISCONTINUITY: a discontinuity marker is placed between fragments that have a gap or overlap of
* more than 50 milliseconds. For most playback scenarios, it is recommended to use a value of
* ON_DISCONTINUITY so that the media player timeline is only reset when there is a significant issue
* with the media timeline (e.g. a missing fragment).
*
* The default is ALWAYS when HLSFragmentSelector is set to SERVER_TIMESTAMP, and
* NEVER when it is set to PRODUCER_TIMESTAMP.
*
* Media players typically build a timeline of media content to play, based on the timestamps of each
* fragment. This means that if there is any overlap or gap between fragments (as is typical if
* HLSFragmentSelector is set to SERVER_TIMESTAMP), the media player timeline will also
* have small gaps between fragments in some places, and will overwrite frames in other places. Gaps in the
* media player timeline can cause playback to stall and overlaps can cause playback to be jittery. When
* there are discontinuity flags between fragments, the media player is expected to reset the timeline,
* resulting in the next fragment being played immediately after the previous fragment.
*
* The following modes are supported: *
*
* ALWAYS: a discontinuity marker is placed between every fragment in the HLS media playlist. It
* is recommended to use a value of ALWAYS if the fragment timestamps are not accurate.
*
* NEVER: no discontinuity markers are placed anywhere. It is recommended to use a value of
* NEVER to ensure the media player timeline most accurately maps to the producer timestamps.
*
* ON_DISCONTINUITY: a discontinuity marker is placed between fragments that have a gap or
* overlap of more than 50 milliseconds. For most playback scenarios, it is recommended to use a value of
* ON_DISCONTINUITY so that the media player timeline is only reset when there is a significant
* issue with the media timeline (e.g. a missing fragment).
*
* The default is ALWAYS when HLSFragmentSelector is set to SERVER_TIMESTAMP
* , and NEVER when it is set to PRODUCER_TIMESTAMP.
* @return Returns a reference to this object so that method calls can be chained together.
* @see HLSDiscontinuityMode
*/
public GetHLSStreamingSessionURLRequest withDiscontinuityMode(String discontinuityMode) {
setDiscontinuityMode(discontinuityMode);
return this;
}
/**
*
* Specifies when flags marking discontinuities between fragments are added to the media playlists. *
*
* Media players typically build a timeline of media content to play, based on the timestamps of each fragment. This
* means that if there is any overlap or gap between fragments (as is typical if HLSFragmentSelector is set
* to SERVER_TIMESTAMP), the media player timeline will also have small gaps between fragments in some
* places, and will overwrite frames in other places. Gaps in the media player timeline can cause playback to stall
* and overlaps can cause playback to be jittery. When there are discontinuity flags between fragments, the media
* player is expected to reset the timeline, resulting in the next fragment being played immediately after the
* previous fragment.
*
* The following modes are supported: *
*
* ALWAYS: a discontinuity marker is placed between every fragment in the HLS media playlist. It is
* recommended to use a value of ALWAYS if the fragment timestamps are not accurate.
*
* NEVER: no discontinuity markers are placed anywhere. It is recommended to use a value of
* NEVER to ensure the media player timeline most accurately maps to the producer timestamps.
*
* ON_DISCONTINUITY: a discontinuity marker is placed between fragments that have a gap or overlap of
* more than 50 milliseconds. For most playback scenarios, it is recommended to use a value of
* ON_DISCONTINUITY so that the media player timeline is only reset when there is a significant issue
* with the media timeline (e.g. a missing fragment).
*
* The default is ALWAYS when HLSFragmentSelector is set to SERVER_TIMESTAMP, and
* NEVER when it is set to PRODUCER_TIMESTAMP.
*
* Media players typically build a timeline of media content to play, based on the timestamps of each
* fragment. This means that if there is any overlap or gap between fragments (as is typical if
* HLSFragmentSelector is set to SERVER_TIMESTAMP), the media player timeline will also
* have small gaps between fragments in some places, and will overwrite frames in other places. Gaps in the
* media player timeline can cause playback to stall and overlaps can cause playback to be jittery. When
* there are discontinuity flags between fragments, the media player is expected to reset the timeline,
* resulting in the next fragment being played immediately after the previous fragment.
*
* The following modes are supported: *
*
* ALWAYS: a discontinuity marker is placed between every fragment in the HLS media playlist. It
* is recommended to use a value of ALWAYS if the fragment timestamps are not accurate.
*
* NEVER: no discontinuity markers are placed anywhere. It is recommended to use a value of
* NEVER to ensure the media player timeline most accurately maps to the producer timestamps.
*
* ON_DISCONTINUITY: a discontinuity marker is placed between fragments that have a gap or
* overlap of more than 50 milliseconds. For most playback scenarios, it is recommended to use a value of
* ON_DISCONTINUITY so that the media player timeline is only reset when there is a significant
* issue with the media timeline (e.g. a missing fragment).
*
* The default is ALWAYS when HLSFragmentSelector is set to SERVER_TIMESTAMP
* , and NEVER when it is set to PRODUCER_TIMESTAMP.
* @return Returns a reference to this object so that method calls can be chained together.
* @see HLSDiscontinuityMode
*/
public GetHLSStreamingSessionURLRequest withDiscontinuityMode(HLSDiscontinuityMode discontinuityMode) {
this.discontinuityMode = discontinuityMode.toString();
return this;
}
/**
*
* Specifies when the fragment start timestamps should be included in the HLS media playlist. Typically, media * players report the playhead position as a time relative to the start of the first fragment in the playback * session. However, when the start timestamps are included in the HLS media playlist, some media players might * report the current playhead as an absolute time based on the fragment timestamps. This can be useful for creating * a playback experience that shows viewers the wall-clock time of the media. *
*
* The default is NEVER. When HLSFragmentSelector is SERVER_TIMESTAMP, the
* timestamps will be the server start timestamps. Similarly, when HLSFragmentSelector is
* PRODUCER_TIMESTAMP, the timestamps will be the producer start timestamps.
*
* The default is NEVER. When HLSFragmentSelector is SERVER_TIMESTAMP, the
* timestamps will be the server start timestamps. Similarly, when HLSFragmentSelector is
* PRODUCER_TIMESTAMP, the timestamps will be the producer start timestamps.
* @see HLSDisplayFragmentTimestamp
*/
public void setDisplayFragmentTimestamp(String displayFragmentTimestamp) {
this.displayFragmentTimestamp = displayFragmentTimestamp;
}
/**
*
* Specifies when the fragment start timestamps should be included in the HLS media playlist. Typically, media * players report the playhead position as a time relative to the start of the first fragment in the playback * session. However, when the start timestamps are included in the HLS media playlist, some media players might * report the current playhead as an absolute time based on the fragment timestamps. This can be useful for creating * a playback experience that shows viewers the wall-clock time of the media. *
*
* The default is NEVER. When HLSFragmentSelector is SERVER_TIMESTAMP, the
* timestamps will be the server start timestamps. Similarly, when HLSFragmentSelector is
* PRODUCER_TIMESTAMP, the timestamps will be the producer start timestamps.
*
* The default is NEVER. When HLSFragmentSelector is SERVER_TIMESTAMP, the
* timestamps will be the server start timestamps. Similarly, when HLSFragmentSelector is
* PRODUCER_TIMESTAMP, the timestamps will be the producer start timestamps.
* @see HLSDisplayFragmentTimestamp
*/
public String getDisplayFragmentTimestamp() {
return this.displayFragmentTimestamp;
}
/**
*
* Specifies when the fragment start timestamps should be included in the HLS media playlist. Typically, media * players report the playhead position as a time relative to the start of the first fragment in the playback * session. However, when the start timestamps are included in the HLS media playlist, some media players might * report the current playhead as an absolute time based on the fragment timestamps. This can be useful for creating * a playback experience that shows viewers the wall-clock time of the media. *
*
* The default is NEVER. When HLSFragmentSelector is SERVER_TIMESTAMP, the
* timestamps will be the server start timestamps. Similarly, when HLSFragmentSelector is
* PRODUCER_TIMESTAMP, the timestamps will be the producer start timestamps.
*
* The default is NEVER. When HLSFragmentSelector is SERVER_TIMESTAMP, the
* timestamps will be the server start timestamps. Similarly, when HLSFragmentSelector is
* PRODUCER_TIMESTAMP, the timestamps will be the producer start timestamps.
* @return Returns a reference to this object so that method calls can be chained together.
* @see HLSDisplayFragmentTimestamp
*/
public GetHLSStreamingSessionURLRequest withDisplayFragmentTimestamp(String displayFragmentTimestamp) {
setDisplayFragmentTimestamp(displayFragmentTimestamp);
return this;
}
/**
*
* Specifies when the fragment start timestamps should be included in the HLS media playlist. Typically, media * players report the playhead position as a time relative to the start of the first fragment in the playback * session. However, when the start timestamps are included in the HLS media playlist, some media players might * report the current playhead as an absolute time based on the fragment timestamps. This can be useful for creating * a playback experience that shows viewers the wall-clock time of the media. *
*
* The default is NEVER. When HLSFragmentSelector is SERVER_TIMESTAMP, the
* timestamps will be the server start timestamps. Similarly, when HLSFragmentSelector is
* PRODUCER_TIMESTAMP, the timestamps will be the producer start timestamps.
*
* The default is NEVER. When HLSFragmentSelector is SERVER_TIMESTAMP, the
* timestamps will be the server start timestamps. Similarly, when HLSFragmentSelector is
* PRODUCER_TIMESTAMP, the timestamps will be the producer start timestamps.
* @return Returns a reference to this object so that method calls can be chained together.
* @see HLSDisplayFragmentTimestamp
*/
public GetHLSStreamingSessionURLRequest withDisplayFragmentTimestamp(HLSDisplayFragmentTimestamp displayFragmentTimestamp) {
this.displayFragmentTimestamp = displayFragmentTimestamp.toString();
return this;
}
/**
*
* The time in seconds until the requested session expires. This value can be between 300 (5 minutes) and 43200 (12 * hours). *
*
* When a session expires, no new calls to GetHLSMasterPlaylist, GetHLSMediaPlaylist,
* GetMP4InitFragment, GetMP4MediaFragment, or GetTSFragment can be made for
* that session.
*
* The default is 300 (5 minutes). *
* * @param expires * The time in seconds until the requested session expires. This value can be between 300 (5 minutes) and * 43200 (12 hours). *
* When a session expires, no new calls to GetHLSMasterPlaylist,
* GetHLSMediaPlaylist, GetMP4InitFragment, GetMP4MediaFragment, or
* GetTSFragment can be made for that session.
*
* The default is 300 (5 minutes). */ public void setExpires(Integer expires) { this.expires = expires; } /** *
* The time in seconds until the requested session expires. This value can be between 300 (5 minutes) and 43200 (12 * hours). *
*
* When a session expires, no new calls to GetHLSMasterPlaylist, GetHLSMediaPlaylist,
* GetMP4InitFragment, GetMP4MediaFragment, or GetTSFragment can be made for
* that session.
*
* The default is 300 (5 minutes). *
* * @return The time in seconds until the requested session expires. This value can be between 300 (5 minutes) and * 43200 (12 hours). *
* When a session expires, no new calls to GetHLSMasterPlaylist,
* GetHLSMediaPlaylist, GetMP4InitFragment, GetMP4MediaFragment, or
* GetTSFragment can be made for that session.
*
* The default is 300 (5 minutes). */ public Integer getExpires() { return this.expires; } /** *
* The time in seconds until the requested session expires. This value can be between 300 (5 minutes) and 43200 (12 * hours). *
*
* When a session expires, no new calls to GetHLSMasterPlaylist, GetHLSMediaPlaylist,
* GetMP4InitFragment, GetMP4MediaFragment, or GetTSFragment can be made for
* that session.
*
* The default is 300 (5 minutes). *
* * @param expires * The time in seconds until the requested session expires. This value can be between 300 (5 minutes) and * 43200 (12 hours). *
* When a session expires, no new calls to GetHLSMasterPlaylist,
* GetHLSMediaPlaylist, GetMP4InitFragment, GetMP4MediaFragment, or
* GetTSFragment can be made for that session.
*
* The default is 300 (5 minutes). * @return Returns a reference to this object so that method calls can be chained together. */ public GetHLSStreamingSessionURLRequest withExpires(Integer expires) { setExpires(expires); return this; } /** *
* The maximum number of fragments that are returned in the HLS media playlists. *
*
* When the PlaybackMode is LIVE, the most recent fragments are returned up to this value.
* When the PlaybackMode is ON_DEMAND, the oldest fragments are returned, up to this
* maximum number.
*
* When there are a higher number of fragments available in a live HLS media playlist, video players often buffer * content before starting playback. Increasing the buffer size increases the playback latency, but it decreases the * likelihood that rebuffering will occur during playback. We recommend that a live HLS media playlist have a * minimum of 3 fragments and a maximum of 10 fragments. *
*
* The default is 5 fragments if PlaybackMode is LIVE or LIVE_REPLAY, and
* 1,000 if PlaybackMode is ON_DEMAND.
*
* The maximum value of 5,000 fragments corresponds to more than 80 minutes of video on streams with 1-second * fragments, and more than 13 hours of video on streams with 10-second fragments. *
* * @param maxMediaPlaylistFragmentResults * The maximum number of fragments that are returned in the HLS media playlists. *
* When the PlaybackMode is LIVE, the most recent fragments are returned up to this
* value. When the PlaybackMode is ON_DEMAND, the oldest fragments are returned, up
* to this maximum number.
*
* When there are a higher number of fragments available in a live HLS media playlist, video players often * buffer content before starting playback. Increasing the buffer size increases the playback latency, but it * decreases the likelihood that rebuffering will occur during playback. We recommend that a live HLS media * playlist have a minimum of 3 fragments and a maximum of 10 fragments. *
*
* The default is 5 fragments if PlaybackMode is LIVE or LIVE_REPLAY,
* and 1,000 if PlaybackMode is ON_DEMAND.
*
* The maximum value of 5,000 fragments corresponds to more than 80 minutes of video on streams with 1-second * fragments, and more than 13 hours of video on streams with 10-second fragments. */ public void setMaxMediaPlaylistFragmentResults(Long maxMediaPlaylistFragmentResults) { this.maxMediaPlaylistFragmentResults = maxMediaPlaylistFragmentResults; } /** *
* The maximum number of fragments that are returned in the HLS media playlists. *
*
* When the PlaybackMode is LIVE, the most recent fragments are returned up to this value.
* When the PlaybackMode is ON_DEMAND, the oldest fragments are returned, up to this
* maximum number.
*
* When there are a higher number of fragments available in a live HLS media playlist, video players often buffer * content before starting playback. Increasing the buffer size increases the playback latency, but it decreases the * likelihood that rebuffering will occur during playback. We recommend that a live HLS media playlist have a * minimum of 3 fragments and a maximum of 10 fragments. *
*
* The default is 5 fragments if PlaybackMode is LIVE or LIVE_REPLAY, and
* 1,000 if PlaybackMode is ON_DEMAND.
*
* The maximum value of 5,000 fragments corresponds to more than 80 minutes of video on streams with 1-second * fragments, and more than 13 hours of video on streams with 10-second fragments. *
* * @return The maximum number of fragments that are returned in the HLS media playlists. *
* When the PlaybackMode is LIVE, the most recent fragments are returned up to
* this value. When the PlaybackMode is ON_DEMAND, the oldest fragments are
* returned, up to this maximum number.
*
* When there are a higher number of fragments available in a live HLS media playlist, video players often * buffer content before starting playback. Increasing the buffer size increases the playback latency, but * it decreases the likelihood that rebuffering will occur during playback. We recommend that a live HLS * media playlist have a minimum of 3 fragments and a maximum of 10 fragments. *
*
* The default is 5 fragments if PlaybackMode is LIVE or LIVE_REPLAY,
* and 1,000 if PlaybackMode is ON_DEMAND.
*
* The maximum value of 5,000 fragments corresponds to more than 80 minutes of video on streams with * 1-second fragments, and more than 13 hours of video on streams with 10-second fragments. */ public Long getMaxMediaPlaylistFragmentResults() { return this.maxMediaPlaylistFragmentResults; } /** *
* The maximum number of fragments that are returned in the HLS media playlists. *
*
* When the PlaybackMode is LIVE, the most recent fragments are returned up to this value.
* When the PlaybackMode is ON_DEMAND, the oldest fragments are returned, up to this
* maximum number.
*
* When there are a higher number of fragments available in a live HLS media playlist, video players often buffer * content before starting playback. Increasing the buffer size increases the playback latency, but it decreases the * likelihood that rebuffering will occur during playback. We recommend that a live HLS media playlist have a * minimum of 3 fragments and a maximum of 10 fragments. *
*
* The default is 5 fragments if PlaybackMode is LIVE or LIVE_REPLAY, and
* 1,000 if PlaybackMode is ON_DEMAND.
*
* The maximum value of 5,000 fragments corresponds to more than 80 minutes of video on streams with 1-second * fragments, and more than 13 hours of video on streams with 10-second fragments. *
* * @param maxMediaPlaylistFragmentResults * The maximum number of fragments that are returned in the HLS media playlists. *
* When the PlaybackMode is LIVE, the most recent fragments are returned up to this
* value. When the PlaybackMode is ON_DEMAND, the oldest fragments are returned, up
* to this maximum number.
*
* When there are a higher number of fragments available in a live HLS media playlist, video players often * buffer content before starting playback. Increasing the buffer size increases the playback latency, but it * decreases the likelihood that rebuffering will occur during playback. We recommend that a live HLS media * playlist have a minimum of 3 fragments and a maximum of 10 fragments. *
*
* The default is 5 fragments if PlaybackMode is LIVE or LIVE_REPLAY,
* and 1,000 if PlaybackMode is ON_DEMAND.
*
* The maximum value of 5,000 fragments corresponds to more than 80 minutes of video on streams with 1-second * fragments, and more than 13 hours of video on streams with 10-second fragments. * @return Returns a reference to this object so that method calls can be chained together. */ public GetHLSStreamingSessionURLRequest withMaxMediaPlaylistFragmentResults(Long maxMediaPlaylistFragmentResults) { setMaxMediaPlaylistFragmentResults(maxMediaPlaylistFragmentResults); return this; } /** * Returns a string representation of this object. This is useful for testing and debugging. Sensitive data will be * redacted from this string using a placeholder value. * * @return A string representation of this object. * * @see java.lang.Object#toString() */ @Override public String toString() { StringBuilder sb = new StringBuilder(); sb.append("{"); if (getStreamName() != null) sb.append("StreamName: ").append(getStreamName()).append(","); if (getStreamARN() != null) sb.append("StreamARN: ").append(getStreamARN()).append(","); if (getPlaybackMode() != null) sb.append("PlaybackMode: ").append(getPlaybackMode()).append(","); if (getHLSFragmentSelector() != null) sb.append("HLSFragmentSelector: ").append(getHLSFragmentSelector()).append(","); if (getContainerFormat() != null) sb.append("ContainerFormat: ").append(getContainerFormat()).append(","); if (getDiscontinuityMode() != null) sb.append("DiscontinuityMode: ").append(getDiscontinuityMode()).append(","); if (getDisplayFragmentTimestamp() != null) sb.append("DisplayFragmentTimestamp: ").append(getDisplayFragmentTimestamp()).append(","); if (getExpires() != null) sb.append("Expires: ").append(getExpires()).append(","); if (getMaxMediaPlaylistFragmentResults() != null) sb.append("MaxMediaPlaylistFragmentResults: ").append(getMaxMediaPlaylistFragmentResults()); sb.append("}"); return sb.toString(); } @Override public boolean equals(Object obj) { if (this == obj) return true; if (obj == null) return false; if (obj instanceof GetHLSStreamingSessionURLRequest == false) return false; GetHLSStreamingSessionURLRequest other = (GetHLSStreamingSessionURLRequest) obj; if (other.getStreamName() == null ^ this.getStreamName() == null) return false; if (other.getStreamName() != null && other.getStreamName().equals(this.getStreamName()) == false) return false; if (other.getStreamARN() == null ^ this.getStreamARN() == null) return false; if (other.getStreamARN() != null && other.getStreamARN().equals(this.getStreamARN()) == false) return false; if (other.getPlaybackMode() == null ^ this.getPlaybackMode() == null) return false; if (other.getPlaybackMode() != null && other.getPlaybackMode().equals(this.getPlaybackMode()) == false) return false; if (other.getHLSFragmentSelector() == null ^ this.getHLSFragmentSelector() == null) return false; if (other.getHLSFragmentSelector() != null && other.getHLSFragmentSelector().equals(this.getHLSFragmentSelector()) == false) return false; if (other.getContainerFormat() == null ^ this.getContainerFormat() == null) return false; if (other.getContainerFormat() != null && other.getContainerFormat().equals(this.getContainerFormat()) == false) return false; if (other.getDiscontinuityMode() == null ^ this.getDiscontinuityMode() == null) return false; if (other.getDiscontinuityMode() != null && other.getDiscontinuityMode().equals(this.getDiscontinuityMode()) == false) return false; if (other.getDisplayFragmentTimestamp() == null ^ this.getDisplayFragmentTimestamp() == null) return false; if (other.getDisplayFragmentTimestamp() != null && other.getDisplayFragmentTimestamp().equals(this.getDisplayFragmentTimestamp()) == false) return false; if (other.getExpires() == null ^ this.getExpires() == null) return false; if (other.getExpires() != null && other.getExpires().equals(this.getExpires()) == false) return false; if (other.getMaxMediaPlaylistFragmentResults() == null ^ this.getMaxMediaPlaylistFragmentResults() == null) return false; if (other.getMaxMediaPlaylistFragmentResults() != null && other.getMaxMediaPlaylistFragmentResults().equals(this.getMaxMediaPlaylistFragmentResults()) == false) return false; return true; } @Override public int hashCode() { final int prime = 31; int hashCode = 1; hashCode = prime * hashCode + ((getStreamName() == null) ? 0 : getStreamName().hashCode()); hashCode = prime * hashCode + ((getStreamARN() == null) ? 0 : getStreamARN().hashCode()); hashCode = prime * hashCode + ((getPlaybackMode() == null) ? 0 : getPlaybackMode().hashCode()); hashCode = prime * hashCode + ((getHLSFragmentSelector() == null) ? 0 : getHLSFragmentSelector().hashCode()); hashCode = prime * hashCode + ((getContainerFormat() == null) ? 0 : getContainerFormat().hashCode()); hashCode = prime * hashCode + ((getDiscontinuityMode() == null) ? 0 : getDiscontinuityMode().hashCode()); hashCode = prime * hashCode + ((getDisplayFragmentTimestamp() == null) ? 0 : getDisplayFragmentTimestamp().hashCode()); hashCode = prime * hashCode + ((getExpires() == null) ? 0 : getExpires().hashCode()); hashCode = prime * hashCode + ((getMaxMediaPlaylistFragmentResults() == null) ? 0 : getMaxMediaPlaylistFragmentResults().hashCode()); return hashCode; } @Override public GetHLSStreamingSessionURLRequest clone() { return (GetHLSStreamingSessionURLRequest) super.clone(); } }