Closed chrishobcroft closed 3 months ago
One thing that's cool about recording to Swarm or IPFS is that no matter how many people do it, the data won't need to be copied or stored twice.
Implementation wise, this should be low hanging fruit at the media server layer since the files are already being temporarily written to disk anyway. I think if we add a ?writeToSwarm=true
or ?writeToIPFS=true
flag to the rtmp interface, then the node could probably do this at the completion of the stream and report the hash back to the user on the command line or local API call.
At the player level, yes we should be able to stream the content into IPFS or Swarm if the user hits the big red record button.
Understood.
And perhaps a "record to local storage" option in the player might be some "low hanging fruit" which takes a step towards a slightly more consumer-focussed option which the majority might more likely understand, without them needing to comprehend what decentralised storage means.
It reminds me a little bit of the days when you had a VHS recorder, which allowed you to record whatever you were watching on the TV at the time #retro
The current implementation of the Livepeer Stream Viewer exists at this URL. This allows simple viewing of a stream based on a Stream ID.
This current implementation does not allow recording of content, for viewers to watch / edit / post-produce / release after the livestream has happened.
As a result, it is less attractive for live video content creators to use for broadcasting, as unless they are recording the content at source (which is a CPU intensive and Disk I/O intensive operation), then their creation is lost forever.
This project seeks to evolve the existing Livepeer Stream Viewer into a Livepeer Stream Viewer and Recorder, by adding a simple "record" button, to allow a user to record to a local storage device.
Further iterations could seek to record to a remote storage device such as Swarm / IPFS / Storj.