Does storj even work for VIDEO STREAMING?

I’m saying it’s S3, not Youtube. I’m not saying it can’t be used to build youtube on top of it.

Then I guess it’s just an attitude problem, my friend. If you want people to help you out with this in more detail, I suggest changing the way you ask for help. As I wouldn’t have responded to begin with if @jammerdan didn’t mention me. There are a lot of helpful people on this forum with more knowledge about the specific use case than me, but you run a great chance of alienating them before they can respond. It doesn’t help that you didn’t actually respond to any of the helpful parts of my message, but chose to complain more. So I’m out. Hopefully others will be a little more patient.

1 Like

Hello @what,
Welcome to the forum!

The map on preview is currently disabled and should be fixed soon.

As many already mentioned, you file is actually split to pieces and distributed across the globe.
So if you build your transcoding site/application, you will download pieces from different nodes in parallel to reconstruct the file. If your video is already optimized for streaming (so it starts to play without downloading the whole file first), it will be played even in the preview from our linksahring service.
But yes, the storage platform is not designed to transcode video without additional software on your end.
The browser and OS also plays role, they should support the video format to play it as a stream.

4 Likes

Thanks Alexey, but transcoding is not what I have been talking about. I know how video delivery works very well. :+1: I know how to make different CDN’s work. I didn’t actually say transcoding, because I’ve tried webm, mp4, AV1 on storj, and these deliver fine, but delivery via fragments & piecing together, as you say, is done by the native browser player or in some steps is done by a server.

A good start is here to understand how streaming media works.

I have transcoded, and uploaded a m3u8 playlist in a folder, it doesn’t deliver as Storj delivers singular files natively.

Again, not using Storj for transcoding.

HLS formats in a folder will need a serverless iteration or function or server, which will increase latency of delivery greatly. Therefore, Storj is not a good video delivery streaming medium.

I was looking at this page for a bit and I think most can be done with Storj. If you use uplink you can set the appropriate content type when uploading your files using --content-type. You can also use that to create the appropriate access grant with all the right access rights. So I think setting the cross origin policy is what remains. I did see some mention of CORS on the github, but couldn’t find anything about how to set that up correctly. Perhaps a Storjling could help you out there.

You could avoid the CORS issues by hosting a static website on Storj. Even if just for testing purposes. Hosting a Static Website - Storj Docs

There is some info on how to set content type in this post: Static website: index.html does not open in browser, instead it downloads - #7 by sean

And creating an appropriate access grant is mentioned on the first link I posted, though it doesn’t go into details on access permissions. I believe it’s read only by default, but you might want to look into other settings with ./uplink share --help

Ps. I get why your previous post was flagged. But I also understand that the post limit can be annoying and you had a legitimate reason to keep posting. I’m not sure if the limit can be lifted on your original account, but that would be nice if it could. I never had the intention to alienate you with my previous posts, just to redirect the conversation into something more productive. I hope this helps a little and you can let us know which parts you get stuck on trying to implement this on Storj.

3 Likes

As Storj for streaming is indeed mentioned a lot, maybe it is really worth it to create some tutorial how it is setup for such a use case.

1 Like

The way I understand it from my short time playing with uplink is this:

There are three ways of using Storj:

  1. You store data on it, you retrieve the data from it using uplink or whatever. Basically using it like a nfs mount (but a bit more complicated). In this case you save storage (do not need to store the data locally), but use up double bandwidth (depending on how the ISP counts it) since your server will download the data from Storj and then send it to the client. This also would result in higher latency.
  2. You store data on it, but use linkshare so the client can get the data himself. This way you do not need to use up your own bandwidth (instead a Storj server does the download-upload), but are limited in what can be done with this, HLS might be a problem here and latency is still high.
  3. The client can support the uplink protocol and take data from Storj directly. This would have the lowest latency (probably still quite high compared to a regular http server) and highest throughput, but I do not know if there is a version of uplink that can run inside a browser and if there is any video player that can take data from Storj. I’m sure that no STBs can do that.

Correct me if I am wrong (I probably am), but to me it looks that unless it is possible to get option 3, Storj is a bit useless for storing video (might as well just add some HDDs to the server and get higher performance).

Here is a sample video encoded using Livepeer, stored, and streamed from Storj via the live peer web player.

https://lvpr.tv/?url=https://link.storjshare.io/raw/jwjfgdxkvmfgngsgitii6pny62za/demo-bucket/samplevideo/hls/index.m3u8

Here is the wonderful lab they did with us.

@what if you are interested in enhancing our LinkShare to play HLS let me know.

6 Likes

Interesting, that link is HLS (but with only one segment). It takes about 1 second to download the first manifest, 1 second to download the second one and 1.6-1.8 seconds to get the 8 second long segment, out of which 0.2 seconds is spent downloading it and the rest is waiting).

