We're following WHIP as it matures - WHIP is very lightweight and addresses a lot of the latency overhead with RTMP.

Hello!

Tencent has video push/pull via QUIC: https://intl.cloud.tencent.com/document/product/267/41047

Looks like Bilibli tried it a while back too: https://github.com/wangsheng-bilibili/quic-obs-plugins

🙂

Stream already does HTTP/3 (QUIC) with HLS/DASH. I believe this is the same thing as described in the tencent docs.

Lucas is doing some really interesting work. He is less of a fan of WebRTC, SRT, RIST, FTL and might recommend just raw RTP over QUIC: https://datatracker.ietf.org/doc/html/draft-engelbart-rtp-over-quic ... I would like to see RTP or MPEG-TS in/out of Cloudflare via QUIC but this is because my company makes thick clients and does multicast rebroadcasting on the last mile.

Well... SRT is more appropriate here. NDI is userful on intranet, but for Internet SRT is a way to go. I have my WebRTC solution, using pion that send the signal back to our client (Broadcast TV) using SRT link. The latency is low as 1s. Using SRT they can consume using many clients to push the image back the Switcher (like VMIX)

Setting SRT to 1s doesn't give you much of a resend buffer so you end up losing data, right? What is great about Stream (I think I heard this right) is that they automatically set up the RTMP ingest point to be very close to your OBS. This is a problem with other services as RTMP drops with too many hops or resends (it's TCP based). So this could allow for such a low buffer setting in SRT. Still, I am a fan of a scheme with no resend, UDP, and FEC for error handling. There is plenty of circuit capacity, so why not just double the bandwidth? This gives you a very low latency option for ingest.

NDI 5 now has internet remote features

but, this is WebRTC anyway.

Hey @User, does Stream support audio-only streams?

No, audio-only input formats aren't supported. We state "video" in the docs but open to feedback here - https://developers.cloudflare.com/stream/faq#what-input-file-formats-are-supported

Curious though: what's the use-case?

I have a small app that I want to turn into a web-based radio station. Definitely not large scale or anything, was just thinking that if Stream was able to support that, I'd be able to help test it out.

Got it. Since we package as HLS & DASH it may not make sense here - not always an efficient way to serve audio-only content. We’re focused more heavily on the video experience. Probably a good use case for R2 storage in the future but defer to Zaid (Stream PM) on thinking here after the weekend.

Cool, yeah I get that!

Stream supports QUIC pull for browser-based UDP playback which is fantastic. I would like to see Stream support QUIC push for ingress. We wrote our encoder in Rust with Gstreamer bindings so we are not to far away from supporting this with QUICHE: https://docs.quic.tech/quiche/

Ideal ingress: QUIC Push of RTP with FEC which contains AV1 video and Opus audio. Here is some hardware that you can rack up to convert this to standard HLS/DASH: https://www.netint.ca/netint-announces-the-worlds-first-commercially-available-hardware-av1-encoder-for-the-data-center/ ... someday software encoding will go back to ASICs which produce better looking live video with a smaller carbon footprint. Of course my company wants to push this to get folks to adopt our QT+Gstreamer player app which can support AV1 once more people have Intel Tiger Lake CPUs for decoding AV1.

If you’re doing your own encoding, providing your own player infra, and want to push RTP - I’d suggest looking at Spectrum for UDP proxying (including QUIC as udp/443) - https://developers.cloudflare.com/spectrum/

Your use-case is super interesting but diverges from where Stream is headed - we’re less about “raw protocols”, and more about “serverless video”.

Our SRT settings has only 125ms of buffer. There’s no resent because is also UDP based. 1s is the diff from our WebRTC ingest source to the SRT render.

Anyway in this channel we can get help with the new cloudflare TURN server?

Roger that. Thank you!

Best thing to do is to fill out the form in the blog - we’re triaging the interest and getting back to folks over the next couple of weeks. Hold tight! 😉

Nice! Our company has users in every state on Brazil, and cloudflare (after the recent expansion) is the only provider that is can serve our users on the Northern states. All others has only peers points on the southwest with not optimal.

I could use cloudflare stream, but right know our mobile software only sends WebRTC, not RTMP.

Also the latency diff is not great.

I just signed up for the WebRTC Components beta, but I'm curious about whether Streams will support data channels at any point or how support for data channel broadcasting might evolve in Cloudflare's services.

The TURN server [relay] won't discriminate - we shouldn't block Data Channels from being sent between peers.