Nevermind, this did it: https://iframe.videodelivery.net/0b531a302e8f3485db8a727038548a2f?poster=https%3A%2F%2Fvideodelivery.net%2F0b531a302e8f3485db8a727038548a2f%2Fthumbnails%2Fthumbnail.gif%3Ftime%3D5s%26height%3D200%26duration%3D4s Cloudflare Stream

that's still the watch subdomain so I'd assume no

Thanks for the help 🙂

Hi guys, It would be helpful if someone could help me out with the following questions, 1. From server-side analytics, is there any way to get the resolution it's going to support from HLS or dash URL? 2. Is there any way that I can group the values of server-side metrics based on the custom field?

reference - https://developers.cloudflare.com/stream/getting-analytics/fetching-bulk-analytics/#example-usage

So I was trying to use the stream direct upload via TUS and the endpoint started returning this error I thought this was strange as I only have about 20 vids on my dashboard with only like 10 of them having videos uploaded all shorter than 10 mins So I checked on Cloudflare and it says i'm using 1100 mins, but I counted all the mins on all the videos I have uploaded and it comes out at 87.25 mins, Which Is a long shot away from 1100 mins, So whats gone on here?

So I ran a script to loop over all videos pending an upload and delete them and my capacity dropped down to 87 mins How is a video pending an upload using storage if nothing has actually been uploaded yet?? This seems like a major bug that should be investigated

Yeah, so I was at 87 mins, I sent this request Now I'm at 327 mins Before: After:

So some further investigation I did a Direct Upload without the TUS stuff and it so just /stream/direct_upload endpoint, And that also increases the storage usage even with nothing being uploaded??

Why is an empty video thats pending upload using storage? also, the direct_upload one uses less storage than the tus one?

Hey there, hopefully I can clarify this a bit. Both TUS and direct-creator upload allocate a certain amount of storage space for an upload. For TUS, we allocate that space since it's a resumable protocol and the upload can be interrupted and resumed later- we want to ensure we maintain storage for the upload in that situation. For direct-creator upload, customers want to ensure the link they provide to their end-user allows for the upload, and they must specify the amount of storage they want to allocate with the

maxDurationSeconds

field in the data. These uploads in

pending

state will count against the total storage quota for a certain amount of time (detailed below). If using direct-user upload method, the storage space specified with

maxDurationSeconds

is held for a default amount of time of 30 minutes but can be held up to 6 hours if desired. You can also set it to expire as quickly as 2 minutes in the future. This is done with the

expiry

field. I believe the default allocated amount of storage held for a TUS upload is for a 4 hour video, which is likely more time than the value you’ve sent with

maxDurationSeconds

, so that hopefully explains the discrepancy. Also, TUS will wait for an upload to appear for up to a day, where direct-user upload defaults to 30 minutes before no longer reserving the storage space. It might be worth avoiding this situation by uploading via link instead: https://developers.cloudflare.com/stream/uploading-videos/upload-via-link/

This makes a lot more sense to me now thanks It had tripped me up based of the fact that I was getting the reached storage capacity error with like barely 80 mins used Our solution has our staff upload videos which then get attached to an object, and I have a background task that runs and cleans up pending videos so there isn't too many hanging around, I was doing this with the original direct-creator uploads which was fine, Until someone wanted to upload a video that was 400MB and I realised on the documentation that 200MB is the limit for that so I had to change over to using TUS (it says recommended for over 200MB but is technically required so that should change) We would have used the upload via link, however that requires someone to upload the video somewhere first then drop the link which seemed counter intuitive and isn't really an option for our use case I'll mess around with the

maxDurationSeconds

and the

expiry

option and see what happens, Thanks for the info, I assumed that it was reserving space but due to it being billed on minutes stored I didn't think that would be the case as wouldn't this lead to false billing in some circumstances where you are billed for reserved space that wasn't actually used?

So just from quick testing, passing the

maxDurationSeconds

option in the data makes zero difference and it still claims 240 mins of storage space even when passing it at a max duration of 60 seconds

Oh gosh, you’re right. I’m sorry, I provided you the wrong info - to specify the

maxDurationSeconds

for a TUS direct user upload, it needs to be sent as a header, like so:

'Upload-Metadata: maxDurationSeconds NjAw

where NjAw is the base64 encoded value for “600” (or 10 minutes), not in the request body like I previously suggested https://developers.cloudflare.com/stream/uploading-videos/direct-creator-uploads/#upload-metadata-header-syntax. I totally understand that the storage capacity error is confusing when you haven’t actually uploaded many videos, and I think your experience shows we need to do a lot to clarify this in our docs. We really appreciate your feedback here. Please let me know if you hit on any more friction, but hopefully you’ll be sorted out now!

I had hit a hitch with TUS uploads but I think i've figured it out, was getting CORS errors but after reading the forums it appears that I need to change my logic What I was doing was generating the upload URL in the background and storing the ID and url then serving the URL to tus client But I have to do that request to generate direct user URL when the user uploads the file to avoid the CORS error rather than doing it early

I'm also using the Cloudflare Images along side stream to manage thumbnails for the videos we upload, to be honest this is for a very small niche little feature but it's interesting how Stream manages this, TUS uploads are the only unclear thing in the documentation at the moment that has taken more digging Other than this Stream has worked very well for me and I was quickly able to build a little wrapper around video uploads with direct creator upload (not using tus)

Nice! Yeah TUS is an... interesting protocol.

In case it's helpful, there's also a thumbnail API for stream - you can use it to generate different thumbnails https://developers.cloudflare.com/stream/viewing-videos/displaying-thumbnails/

The thumbnail doesn't actually occur in the video anywhere, Its more like a friendly thumbnail

ah ok, if it's not in the video, then you're on the right track doing it another way

I'm actually using stream for the sake of embedding videos in a URL when it's sent to discord so I upload to stream, enable mp4 downloads then I move on

Our use case as a knowledgebase has us linking articles regularly via Discord so if it has a video on it we wanted it embeded in Discord which was another challenge and Stream defiantly made it easy just got a little stuck along the way Thanks for the advice / help nice to have some clarification on this

Very cool. Happy to help, and it's always neat hearing how the product is being used. We'll make some updates on our end to clarify in the docs so others don't hit on the same issue. Cheers!

Any idea on why this is happening?

It would appear my resumable uploads are not very resumable

hmm let's see

oops, keep forgetting to make this a threaded response- please see answer below!

I found it:

unexpected status received from storage: 400; body: Failed to parse Content-Range header

Yeah, I still get the same error, I have no idea what I'm actually doing wrong to be honest after reading over the documentation for TUS uploads I'm a bit stuck Copied example from the linked Codepen just minorly adapted It calls to my url which has this logic Essentially I just check if that article exists, if it does I check if I have in my cache the last request to Cloudflare to generate the URL and serve that back if I do, If I don't I go to cloudflare, make the request then store against the article itself the stream id and the video upload url then return all the headers from the request to cloudflare. It requests to my URL and redirects which all looks cool, but then after the first chunk, it tries to upload the same chunk again I think then Cloudflare appears to be giving an error because that chunk has already been uploaded? This is very likely just an issue with my code but I have no idea what to change here, The TUS guide you guys have (https://developers.cloudflare.com/stream/uploading-videos/upload-video-file/#docs-content) is pretty nice, but it's more for regular uploads with TUS so they go direct to the cloudflare API

/stream

endpoint which I can't do for direct creator uploads. I've had a scan over the forums and Can't really find anyone else with the same issue so I'm a bit stuck any ideas would be appreciated