ewh

ewh

Hi,

I am using the streaming upload API. According to the docs, the PUT should be sent to the endpoint specifying content-length and content-type. The video file data should be streamed as part of that PUT. This approach generally works fine.

However, instead of using a single PUT, would it be possible to break the streaming process into multiple PUT calls using the content-range header? According to the docs, it looks like the content-range header is mentioned while discussing the exception event that not all data was transferred in the first PUT operation and that the content-range header may be sent to resume the original transfer.

My question: Can the content-range header be used in the first PUT to logically specify that we would like to send only a portion of the total data in the first PUT? For example, on the first PUT, do this:
content-range: 0-99/1000
content-length: 100

Thanks!

ewh

ewh

Hi Brad,

Thanks for the prompt response!

This approach seems to fail. My approach is to PUT n bytes. Verify what was written. PUT n bytes. Verify what was written. ... Do this until the video file has been entirely ingested.

After each PUT operation, I verify the uploaded file so far (using "Content-Range: bytes */*"). It always returns "Range: bytes=0-n", where "n" is the number of bytes I wrote on my last PUT. Somehow, each PUT seems to cause Vimeo to my previous PUT operations. Vimeo only stores my most recently written chunk. Is there any way I can get Vimeo to let me use the content-range header for partial writes, without discarding my previously written chunks?

Thanks!

ewh

ewh

Hi Brad,

I also have a question about the indexing of the byte number for the Content-Range header. Content-Range is 0-based, right?

The upload docs have sample code which does this: "Content-Range: bytes 1001-339108/339108". (This is to resume an upload.) Since there are 339108 total bytes in the file, wouldn't the code look like "bytes 1001-339107/339108", since the last byte of the file would be byte 339107, instead of 339108.

Thanks!

Brad Dougherty

Brad Dougherty Staff

Yeah, the docs are incorrect. It should be 339107.

So if you were uploading a 1500 byte file in 500 byte chunks, the first call would have the full Content-Length, and subsequent calls would have the following Content-Range headers:

Content-Range: bytes 500-999/1500 Content-Range: bytes 1000-1499/1500

exlunch

exlunch

Hello Brad.

Vimeo only stores my most recently written chunk.
Is there any way I can get Vimeo to let me use the content-range header for partial writes, without discarding my previously written chunks?

this is ewh''s question, and I also meet same problem using upload api.

could you please tell us about this issue?

-----edited-----
I found i missed "bytes" words at Content-Range.

ewh

ewh

Hi Brad,

For the first transfer, is the suggestion to send 500 bytes, but set a Content-Length of 1500? This seems to cause my HTTP library to hang/block on the first transfer attempt waiting for more data. The transfer eventually times out.

After the first transfer request times out, I query Vimeo (using Content-Range: bytes */*) to see what has been written. After the first transfer, Vimeo returns that the correct amount of data has been transferred. However, on each of the subsequent requests, Vimeo seems to be dropping all the previous transfers just as before.

Am I correctly following your suggestion?

Thanks!

Brad Dougherty

Brad Dougherty Staff

That was just an example. You can transfer in whatever size you want. Just make sure that you're passing the full content length of the file.

GUI Leinster Branch

GUI Leinster Branch PRO

Since I think I just got this working myself, I'll chip in my 2 pence worth (!): The example in the docs misled me with the range 0-1000. This doesn't mean 1000 bytes, it's 1001. The HTTP Content-Range header is made of two *zero-based* byte indeces plus the *full* length. I'd have got it quicker if the example used 0-999 to represent a 1000 byte chunk. my C# code for the header looks like this:

request.Headers.Add("Content-Range", string.Format("bytes {0}-{1}/{2}", offset, numBytes - 1, numBytes));

...where offset if the byte to pick up from, i.e., the last byte verified (which is a zero based index) *plus one*.

The docs say the verify request should come back with the *size* of you file - but this is not the case - it will be *one less* than your file size because it is the last byte index written.

:o)

GUI Leinster Branch

GUI Leinster Branch PRO

...and as Brad suggests - transfer as much as you want, i.e. the whole lot - but put an error trap round the request so you can try again, from the point it failed (using verify request) - until you've uploaded the whole lot - or until you've tried more than a reasonable number of times.

I think it would be clearer for people like me (!) if the docs made it clear where and if they're referring to the zero-based index of a byte, rather that the byte number.

(btw - I'm just posting this in case someone finds it useful - I would have!)

ViperMed

ViperMed Plus

Please can someone help me to upload a video through streaming? I want to upload the video from my browser and i dont find exaples of code. thanks a lot!!!

Dean Humphreys

Dean Humphreys

Hi,

I am having the same problem as ewh with the "Content-Range" header. I am using javascript to PUT videos to the Vimeo endpoint. I get an upload ticket and deal with the initialising and completion of the upload via php on another server. All the javascript does is PUT the video data to an endpoint.

My client has an unreliable internet connection and I am therefore building a resumable uploader that tries to auto resume.

What I have noticed is that if I remove the "Content-Range" header and set my chunk size to bigger than the uploading video, it uploads correctly. As soon as I add the header things go wrong.
I understand that the header should be in the form "Content-Range": "bytes 1001-4999/5000" but this causes issues for some reason. When I use this format, chrome doesn't send the "Content-Length" header and the request fails. FF send the header, but fails as well.

I have uploaded a test version below. The headers are being added on ln 121 of autoUploader.js

Thanks.
Dean

Links: test.paperjet.info/auto_uploader/, test.paperjet.info/auto_uploader.zip

This conversation is missing your voice. Please join Vimeo or log in.