Price is pretty good, surprisingly. Looks like they take RTMP in and output m3u8 (probably fmp4 behind the scenes). 2 second latency is also not bad.
Larger streamers on Twitch can get ~20k concurrent viewers. A long streaming day would be 10 hours. They would also be streaming from NA so using their example pricing suggests:
Input: $2/hour * 10 hours = $20
Output: $0.15 * 10 * 20,000 = $30k
A worst case scenario of $30,020/day of streaming. Still seems financially unviable. I guess Twitch can stay in business for now.
Until 5 years ago I was CTO of a company called Livestation where we handled live streaming of about 40 news broadcasters including Al Jazeera, BBC World, CNN International, etc.
In my stint we dealt with the Egyptian and Turkish uprisings. The relevant diasporas were super keen to see what was going on in all those countries, and often the only places you could see them online was with us (we had raw feeds in a few places).
There is no way we would have paid $752/hour for 20,000 users for 10 hours. We would have dropped the bit rate way, way down (which is fine for most content), and we'd agreed pretty decent bandwidth rates all round.
Depending on context, 2 second latency might not be worth it either - spend less, get 10 second latency and use HLS using an off the shelf CDN, and you're going to pull the price down even further. When Akamai can offer you a better deal than this, you have to wonder how good a deal this is. :-)
We did end up using RTMP a lot for a P2P live streaming product, but that never took off, and eventually the company folded. Fun times, though.
> When Akamai can offer you a better deal than this, you have to wonder how good a deal this is. :-)
If you were doing the volume of traffic necessary to get the Akamai discount in the range you are suggesting then you are also going to be able to negotiate Amazon pricing in a similar way. It is unfair to compare theoretical bulk CDN pricing to non-discounted Amazon pricing. It would be like negatively comparing the published price of some other CDN to your private knowledge of deals you did with Akamai that probably included contractual commitments.
If you go by published CDN pricing (I use Fastly as an example in another post below) and assume you are pushing close to the maximum bitrate then the comparison is actually reasonably fair. Anything outside of that is speculation based on theoretical deals you might negotiate based on theoretical usages.
However, I would have no problem agreeing that building your own system to handle large scale would probably get to a lower $/GB. But then you have to build it, maintain it, monitor it, etc.
Imagine you're a University that needs to, as quickly as possible, build a system to have streaming video for all your classes. Otherwise, you've got students and parents saying they want their money back because they paid for real classes, with Q&A and a live professor, and not pre-recorded videos.
200 viewers for 2 hours sound about right for a typical large University lecture. Typical students are paying hundreds or even thousands of dollars per lecture. $64 per class would put a dent into the University's budget, but not a huge one. And the fact that you can now scale a class to 1000 to 2000 students simultaneously, well that's cheaper than hiring more professors.
In short, I don't think this is meant to compete with Twitch or Youtube. That doesn't mean it doesn't have a niche it can work within.
(Bias note: I work for a totally unrelated branch of AWS. My thoughts and words are my own and are not representing my employer in any way.)
My University had GSuite for all students and faculty. Meet supports up to 250 participants for a normal call and Livestream only for up to 100,000 viewers.
I imagine Microsoft has a similar offering for schools that use their products. I don't see a case where it makes sense for schools to be rolling their own livestream platform and paying these fees.
Edit: I'm not positive if the Livestream capabilities are included in the free Education package or just the enterprise package.
I don't get how it can cost so much, and also how YouTube or Twitch would let you stream for free. They can't be making that much money off a stream, can they?
A 10 hour stream viewed by 20,000 people... My recollection of YouTube is that they pay the creator approximately a dollar per thousand views, if that's a third of what they make, then they make 3 dollars per thousand views. Assume YouTube counts a view as ten minutes, so 200k hours of streaming would be 1,200,000 views (200k hours to minutes / 10) would be (120*3) 3,600 dollars?
Something seems off by an order of magnitude. Is the markup that high? Did I make a calculating mistake?
You can't compare it to how much it costs YouTube. You have to compare it to how much it would take to build yourself.
Here is Fastly CDN pricing https://www.fastly.com/pricing which is a good enough indication of the market value of data transfer costs. Note that CDNs charge in $/GB (big B byte) and video is usually considered in Mbps (small b bit). Consider that the most costly tier of Amazon service ($0.17/hour) is based on a 8.5 Mbps 1080p stream. You should be able to use that to calculate if the service is competitive to bulk data transfer.
So based on that math, not a bad deal. Of course, Amazon is assuming (rightly) that with adaptive bit rate most people won't be streaming 8.5 Mbps continuously. And since they own their own CDN (Cloudfront) they aren't paying $0.08/GB. In fact, anyone doing significant bandwidth would get a discount.
This is all very hand-wavy math but it should give you some insight as to why there are so few competitors in the consumer video space. Video delivery is just plain expensive from a data transfer perspective.
I don't have a particularly good source for this, but I've seen this reported by major YouTubers: the advertising revenue split on YouTube is 45/55. YouTube keeps 45%, the creator gets 55%. So if the creator gets $1, YouTube keeps about $0.80.
Because most recordings are never actually streamed to that many people. My guess is that the popular and expensive streams make profit while the rest cost basically nothing to host.
I assume you're being sarcastic/coy, but for those that might not know, Amazon owns Twitch. I'm guessing this service is them white labeling Twitch's tech infrastructure, and priced such that someone could not make a Twitch competitor with reasonable profit margins.
For what it's worth, that's just income directly from sponsored content. The bulk of livable streaming income (outside of huge endorsements) comes from monthly subscriptions, so conversion rate matters as much as total viewership.
This isn’t for consumer streaming — those people will still use Twitch. This is for people building things like corporate meeting software for which the users will never be close to 20,000 concurrent and the costs of $30k don’t even get looked at.
Yup agreed -- looking at it from the lens of building a streaming website that scales to that many viewers per stream, it isn't going to be cheap (but cool it can handle it if you put the money in I guess).
I assume this is more targeted towards universities where they have a max of 300 students (at least that's what my university capped classes at) and they need something to get started quickly. At most they may stream for like 6 hours a day for each class. You don't even need good quality -- lowest tier quality (SD) ends up being
$2.00 per hour * 6 = $12
$0.0375 per hour * 6 * 500 = $67.50
Honestly ~$80-100 per day to stream to all your students? Still kinda expensive I guess but might be a small price to pay for a university if it means they can offer streaming education. Not to mention 99% of the time students don't even tune in and just watch the VOD.
Weird that they just not charge for egress as with other services.
Also it seems a lot cheaper, assuming full hd is 1 MB/s. That would mean approx 3.6GB/h which would come out at 0.54$/h in comparison to their 0.15$/h pricing
> Weird that they just not charge for egress as with other services.
My guess is they are charging ingress in place of some equivalent of compute necessary to transmux. That cost is fixed regardless of number of viewers.
Their docs state "The maximum input for a Standard channel is 8.5 Mbps and 1080p resolution (full HD)." but they could be outputting something less than that.
The proliferation of half-baked services at AWS needs to end. There are way too many services that are just enticing enough to get you to play around with it, but then you realize it's totally crippled and unusable for most actual workflows, or that someone else already does it way better. They need to focus on a few that are commercially viable and let other companies prove out the rest.
I've always said AWS is the master of the 80% solution. They make a product that gets you most of the way there.
The reason they can get away with this is because your data is already at AWS. It's a lot easier to use a new service if the data you need is already there.
That's their advantage. That's where the real lock in comes from. Not from you using their services, but from you keeping your data there.
This seems to be a large part of the business model though. A platform play only needs to get you in the door and hooked on the almost-great bit of the platform you needed.
They win when the first comment in any technical-requirements-finding session is "well AWS has <X>... that could work?".
New companies choose AWS almost by default these days, and the alphabet soup of services available means that it's got an answer for just about any paradigm you're interested in, which means there's no reason to leave.
The proliferation of half-baked services at AWS will never end. They won't become fully baked either, because that doesn't make business sense -- doing just enough to capture new business is most efficient, and in the worst case just let some partner build on your platform and offer their services.
A lot of people would rather use 20 mediocre products from one vendor than 20 fantastic products from different vendors. I’m like this with Target —- I don’t want to go to multiple stores so I limit my household items to things that Target sells.
There are plenty of companies thoroughly locked in to AWS infrastructure. They don't need to lure in new companies with these services (though the wide variety helps). The point is to get companies already locked in to start using these services and lock themselves in more, so they have even more difficulty ever leaving.
There are other cloud providers, some of which are trying the fewer, higher quality services strategy. You can choose one of them if you prefer their offerings. If your answer is that they are missing some niche feature that you need, then I think you found out why AWS' strategy is working.
No kidding, when I met with an AWS salesperson, I joked that AWS had more services than there are nouns in the dictionary. He quickly rattled off the current grand total of services, but would not make an attempt at listing them all.
>Firstly, the video is low latency, which means that the time between you broadcasting and the time the video shows up on your viewer’s screens can be as low as 2-3 seconds.
Excuse my ignorance, and I'm sure 2 seconds is probably an engineering feat, but I'm genuinely curious. What is it that prevents latency to go as down as a few hundred ms (pretty much close to and IP round trip) ?
1) If you want very low latency, any network jitter or delays will cause pauses on the viewer side and "skips" when the feed catches up after a brief dropout. This is fine for video chat, where a little blip doesn't interrupt the experience. For live streams with 30k+ viewers, it's pretty annoying and very noticeable if the audio cuts out or skips. A 2-3 second window is typically large enough to paper over any jitter or retransmits due to packet loss between the broadcaster and Twitch servers.
2) Transcoding can be done with very low latency, but it's harder to scale horizontally and uses more bandwidth than if you give yourself a few hundred ms of buffer. Larger buffers enable better compression. Transcoding is needed if you want to stream to mobile, web, etc. in multiple formats, bitrates, or resolutions.
3) Chunked HTTP content is much easier to serve than RTMP or WebRTC-style content. You can use nginx or drop your content on a low-cost CDN. The caveat is that chunking generally introduces latency unless you do something fancy such as streaming chunks as they're being written to disk.
This definitely isn't ignorance, it's a very, very common question. The TL;DR on it is: cost.
The most cost-effective way of delivering video is using some form of HTTP streaming (like HLS or DASH). In a nutshell, the player downloads a manifest that tells it where to find chunks of video, which are downloaded and cached in normal, commodity CDNs. Everything is stateless and is scaled like any other form of HTTP download. To do all of this you end up needing to transcode the incoming stream. All along the way through this process introduces latency, and for reference 20 seconds is perfectly normal HLS latency, so credit where credit's due, this is really impressive. One of my colleagues wrote about the state of low latency last year[1], and considered < 4 seconds to be "ultra low latency"...that's really rare, particularly among platforms.
You can get lower latency, of course, but typically that involves stateful connections. All of that cheap commodity stuff that comes with HTTP streaming above goes away, and scaling to a large number of viewers can get extremely costly (and operationally difficult).
mmcclure is way too polite to say so, but Amazon IVS is definitely not going to give you 2s latency.
Currently, IVS configured for "ultra low latency" is using HLS segments that are three seconds long. The client tries not to buffer more than one segment, so on a good network connection you'll see ~4 seconds of latency.
In theory, you could start playing the video while you're still downloading the first segment. That's how you'd get ~2s of latency. But the AWS player doesn't actually do that. And for good reason. These are TCP connections, so if there's any packet loss at all, you'll have to either buffer or skip the segment and change bitrates. Starting the video and then immediately buffering is a pretty poor user experience.
This is pretty easy to test. I just did, twice: streaming from OBS on my desktop and then directly from our compositing servers in the cloud. In both cases the latency was ~4 seconds.
> but typically that involves stateful connections [...] and scaling to a large number of viewers can get extremely costly (and operationally difficult)
This is why we built Pushpin, to make it easier to handle stateful connections at scale. The project is mostly intended for moving application data, but it does work for media streaming too. See our live MP3 demo [1]. The backend runs GStreamer in a loop to produce the audio, and has no awareness of client connections. Pushpin moves the bytes and knows nothing about audio or codecs.
You mean all those Twitch streamers see their chats More than 4 seconds after the relevant video has elapsed? And can you explain what you mean by “stateful”? Thanks
Because the protocol in question has support for caching through CDNs. If there are two viewers in the same city you can reduce your global bandwidth needs by half. There are alternatives like WebRTC that do not support caching and allow sub 1 second latency but they are also far more expensive.
I wonder if this will help solve problems created by shelter in place. It seems like it would be easy to spin up a website to stream classes to students using this.
It depends on what you mean by "live." Twilio video is WebRTC, so it's very low latency. (Much lower than IVS.) But Twilio scales only to 50 people watching at a time, and costs ~10x what IVS costs.
On the other hand, IVS scales to an infinite audience. But IVS has 4+ seconds of latency. Which might not be live enough for your use case.
With IVS, you'll also need some way of capturing the video, encoding it as RTMP, and sending it to AWS. Not terribly hard if you've done a fair amount of video work previously, but not trivial if you haven't.
If IVS is roughly what you need, it's very much worth looking at Mux. Great APIs, great support, been around much longer, and there's excellent sample code for building stuff on mobile.
If you do need interactive latency (<200ms), you might also want to check us out at Daily.co. We compete with Twilio programmable video, have been around roughly as long, scale to 200 people in a live session, and we can stream to Mux for infinitely scalable recording and IVS-style live distribution.
The audio at the top of the page, marked "Voiced by Amazon Polly" has so much dissonance - they've inserted fake sounds to seem as if the speaker is drawing breath, which sounds pretty realistic, but the actual enunciation of words is so robotic and fake-sounding :)
I spend HOURS editing breaths and other noises out of the VOs I do... and they put them in? Why on earth would you do that? The voice is the unconvincing part - if that was 100% realistic, then the breaths to try to convince the listener that it's real would not be needed!
Yes, I immediately noticed that when I started listening too. You can hear him inhale at the start of a paragraph which is kind of freaky, because his voice is super-robotic.
Amazon Polly is in the uncanny valley of text to speech now.
Sometimes it seems things change quickly online, sometimes not so quickly.
It’s been about 20 years since we built “broadband activated merchandising” (aka “BAM”) for selling wrestling hats and t-shirts at scale to millions of viewers, contextually triggered along side WWE live event video streams:
A system and method for enhancing electronic commerce and/or communicating information concerning products and/or services in connection with multimedia (e.g., video) transmission and delivery is provided. The system and method facilitate targeted marketing and/or merchandising in connection with video streams delivered to users across a computer network, e.g., the Internet and/or the World Wide Web, by synchronizing ancillary content with the video stream. The method/system may be used in a broad range of applications for live, taped live and on-demand video streams.
In your 640 or 800 px wide browser window, beside the live stream (320x240 at 700 kbps, ahem!), you had a product pane showing contextual offers you could add to your cart, and then check out when the event was over.
The stream metadata was fed by a producer watching the live action and using a e-commerce store event dashboard to choose what products to promote when.
For comparison, from this AWS article:
The team have added the ability to send timed metadata along with the video so that you can fire events in your application at crucial points in the live stream... you can build experiences that create a more valuable relationship with your viewers on your own websites and applications. For example, if you were live-streaming a product launch, you could synchronize additional product information to be displayed as new products appear in the video. You could even show a buy now button that allows viewers to purchase the exact product they are watching at that moment on the live-stream.
Mux supports both VOD and Live video (and seamless transition from Live to VOD); this service is only live streaming. We’re a crack team of video experts who work really closely with our customers. Better developer experience, documentation, and support. More feature-rich and powerful. 100% focused on building the best video products for developers, rather than being AWS service #213.
In general, we don’t like to bad-mouth competitors and we have lots of friends in engineering at Twitch and AWS (hi folks!), so hopefully this won’t be taken the wrong way. Twitch has built a great platform and kudos to them for this service, and obviously AWS is the most successful software business in the world today. Online video is growing quickly and there is room for a lot of players to succeed.
Readit News
Larger streamers on Twitch can get ~20k concurrent viewers. A long streaming day would be 10 hours. They would also be streaming from NA so using their example pricing suggests:
Input: $2/hour * 10 hours = $20
Output: $0.15 * 10 * 20,000 = $30k
A worst case scenario of $30,020/day of streaming. Still seems financially unviable. I guess Twitch can stay in business for now.
EDIT:
Basic table
In my stint we dealt with the Egyptian and Turkish uprisings. The relevant diasporas were super keen to see what was going on in all those countries, and often the only places you could see them online was with us (we had raw feeds in a few places).
There is no way we would have paid $752/hour for 20,000 users for 10 hours. We would have dropped the bit rate way, way down (which is fine for most content), and we'd agreed pretty decent bandwidth rates all round.
Depending on context, 2 second latency might not be worth it either - spend less, get 10 second latency and use HLS using an off the shelf CDN, and you're going to pull the price down even further. When Akamai can offer you a better deal than this, you have to wonder how good a deal this is. :-)
We did end up using RTMP a lot for a P2P live streaming product, but that never took off, and eventually the company folded. Fun times, though.
If you were doing the volume of traffic necessary to get the Akamai discount in the range you are suggesting then you are also going to be able to negotiate Amazon pricing in a similar way. It is unfair to compare theoretical bulk CDN pricing to non-discounted Amazon pricing. It would be like negatively comparing the published price of some other CDN to your private knowledge of deals you did with Akamai that probably included contractual commitments.
If you go by published CDN pricing (I use Fastly as an example in another post below) and assume you are pushing close to the maximum bitrate then the comparison is actually reasonably fair. Anything outside of that is speculation based on theoretical deals you might negotiate based on theoretical usages.
However, I would have no problem agreeing that building your own system to handle large scale would probably get to a lower $/GB. But then you have to build it, maintain it, monitor it, etc.
200 viewers for 2 hours sound about right for a typical large University lecture. Typical students are paying hundreds or even thousands of dollars per lecture. $64 per class would put a dent into the University's budget, but not a huge one. And the fact that you can now scale a class to 1000 to 2000 students simultaneously, well that's cheaper than hiring more professors.
In short, I don't think this is meant to compete with Twitch or Youtube. That doesn't mean it doesn't have a niche it can work within.
(Bias note: I work for a totally unrelated branch of AWS. My thoughts and words are my own and are not representing my employer in any way.)
I imagine Microsoft has a similar offering for schools that use their products. I don't see a case where it makes sense for schools to be rolling their own livestream platform and paying these fees.
Edit: I'm not positive if the Livestream capabilities are included in the free Education package or just the enterprise package.
More likely they just email links to Zoom conferences or something to that effect, no?
A 10 hour stream viewed by 20,000 people... My recollection of YouTube is that they pay the creator approximately a dollar per thousand views, if that's a third of what they make, then they make 3 dollars per thousand views. Assume YouTube counts a view as ten minutes, so 200k hours of streaming would be 1,200,000 views (200k hours to minutes / 10) would be (120*3) 3,600 dollars?
Something seems off by an order of magnitude. Is the markup that high? Did I make a calculating mistake?
Here is Fastly CDN pricing https://www.fastly.com/pricing which is a good enough indication of the market value of data transfer costs. Note that CDNs charge in $/GB (big B byte) and video is usually considered in Mbps (small b bit). Consider that the most costly tier of Amazon service ($0.17/hour) is based on a 8.5 Mbps 1080p stream. You should be able to use that to calculate if the service is competitive to bulk data transfer.
Quick math:
So based on that math, not a bad deal. Of course, Amazon is assuming (rightly) that with adaptive bit rate most people won't be streaming 8.5 Mbps continuously. And since they own their own CDN (Cloudfront) they aren't paying $0.08/GB. In fact, anyone doing significant bandwidth would get a discount.This is all very hand-wavy math but it should give you some insight as to why there are so few competitors in the consumer video space. Video delivery is just plain expensive from a data transfer perspective.
Target market could be for example companies that provide live streams as streams as service (equipment, people, production etc)
I assume you're being sarcastic/coy, but for those that might not know, Amazon owns Twitch. I'm guessing this service is them white labeling Twitch's tech infrastructure, and priced such that someone could not make a Twitch competitor with reasonable profit margins.
Edit: I'd googled this before, but apparently I found the right way to ask: this site says from 1c to $1/hour/viewer. https://wallethacks.com/how-much-do-twitch-streamers-make/#:....
I assume this is more targeted towards universities where they have a max of 300 students (at least that's what my university capped classes at) and they need something to get started quickly. At most they may stream for like 6 hours a day for each class. You don't even need good quality -- lowest tier quality (SD) ends up being
$2.00 per hour * 6 = $12 $0.0375 per hour * 6 * 500 = $67.50
Honestly ~$80-100 per day to stream to all your students? Still kinda expensive I guess but might be a small price to pay for a university if it means they can offer streaming education. Not to mention 99% of the time students don't even tune in and just watch the VOD.
Also it seems a lot cheaper, assuming full hd is 1 MB/s. That would mean approx 3.6GB/h which would come out at 0.54$/h in comparison to their 0.15$/h pricing
My guess is they are charging ingress in place of some equivalent of compute necessary to transmux. That cost is fixed regardless of number of viewers.
Their docs state "The maximum input for a Standard channel is 8.5 Mbps and 1080p resolution (full HD)." but they could be outputting something less than that.
The reason they can get away with this is because your data is already at AWS. It's a lot easier to use a new service if the data you need is already there.
That's their advantage. That's where the real lock in comes from. Not from you using their services, but from you keeping your data there.
They win when the first comment in any technical-requirements-finding session is "well AWS has <X>... that could work?".
New companies choose AWS almost by default these days, and the alphabet soup of services available means that it's got an answer for just about any paradigm you're interested in, which means there's no reason to leave.
The proliferation of half-baked services at AWS will never end. They won't become fully baked either, because that doesn't make business sense -- doing just enough to capture new business is most efficient, and in the worst case just let some partner build on your platform and offer their services.
But I agree, too much stuff under the AWS umbrella, and trivial ones like this, will impact the brand image.
Deleted Comment
Excuse my ignorance, and I'm sure 2 seconds is probably an engineering feat, but I'm genuinely curious. What is it that prevents latency to go as down as a few hundred ms (pretty much close to and IP round trip) ?
1) If you want very low latency, any network jitter or delays will cause pauses on the viewer side and "skips" when the feed catches up after a brief dropout. This is fine for video chat, where a little blip doesn't interrupt the experience. For live streams with 30k+ viewers, it's pretty annoying and very noticeable if the audio cuts out or skips. A 2-3 second window is typically large enough to paper over any jitter or retransmits due to packet loss between the broadcaster and Twitch servers.
2) Transcoding can be done with very low latency, but it's harder to scale horizontally and uses more bandwidth than if you give yourself a few hundred ms of buffer. Larger buffers enable better compression. Transcoding is needed if you want to stream to mobile, web, etc. in multiple formats, bitrates, or resolutions.
3) Chunked HTTP content is much easier to serve than RTMP or WebRTC-style content. You can use nginx or drop your content on a low-cost CDN. The caveat is that chunking generally introduces latency unless you do something fancy such as streaming chunks as they're being written to disk.
Source: I designed the video streaming network that Twitch was running when Amazon acquired it. More info here http://highscalability.com/blog/2010/3/16/justintvs-live-vid...
The most cost-effective way of delivering video is using some form of HTTP streaming (like HLS or DASH). In a nutshell, the player downloads a manifest that tells it where to find chunks of video, which are downloaded and cached in normal, commodity CDNs. Everything is stateless and is scaled like any other form of HTTP download. To do all of this you end up needing to transcode the incoming stream. All along the way through this process introduces latency, and for reference 20 seconds is perfectly normal HLS latency, so credit where credit's due, this is really impressive. One of my colleagues wrote about the state of low latency last year[1], and considered < 4 seconds to be "ultra low latency"...that's really rare, particularly among platforms.
You can get lower latency, of course, but typically that involves stateful connections. All of that cheap commodity stuff that comes with HTTP streaming above goes away, and scaling to a large number of viewers can get extremely costly (and operationally difficult).
[1] https://mux.com/blog/the-low-latency-live-streaming-landscap...
Currently, IVS configured for "ultra low latency" is using HLS segments that are three seconds long. The client tries not to buffer more than one segment, so on a good network connection you'll see ~4 seconds of latency.
In theory, you could start playing the video while you're still downloading the first segment. That's how you'd get ~2s of latency. But the AWS player doesn't actually do that. And for good reason. These are TCP connections, so if there's any packet loss at all, you'll have to either buffer or skip the segment and change bitrates. Starting the video and then immediately buffering is a pretty poor user experience.
This is pretty easy to test. I just did, twice: streaming from OBS on my desktop and then directly from our compositing servers in the cloud. In both cases the latency was ~4 seconds.
This is why we built Pushpin, to make it easier to handle stateful connections at scale. The project is mostly intended for moving application data, but it does work for media streaming too. See our live MP3 demo [1]. The backend runs GStreamer in a loop to produce the audio, and has no awareness of client connections. Pushpin moves the bytes and knows nothing about audio or codecs.
[1] http://audiostream.fanoutapp.com/
On the other hand, IVS scales to an infinite audience. But IVS has 4+ seconds of latency. Which might not be live enough for your use case.
With IVS, you'll also need some way of capturing the video, encoding it as RTMP, and sending it to AWS. Not terribly hard if you've done a fair amount of video work previously, but not trivial if you haven't.
If IVS is roughly what you need, it's very much worth looking at Mux. Great APIs, great support, been around much longer, and there's excellent sample code for building stuff on mobile.
If you do need interactive latency (<200ms), you might also want to check us out at Daily.co. We compete with Twilio programmable video, have been around roughly as long, scale to 200 people in a live session, and we can stream to Mux for infinitely scalable recording and IVS-style live distribution.
Amazon Polly is in the uncanny valley of text to speech now.
It’s been about 20 years since we built “broadband activated merchandising” (aka “BAM”) for selling wrestling hats and t-shirts at scale to millions of viewers, contextually triggered along side WWE live event video streams:
A system and method for enhancing electronic commerce and/or communicating information concerning products and/or services in connection with multimedia (e.g., video) transmission and delivery is provided. The system and method facilitate targeted marketing and/or merchandising in connection with video streams delivered to users across a computer network, e.g., the Internet and/or the World Wide Web, by synchronizing ancillary content with the video stream. The method/system may be used in a broad range of applications for live, taped live and on-demand video streams.
https://patents.google.com/patent/US20020019978A1/en
In your 640 or 800 px wide browser window, beside the live stream (320x240 at 700 kbps, ahem!), you had a product pane showing contextual offers you could add to your cart, and then check out when the event was over.
The stream metadata was fed by a producer watching the live action and using a e-commerce store event dashboard to choose what products to promote when.
For comparison, from this AWS article:
The team have added the ability to send timed metadata along with the video so that you can fire events in your application at crucial points in the live stream... you can build experiences that create a more valuable relationship with your viewers on your own websites and applications. For example, if you were live-streaming a product launch, you could synchronize additional product information to be displayed as new products appear in the video. You could even show a buy now button that allows viewers to purchase the exact product they are watching at that moment on the live-stream.
Pretty cool to see this descendant!
https://www.bloomberg.com/features/2020-viya-china-livestrea...
Mux supports both VOD and Live video (and seamless transition from Live to VOD); this service is only live streaming. We’re a crack team of video experts who work really closely with our customers. Better developer experience, documentation, and support. More feature-rich and powerful. 100% focused on building the best video products for developers, rather than being AWS service #213.
In general, we don’t like to bad-mouth competitors and we have lots of friends in engineering at Twitch and AWS (hi folks!), so hopefully this won’t be taken the wrong way. Twitch has built a great platform and kudos to them for this service, and obviously AWS is the most successful software business in the world today. Online video is growing quickly and there is room for a lot of players to succeed.