Amazon Interactive Video Service – Add Live Video to Your Apps and Websites • Hacker News Board

Re: Amazon Interactive Video Service – Add Live Video to Your Apps and Websites

#41

Post by kwindla » Thu, Jul 16, 2020, 4:46 AM UTC

mmcclure wrote: post #17

moralestapia wrote: post #12

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

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 down…

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.

Re: Amazon Interactive Video Service – Add Live Video to Your Apps and Websites

#42

Post by kwindla » Thu, Jul 16, 2020, 4:54 AM UTC

interesting_att wrote: post #33

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

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.

Re: Amazon Interactive Video Service – Add Live Video to Your Apps and Websites

#43

Post by jpalomaki » Thu, Jul 16, 2020, 5:00 AM UTC

ALittleLight wrote: post #37

reggieband wrote: post #2

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…

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…

Price is likely set based more on how much customers are willing to pay for this service. The cost to provide the service can be much lower.

Target market could be for example companies that provide live streams as streams as service (equipment, people, production etc)

Re: Amazon Interactive Video Service – Add Live Video to Your Apps and Websites

#44

Post by goldenshale » Thu, Jul 16, 2020, 5:29 AM UTC

ALittleLight wrote: post #37

reggieband wrote: post #2

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…

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…

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.

Re: Amazon Interactive Video Service – Add Live Video to Your Apps and Websites

#45

Post by loosescrews » Thu, Jul 16, 2020, 5:57 AM UTC

woeirua wrote: post #8

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.

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.

Re: Amazon Interactive Video Service – Add Live Video to Your Apps and Websites

#46

Post by reggieband » Thu, Jul 16, 2020, 6:11 AM UTC

ALittleLight wrote: post #37

reggieband wrote: post #2

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…

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…

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.

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.

Re: Amazon Interactive Video Service – Add Live Video to Your Apps and Websites

#47

Post by djaychela » Thu, Jul 16, 2020, 6:40 AM UTC

nameoda wrote: post #14

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!

Re: Amazon Interactive Video Service – Add Live Video to Your Apps and Websites

#48

Post by donavanm » Thu, Jul 16, 2020, 6:48 AM UTC

ponker wrote: post #40

mmcclure wrote: post #27

Earlier quoted context omitted.

> 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 wh…

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?

Its not just that it can be cached, but that it can use very standard existing infrastructure like HTTP CDNs, mobile browsers, etc. The limitation is that the audio/video is encoded as segments, each a few seconds long. Because of this it looks kind of like serial batch processing with latency constraints based on the batch size (segment duration). This is in contrast to say webrtc or rtmp thats a lot closer to a multiplexed stream of data.

Re: Amazon Interactive Video Service – Add Live Video to Your Apps and Websites

#49

Post by kvogt » Thu, Jul 16, 2020, 7:40 AM UTC

moralestapia wrote: post #12

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

Tradeoffs, transcoding, and delivery.

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

Re: Amazon Interactive Video Service – Add Live Video to Your Apps and Websites

#50

Post by jorams » Thu, Jul 16, 2020, 7:57 AM UTC

ALittleLight wrote: post #37

reggieband wrote: post #2

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…

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…

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.