Allow specifying an endpoint to be used for S3 requests. This makes
it possible to use integrations providing object storage based on S3
API like MinIO.
When the endpoint-uri property is specified, the endpoint resolver to
use will be overridden when making S3 requests.
Ideally, when player encounter PLAYLIST-TYPE is VOD, player should
not reload the playlist. For playlist-type=vod, initially we put
PLAYLIST-TYPE=EVENT, and later change it to VOD, which confuse some
players so we shold put ENDLIST here.
In any case putting ENDLIST is right thing to do to indicate no new
segment will be added to playlist.
in current implementation EXT-X-ENDLIST is never set for any playlist-type.
After calling playlist.stop(), during write_final_playlist() is called.
in final playlist write, segment is not added but update_playlist is called.
and update_playlist reset end_list again, so plugin never put ENDLIST.
STS provide temporary credentials to access AWS resource. Temporary
credentials include, AccessKeyId, SecretAccessKey and SessionToken.
With session-token property, element will be able to use temporary
credentials. When session-token is not set, element can use long
term credentials.
Keeping the upload-part-retry-duration & complete-upload-retry-duration
properties changes the semantics in comparison to their usage in
rusotos3sink. Deprecate these two properties and add a warning while
making them noop.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/759>
`PadTemplate::caps()` returns a reference to the caps now instead of a
new strong reference, so keeping the template in scope as long as the
caps reference is required.
warning: this expression borrows a value the compiler would automatically borrow
--> net/reqwest/tests/reqwesthttpsrc.rs:126:56
|
126 | async move { Ok::<_, hyper::Error>((&mut *http_func.lock().unwrap())(req)) }
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: change this to: `(*http_func.lock().unwrap())`
|
= note: `#[warn(clippy::needless_borrow)]` on by default
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#needless_borrow
This implements a default timeout and retry duration for the remaining
S3 requests that were still able to be blocked indefinitely. There are 3
classes of operations: multipart upload creation/abort (should not take
too long), uploads (duration depends on part size), multipart upload
completion (can take several minutes according to documentation).
We currently only expose the part upload times as configurable, and hard
code the rest. If it seems sensible, we can expose the other two sets of
parameters as well.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/690>
Previously, the actual reading from the streaming body of a GetObject
request was not within the same timeout/retry path as the dispatch of
the HTTP request itself. We consolidate these two into a single async
block and create a sum type to encapsulate the rusoto and std library
error paths within that future.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/690>
Have seen a few times where machines that are in perfect time sync with a good source the requests fail with `RequestExpired` errors.
https://docs.aws.amazon.com/transcribe/latest/dg/CommonErrors.html
While not perfect, bumping to five minutes gives more a chance that the signed requests to start streaming won't be expired.
Rusoto does not implement timeouts or retries for any of its HTTP
requests. This is particularly problematic for the part upload stage of
multipart uploads, as a blip in the network could cause part uploads to
freeze for a long duration and eventually bail.
To avoid this, for part uploads, we add (a) (configurable) timeouts for
each request, and (b) retries with exponential backoff, upto a
configurable duration.
It is not clear if/how we want to do this for other types of requests.
The creation of a multipart upload should be relatively quick, but the
completion of an upload might take several minutes, so there is no
one-size-fits-all configuration, necessarily.
It would likely make more sense to implement some sensible hard-coded
defaults for these other sorts of requests.
