client.rb in aws-sdk-kinesisvideoarchivedmedia-1.47.0

- old
+ new

@@ -273,10 +273,15 @@
     #       functionality of `standard` mode along with automatic client side
     #       throttling.  This is a provisional mode that may change behavior
     #       in the future.
     #
     #
+    #   @option options [String] :sdk_ua_app_id
+    #     A unique and opaque application ID that is appended to the
+    #     User-Agent header as app/<sdk_ua_app_id>. It should have a
+    #     maximum length of 50.
+    #
     #   @option options [String] :secret_access_key
     #
     #   @option options [String] :session_token
     #
     #   @option options [Boolean] :stub_responses (false)
@@ -612,17 +617,17 @@
     # @option params [String] :playback_mode
     #   Whether to retrieve live, live replay, or archived, on-demand data.
     #
     #   Features of the three types of sessions include the following:
     #
-    #   * <b> <code>LIVE</code> </b>\: 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.
+    #   * <b> <code>LIVE</code> </b>: 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.
     #
     #     <note markdown="1"> 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
@@ -631,11 +636,11 @@
     #     available after a subsequent fragment is added to the manifest, the
     #     older fragment is not added, and the gap is not filled.
     #
     #      </note>
     #
-    #   * <b> <code>LIVE_REPLAY</code> </b>\: For sessions of this type, the
+    #   * <b> <code>LIVE_REPLAY</code> </b>: 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
@@ -644,11 +649,11 @@
     #     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.
     #
-    #   * <b> <code>ON_DEMAND</code> </b>\: For sessions of this type, the
+    #   * <b> <code>ON_DEMAND</code> </b>: 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
@@ -972,14 +977,14 @@
     # @option params [String] :playback_mode
     #   Whether to retrieve live, live replay, or archived, on-demand data.
     #
     #   Features of the three types of sessions include the following:
     #
-    #   * <b> <code>LIVE</code> </b>\: 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
+    #   * <b> <code>LIVE</code> </b>: 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.
     #
     #     <note markdown="1"> In `LIVE` mode, the newest available fragments are included in an
@@ -991,11 +996,11 @@
     #     available after a subsequent fragment is added to the playlist, the
     #     older fragment is not added, and the gap is not filled.
     #
     #      </note>
     #
-    #   * <b> <code>LIVE_REPLAY</code> </b>\: For sessions of this type, the
+    #   * <b> <code>LIVE_REPLAY</code> </b>: 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
@@ -1005,11 +1010,11 @@
     #     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.
     #
-    #   * <b> <code>ON_DEMAND</code> </b>\: For sessions of this type, the HLS
+    #   * <b> <code>ON_DEMAND</code> </b>: 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
@@ -1066,19 +1071,19 @@
     #   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.
+    #   * `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
+    #   * `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
+    #   * `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).
@@ -1490,10 +1495,10 @@
         operation: config.api.operation(operation_name),
         client: self,
         params: params,
         config: config)
       context[:gem_name] = 'aws-sdk-kinesisvideoarchivedmedia'
-      context[:gem_version] = '1.46.0'
+      context[:gem_version] = '1.47.0'
       Seahorse::Client::Request.new(handlers, context)
     end
 
     # @api private
     # @deprecated