It's a little odd that they elected to invent their own way of requesting just a range of bytes in a file. It's built into HTTP: https://tools.ietf.org/html/rfc7233
Perhaps it mitigates against proxies stripping the headers, or it simplifies caching.
One of many reasons to use HTTPS: prevent tampering with your requests and responses.
I find it particularly telling that switching to HTTPS caused many streaming errors to mysteriously vanish, and I suspect ISP / proxy tampering to be part of the cause. I'd love to know more about what their engineers saw though.
Edit: not sure what format they are using, probably several depending on the client... But one url per chunk makes sense for multiple delivery formats as well.
The formats that send time ranges instead of bytes ranges are the worst. In that case the server/cdn has to retrieve & read the manifest, decode time indexes to fragments/chunks/ranges, and then return the appropriate byte stream to the player. This also means you cant cache based on the URI plus query string!
Source: ive worked at both ISPs and CDNs supporting streaming content
Yes, see http://stackoverflow.com/questions/15561508/xmlhttprequest-2...
> Can you set them from random video player SDKs?
Good point, probably not.