How do they do it on this website?
The link above corresponds to a livestreaming site for Spanish TV.
It does indeed use IPFS, so I guess it is not spam to link to it 
As far as I can see, video chunks addressed by CID are retrieved from a Pinata gateway.
1 Like
Yep, they use HLS for streaming video chunks from IPFS Gateway, which from the HLS point of view is just an HTTP server.
To learn more, see:
- HTTP Live Streaming - Wikipedia
- https://www.cloudflare.com/learning/video/what-is-http-live-streaming
IPFS has been used for HLS streaming since very early days, for example the Our Networks 2018 conference in Toronto was streamed this way, you can find prior art at:
The [server] pulls that RTMP stream, encodes ts chunks in a live m3u8 file using ffmpeg, then IPFS adds and pins those files and uses IPNS to publish the m3u8 to its node ID. The built-in ipfs-http gateway allow those content to be accessed via HTTP, which is what the embedded player on the website will use.
Hi, this is very interesting.
But I understand that you need your own node, or a service like Pinata to serve the content.
In the tests I have been able to perform, if I use a public gateway to serve the .ts fragments, it does not work because it takes several seconds to propagate after making the pin.
With Pinata it works perfectly, and with my own node as well.
However, if I use my own node to serve the .ts all the streaming bandwidth traffic will go through my node, so I would not have the decentralized advantages of IPFS.
Or is there another solution?
You’ve more or less answered the question: one will not have good time with one IPFS node, DHT and freeloading on free public goods gateways. Having more than one source of data and fast content routing is what makes content-addressing in live streaming context worthwhile.
For IPFS deployment to make sense, one should to architect app/service to replicate stream to multiple content providers as fast as possible. Using public gateways as a “free CDN” is a dead end – users are not benefiting from content-addressing much, gateways are provided as best-effort, and growing viewer base is not increasing resiliency of the live stream.
One way of approaching this, is to run own node as initial source of data and then pay multiple entities to peer with you (skipping DHT) and pin to them to increase number of sources, they can also run high performance gateway+HTTP CDN for you.
In addition to that you could have the app your every client runs on their machine to also act as an IPFS node that co-hosts the streamed data and use something in addition to DHT for faster content routing and peer discovery (e.g. own delegated routing endpoint (specs), or IPNS over Pubsub (specs, config), or a custom pubsub-based solution.
Building blocks are there, but the defaults in software like Kubo/Boxo/Helia are not tuned towards live streaming use case, so you need to adjust / build what is missing.