Livestream concurrency when streaming just with a browser

Hello,

I am planning to use api.video to offer a streaming service in my country, so I am developing the whole process so that I can check whether it works according to the plan.

Since I did not find .NET SDK I have developed a small one by myself. It works, but when developing client side, I got some questions:

  1. I don’t want customer who does the live stream to install anyting in his local computer so I want a 100% web based solution. If I create a websocket server in a remote server, what about performance of the streaming? the server will have an encoder installed, so the client computer, by mean of the browser, will send the streaming without any enconding to the server by using socket.io js library.

  2. socket.io library is the only option to transmit video to rtmp server?

  3. When many people are streaming at the same time, what about api.video performance? Can I know about some experience in a real world application?

  4. The same as above, what about performance for saved videos to be watched at the same time?

  5. I will have the option to save the video so that visitors will be able to watch on-demand videos if they could not watch them live. Where the video will be stored? I mean, in what server in some part of the globe.

  6. If, for some reason, I need to download a saved video. Can I connect to a server and see the videos to download any of them, such as a ftp or drive in the cloud?

Thanks in advance for your clarifications.

Regards
Jaime

Hi Jaime,

A lot of great questions to unpack here, I’ll quote your questions for easier reference:

  1. I don’t want customer who does the live stream to install anything in his local computer so I want a 100% web based solution. If I create a websocket server in a remote server, what about performance of the streaming? the server will have an encoder installed, so the client computer, by mean of the browser, will send the streaming without any encoding to the server by using socket.io js library.

There are a couple of things to note here.

  1. There is an intermediate server that is transcoding the video to RTMP - and then sending it to api.video. You’ll want to make sure it has the computing capacity to transcode all your concurrent streams.

  2. The code in my livestream demo does nothing to check the uplink speed of the customer. If they have a poor upload rate - the ffmpeg transcoding on the intermediate server just fails, and the stream stops.

  3. There are versions of FFMPEG that run in the browser (or as WASM) to skip that intermediate server… You could also look at libraries like https://github.com/t-mullen/Web-Broadcasting-Software - which looks a lot like OBS, but runs right in the browser.

  1. socket.io library is the only option to transmit video to rtmp server?

You can probably get away with plain vanilla websockets.

  1. When many people are streaming at the same time, what about api.video performance? Can I know about some experience in a real world application?

api.video has capacity to handle all of your live streams uploads at once. This is scalable, meaning that if the live streaming servers near their capacity limit, more servers can be provisioned.

  1. The same as above, what about performance for saved videos to be watched at the same time?

Our servers and global CDN network ensure that there is no playback issue for livestreams or video on demand playback.

  1. I will have the option to save the video so that visitors will be able to watch on-demand videos if they could not watch them live. Where the video will be stored? I mean, in what server in some part of the globe.

When you turn on the recording of livestreams, the video is re-encoded after the livestream ends for higher quality video on demand playback.

Videos are stored in North America (Canada) and Europe (France). However, our global CDN ensures rapid playback anywhere in the world.

  1. If, for some reason, I need to download a saved video. Can I connect to a server and see the videos to download any of them, such as a ftp or drive in the cloud?

Your original file is not saved. However, by default (unless disabled) all videos uploaded have a mp4 version created and available via HTTP (it is included in the API response for that video). (Note: the maximum size for the mp4 is 1080p, so any 4k video uploaded can be streamed in 4K, but only downloaded as 1080p)

I hope this helps! feel free to reach out if you have additional questions.

Doug

Thanks doug, it is clear.

Can you please tell me about the capacity the server that transcode the data should have?

I am using this same thread to ask you a short question.

The program I have developed to test the video streaming works, however, I have a question regarding the timestamp displayed when I see the uploaded videos in my Dashboard.

One video shows this date and time: [2020-09-29 13:48 (UTC)]. It turns out that time difference between UTC and my local time is -3 currently. That video was recorded at 08:48 local time. So UTC time should be 11:48. What happened to this?

Thanks
Jaime

I just uploaded a video at 1406 BST.

BST is one hour ahead of UTC, and when I query with the API:

"publishedAt": "2020-09-29T13:06:00+00:00",
"updatedAt": "2020-09-29T13:06:00+00:00",

UTC: 1306 (the API)
BST: 1406 (my watch)
CEST: 1506 (go.api.video)

:slight_smile:

Capacity testing for your intermediate server. I honestly am not sure. I am running my demo site on the smallest AWS server, and it has done 2-3 streams at once successfully.

I would recommend testing. :slight_smile:

Regarding time difference, there are 2 possiblities:

One is that the dashboard is showing CEST and not UTC. If that is the case, I think Dashboard display should be fixed (this is more likely by seeing your test).

The other possibility is a timezone issue.

My country timezone is UTC-4 according to winter time and UTC-3 according to summer time. We started summer time on last September 5th. It will last until April 4th, 2021.

The fact is that this timezone difference have not being constant during last years. Formerly, summer time started on second sunday of October every year. That has changed a lot since year 2011. So for the systems to respect the current timezone change, they have to be updated.

In Windows systems, Microsoft provided the corresponding patch to modify timezone changes.

I have also a Linux server which is also cofigured for the updated timezone:

image

See that current UTC time is 14:15. (I am writing this message at 11:15)

If this is the problem, and according to my theory, hour shown in uploaded videos will be right after October 10th, however, this is unlikely :grin:

Regards
Jaime

I’m pretty sure it is the dashboard is in CEST (as our developers are in France). They are aware of the bug, and will resolve it.

Timezones are a pain - aren’t they?

1 Like

Yes… specially when developing an application to be used worldwide.

I have other question, but it’s time for another thread :grinning: