
Amazon Interactive Video Service – Add Live Video to Your Apps and Websites - rengers
https://aws.amazon.com/blogs/aws/amazon-interactive-video-service-add-live-video-to-your-apps-and-websites/
======
reggieband
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.

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      $64

~~~
ALittleLight
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?

~~~
reggieband
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](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
    

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.

~~~
notyourday
It is worse than that.

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.

------
woeirua
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.

~~~
jedberg
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.

~~~
woeirua
Most of the competing services are built on AWS anyways, so it's not like
there's big problem switching back and forth...

------
moralestapia
>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) ?

~~~
mmcclure
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).

[1] [https://mux.com/blog/the-low-latency-live-streaming-
landscap...](https://mux.com/blog/the-low-latency-live-streaming-landscape-
in-2019/)

~~~
ponker
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

~~~
mmcclure
> all those Twitch streamers see their chats More than 4 seconds after the
> relevant video has elapsed

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.

~~~
ponker
Huh, thanks, I think I’m starting to get it. Is it that the connection-based
model needs the data “copied” into each user’s stream on the server-side while
the “stash the files in a bin” stateless model allows the networking hardware
to cache this data somewhere in memory and just copy it on the fly onto
different network links?

~~~
sudhirj
Stashing files–let's say that each file is one second long and is just
numbered with the unix timestamp – makes things cost effective because now the
server is just dropping files no 1,2,3,4... into a directory, and everyone is
pulling them out in sequence the way an other file would be downloaded. This
also allows exploiting the HTTP architecture – if you set the Cache-Control:
public headers on the files (which you can do happily because they'll never
change) they'll be cached at lots of places along the way, like CDNs, the
local ISP, the office network, etc. HTTPS blew out most of these caching
benefits, but at least the CDNs can cache the files at edges all over the
world.

------
pctf
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.

~~~
techntoke
Did you see the costs? Might as well use YouTube.

------
interesting_att
Does anyone know how this would compare to Twilio's programmatic video?
Specific use case is for livestreaming within a mobile app.

~~~
kwindla
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.

------
nameoda
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 :)

~~~
djaychela
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!

------
Terretta
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._

[https://patents.google.com/patent/US20020019978A1/en](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!

~~~
psds2
After you pointed this out I think I realized the target market - A tool to
build a platform for the rising live stream direct sales model.

[https://www.bloomberg.com/features/2020-viya-china-
livestrea...](https://www.bloomberg.com/features/2020-viya-china-livestream-
shopping/)

------
phenkdo
How does this compare to mux.com?

~~~
jon_dahl
Caveat: Mux founder.

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.

~~~
swyx
this was a great answer!

------
gpmcadam
TwitchAAS?

