Hi, I want to integrate cloudflare live stream via apis and want to get videos of that live input. Is there anyone to help?

Hey there! Have you checked out our live documentation? https://developers.cloudflare.com/api/operations/stream-live-inputs-list-live-inputs https://developers.cloudflare.com/stream/stream-live/

We sure think so!

How long did you wait for pending to go away? DNS propagation can take upwards of 24-48 hours in some cases once you add CNAME on your domain registrar.

This isn't working for us either. We have a support ticket open on it

Thought i might just note that you can open WHIP/WHEP video streams, whilst Cloudflare stream says that the WHIP ingestion 'input status' connection is 'disconnected'. Most likely a bug.

Has anyone using WHIP/WHEP with stream got any idea how long the negotiation to open the video stream should take? Seems to be taking quite some time, 5-10 Seconds+ https://developers.cloudflare.com/stream/webrtc-beta/

+1 same outcome here

Stream is pretty good for live video, certainly cheaper than AWS IVS (AKA, Twitch.tv underlying infrastructure), but for VOD traditional per GB charges fit that model better. With VOD the key is customised encoding + CDN + storage. But stream is completely managed, no control over quality or bitrate, codec or other. Remember it's 1 minute for 240p, 360p, 480p, 720p or 1080p, even when those data rates can be under 1Mbps or 350Mb/hour. At which, no, would be the answer. It really depends your use case. It's also 1 minute for loading, 1 minute for changing resolutions, regardless if viewed. The tradeoff comes at 1) How good is your compression 2) How big are your files If your data rate is low/compressed well, 3) Do you need control over your codecs 4) Do you need control over your licensing of videos & DRM, than Stream is not yet near AWS/Cloudfront, cause that product from AWS is like 5+ years old & runs Disney, Netflix*, HBO, Prime, Binge etc etc Personally think these should be separated, VOD (Custom encoding + CDN + Storage) packaged by minute or GB, Live Stream (Managed encoder + CDN + Storage) packaged by minute, Audio/Podcasts, as the data usage is immensely different & they're very different products, I can't imagine Disney using Stream to deliver 4K, HDR, Dolby content, as the encoder wouldn't allow it. But Disney would use the CDN + their custom encoding, which is mostly AWS AEM + Akamai/Cloudfront (terrible pricing), as the requirements of VOD encoding simply don't fit a one size fits all AVC model. For live video, custom encoding is less of a concern to none of a concern, latency & quality are more important.

I am finding the playback for WHEP to be quite long after the initial POST handshake. But the handshake for the /play POST is about 1.5 seconds, then it's like 10 or more seconds for the video to play, but most fail (Understand it's BETA so don't really put my thought into the failures) I've been testing WHIP/WHEP quite a lot atm. RTMP/HLS playback is quite fast, acceptable, around 1 second or less, but WHIP is very long.

So if I wanted to use CF Stream for a streaming platform wouldn’t be a bad idea?

It would be fine for either VOD or streaming, depending your use case, bitrate & viewing hours. But for a streaming platform it would work fine, live video is where Stream suits best.

okay, ill have to look in to it for the website then

It works fine for me. It only shows connected once you've actually got a connected WebRTC stream, not just the HTTP handshake

It's the time from getting the WebRTC information for the stream back from the server, and the video starting, video starting takes FAR longer than RTMP/HLS.

It might be server location of the TURN/STUN server? I don't know where they are based.

let answerSDP = await response.text();

in particular, after recieving the SDP information, the loading of video takes quite some time. Also, the WebRTC can be open but the Cloudflare dashboard will show "disconnected" yet the stream is still working. It's all Beta so I don't expect perfect results. Just noting what I see.

What I think is happening is the server for ingestion doesn't seem to be running, the WHIP service starts up, then the WHEP makes a call on line 34 which outputs an error on line 58

let response = await postSDPOffer(endpoint, ofr.sdp);

the SDP information response isn't ready so it outputs errors & freezes. After connection negotiation ended, you would assume the playback starts, but for me it hangs & doesn't load video. Funnily enough, if the dashboard says 'disconnected' I am less likely to see failing playback. Right now the server is connected and no video output shows.

As you can see, I have localhost server open, webcam open, server has Connected, yet playback says there is no livestream. And when it's disconnected, it works. Will see if i can work around it.

2 browsers, left browser WHEP working fine, right browser says the livestream isn't playing & fails. So not sure if client or server issue at this stage, it seems to be the client does not receive an SDP offer from the server & plays nothing.

Hi, is there any way to enable auto caption for all the videos inside my stream library? OR can I do this automatically after uploading a video, Is there any workaround?

are you able to add a few different download qualities?

Just to confirm I'm getting the same issue, H264 video streams with OPUS audio for reference, not sure if VP8/VP9 change this in any way, didn't test that in a while now.

Reliability has been fine for the most part on my end lately when it comes to consistent playback, the only issue I have is that if something goes wrong with the stream (still running but there was a network problem, I'm assuming it misses some keyframes), the dashboard and API will both claim everything is fine, even though it won't be able to calculate statistics. The annoying part is that GStreamer (which I use to stream) will also happily just churn away in this state so I can't even figure out a good way to recover from this automatically. I'm not sure if the reason for the stream status being "wrong" like this is similar on CF's side, I don't know the tech stack they use so I can't guess much.

I used a VP9 video file i got from Steam store as a stream test, same result. I am not sure, but i think the reencoding on the cloudflare server is going out as VP8 or VP9? I believe it is reading the SDP offer. I get that from

let answerSDP = await response.text();

in the negotiate js file, but I need to read the spec to understand that.

I find that too, ATM, there doesn't seem to be a reconnection made, when moving from 4G/5G to wifi, the WHIP connection will completely fail & need to be remade, this is because the status on the server changes from "connected" to "disconnected" & "client_disconnect", same for the WHEP. This includes if the stream input on the server side has the same UID. This can be fixed on the input client side by checking if the stream input goes down, to redo the /publish endpoint & restart the stream, also it's being done currently in the WHEP client by the looks of it, I haven't taken a longer look. There could be quite an issue with recordings for this, as if the stream goes down, does the video stop recording and make a new recording? Or continue on the old recording? I have been polling the API from when the WHIP connects to the server, when the server gets it and when the WHEP starts, for me it's very long. RTMP/HLS is much faster. But it's all beta, I am just noting what I see.

The longer you run it, the more dropped frames, jitter, lag & delay between host/client there seems to be. Audio seems to delay longer than video. https://cdn.discordapp.com/attachments/893253103695065128/1111853530450505788/IMG_0335.MOV

Hi there, anyone built webinair or conference system using cloudflare webrtc? is it possible?

The WHIP/WHEP model is made for 1 to many, aka, more like Twitch, less like Zoom.

Got it So its not suitable for webinairs as people need to interact