Hi all i am confused with what features are working with Whip/Whep and which are not Specifically i am intersted in the recording and it seems like there is a feature for it under Live Playback and Recording there is a switch to turn it on Is this working feature is there some sort of timeline for when the new features are coming online or is there a pilot program for this ?

Recording is not implemented yet for webrtc. But it is on the roadmap

See https://developers.cloudflare.com/stream/webrtc-beta/#limitations-while-in-beta

so the way stream pricing works is if I had 100 viewers on 1 stream for 1 hour that would be 6000 minutes = $6?

if so then by extension would having a decent size like ~5000 viewers around the clock amount to 5000 * 60 * 24 * 30 = 2.1M minutes and cost $216k a month? 😬

Good question

Both of those sound accurate, although I would think that you can get an enterprise contract with a volume discount at that usage level.

@Rachel So I'm trying to proof test video-only streaming with CF stream WHIP, but it appears wish.chens.link does not support it yet. Getting

Unexpected status code 406: cannot satisfy playback request: requesting non-existent audio track

after attempting to play the WHEP url

Yeah I haven't done anything on my site to make it work yet

Should the cloudflare player theoretically work?

The cloudflare player also wouldn't work with video only atm

ah damn

I will have it fix next week

Sounds good 👍

You could use our stack blitz example, and remove audio transceiver manually

Wanted to do a video-only stream since we're somewhat strained for bitrate and audio is not necessary for my use-case

Ah ok, might try that then thanks!

In that case it shouldn't be too difficult to quickly write some JS

Not super familiar with browser webrtc stuff but I assume the issue is coming from adding an audio transceiver here?

^ Yep it's working in that way

@Rachel Bug report: Audio-only WHIP streams cause cloudflare to report the same values for video bitrate and audio bitrate, even though there's no video track. Video-only streams seem to behave correctly

@Kyle_Cloudflare fyi

@Mickie Betz A new problem has emerged with Stream. If we launch our custom Chromecast application first and then select the video workout from our app (or website), the casting fails and an error appears. However, if we start the video first and then initiate the cast, it works as intended. This suggests that there may be an issue at the beginning of the encoding. We have encountered this problem in both our Android and iOS apps, as well as our web app. Re-encoding the video using MUX resolves the issue. At this point, our priority is to ensure proper playback on all modern devices, and we are considering reverting to MUX to achieve this. MUX is an HLS-only service. We also bypassed the MPEG-Dash stream by only loading the HLS manifest. Our developers are attempting to troubleshoot the issue but have not yet identified a specific cause. The same source file, when encoded with MUX, functions correctly in all situations. I have used MediaStreamValidator in the terminal and found Must-Fix errors, although this tool is known to be strict. Any assistance would be greatly appreciated, as we would prefer not to switch back to MUX, given that it operates with a commit (which is the main reason we transitioned to Cloudflare).

For WHEP egress is it enough to open stun.cloudflare.com:3478 UDP for the connection to succeed or more ports/protocols are needed? My client uses a very strict internal proxy and need them to be able to receive-only the WHEP video stream. Do we also need to allow outbound and inbound on their end for WHEP direct connection to work? Can you please give me some more information like what FQDN should be used with cloudflare's global network etc?

you can find the A and AAAA records on stun.cloudflare.com. the stun and webrtc traffic will use those anycast addresses. STUN uses the port 3478, and WebRTC uses the port 1473. Note that they are over UDP

So, opening 3478 / 1473 UDP would enable them to connect and receive AV data and no other ports needed?

I don't know what firewall/proxy they are using in their network, but at a minimum you need to allow outbound UDP to 3478 and 1473 on our anycast IPs

However their environment may be more complicated

I have seen corporate network that blocks UDP completely