that the file isn’t web optimized wouldn’t make it not load… i mean downloading a 6gb file at 10MB/s only takes 10 minutes.
the file in question it’s like it’s not even trying… so either not supported by the web player or something rejects it from even trying…
@will.topping
just try using a standard codec and format for the file you upload, then it should run just fine… something like H264 is the golden standard still that should run on everything.
i’m sure it will work just fine then, if there isn’t an unknown max filesize.
I mean, in theory it could play it if it had infinite bandwidth. It’s just trying its very best to make that happen. In some theoretical future when everyone has 100gbps internet it probably would work just fine.
@SGC Did you read my comment? It’s not about just downloading the file, it’s about having to constantly skip back and forth through the file. In order to play this file it is downloading the same pieces of it over and over again as a result. It’s trying, it really is… it’s just not going to work on any normal connection.
Hmm, doesn’t it need to be cached locally?
If it‘s a 87GB file, the client that wants to play it,also needs to cache the whole file temporarily in order to play it as far as I understood the problem with the non-streamable file formats?
I think it would be a really cool thing, if there are streaming issues, that a customer gets the option to transcode it (via Videocoin) and store the transcoded version alongside with the original on Storj DCS.
But here is the problem of the automatic player option that was built into it. Some customers simply might want to store a movie file without interest in streaming it, some might be interested in streaming it. So may be a stream tag or permission might be helpful to make a disticintion between those different users. For those who want to stream then additional options like transcoding could be offered.
mine sure isn’t it’s all just grayed out without any indication anything is happening.
web optimization its called in handbrake i believe, the scratch / skipping thing
i’m on 800 mbit sync full duplex fiber, with a proxy in front thats like 100gbit.
if i click it and it can run it should run…
I feel like you’re just purposely ignoring all the context I’m giving… I tested this on a local server and it was extremely struggling… it’s not just a matter of having enough speed for the bitrate.
i suppose if its a 87GB file that not so surprising, i suppose web optimizing would make a big difference in that case, hadn’t thought about it that way…
my browser flat out refuses to run it.
so basically you are saying i was right to begin with, it was a codec issue
Well… yes and no. The codec really only defines how the video and audio streams are encoded. The container determines how those tracks are laid out in the file. Though variable bitrate would be a codec setting I guess and that sure doesn’t help. But that combined with the container layout is the real issue.
That said, you can easily make H.265 streaming files if you don’t use variable bitrate and use the right type of container and layout. So there is nothing wrong with the codec itself per se.
web optimizing it would make any size video playable and the correct codec would ensure the web player would work.
so yeah nothing wrong with the codec, just where and how it was used.
maybe i phrased it poorly.
i like that H265 is seeing more usage, it’s an amazing codec.
tho it does demand a lot out of whatever plays it and it would ofc still not work nearly as many places as H264, which was why i suggest that as a general approach that would work in almost all cases.
ofc H265 would be far superior in the cases involving modern hardware and limit internet bandwidth.
and i’m not really that familiar with the internal file structure of video files, aside from what one learns lightly dealing various video tools over the years.
i just try to stick close to the most used types of encoding, since i hate when i move files around between different things and they stop working…