The 1-1.4 second latency is a bit bad, since if the client has a slow connection (barely good enough to download the segment in time) it will make it worse.

Other than that, it seems good enough for HLS, maybe even doing live streams, which could then be converted to recordings, as long as there is no need for dynamically generated manifests (some types of time shifting etc).
There is probably no authorization (I assume there is no way to limit access by IP etc).

I got it working. You need to add RAW after the link.storjshare.io/ lol :sunglasses: I picked that up in the link you sent from lvpr.tv

Here it is working directly after an upload from the browser

Don’t sweat it mate. Water off a duck’s back. I only really attacked (compared) the product, not the man. And the product is making claims of being useful for video, which is an extremely tall order measured in microseconds, tuned on C++, Go & Rust, made using custom ASIC’s in Googles case, consistently a loss leader & constantly a moving target.

I honestly don’t know but, if we’re real frank, a finely tuned server with a very specific CPU and a RAID setup via a massive data pipe is going to fly much faster vs small chunks in distributed areas.

Storj makes much more sense in storage and delivery of things such as distros or software distribution, as that is something you just don’t care if it’s 100ms or 1 second to start appearing in google downloads manager.

If you add a CDN in front of Storj, then the difference is not noticable, but at that point, it’s just acting as a object store.

Just to comment on performance, I don’t know anything about tuning Storj, but from anything I’ve seen it’s certainly not replacing a highly distributed & ultimately fine tuned CDN such as Cloudflare.

It just is what it is in video.

Screenshot 2023-01-12 at 10.49.40 am

This is from 2012, imagine what it is now, probably 50-100ms. “Online viewers ditch slow-loading video after 2 seconds”

That is correct, delivering video is measured in spinning loaders, we make different transcoded sizes for different screens, different codecs for different machines, different bitrates for different segments.

Then it consumes so much more data than anything else that It’s actually not very profitable for a CDN vs delivering a website cache for $9 a month or $25 a month from Cloudflare, they milk the profit on those sites, and probably make next to nothing on Video.

I’ll keep playing, I’ve already tested this behind Cloudflare & set a cache policy to all, it’s obviously MUCH faster, but Cloudflare kicks video delivery from Cache at volume, so that is not an option.

We’re just talking video, is Storj the best for video delivery as noted in the marketing, from what you’ve seen in this thread with loading times & samples, you can certainly make your own conclusions.

Here are some examples of Big Buck Bunny in 4K in MP4 and HLS .ts files. You can see both delivered from storj directly in an independent player. And also a link to cloudflare R2 (which is not a CDN but is distributed in 4-5 main hubs, and performs like S3)

Storj Big Buck Bunny HLS Stream

Screenshot 2023-01-12 at 11.52.13 am

The original Big Buck Bunny in MP4 format on Storj

Cloudflare R2 USA Big Buck Bunny

If you’re reading this after looking at Storj for video. There are use cases where Storj is fine, and some areas where it is not, it mainly comes down to speed & latency that only really a cached hot server can deliver.

Here’s the take aways:

Video delivery for signage (indoor): Yes, it is cached in the browser anyway

Video delivery for outdoor advertising: Yes, it is cached anyway on device

Video delivery for online advertising: No, loading speed is key

Video delivery for pre-roll ads: No, loading speed is key

Video delivery for classrooms or training: Yes, no one will notice the load time

Video delivery for adult content: No, loading time is most important

Video delivery for movies, games, content: No, loading time is most important

Video delivery for mobile: No, latency is most important

Storj, recursive uploads in the browser would be a good idea.

Goes to show, that the 5 upvotes you got couldn’t have been more wrong :crazy_face:, cause I did the work, fixed the issue & displayed why Storj isn’t as good at media streaming as the marketing would say. But it might work very well for a specific type of video delivery & a change in marketing direction on WHICH video delivery is a good fit, would alleviate any criticism.

Look, I don’t want to go back to discussing that now that the topic is about meaningful content, but I’m happy to have been wrong in this case. It’s just unusual to see someone complain and not give details about where they get stuck or what they tried in addition to inaccuracies about how storj works (like always downloading the whole file or not being able to handle video streams from multiple files) and then see them actually do the work. I guess those up votes agreed with that initial impression. Unfortunately as with any forum, some people just come around to complain and bash. As I mentioned before, it was an impression based on attitude, not knowledge.

But lets forget about that now. I’m glad you got it working and it’s good to see some numbers. Time to first byte is definitely a downside. Which is kind of inherent to how the network works. And the gateway puts an additional step inbetween as well. You’d already see better time to first byte performance when using uplink, but unfortunately there is no browser compatible uplink implementation yet. And while building that has been discussed, the fact that the browser would have to communicate directly with storage nodes would add a whole mess of things to deal with. Like somehow making cross origin resources work with every node and getting them all valid TLS certs. Not impossible, but also not easy. That said, time to first byte is also a main concern for the developers who are always working on improving that performance. But due to the nature of the network it’s unlikely they will ever match fully optimized servers. However, it could be good enough for more use cases after some improvements.

