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
Viewers Hours Min Best Worst
20000 10 $7,520 $14,020 $30,020
2000 6 $462 $852 $1,812
500 4 $83 $148 $308
200 2 $19 $32 $64In 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:
8.5 Mbps / 8 = 1.0625 MB/s
* 60 * 60 = 3825 MB/h
/ 1024 = 3.73 GB/h
* 0.08 $/GB = $0.30/hour
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.
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) ?
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.
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.
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.
I assume you will only be charged for full hd if the client is streaming it
In order to do streaming well (i.e. to prevent consumers from running away and coming back), one needs take an incoming stream and re-encode it in multiple bit rates - 1080p stream would have not only 8Mbit/sec but also 2Mbit/sec, and 128Kbit/sec qualities. In addition to that for a decent distribution there should also be a 4Mbit/sec and probably 64kbit/sec streams.
As players either hunt down or hunt up, one would be carrying a pretty big number of random cold chunks that are unlikely to be requested again at the edge, which has a negative impact on hit CDN hit rates.
I'm sure that I would have got a better deal if only I'd figured out how...
That's so short sighted. Anyone who wanted to cheat could do anything to circumvent that - first comes to mind is plastering the wall with notes...
I do find it funny that people get mad about this "invasion of privacy" except this is exactly what a live in person proctor is looking for.
Yep! I think Twitch can sometimes be at 4 seconds or less for what it's worth, but yes, that delay is real. It's generally not really noticeable because the communication is totally async; the streamer is doing other stuff, finishing other thoughts, etc, then can get to messages as they see them.
> can you explain what you mean by “stateful”?
Sure! I was talking about what kind of connection is necessary to deliver the video. A lot of real-time video solutions require stateful connections to the client, which means that once the client connects, the connection is kept open, and video data is streamed via that connection. Common examples on the web are things like WebSockets and WebRTC, but it gets really expensive because you basically have to maintain a persistent connection with every single viewer and it makes it impossible (or extremely difficult) to do any kind of meaningful caching.
Stateless connections on the other hand are most of your common HTTP requests. The client asks for a resource, and gets it back. No prior connection setup is required, servers, networks, whatever can change between each request and everything will merrily chug along, which makes it much easier to scale.