I think there's a /disconnect endpoint somewhere

Hey folks, customers reported a few issues with uploaded videos, and I've noticed quite a few encoding issues as well. Looks like it started yesterday. Could someone take a look?

666fcd58b67da767b6511b7f3800d7a6

56597807cddf354dcd1111e3332d93ee

73721a83cbdf4a33791993833532c666

These are all reporting "video failed to be encoded due to unknown cause" and retrying it seems to help

Good morning folks, can someone please take a look and see if this happens to them as well? I have customers who are not happy about this and are asking for refunds! I've also opened a ticket : 2778819

We're taking a look now, nothing to report back yet but wanted to let you know we're investigating

Thanks Mickie 👏

If it helps, I've re-uploaded the same video (from the same link) and it did encode correctly.

12d95fcdffe9874e39af79970e123c73

- encoded correctly

2a587fc991a0177a30b72dc2e903c8cf

- didn't encode. both were uploaded from the exact same R2 bucket link

thanks for those - also helpful to know you're uploading from R2!

@altryne we shipped a change and have seen big reduction in issue on our side- please let us know if things look better/good on your end! We suspect you were hitting on a race condition where we were seeing the upload file stored but when attempting to begin the encoding process it would report it didn't exist yet - we've improved this scenario

Thanks Mickie! Will report

Hey everybody, general question about the webrtc beta. How is the multichannel audio support currently? The documentation is a bit sparse outside of the one dev article I can find and I couldn't find an indication of which features are implemented or missing yet. https://developers.cloudflare.com/stream/webrtc-beta/

I think pretty much everything is built for 1 audio, 1 video track

I was eyeing the stream platform as an alternative to janus which can do 5.1 over Opus. https://github.com/meetecho/janus-gateway/pull/2059 https://janus.conf.meetecho.com/multiopus.html

The track isn't so much the issue so long as it can be multichannel.

Though I believe in the original WebRTC implementation you couldn't switch tracks during the session without a client reconnect, I think WHIP smooths that out but the recent reading may have blended together.

Seems very good since the change as far as I can tell.

Hey, can you share some info on the progress of Calls? I saw it’s in private beta, I’m interested to know how far are we (roughly speaking) from public beta? It seems super cool and I look forward to playing with it!

I'm noticing a fairly significant slowdown in "download" progress. It's not queued, the video is in "downloading" state, the link is in R2 (also cloudflare) so download should be... instant? Like it used to be> And here's an example of a 3 minute video being stuck in download for more than 3 minutes. it eventually downloaded, but the speed... is so slow. This fees like a significant regression of capabilities.

It looks like this original video is hosted on twitter, not R2. We've seen slowness in fetching files from Twitter in past because of their multi-CDN setup. It looks like the video you shared went from uploaded to fully encoded in 4 min - maybe a bit of lag in relaying that info through UI though

Would you mind sending inquiry email to Stream/Calls Product Manager Zaid? zaid@cloudflare.com - just chatted with him and he's hoping to learn a bit more about your use case and any needs you have

oh, you're right, my bad. This one was indeed a direct twitter download. Yeah could be a UI lag on cloudflare part? I saw that it was stuck on downloading (previously it used to say queued if it was) This vid is ~14MB, even with slow CDN, download use to take less than a second before, 4 minutes seems... extreme?

To clarify, it's taking 4 minutes for the entire processing (encoding taking the bulk of that time). On our end I see the fetching of original file ("downloading" in UI) only took 3 seconds, so I'm not sure anything is wrong here

Will do, thanks

Hey Mickie, the above was just an example, but now we've got 5 videos stuck in "downloading" for over 35 minutes. The links are not only twitter, they are from R2 as well I'll open another ticket

Could it be related to https://www.cloudflarestatus.com/incidents/kzkm7sjscrzd ?

Yeah this makes sense "and new video uploads" When I looked before posting, there was no incidents reported. Hoping for a quick resolution

Hi everyone, thanks for your patience. We're dealing with an incident, the status page will reflect our progress on resolving. We have a fix in place and waiting for the queue of previously enqueued videos to reduce. We'll keep the room updated.

This is now resolved

Confirming that this has stopped happening to my customers