livepeer / grants

⚠️ DEPRECATED ⚠️ Please visit the new homepage at https://livepeer.notion.site/Livepeer-Grants-Program-f91071b5030d4c31ad4dd08e7c026526
44 stars 7 forks source link

[Open LN Grant]: Write live and recorded m3u8 playlists to S3 storage #157

Closed eliteprox closed 1 year ago

eliteprox commented 1 year ago

Please describe your project. Start with the need or problem you are trying to solve with this project. Describe why your solution is going to adequately solve this problem.

This proposal extends Livepeer’s video storage & playback S3 implementation to include m3u8 playlists.

As a broadcaster, I have an option of recording live videos to an S3 storage bucket. Common S3 storage providers integrate Edge caching options with their buckets, allowing a developer to easily serve up files with global CDN coverage. However, Livepeer’s recording functionality only stores the playlists in a proprietary JSON format, requiring the segments to be pulled back through an active broadcaster node to be replayed, leaving the HLS segments un-usable outside the context of Livepeer.

Our solution is to introduce an option to store playlists in m3u8 format on S3 storage, enabling live and recorded playback directly from an S3 bucket’s CDN edge. This enables developers to more quickly integrate CDN and S3 video playback with emerging Ethereum ecosystem partners like Swarm and StorJ.

The grant also includes documentation of the entire S3 object storage functionality on docs.livepeer.

Link to public GitHub repo (if applicable)

https://github.com/eliteprox/go-livepeer/tree/develop-swarmstorage

Link to demo website (if applicable)

https://youtu.be/3-8VI58Z1u4

Please describe in more detail why this proposal is valuable for the Livepeer ecosystem

This new storage/playback capability unlocks increased flexibility for developers building on the Livepeer network, while providing creators and broadcasters complete ownership of their content in a standard and reusable format.

Our proposal suggests including cli flags to enable the new m3u8 playlist recording functionality; thus, we need to work with the core team to ensure any new features we introduce don’t break existing functionality.

Please describe in details what your final deliverable for this project will be.

Once completed, new cli flags will be made available to broadcasters, enabling them to livestream and record in the m3u8 format. Once saved, videos can be played back at any time and the holder of those files will have complete ownership of their content.

Please break up your development work into a clear set of milestones

Phase 1 - March 2023 - May 2023 - 40 hours - $5,000 ($125/hr) Research: Identify current recording/storage capabilities in go-livepeer to evaluate the problem and establish groundwork for a solution. – 15 hours ($1,875) @eliteprox (complete) Foundation: Build dev environment and setup infrastructure for testing. – 3 hours ($375) @eliteprox (complete)

Phase 2 - June 2023 - 45 hours - $5,000 ($125/hr) Finalize code. – 20 hours ($1,875) @eliteprox

Comprehensive testing. - 18 hours ($2,250) @eliteprox

Phase 3 - July 2023 - 10 hours - $1,250 ($125/hr) Document: Add a new page/section to Livepeer’s documentation that acts as an overview of the recording flags, how to use them, and what the use case is. - 4 hours ($500)

Community watercooler 1 - pre-release - 3 hours ($375) @eliteprox

Community watercooler 2 - post-release. - 3 hours ($375) @eliteprox

Sum up the total requested budget across all milestones, and include that figure here. Also, please include a budget breakdown to specify how you are planning to spend these funds.

The total requested budget is $11,875 and is broken down based on the cumulative work described in phases 1 through 3.

Specify your team's long-term plans to maintain this software and upgrade it over time

Once merged, maintenance and upgrades become a collaborative effort from this projects team, Livepeer’s greater community and Livepeer’s core team.

Please describe (in words) your team's relevant experience, and why you think you are the right team to build this project. You can cite your team's prior experience in similar domains, doing similar dev work, individual team members' backgrounds, etc.

The team behind this project are all active members of Livepeer’s Orchestrator community and are committed to delivering a robust, alternative option for recording/playing back video on the network.

John @eliteprox - https://github.com/eliteprox

Mike Zupper @mikezupper - https://github.com/mikezupper

Ben @AuthorityNull - https://github.com/AuthorityNull

