yes, underneath it does.

I seem to be getting a 501 using to send a sample stream to an input. Tried old and fresh inputs

For what it's worth the link to discord from the Stream docs is only to this channel, and won't work if you aren't already in the server. The main docs page discord link under

Community

is an invite https://discord.com/invite/cloudflaredev/ so I still managed to get here eventually, but clicking directly on the https://discord.com/channels/595317990191398933/893253103695065128 links from https://developers.cloudflare.com/stream/webrtc-beta/ didn't get me anywhere. Maybe worth having both links (discord invite and channel link) on the page for new folks.

I played around with the new webrtc stuff and overall it's very exciting. I was just using the OBS "Virtual Camera" (if other folks want to try this make sure to set your color format to RGB, and it looks best if canvas resolution matches output resolution) with the example js code. Using Chrome/Chrome for both WHIP/WHEP had the most success for me, although I think Chrome was sending mono pcm for the audio, which is fine for a microphone, but definitely wasn't doing well with music. I didn't have much success with Firefox on either side and I think trying to use it on the WHIP side got my 'live input' stuck? I'm not 100% sure on what condition triggered it, but several times I had success continuing my testing by going back to Chrome/Chrome with a new 'live input'.

@mike appreciate the feedback and we'll get the discord link fixed up 👍 We're digging into edge cases folks are encountering, its been a great day to launch an open beta 🔥

@tt2468 We're actively working to get our backend supporting more clients, that's one of the clients we're aiming to get compatibility with.

Are there any plans to support input via RTMPS and output via WebRTC with the same Live Input ID? 🤔 I tried it myself for fun even though I don't think its supposed to work and it breaks in a weird way (No errors like when not live, just no video stream either) but I suppose that's to be expected.

Happy to give you the input UID if you want

@Erisa | Support Engineer Long term we absolutely are planning to support RTMP <> webrtc ; short-term, ie this quarter, it's probably a stretch. We have plans to handle the error case much better in communicating what's wrong to users.

@tt2468 that'd be great, feel free to dm it to me

Understood, cheers!

SRT to WebRTC would be awesome, but definitely pretty complicated to mux to RTP and retransmit

(Also yeah when I say RTMPS, SRT would also be fine too, I just mean non-WebRTC <> WebRTC in general)

Aye we definitely want to get WebRTC <> non-WebRTC working, non-trivial but super worthwhile.

FWIW I'd also be very interested in this: my use-case is viewing RTMPS-only cameras from a WebRTC stream on a different network 🙂

Me too. Did you find a solution?

I'm told that the webrtc feature does not yet support trickle ICE, which is what apps like simple-whip-client use

And that it should be available in a few weeks

I think I'll try the GStreamer whipsink meanwhile. I hope it works

Correct — we're working on adding Trickle ICE support. Coming soon!

Wait that exists? Why even use simple-whip-client then?

Because we don't know if gstreamer whipsink works OK as it was released couple of weeks ago. Simple-whip-client is already used by many people. It will be great if CF releases a quick example of using gstreamer whipsink 🙂

Yeah, getting there! @Brendan Irvine-Broque and I are working on getting together a list of clients for WHIP and WHEP that works

ah, I see

Well whipsink sounds like what I'm looking for at least

if anything, it actually makes my implementation way simpler

if it doesn't require trickle ICE, it should work

I can also test this week or next.

I'm setting the following option in simple-whip-client:

Trickle ICE:    no (candidates in SDP offer)