if each streamer will register that they are going online (your step 3), you know when the stream has started, With a webhook - you could receive an alert when the stream stops.
In the meantime, you can call get livestream and look to see the broadcasting parameter:
"broadcasting":false
If you check every 5 seconds, you’ll know if it is still broadcasting (true), or if the broadcast has stopped (false).
When the stream flips from true-> false, you can remove the stream from your listing.
If you have streamers that will stream over and over, you can reuse stream keys (so each streamer has one unique key). Then you’ll have to track streams from going false-> true (which could possibly remove the need for step 3 "“listing the stream”) You can get 100 streams at a time in the list of streams endpoint.
Without webooks - there will be some polling to our APIs, but it can be done this way, until our Live webhooks are released.
Sorry there was a mistake in my first post, step 3 is “stream for a while” I am not sure how it changed, but you can see in the edit that it was originally like that before.
For publishing the stream, I don’t want to rely only on user action obvious reason. I don’t want my user to have the possibility to publish a dead stream. I guess I could use the polling to check if broadcasting comes from false to true.
I will give it a try.
However, what is up with the 100 streams at the time? I cannot have more than 100 simultaneous livestreams? Or is it only a limitation of the get livestream request?
Also, do you have an ETA on the livestreams webhooks?
Hello and thank you for a great service. I am also waiting for this webhook to synchronize broadcasting state with the data on our end. When is the estimated release date?
Hi Doug,
I gave a try to making it work with polling, but I cannot achieve what I want. Maybe you have more ideas.
Because there is a delay of about 10 seconds (i am from Montreal) to the livestream and that the broadcasting field switch instantly want the stream starts/ends, that cause problems.
When starting a stream, the video playback is only available about 10 seconds after the broadcasting field is set to true, which cause the video player to hang and the webpage needs to be refreshed.
When stopping the stream, the last 10 seconds gets cut because of the that too.
If I try to detect the beginning of the video playback on polling the manifest, this can work for the first time a stream key is used, after that the manifest is always there, so I cannot know if the stream is running or not.
I also would want to avoid hardcoding wait timers to my website. I don’t see it as a good practice is this context and I guess the stream delay could be different depending on a few factors, so I would not know what time to put.
If you have ideas to fix this, let me know. A webhooks that tell me when the livestream playback is available/has ended would be best. However I could make by if it is only a field in the livestream information that needs polling.
I appreciate you giving it a go, and I agree that there is a bit of nuance right when the stream starts. We’ve been experimenting with this as well over the last weeks. You may have noticed that you can livestream right from my.api.video, and we’ve been working to get the UX just right (and I think that ‘just right UX’ is still in staging at the moment…):
But this is what we are doing to make the experience awesome:
When a user starts the stream, (broadcasting false-> true) we know that this video is coming online soon, and we display a preview (in your use case you might put a link to the page “starting soon…”). But as you noted, the live stream is not actually available for the end user yet.
Poll on the manifest.m3u8 every 5s. We know the stream is starting up, but the manifest response will be a 404 (not found) until there is video being delivered.
3, Once the manifest response is 200 (ok): Video is streaming, and you’re ready to go!
When a stream is ending:
Broadcasting true-> false (at this point, perhaps you stop promoting this stream - it is ending in the next 15-20s, and no one wants to start watching a stream for it to just end.
Keep playing the video until the manifest starts throwing a 404 - then pull the stream from all viewers.
This has been a great learning experience for us - we initially wrote the live webhooks user story to fire on the change in the broadcasting state, but what we want is broadcasting:true and manifest.response to be 200. for the webhook to fire that there is a stream ready.
Thanks for working with us on this, and I am working to prioritise the live webhooks with the team
I have been trying a few things and I am getting close to what I want.
My poller has two main loops. It is running on a Google compute vm from Google cloud.
The first one polls every 5 seconds for all the livestreams, then compare the broadcasting status from the previous result. If it has changed, depending on whether the status went from true to false or false to true, the livestream is added to a corresponding data structure.
The second loop runs every second. It takes the two data structures with livestreams that had changes with their broadcasting status and do a get request on their hls link. For the livestream that went from broadcasting false to true, it is waiting on a status 200 for the hls link. For the livestreams that stop broadcasting, it is waiting on a 404 status for the hls link.
This seems to be working well for detecting when the livestream is online and watchable. It is a bit slow, there is a delay of about 20 seconds from broadcast to status 200 on the hls, but it is manageable.
However, when a livestream is stopping, something is wrong. The broadcasting change from true to false is correctly detected, but the hls manifest does not change to 404 (not always, but it most of the time). It seems to be cached either in your servers or on the way to my vm. This is acceptable for detecting the end of the stream, because I could use only the broadcasting change to stop promoting the stream. The problem comes when the streamer tries to restart its stream, I am not about to detect when the video is watchable because the hls manifest is already 200.
Would you know more about this caching problem?
Do you have any solution for me?
How long are you delaying between the stream stopping and restarting the stream? We recommend 30 seconds between these two steps. The reason is exactly what you are seeing in your testing - since the manifest never goes to the ‘404 state’, the manifests get jumbled, and sometimes the viewer ‘gets stuck’ watching the old stream and cannot see the new one. After 30s, the stream manifest will reset to the 404, and then it is ok to restart the stream.
So I have been working on my solution on the last few days. I am satisfied with the results for now.
I did some test on the time it takes for the manifest going from 200 to 404. It can take from 30 sec to sometimes 10 minutes. It is inconsistent, so I won’t rely on it, but it is fast enough for it to be working when two livestream are separeted by a significant amount of time.
With my poller set up, when a user wants to start a stream, there is a delay of about 20 second before I detect a 200 on the manifest, which is fine. The use then proceed to the next step of the stream creation.
When creating the livestream, if the manifest is still at 200 (because the user fiddled with/restart the process), I tell the user to wait before starting its stream (for the manifest to go to 404) before proceeding.
While waiting, I give to option to the user to reset its stream key. This delete the stream from api video and create a new one so I can be sure the manifest is 404. If the manifest hang on 200 for any reason, this takes care of it.
It is working fine for now. I am still looking forward for the webhooks as it is stretching my free vm on google cloud compute and would be faster, more reliable and cleaner.