How did you learn about the Livepeer Grants Program?

The team has been actively participating in Livepeer’s network and the grants program since 2021.

Was this project started at a hackathon or another web3 event? Which one?

This project was not started at a hackathon or web3 event, although it may be presented at one.

Please include any additional information that you think would be useful in helping us to evaluate your proposal.

We know this project will allow for developers and creators to unlock much needed enhancements when recording or playing back video using Livepeer and we hope the grants committee sees the benefit as we do. Please reach out with any questions or concerns.

This grant will help support the integration of Livepeer with Swarm for CDN functionality. See https://github.com/livepeer/Grant-Program/issues/154

mikezupper commented 1 year ago

An absolute game changer. This is a fundamental building block key to the success of a decentralized media platform. I can’t wait to use this feature within my Xode.Live media stack

hansy commented 1 year ago

Thanks for applying @eliteprox! We'll get back to you within 2-4 weeks with a funding decision!

hansy commented 1 year ago

Hey @eliteprox, we'd love to fund this! Let's chat next week to iron out some of the milestone and deliverable details. I'm @hansy_ on Discord.

leszko commented 1 year ago

This feature could be helpful for go-livepeer. However, let me provide some additional context.

Having this in mind, I think we should think if we should focus on supporting recording in go-livepeer (and to make it reliable, we probably need some more work than this GH Issue) or make the recording deprecated and decide that the recording should be done at source (like it's done in Catalyst).

CC: @thomshutt

eliteprox commented 1 year ago

Hey @leszko, thanks for the info on catalyst and for evaluating this. I noticed the playback in go-livepeer for recordings was not working. I found some inconsistencies in the /recordings endpoint on the broadcaster, and it didn't seem to be feature complete. It appears to be checking for json playlists in the wrong location(s). It is comforting to know catalyst isn't dependent on any of this, so we can build without that dependency if we want to.

My goal was to make it so that an S3 edge cache can be used for playback of live and recorded video. In this way, the playback doesn't involve go-livepeer at all. I was planning to leave the /recordings endpoint on the broadcaster as-is. However, I can work on fixing that or deprecating it. The recordings endpoint does provide for AuthWebhook authentication which would be important for some use cases versus the S3 solution. I think supporting both is ideal. What do you think? I'm available for a call today to discuss the scope in more detail.

I have completed successful tests of live streaming and recorded playback over S3 and CDN cache. I think this feature as I have developed it so far is reliable. A 2nd phase could involve moving the recording uploads to the orchestrator side, which would provide a more authentic decentralized workflow for video distribution and recording.

leszko commented 1 year ago

I'm leaning more towards making recording in go-livepeer deprecated. The thing is that, in general, the fewer features we have in go-livepeer, the better. And recording can be easily supported from outside.

The recordings endpoint does provide for AuthWebhook authentication which would be important for some use cases versus the S3 solution. I think supporting both is ideal. What do you think? I'm available for a call today to discuss the scope in more detail.

Sorry, I couldn't join the call yesterday, but could you describe the use cases in which you need /recordings and AuthWebhook? As mentioned, unless we do have a strong use case for /recordings I'd deprecate it (and remove it in the future).

eliteprox commented 1 year ago

The broadcaster /recordings endpoint is used for playback of recorded video in go-livepeer. It is not needed for the S3 recording feature that I've built since playback is done from S3/Edge without the broadcaster.

/recordings integrates with authwebhook to authenticate playback of video. I wasn't able to get this endpoint to work because it appears to be looking for playlists in the wrong directory of object storage. When I developed the playlists for S3 storage, I used the same code and and repurposed it to serialize/upload the m3u8 playlists at the end of the stream.

I wasn't able to join a call this week either, but I'd like to set something up. I will configure catalyst for a broadcaster node to become more familiar with the go forward solution.

I think a true value add would be to find a way to implement recording upload from the orchestrator rather than catalyst or livepeer broadcaster. This would allow re-use of this work and build towards a decentralized implementation of recording.

github-actions[bot] commented 1 year ago

This issue has been marked as stale with no activity. It will close in 7 days.

github-actions[bot] commented 1 year ago

This issue has been automatically closed.