Using Amazon IVS as ingest server

[chai2]

Hi there. Thank you so much for the medium article and this repo. Got me a pretty good start with WebRTC stuff.

I'm trying to implement an AWS IVS(Or Kinesis seem to be better??) approach - API_GetStream.html as my ingest server to stream video on my web application(in-works). Wondering where I need to configure Ingest server and Server Key? signaling_server?

The problem I'm trying to solve is basically a streamer "live-stream" from their device browser(without the need of downloading any broadcaster software like OBS. Sorry for the noob stupid question :) Any pointers are welcome.

[jeanpaulsio]

Not a noob question at all! Honestly, the implementation with AWS IVS or even Kinesis is a little bit out of my depth simply because I'm not familiar with those tools!

Let me do some research on those tools and see if I can point you in the right direction :)

How far were you able to get?

[chai2]

@jeanpaulsio - Thanks for your response. Was wondering, when you're going to get to this "issue" even though its more of an asking a recommendation :)

TLDR: Going to drop RTMP from the original design I had in mind and want to move forward with WebRTC so the "streamer" can stream from a browser(desktop or mobile) that can be viewed by ~50 to 100 users simultaneously. If it involves setting up an open-source server on AWS myself to republish WebRTC stream from browser to stream server and rebroadcast from the stream server to the viewers. Phew, when TLDR is so long lol 😁

So, I asked the following question around Reddit, and got some additional info since I started this thread.

I'm wondering if using a WebRTC to RTMP stream server(using AWS Interactive Video Service) will be more performant.

Any recommendations on a cost-effective solution for 1 user stream from a browser and viewed by say, 50 users?

Approach: Streamer Browser -> WebRTC to RTMP Adapter -> RTMP Server(AWS Interactive Video Server or similar) -> Video with Video.js in Browser for Viewers.

Responses:

If you need real-time (as in, people hear that person streaming within 500 milliseconds of them actually saying something), broadcaster sends WebRTC stream to a media server, which redistributes via WebRTC.

If you need "close to real-time", then IMO a much better option is: live HLS or DASH streams. Both of those are digestible by nearly everything, and distribution is dramatically easier than WebRTC. Broadcaster probably still sends WebRTC, but media server decodes/re-encodes/repackages to HLS or DASH.

I would not use RTMP. That's a proprietary format developed by Adobe for Flash, and it's pretty much junk. You're much better off using HLS or DASH.

tl;dr WebRTC is for "real-time". If you only need "close to real-time" (think 1-3 seconds) or "ten or twenty seconds of latency is fine (or even preferable, in some instances)", then HLS/DASH is 100% the way to go.

Decision:

At this point, I'm considering moving forward with WebRTC and not considering RTMP anymore, for the reasons you mentioned above(proprietary format developed by Adobe for Flash) and WebRTC being open source.

I'm currently in the exploration phase of solving my problem with AWS Kenisis, MediaLive, or Chime SDK.

Tried using some of third-party media server solutions like Twilio, AntMedia Stream, etc but, it's expensive $$$. AWS would definitely be cost-effective if I could crack it :)