In OBS, it'll just be the normal encoder configuration

i mean the browser ))

@skaboy007 For the browser you can configure things via https://developer.mozilla.org/en-US/docs/Web/API/RTCRtpSender/setParameters The browser gets feedback from the server and tries to pick the best bitrate possible. If your connection isn't good (packet loss, increasing latency) it will lower the bitrate. To see this all happening chrome://webrtc-internals is your best tool!

WebRTC for the Curious contains some info on this https://webrtcforthecurious.com/docs/06-media-communication/#identifying-and-communicating-network-status

and happy to answer in more detail here!

ye thanks, familiar with this already. I was wondering if the WHIP lib provided has a direct API setting. for the above, i need to digest the lib. its at least what i understood

@skaboy007 doesn't look like, but it would be so easy to copy+modify!

I would just copy WHIPClient.js and add either the params or hardcode

will do, but wanted to avoid it. like to do things in a maintainable way. any update and its irrelevant.

Hi everyone, i'm having issues with the Streams with WHIP/WHEP, i discovered that WHIP clients cannot disconnect because in the WHIP example the DELETE call on the publisher link returns 405 "reserved for future" so any client that connects after the streamer disconnected and reconnects will try to reconnect to an old stream, really weird issue

I remember the DELETE method being implemented as of like a month ago. I'm not aware of them unimplementing it

Can I transfer cloudflare stream video to r2 storage (or other object storage services) directly, or do I have to download video and upload manually?

hi guys, do you know how to save the cf stream video (webrtc - WHIPClient) for replay later?

Hi, have a problem, at now we try use WebRTC (WHIP), default example on C# .NET with HttpClient and StringContent(content, encoding, content-type) body generate header "content-type" = "application/sdp; charset=utf-8", and WebRTC (WHIP) URL api return this error

expecting application/sdp as content-type

we fixed this

content.Headers.ContentType = new System.Net.Http.Headers.MediaTypeHeaderValue("application/sdp") { CharSet = string.Empty };

this add new problems for .net developers, content-type is valid but return the error Example

var client = new HttpClient();

var content = new StringContent(localSdp.Content, default, "application/sdp");

var httpRequest = new HttpRequestMessage(HttpMethod.Post, url);

httpRequest.Content = content;

var httpResponse = await client.SendAsync(httpRequest);

// httpResponse.StatusCode return 400...

Hello, im having the same question as stated in this forum's post: https://community.cloudflare.com/t/deferring-the-upload-length-of-resumable-streams/421584 does anyone know how to address this? I want to stream a MediaRecorder as the user is recording it. But whenever I try to remove the

Upload-Length

I get a 400 error. And when I add

'Upload-Defer-Length': '1',

I get error 501

Not Implemented

Is this not supported by CF?

For Stream WebRTC, if a sender refreshes their browser during an ongoing broadcast it seems to take a while before the sender and any new/previously connected receivers can renegotiate a working connection to the new broadcast on the same live input. Is there a way to shorten the amount of dead time? Is the workaround to create a new live input and WebRTC session and have all peers switch over?

For RTMP, I think there's an endpoint to force disconnect the publisher. It may or may not be available for WHIP, I haven't tested

Anyone running long lasting streams on WebRTC without any viewers at all times? It all seems good when someone is watching, never had an issue like that, but if I leave the stream going for hours sometimes it just goes offline in the dashboard, but I see no errors on the WHIP side, and WHEP side gets a 201 like everything is OK. Restarting the stream is not a huge deal, but the lack of errors on any end is a problem.

Hmm, I'm going to deploy something like this soon. Will find out if I get that too

keep in mind I can't really get a reliable repro, it just decides to up and leave it seems

technically, you can check the status through the API, but that means having your API keys on the end device... not really ideal

I'm noticing this behavior as well. Was hoping sending a delete call would shorten the reconnect dead space where a publisher can send a stream the the live input but receivers can only seem to connect to the old stream

i'm literally forced to create a new live input and change the watch url to the clients on the fly with a gimmick

not the best solution!

Yes! That's the direction we're thinking about heading We can also close the peer connection manually but either way it still seems to take cloudflare ~30 seconds to realize that there's a new stream on the live input and to stop serving the dead stream to receiving peer connections

wrong url. Need to use the url in the location header from the original request

Not the publisher one but the live creation url?

hmm are you doing whip or whep

Whip to stream and whep to watch

so, in the initial POST with the sdp, check location header of the response from us