The other side of that is that Storj can be incredibly fast when it comes to throughput. This is where the parallel nature of transfers and lack of congestion on single routes really works in it’s advantage. That’s only useful to a certain point for video streaming though, where fast enough is plenty and anything beyond that no longer useful.

One additional note. It has been discussed that Storj could function more like a CDN by automatically expanding availability of files based on demand. This would increase the number of pieces on the network for each segment and could also be built to ensure availability on nodes in regions where demand is high. This was already part of the original whitepaper as a possible future expansion of the product, but as far as I know this idea so far hasn’t gone beyond a concept description. And I would bet that this is by far the most effective when used with uplink directly, instead of the gateway. Though it would help with both, since the gateway itself is also globally distributed.

I guess you could deliver first few segments from the server and then switch to Storj for the rest of the video (while those segments play, the rest loads), though I am not sure if that is possible with HLS (I usually work with STBs and I’m pretty sure some of them would not like this, but a browser based player may handle it correctly).

This would be useless for short videos, but probably would work for longer ones or a live stream (assuming it is possible to make live stream work with Storj).

The browser will look within a folder to find the playlist, that playlist will then download each .ts file in a line, I wouldn’t recommend using a CDN to load the content and then Storj to load the rest, as the first time to byte of the Storj download will be roughly 1-2 seconds, which means the buffer cache is reset & the whole video could stop it’s download pipeline. You’re also downloading content from say a USA east server, then possibly the content from USA east but not within the same zone, that would be a nightmare to test on the user side. If something went wrong, is it the CDN? Is it Storj? The same is true for RTMP to HLS, DASH, RTSP to whatever, on and on.

TBH, just don’t think this is a very practical business case to use Storj for important video files unless latency/delivery speed isn’t of priority, in that case it works fine. But as a business, in what case isn’t speed/latency important for the cost?

But at hyperscale or at PB scale, Akamai is going to undercut practically anyone in the market. And they have edge nodes practically everywhere that are built for caching & delivering content. Anyway it’s been interesting to test. I think storj is suitable for deliverables. But video, might need more tuning.

Yeah, if the 2 second pause before playing the video is to long and cannot be covered up (by showing an ad or something for those seconds), then I do not see a way to make Storj work. HLS for live stream could be possible, but could also be prone too bugs. HLS for VOD should work OK (other than the pause).

Best would be if it was possible for the client to pull file directly from Storj network as going through the gateway makes it a slower copy of a “real” CDN and loses the performance aspeect of pulling from many nodes at once.

We are doing hundreds of thousands of HD video streams per day now. Plenty of great ideas are being discussed/tested to further reduce time to first byte. The future is bright.

6 Likes

Unfortunately ads are video, and video delivery of ads is probably the most load time specific use case of video, that needs to be ultra fast.

I look forward to seeing it, as if you can make distributed delivery deliver a video file in sub millisecond times from lots of points on earth, then really a tradition CDN will definitely have an issue keeping up.

I’m going to keep playing with storj for video & see if there are creative ways such as @Pentium100 has said by using two systems, but I found out today the CDN from cloudflare is free with R2 which is just $0.015/GB with free egress using the CDN cache, that’s truly a very good deal.

ads are also short, which means they do not take up a lot of space and could be stored on the server.

Only for content that is almost all pure html files. The moment Cloudflare notices that you’re using their CDN for images, videos and other non-text files, they’ll suspend you. See the point 2.8. in their subscription agreement (emphasis mine):

2.8 Limitation on Serving Non-HTML Content

The Services are offered primarily as a platform to cache and serve web pages and websites. Unless explicitly included as part of a Paid Service purchased by you, you agree to use the Services solely for the purpose of (i) serving web pages as viewed through a web browser or other functionally equivalent applications, including rendering Hypertext Markup Language (HTML) or other functional equivalents, and (ii) serving web APIs subject to the restrictions set forth in this Section 2.8. Use of the Services for serving video or a disproportionate percentage of pictures, audio files, or other non-HTML content is prohibited, unless purchased separately as part of a Paid Service or expressly allowed under our Supplemental Terms for a specific Service. If we determine you have breached this Section 2.8, we may immediately suspend or restrict your use of the Services, or limit End User access to certain of your resources through the Services.

1 Like

That is actually true only for their cloud cache product, R2 to CDN is free as R2 is a paid service & has a different TOS.

Unfortunately for CF is most developers still think that their CDN direct TOS is the same.

R2 Developer confirming R2 TOS is different.