This repository has been archived by the owner on Apr 19, 2023. It is now read-only.
Replies: 1 comment 2 replies
-
Would it be reasonable to refactor the elemental implementation to center around live playout of mp4 files in s3 through medialive and keep the IVS implementation as the standard "live streaming" implementation? This way many different use cases and there is less confusion around why you would pick IVS or Elemental. |
Beta Was this translation helpful? Give feedback.
2 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hello folks,
We've had multiple reports of folks accidentally racking up large bills with the AWS Elemental Live-based lives streaming resource. With the launch of IVS and it's simplified pricing, we're considering the future of the Elemental based approach within amplify-video.
As of today, there isn't much functional difference between elemental and ivs implementations within the project. There's a ton of features we could implement with elemental, but these have been largely backlogged to allow focus on fulfilling the "framework" vision as opposed to focusing on depth within each resource. For example, we're planning to design an player builder that will integrate nicely with the backend resources.
Further, maintaining and implementing two service categories the effectively accomplish the same thing is not a great experience for maintainers or users. Why should a user have to chose IVS or Elemental - shouldn't they just have to specify "live stream" and we use the right service for the job?
Option A: We deprecate the existing AWS Elemental implementation until we can refactor the approach (using cloudfromation) and add value-added features that are unique to those services
Option B: We continue to support AWS Elemental in maintenance mode
Option C: ?
If you have opinions on the future of live streaming resources within the project, we'd love to hear them!
Beta Was this translation helpful? Give feedback.
All reactions