Interested. I want to hear more about the dropout on cellular

Yes, H264 was added for testing. Keyframes were likely dropped because of some work-in-progress. You will probably have a much better experience with VP8/9 (for now)

I suspect it's the half-baked rollout of 5G UW

constantly switching between cell sites

Does it happen only on UWB or LTE as well?

Including NR NSA "5G"

I don't know. It's a feedback from my customer, I did not experient this out and about, so I have no further detail to provide

np, do let us know if you have more details

sure thing

would like more feedback during beta

even calls dropout when switching from 5G uw to NSA 5G so I do believe that would be the issue

but if the customer was stationary when expericencinig this, I would have to know more

Yeah that would be a problem.

the thing with VP9 is not that many GPUs supports hardware encoding with it, and I tested with OBS output to URL(CF WHIP endpoint) with vp9 encoding, that didn't fly

so I guess I will have to stick with h264 for now. It works well enough

this... is a possibility? Stream's webhooks are a somewhat sad story overall tbh, we've resorted to just polling for most things

(most things meaning ready to stream, and ready to download)

Yes, it is option. Webhooks are still very limited (only event type is if video is ready/errored state) but can set that for the highest available resolution too

Our WHIP implementation currently only supports H.264, so that'd be why vp9 didn't work

We have a vp9 encoder somewhere iirc, but it's all software

We're working on some fixups for libdatachannel before moving the whip PR to the next stage

tysm !

Any help? we have been trying to set meta-data in the pload-Metadata header when generating video upload url for streams but seems not to be set though, here is how we are doing it

("Upload-Metadata","requiresignedurls $ctx.args.requireSignedURLs,maxDurationSeconds NjAw")

any other additional custom fields like name water mark does not reflect

Hi - I'm using a custom thumbnail for my app, by adding query params of width / height to the thumbnail url - this works as expected, first time requesting the image takes ~2 seconds maybe - but subsequent requests are very fast. However, if I don't request the image for a few days and come back and request it, I'm noticing it is taking ~2 seconds again - is this expected behavior? And if this is the case, I imagine I would be better off saving the image in Cloudflare Images and referencing it from there instead?

Are you trying to send this header for TUS uploads? Something that's a bit of a gotcha is the value of the different options (e.g. value for 'name' or 'watermark') needs to be base64 encoded https://tus.io/protocols/resumable-upload.html#upload-metadata

I suspect your image is falling out of the cache of the thumbnail API - if your thumbnail request doesn't change and you're consistently requesting the same parameters (width, height, timestamp), I agree you'll get a lot of value from storing the images in Cloudflare Images instead of re-generating it

Thanks I'll set that up

I wrote a blog post about my experience getting started w/ Cloudflare Stream. Would love any feedback if I've missed anything obvious. 😊 https://herd.works/blog/cloudflare-stream/

Thanks @Rachel! After some more reading/experimenting, I've made some progress using WHIP for my signaling - I'm sending my offer and getting an answer using the Cloudflare Live Input API's WebRTC endpoints - but still a little fuzzy on how ICE candidates are exchanged in Cloudflare's WebRTC. I'm waiting until my IceGathering state is Complete to send my offer by POST-ing to the publish endpoint, and this does seems to connect for me, but only briefly. I never do see my stream as connected in the Stream Dashboard, and my video is never shown using the WHEP playback url. My state changes go like this:

OnIceGatheringChange COMPLETE

POST to publish endpoint, store answer to my PeerConnection's RemoteDescription

OnSignalingChange STABLE

OnIceConnectionChange CHECKING

OnIceConnectionChange CONNECTED

OnIceConnectionChange COMPLETED

10-20 seconds later...

OnIceConnectionChange DISCONNECTED

Not sure if the exchange of my ICE candidates is the issue here. Maybe I'm just missing it, but I don't see where the candidates are exchanged in the sample repo: https://github.com/cloudflare/workers-sdk/tree/main/templates/stream/webrtc/src. Did try to perform trickle ICE by calling PATCH to my publish endpoint like described https://www.ietf.org/archive/id/draft-ietf-wish-whip-01.html#section-4.1, but get the 405 Method Not Allowed response for these calls, so seems unsupported. Thanks for any guidance here!

Can you maybe show some snippets of code on how you are setting up the tracks, and the signaling process?