Hi everyone, I have a question about live stream billing: If you read the billing explanation in the Cloudflare dashboard, they say: "You will only be billed each month based on how many minutes you stream". If you read the help/support, they say: "... Video minutes delivered to users ..." (https://support.cloudflare.com/hc/en-us/articles/360016450871-Billing-for-Cloudflare-Stream) So if I stream 1000 minutes for 100 Users, do I have to pay $1 or $100 ?

By stream it means how many minutes of video get streamed (delivered) to viewers. I'm pretty sure live streaming was a later addition especially seeing as the billing support page doesn't even acknowledge live streaming on it. So it would be $100. If you had 0 viewers you would pay $0 for live streaming since you only are charged for delivered video.

Thank you. It makes sense, just wanted to be sure 👍

hello guys im trying out live streaming to a website with the SRT protocol using OBS. Is it normal that stream has a 20-30 second delay? Ive read people get about 2-10 seconds on theirs.

I've seen about that when using Stream as a relay

Does anyone here happen to know if the CSAM Scanning tool is/can be used to scan video either stored on Stream?

Hmm... weird I'm not seeing WebRTC WHEP playback for my test stream 🤔 ... with JS error saying "Uncaught TypeError: Cannot read properties of undefined (reading 'tagName')" Also not working in stackblitz demo page

just finished setting up

cloudflared

(which works great btw), and realized that according to the docs (https://developers.cloudflare.com/stream/manage-video-library/using-webhooks/#limitations) under "Limitations", there's this: > Only one webhook subscription is allowed per-account.

so I ask again: what is the recommended way of working with CF Stream webhooks in development? does there exist anything similar to Stripe CLI's stripe listen that forwards webhooks to a local URL, or is there another best practice?

I can't possibly be the only one that want to make sure Webhooks work properly in dev before going to production 🙃

Hey guys! Love the announcement about WebRTC support in Cloudflare streams! I have a question. Does Cloudflare Calls use Cloudflare Streams WebRTC in the background; if so, will it be less expensive? And would there be a different pricing for the audio-only calls?\

@Zaid (Cloudflare) : you mentioned in May '21 that you were working on major upgrades to the webhooks in the coming quarters. did that ever get anywhere? https://community.cloudflare.com/t/trying-to-create-separate-stream-accounts-for-webhooks-to-separate-urls/270401/4

I really wish that in the cases of "we don't support this right now, but you can do that with a worker" - where often a user-implemented worker is created to kinda patch expected CF functionality - you would also provide example Worker implementations in the docs

I am thinking about using WHEP instead of SRT to pull a stream into a remote network (a branch office of a company). There may be packet loss on this connection. How does WHEP handle packet loss?

The default settings in OBS will use a larger keyframe interval(aka GOP, group of pictures) which prefers playback stability over latency. To set a lower keyframe interval: open up the settings, go to the

output

tab on the left, select the

advanced

settings from the dropdown at the top, and the

keyframe interval

field is what you want to edit. I strongly recommend not going below 2 seconds. Lemme know if you see or don't see an improvement tweaking that value.

That's unusual, what browser+operating system are you using?

It is a Gstreamer WHEP client.

I may just use SRT for this use case but thought that WHEP might be beneficial.

I'm not familiar with how the gstreamer's WebRTC implementation handles packet loss. PLIs sent from the client are currently not handled as well as we'd like(somewhere we want to improve); if a keyframe is lost that may break video playback for a keyframe duration. I would expect audio to be stable.

My best case scenario (and perhaps this is coming soon) is RTMPS ingest (from Zoom) with both SRT egress (for my remote network) and WHEP egress for end user streaming playback.

Here is the WHEP client. I am not sure how it handles packet loss: https://github.com/meetecho/simple-whep-client

RTMPS <> WebRTC is going to take a fair bit of time. You may be safer sticking with SRT + RTMPS + HLS/DASH from us for now, then adopting WebRTC when we have that interop working.

You will likely be better off with SRT.

@tt2468 Good advice. Thank you! I am so excited about RTMPS input with WHEP for end users and SRT for backhaul/contribution. This is very unique. Cloudflare also solves our issue of where to ingest RTMPS from Zoom where users could be doing Zoom anywhere globally and then want to stream it to a Cloudflare-based streaming service.

I'm on OSX 12.5.1 (Monterey) & Chrome. However I think I'm not well aware of the tech stack just yet so I'll take more through look at it before proceeding.

That should work pretty well, anything non-standard about your network configuration?

Hello here, is it plan to add new codecs as output ? Today, only H264 is used for output chunks for both HLS and DASH. Adding VP8/VP9/HEVC/AV1 will reduce the bandwith usage for users 🙂

Hey @poacher2k — thanks for the feedback. We're working on adding a lot more runnable examples like this to our docs for things just like this. Expect more examples like these in the coming months.

Cloudflare Calls is built on WebRTC, and Stream and Calls use the same underlying infrastructure. No details on pricing yet, but we'll be quite competitive. Many of the existing many:many WebRTC products out there are very expensive.

Cool! How different will Calls will be from the Stream? In what sense that it's more advisable to build a conferencing app with Calls than WebRTC Streams?