/* * Copyright 2018-2023 Amazon.com, Inc. or its affiliates. All Rights Reserved. * * Licensed under the Apache License, Version 2.0 (the "License"). You may not use this file except in compliance with * the License. A copy of the License is located at * * http://aws.amazon.com/apache2.0 * * or in the "license" file accompanying this file. This file is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR * CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions * and limitations under the License. */ package com.amazonaws.services.kinesisvideo.model; import java.io.Serializable; import javax.annotation.Generated; import com.amazonaws.AmazonWebServiceRequest; /** * * @see AWS API Documentation */ @Generated("com.amazonaws:aws-java-sdk-code-generator") public class GetDASHStreamingSessionURLRequest extends com.amazonaws.AmazonWebServiceRequest implements Serializable, Cloneable { /** *
* The name of the stream for which to retrieve the MPEG-DASH manifest URL. *
*
* You must specify either the StreamName
or the StreamARN
.
*
* The Amazon Resource Name (ARN) of the stream for which to retrieve the MPEG-DASH manifest 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 MPEG-DASH manifest is continually updated with the
* latest fragments as they become available. We recommend that the media player retrieve a new manifest 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 MPEG-DASH manifest, 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 MPEG-DASH manifest 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 manifest, the older fragment is not added, and the gap is not filled.
*
* LIVE_REPLAY
: For sessions of this type, the MPEG-DASH manifest 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
* manifest 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 MPEG-DASH manifest contains all the fragments for
* the session, up to the number that is specified in MaxManifestFragmentResults
. The manifest 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 larger fragment number (that is, the
* newer fragment) is included in the MPEG-DASH manifest. The other fragments are not included. Fragments that have
* different timestamps but have overlapping durations are still included in the MPEG-DASH manifest. This can lead
* to unexpected behavior in the media player.
*
* The default is LIVE
.
*
* Per the MPEG-DASH specification, the wall-clock time of fragments in the manifest file can be derived using
* attributes in the manifest itself. However, typically, MPEG-DASH compatible media players do not properly handle
* gaps in the media timeline. Kinesis Video Streams adjusts the media timeline in the manifest file to enable
* playback of media with discontinuities. Therefore, the wall-clock time derived from the manifest file may be
* inaccurate. If DisplayFragmentTimestamp is set to ALWAYS
, the accurate fragment timestamp is added
* to each S element in the manifest file with the attribute name “kvs:ts”. A custom MPEG-DASH media player is
* necessary to leverage this custom attribute.
*
* The default value is NEVER
. When DASHFragmentSelector is SERVER_TIMESTAMP
, the
* timestamps will be the server start timestamps. Similarly, when DASHFragmentSelector is
* PRODUCER_TIMESTAMP
, the timestamps will be the producer start timestamps.
*
* Fragments are identified in the manifest file based on their sequence number in the session. If
* DisplayFragmentNumber is set to ALWAYS
, the Kinesis Video Streams fragment number is added to each S
* element in the manifest file with the attribute name “kvs:fn”. These fragment numbers can be used for logging or
* for use with other APIs (e.g. GetMedia
and GetMediaForFragmentList
). A custom MPEG-DASH
* media player is necessary to leverage these this custom attribute.
*
* The default value is NEVER
.
*
* 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.
*
* 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 GetDashManifest
, GetMP4InitFragment
, or
* GetMP4MediaFragment
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 MPEG-DASH manifest. *
*
* 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 MPEG-DASH manifest, 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 MPEG-DASH manifest 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 1,000 fragments corresponds to more than 16 minutes of video on streams with 1-second * fragments, and more than 2 1/2 hours of video on streams with 10-second fragments. *
*/ private Long maxManifestFragmentResults; /** ** The name of the stream for which to retrieve the MPEG-DASH manifest 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 MPEG-DASH manifest 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 MPEG-DASH manifest 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 GetDASHStreamingSessionURLRequest withStreamName(String streamName) {
setStreamName(streamName);
return this;
}
/**
*
* The Amazon Resource Name (ARN) of the stream for which to retrieve the MPEG-DASH manifest 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 MPEG-DASH manifest 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 MPEG-DASH manifest 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 GetDASHStreamingSessionURLRequest 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 MPEG-DASH manifest is continually updated with the
* latest fragments as they become available. We recommend that the media player retrieve a new manifest 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 MPEG-DASH manifest, 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 MPEG-DASH manifest 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 manifest, the older fragment is not added, and the gap is not filled.
*
* LIVE_REPLAY
: For sessions of this type, the MPEG-DASH manifest 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
* manifest 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 MPEG-DASH manifest contains all the fragments for
* the session, up to the number that is specified in MaxManifestFragmentResults
. The manifest 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 larger fragment number (that is, the
* newer fragment) is included in the MPEG-DASH manifest. The other fragments are not included. Fragments that have
* different timestamps but have overlapping durations are still included in the MPEG-DASH manifest. 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 MPEG-DASH manifest is continually updated with
* the latest fragments as they become available. We recommend that the media player retrieve a new manifest
* 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 MPEG-DASH manifest, 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 MPEG-DASH
* manifest 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 manifest, the older fragment is not added, and the
* gap is not filled.
*
* LIVE_REPLAY
: For sessions of this type, the MPEG-DASH manifest 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 manifest 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 MPEG-DASH manifest contains all the
* fragments for the session, up to the number that is specified in MaxManifestFragmentResults
.
* The manifest 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 larger fragment
* number (that is, the newer fragment) is included in the MPEG-DASH manifest. The other fragments are not
* included. Fragments that have different timestamps but have overlapping durations are still included in
* the MPEG-DASH manifest. This can lead to unexpected behavior in the media player.
*
* The default is LIVE
.
* @see DASHPlaybackMode
*/
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 MPEG-DASH manifest is continually updated with the
* latest fragments as they become available. We recommend that the media player retrieve a new manifest 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 MPEG-DASH manifest, 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 MPEG-DASH manifest 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 manifest, the older fragment is not added, and the gap is not filled.
*
* LIVE_REPLAY
: For sessions of this type, the MPEG-DASH manifest 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
* manifest 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 MPEG-DASH manifest contains all the fragments for
* the session, up to the number that is specified in MaxManifestFragmentResults
. The manifest 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 larger fragment number (that is, the
* newer fragment) is included in the MPEG-DASH manifest. The other fragments are not included. Fragments that have
* different timestamps but have overlapping durations are still included in the MPEG-DASH manifest. 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 MPEG-DASH manifest is continually updated with
* the latest fragments as they become available. We recommend that the media player retrieve a new manifest
* 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 MPEG-DASH manifest, 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 MPEG-DASH
* manifest 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 manifest, the older fragment is not added, and the
* gap is not filled.
*
* LIVE_REPLAY
: For sessions of this type, the MPEG-DASH manifest 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 manifest 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 MPEG-DASH manifest contains all the
* fragments for the session, up to the number that is specified in MaxManifestFragmentResults
.
* The manifest 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 larger fragment
* number (that is, the newer fragment) is included in the MPEG-DASH manifest. The other fragments are not
* included. Fragments that have different timestamps but have overlapping durations are still included in
* the MPEG-DASH manifest. This can lead to unexpected behavior in the media player.
*
* The default is LIVE
.
* @see DASHPlaybackMode
*/
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 MPEG-DASH manifest is continually updated with the
* latest fragments as they become available. We recommend that the media player retrieve a new manifest 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 MPEG-DASH manifest, 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 MPEG-DASH manifest 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 manifest, the older fragment is not added, and the gap is not filled.
*
* LIVE_REPLAY
: For sessions of this type, the MPEG-DASH manifest 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
* manifest 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 MPEG-DASH manifest contains all the fragments for
* the session, up to the number that is specified in MaxManifestFragmentResults
. The manifest 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 larger fragment number (that is, the
* newer fragment) is included in the MPEG-DASH manifest. The other fragments are not included. Fragments that have
* different timestamps but have overlapping durations are still included in the MPEG-DASH manifest. 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 MPEG-DASH manifest is continually updated with
* the latest fragments as they become available. We recommend that the media player retrieve a new manifest
* 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 MPEG-DASH manifest, 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 MPEG-DASH
* manifest 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 manifest, the older fragment is not added, and the
* gap is not filled.
*
* LIVE_REPLAY
: For sessions of this type, the MPEG-DASH manifest 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 manifest 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 MPEG-DASH manifest contains all the
* fragments for the session, up to the number that is specified in MaxManifestFragmentResults
.
* The manifest 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 larger fragment
* number (that is, the newer fragment) is included in the MPEG-DASH manifest. The other fragments are not
* included. Fragments that have different timestamps but have overlapping durations are still included in
* the MPEG-DASH manifest. 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 DASHPlaybackMode
*/
public GetDASHStreamingSessionURLRequest 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 MPEG-DASH manifest is continually updated with the
* latest fragments as they become available. We recommend that the media player retrieve a new manifest 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 MPEG-DASH manifest, 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 MPEG-DASH manifest 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 manifest, the older fragment is not added, and the gap is not filled.
*
* LIVE_REPLAY
: For sessions of this type, the MPEG-DASH manifest 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
* manifest 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 MPEG-DASH manifest contains all the fragments for
* the session, up to the number that is specified in MaxManifestFragmentResults
. The manifest 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 larger fragment number (that is, the
* newer fragment) is included in the MPEG-DASH manifest. The other fragments are not included. Fragments that have
* different timestamps but have overlapping durations are still included in the MPEG-DASH manifest. 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 MPEG-DASH manifest is continually updated with
* the latest fragments as they become available. We recommend that the media player retrieve a new manifest
* 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 MPEG-DASH manifest, 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 MPEG-DASH
* manifest 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 manifest, the older fragment is not added, and the
* gap is not filled.
*
* LIVE_REPLAY
: For sessions of this type, the MPEG-DASH manifest 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 manifest 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 MPEG-DASH manifest contains all the
* fragments for the session, up to the number that is specified in MaxManifestFragmentResults
.
* The manifest 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 larger fragment
* number (that is, the newer fragment) is included in the MPEG-DASH manifest. The other fragments are not
* included. Fragments that have different timestamps but have overlapping durations are still included in
* the MPEG-DASH manifest. 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 DASHPlaybackMode
*/
public GetDASHStreamingSessionURLRequest withPlaybackMode(DASHPlaybackMode playbackMode) {
this.playbackMode = playbackMode.toString();
return this;
}
/**
*
* Per the MPEG-DASH specification, the wall-clock time of fragments in the manifest file can be derived using
* attributes in the manifest itself. However, typically, MPEG-DASH compatible media players do not properly handle
* gaps in the media timeline. Kinesis Video Streams adjusts the media timeline in the manifest file to enable
* playback of media with discontinuities. Therefore, the wall-clock time derived from the manifest file may be
* inaccurate. If DisplayFragmentTimestamp is set to ALWAYS
, the accurate fragment timestamp is added
* to each S element in the manifest file with the attribute name “kvs:ts”. A custom MPEG-DASH media player is
* necessary to leverage this custom attribute.
*
* The default value is NEVER
. When DASHFragmentSelector is SERVER_TIMESTAMP
, the
* timestamps will be the server start timestamps. Similarly, when DASHFragmentSelector is
* PRODUCER_TIMESTAMP
, the timestamps will be the producer start timestamps.
*
ALWAYS
, the
* accurate fragment timestamp is added to each S element in the manifest file with the attribute name
* “kvs:ts”. A custom MPEG-DASH media player is necessary to leverage this custom attribute.
*
* The default value is NEVER
. When DASHFragmentSelector is SERVER_TIMESTAMP
* , the timestamps will be the server start timestamps. Similarly, when DASHFragmentSelector is
* PRODUCER_TIMESTAMP
, the timestamps will be the producer start timestamps.
* @see DASHDisplayFragmentTimestamp
*/
public void setDisplayFragmentTimestamp(String displayFragmentTimestamp) {
this.displayFragmentTimestamp = displayFragmentTimestamp;
}
/**
*
* Per the MPEG-DASH specification, the wall-clock time of fragments in the manifest file can be derived using
* attributes in the manifest itself. However, typically, MPEG-DASH compatible media players do not properly handle
* gaps in the media timeline. Kinesis Video Streams adjusts the media timeline in the manifest file to enable
* playback of media with discontinuities. Therefore, the wall-clock time derived from the manifest file may be
* inaccurate. If DisplayFragmentTimestamp is set to ALWAYS
, the accurate fragment timestamp is added
* to each S element in the manifest file with the attribute name “kvs:ts”. A custom MPEG-DASH media player is
* necessary to leverage this custom attribute.
*
* The default value is NEVER
. When DASHFragmentSelector is SERVER_TIMESTAMP
, the
* timestamps will be the server start timestamps. Similarly, when DASHFragmentSelector is
* PRODUCER_TIMESTAMP
, the timestamps will be the producer start timestamps.
*
ALWAYS
, the
* accurate fragment timestamp is added to each S element in the manifest file with the attribute name
* “kvs:ts”. A custom MPEG-DASH media player is necessary to leverage this custom attribute.
*
* The default value is NEVER
. When DASHFragmentSelector is
* SERVER_TIMESTAMP
, the timestamps will be the server start timestamps. Similarly, when
* DASHFragmentSelector is PRODUCER_TIMESTAMP
, the timestamps will be the producer start
* timestamps.
* @see DASHDisplayFragmentTimestamp
*/
public String getDisplayFragmentTimestamp() {
return this.displayFragmentTimestamp;
}
/**
*
* Per the MPEG-DASH specification, the wall-clock time of fragments in the manifest file can be derived using
* attributes in the manifest itself. However, typically, MPEG-DASH compatible media players do not properly handle
* gaps in the media timeline. Kinesis Video Streams adjusts the media timeline in the manifest file to enable
* playback of media with discontinuities. Therefore, the wall-clock time derived from the manifest file may be
* inaccurate. If DisplayFragmentTimestamp is set to ALWAYS
, the accurate fragment timestamp is added
* to each S element in the manifest file with the attribute name “kvs:ts”. A custom MPEG-DASH media player is
* necessary to leverage this custom attribute.
*
* The default value is NEVER
. When DASHFragmentSelector is SERVER_TIMESTAMP
, the
* timestamps will be the server start timestamps. Similarly, when DASHFragmentSelector is
* PRODUCER_TIMESTAMP
, the timestamps will be the producer start timestamps.
*
ALWAYS
, the
* accurate fragment timestamp is added to each S element in the manifest file with the attribute name
* “kvs:ts”. A custom MPEG-DASH media player is necessary to leverage this custom attribute.
*
* The default value is NEVER
. When DASHFragmentSelector is SERVER_TIMESTAMP
* , the timestamps will be the server start timestamps. Similarly, when DASHFragmentSelector 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 DASHDisplayFragmentTimestamp
*/
public GetDASHStreamingSessionURLRequest withDisplayFragmentTimestamp(String displayFragmentTimestamp) {
setDisplayFragmentTimestamp(displayFragmentTimestamp);
return this;
}
/**
*
* Per the MPEG-DASH specification, the wall-clock time of fragments in the manifest file can be derived using
* attributes in the manifest itself. However, typically, MPEG-DASH compatible media players do not properly handle
* gaps in the media timeline. Kinesis Video Streams adjusts the media timeline in the manifest file to enable
* playback of media with discontinuities. Therefore, the wall-clock time derived from the manifest file may be
* inaccurate. If DisplayFragmentTimestamp is set to ALWAYS
, the accurate fragment timestamp is added
* to each S element in the manifest file with the attribute name “kvs:ts”. A custom MPEG-DASH media player is
* necessary to leverage this custom attribute.
*
* The default value is NEVER
. When DASHFragmentSelector is SERVER_TIMESTAMP
, the
* timestamps will be the server start timestamps. Similarly, when DASHFragmentSelector is
* PRODUCER_TIMESTAMP
, the timestamps will be the producer start timestamps.
*
ALWAYS
, the
* accurate fragment timestamp is added to each S element in the manifest file with the attribute name
* “kvs:ts”. A custom MPEG-DASH media player is necessary to leverage this custom attribute.
*
* The default value is NEVER
. When DASHFragmentSelector is SERVER_TIMESTAMP
* , the timestamps will be the server start timestamps. Similarly, when DASHFragmentSelector 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 DASHDisplayFragmentTimestamp
*/
public GetDASHStreamingSessionURLRequest withDisplayFragmentTimestamp(DASHDisplayFragmentTimestamp displayFragmentTimestamp) {
this.displayFragmentTimestamp = displayFragmentTimestamp.toString();
return this;
}
/**
*
* Fragments are identified in the manifest file based on their sequence number in the session. If
* DisplayFragmentNumber is set to ALWAYS
, the Kinesis Video Streams fragment number is added to each S
* element in the manifest file with the attribute name “kvs:fn”. These fragment numbers can be used for logging or
* for use with other APIs (e.g. GetMedia
and GetMediaForFragmentList
). A custom MPEG-DASH
* media player is necessary to leverage these this custom attribute.
*
* The default value is NEVER
.
*
ALWAYS
, the Kinesis Video Streams fragment number is added to
* each S element in the manifest file with the attribute name “kvs:fn”. These fragment numbers can be used
* for logging or for use with other APIs (e.g. GetMedia
and
* GetMediaForFragmentList
). A custom MPEG-DASH media player is necessary to leverage these this
* custom attribute.
*
* The default value is NEVER
.
* @see DASHDisplayFragmentNumber
*/
public void setDisplayFragmentNumber(String displayFragmentNumber) {
this.displayFragmentNumber = displayFragmentNumber;
}
/**
*
* Fragments are identified in the manifest file based on their sequence number in the session. If
* DisplayFragmentNumber is set to ALWAYS
, the Kinesis Video Streams fragment number is added to each S
* element in the manifest file with the attribute name “kvs:fn”. These fragment numbers can be used for logging or
* for use with other APIs (e.g. GetMedia
and GetMediaForFragmentList
). A custom MPEG-DASH
* media player is necessary to leverage these this custom attribute.
*
* The default value is NEVER
.
*
ALWAYS
, the Kinesis Video Streams fragment number is added
* to each S element in the manifest file with the attribute name “kvs:fn”. These fragment numbers can be
* used for logging or for use with other APIs (e.g. GetMedia
and
* GetMediaForFragmentList
). A custom MPEG-DASH media player is necessary to leverage these
* this custom attribute.
*
* The default value is NEVER
.
* @see DASHDisplayFragmentNumber
*/
public String getDisplayFragmentNumber() {
return this.displayFragmentNumber;
}
/**
*
* Fragments are identified in the manifest file based on their sequence number in the session. If
* DisplayFragmentNumber is set to ALWAYS
, the Kinesis Video Streams fragment number is added to each S
* element in the manifest file with the attribute name “kvs:fn”. These fragment numbers can be used for logging or
* for use with other APIs (e.g. GetMedia
and GetMediaForFragmentList
). A custom MPEG-DASH
* media player is necessary to leverage these this custom attribute.
*
* The default value is NEVER
.
*
ALWAYS
, the Kinesis Video Streams fragment number is added to
* each S element in the manifest file with the attribute name “kvs:fn”. These fragment numbers can be used
* for logging or for use with other APIs (e.g. GetMedia
and
* GetMediaForFragmentList
). A custom MPEG-DASH media player is necessary to leverage these this
* custom attribute.
*
* The default value is NEVER
.
* @return Returns a reference to this object so that method calls can be chained together.
* @see DASHDisplayFragmentNumber
*/
public GetDASHStreamingSessionURLRequest withDisplayFragmentNumber(String displayFragmentNumber) {
setDisplayFragmentNumber(displayFragmentNumber);
return this;
}
/**
*
* Fragments are identified in the manifest file based on their sequence number in the session. If
* DisplayFragmentNumber is set to ALWAYS
, the Kinesis Video Streams fragment number is added to each S
* element in the manifest file with the attribute name “kvs:fn”. These fragment numbers can be used for logging or
* for use with other APIs (e.g. GetMedia
and GetMediaForFragmentList
). A custom MPEG-DASH
* media player is necessary to leverage these this custom attribute.
*
* The default value is NEVER
.
*
ALWAYS
, the Kinesis Video Streams fragment number is added to
* each S element in the manifest file with the attribute name “kvs:fn”. These fragment numbers can be used
* for logging or for use with other APIs (e.g. GetMedia
and
* GetMediaForFragmentList
). A custom MPEG-DASH media player is necessary to leverage these this
* custom attribute.
*
* The default value is NEVER
.
* @return Returns a reference to this object so that method calls can be chained together.
* @see DASHDisplayFragmentNumber
*/
public GetDASHStreamingSessionURLRequest withDisplayFragmentNumber(DASHDisplayFragmentNumber displayFragmentNumber) {
this.displayFragmentNumber = displayFragmentNumber.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 setDASHFragmentSelector(DASHFragmentSelector dASHFragmentSelector) {
this.dASHFragmentSelector = dASHFragmentSelector;
}
/**
*
* 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 DASHFragmentSelector getDASHFragmentSelector() {
return this.dASHFragmentSelector;
}
/**
*
* 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 GetDASHStreamingSessionURLRequest withDASHFragmentSelector(DASHFragmentSelector dASHFragmentSelector) {
setDASHFragmentSelector(dASHFragmentSelector);
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 GetDashManifest
, GetMP4InitFragment
, or
* GetMP4MediaFragment
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 GetDashManifest
, GetMP4InitFragment
, or
* GetMP4MediaFragment
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 GetDashManifest
, GetMP4InitFragment
, or
* GetMP4MediaFragment
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 GetDashManifest
, GetMP4InitFragment
, or
* GetMP4MediaFragment
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 GetDashManifest
, GetMP4InitFragment
, or
* GetMP4MediaFragment
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 GetDashManifest
, GetMP4InitFragment
, or
* GetMP4MediaFragment
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 GetDASHStreamingSessionURLRequest withExpires(Integer expires) { setExpires(expires); return this; } /** *
* The maximum number of fragments that are returned in the MPEG-DASH manifest. *
*
* 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 MPEG-DASH manifest, 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 MPEG-DASH manifest 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 1,000 fragments corresponds to more than 16 minutes of video on streams with 1-second * fragments, and more than 2 1/2 hours of video on streams with 10-second fragments. *
* * @param maxManifestFragmentResults * The maximum number of fragments that are returned in the MPEG-DASH manifest. *
* 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 MPEG-DASH manifest, 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 MPEG-DASH * manifest 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 1,000 fragments corresponds to more than 16 minutes of video on streams with 1-second * fragments, and more than 2 1/2 hours of video on streams with 10-second fragments. */ public void setMaxManifestFragmentResults(Long maxManifestFragmentResults) { this.maxManifestFragmentResults = maxManifestFragmentResults; } /** *
* The maximum number of fragments that are returned in the MPEG-DASH manifest. *
*
* 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 MPEG-DASH manifest, 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 MPEG-DASH manifest 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 1,000 fragments corresponds to more than 16 minutes of video on streams with 1-second * fragments, and more than 2 1/2 hours of video on streams with 10-second fragments. *
* * @return The maximum number of fragments that are returned in the MPEG-DASH manifest. *
* 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 MPEG-DASH manifest, 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 * MPEG-DASH manifest 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 1,000 fragments corresponds to more than 16 minutes of video on streams with * 1-second fragments, and more than 2 1/2 hours of video on streams with 10-second fragments. */ public Long getMaxManifestFragmentResults() { return this.maxManifestFragmentResults; } /** *
* The maximum number of fragments that are returned in the MPEG-DASH manifest. *
*
* 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 MPEG-DASH manifest, 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 MPEG-DASH manifest 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 1,000 fragments corresponds to more than 16 minutes of video on streams with 1-second * fragments, and more than 2 1/2 hours of video on streams with 10-second fragments. *
* * @param maxManifestFragmentResults * The maximum number of fragments that are returned in the MPEG-DASH manifest. *
* 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 MPEG-DASH manifest, 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 MPEG-DASH * manifest 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 1,000 fragments corresponds to more than 16 minutes of video on streams with 1-second * fragments, and more than 2 1/2 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 GetDASHStreamingSessionURLRequest withMaxManifestFragmentResults(Long maxManifestFragmentResults) { setMaxManifestFragmentResults(maxManifestFragmentResults); 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 (getDisplayFragmentTimestamp() != null) sb.append("DisplayFragmentTimestamp: ").append(getDisplayFragmentTimestamp()).append(","); if (getDisplayFragmentNumber() != null) sb.append("DisplayFragmentNumber: ").append(getDisplayFragmentNumber()).append(","); if (getDASHFragmentSelector() != null) sb.append("DASHFragmentSelector: ").append(getDASHFragmentSelector()).append(","); if (getExpires() != null) sb.append("Expires: ").append(getExpires()).append(","); if (getMaxManifestFragmentResults() != null) sb.append("MaxManifestFragmentResults: ").append(getMaxManifestFragmentResults()); sb.append("}"); return sb.toString(); } @Override public boolean equals(Object obj) { if (this == obj) return true; if (obj == null) return false; if (obj instanceof GetDASHStreamingSessionURLRequest == false) return false; GetDASHStreamingSessionURLRequest other = (GetDASHStreamingSessionURLRequest) 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.getDisplayFragmentTimestamp() == null ^ this.getDisplayFragmentTimestamp() == null) return false; if (other.getDisplayFragmentTimestamp() != null && other.getDisplayFragmentTimestamp().equals(this.getDisplayFragmentTimestamp()) == false) return false; if (other.getDisplayFragmentNumber() == null ^ this.getDisplayFragmentNumber() == null) return false; if (other.getDisplayFragmentNumber() != null && other.getDisplayFragmentNumber().equals(this.getDisplayFragmentNumber()) == false) return false; if (other.getDASHFragmentSelector() == null ^ this.getDASHFragmentSelector() == null) return false; if (other.getDASHFragmentSelector() != null && other.getDASHFragmentSelector().equals(this.getDASHFragmentSelector()) == 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.getMaxManifestFragmentResults() == null ^ this.getMaxManifestFragmentResults() == null) return false; if (other.getMaxManifestFragmentResults() != null && other.getMaxManifestFragmentResults().equals(this.getMaxManifestFragmentResults()) == 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 + ((getDisplayFragmentTimestamp() == null) ? 0 : getDisplayFragmentTimestamp().hashCode()); hashCode = prime * hashCode + ((getDisplayFragmentNumber() == null) ? 0 : getDisplayFragmentNumber().hashCode()); hashCode = prime * hashCode + ((getDASHFragmentSelector() == null) ? 0 : getDASHFragmentSelector().hashCode()); hashCode = prime * hashCode + ((getExpires() == null) ? 0 : getExpires().hashCode()); hashCode = prime * hashCode + ((getMaxManifestFragmentResults() == null) ? 0 : getMaxManifestFragmentResults().hashCode()); return hashCode; } @Override public GetDASHStreamingSessionURLRequest clone() { return (GetDASHStreamingSessionURLRequest) super.clone(); } }